Windows Search and Xml files

When you try to use Windows Search on the contents of xml files, you will find that not all text of an xml file is indexed.

For example, if you have the following xml file:

<myelement attrib="myattrib">
myelementtext
</myelement>

You will be able to find it by searching for “myelementext”, but searching on any of the terms below will fail

• <myelement
• "<myelement"
• \<myelement
• "\<myelement"
• %myelement
• ?myelement
• [<]myelement
• xpath:\\myelement

Apparently, you can only search over the prefix of the term (ex: "test*"). With that said, the XML filter only outputs text terms within the XML document. (in our example only the terms myattrib and myelement are indexed). The other elements are attributes that are not typically user facing.

To have all text in an XML file indexed, we need to assign XML extension to use the plain text filter.
This is (currently) not possible with the UI, so you will need to modify the registry.

Navigate to HKEY_CLASSES_ROOT\.xml\PersistentHandler and change the default value to {5e941d80-bf96-11cd-b579-08002b30bfeb}

You will have to rebuild the index (Control Panel / Indexing options / Advanced / Rebuild)  to re-index the xml files.

Copy the lines below into a file with a .reg extension and double click to update the registry for you.

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.xml\PersistentHandler]
@="{5e941d80-bf96-11cd-b579-08002b30bfeb}"

To verify that the 'plain text filter' is being used, go to 'Control Panel', 'Indexing Option'. Select Advanced and on the 'File Types' tab, verify that the 'Plain Text Filter' is being used for the 'xml ' extension

Note that you can also have other files (xsl, xslt, xsd, ...) using the plain text filter by modifying the associated registry key

e.g. for xslt

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.xslt\PersistentHandler]
@="{5e941d80-bf96-11cd-b579-08002b30bfeb}"

For info on how to enable windows search in Windows Server 2008 (R2) see: http://blog.sdbonline.com/2012/02/update-windows-search-and-xml-files-on.html

‘no connection’ when trying to view another user’s calendar – free/busy information (exchange 2010)

A while ago, the company I currently work for updated their servers to Exchange 2010. Ever since, I was unable to view other people’s calendar and free/busy information. The only error I got was a 'no connection’ message in the calendar tab.

I was using Outlook 2010 on a computer that was NOT part of the domain.

When searching the internet, I noticed that I wasn’t the only one suffering from this behavior, but I couldn’t find an answer for the problem.

I turned on logging in Outlook (File – Options – Advanced – Enable troubleshooting logging) and found that the log file (%temp%\olkdisc.log) was filled with error from the Autodiscover service)

This led me to this Outlook 2007 article on TechNet which explains the relationship between the Autodiscover service and the Availability service:

The Availability service for Microsoft Exchange Server 2007 provides calendar information for your users. This information is known as free/busy information. The Autodiscover service provides information for the Availability service by locating and providing the external and internal URLs for the Outlook 2007 client. If your Microsoft Office Outlook 2007 users cannot view calendar information for other Outlook 2007 users in your Exchange 2007 environment, the problem may involve a failure in either the Autodiscover service or the Availability service.

The article provides the following steps to test the Autodiscover service (the article is for Outlook 2007, but the steps are the same for Outlook 2010):

1. While Outlook 2007 is running, hold down the CTRL key, right-click the Outlook icon in the notification area, and then select Test E-mail AutoConfiguration.
2. Verify that the correct e-mail address is in the box next to E-mail Address.
3. Clear the check boxes next to Use Guessmart and Secure Guessmart Authentication.
4. On the Test E-mail AutoConfiguration page, verify that the check box next to Use AutoDiscover is selected, and then click the Test button.

I my case, the test failed because of the Autodiscover services could not be reached.

As it turned out, the Proxy server could not reach the Autodiscover service. I used Internet Explorer to add the url to the ‘Local Intranet’ zone, so the proxy server would be bypassed and everything worked perfectly.

Reflector Alternatives

Now that reflector is no longer a free tool (see http://www.reflector.net/2011/04/why-we-reversed-some-of-our-reflector-decision/), alternatives are gaining popularity.

2 promising alternatives are ILSpy (http://wiki.sharpdevelop.net/ILSpy.ashx), an open source initiative that initiated after the announcement by Red-Gate, and dotPeek (http://www.jetbrains.com/decompiler/) a free tool by JetBrains, the same people that brought us ReShaper.

IE8 Developer tools opening automatically when opening new tab

Got an annoying issue today. Whenever I opened a new tab in Internet Explorer (IE8), a new instance of the 'Developer tools' would open automatically. Normally, when you close them, they shouldn't reopen again until you explicitly want to.

The result was after opening 6 or 7 tabs, there would also be 6 or 7 instances of the developer tools.

I tried turning the off and closing IE, even rebooting, but they would keep 'popping' up.

Eventually, I managed to get rid of them by doing the following

1. Open the registry editor
2. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IEDevTools
3. Set the value of the key 'Pinned' to '1' (REG_DWORD)
4. Open IE - this loaded the developer tools to, but they were pinned (embedded) in the browser window
5. close the developer tools while embedded

This FINALLY prevented the developer tools from being loaded with every tab I openened.

meh :/

Intranet site is identified as an Internet site when you use an FQDN or an IP address

http://support.microsoft.com/kb/303650/en-us