Turn off IE ESC, a very unusual work around to Error 10016 on Windows 2008 R2

You will find countless posts on Internet about the Error messages 10016 on Windows 2008 R2, mostly related to the installation of Sharepoint and/or the IIS WAMREG application.

In example Wictor Wilén has published one of such posts, but you may find truly find tens of similar posts, even KBs on Microsoft support website all pointing you to try to change registry settings or DCOM configurations.

Today, for the previous 8 hours, I dealt with this very same error message 10016, I was basically trying to instance an object from some server side vbscript in an asp page, and there was no way that I was able to make it work.

To make it clear, I was just trying with absolute no joy to execute something like this:

<%
    Set MyObject = Server.CreateObject("MyCOMComponent.MyClass.1")
%>

I was only able to get something like this on the system event log:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
and APPID
{YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY}
to the user COMPANY\myUser SID (S-Z-Z-ZZ-ZZZZZZZZZZ-ZZZZZZZZZ-ZZZZZZZZZZ-ZZZZ) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

I truly tried everything I found on the Internet related to 10016, and much more I managed to conceive myself, I even picked the brain of 4 of my brilliant officemates, but we got nowhere.

I was almost tempted to give up for the day, when serendipity struck gold: instead of trying to browse the asp page from the browser on the server, I tried with the browser on my workstation, and everything worked absolutely fine.

I had just to turn off the IE ESC (Internet Explorer Enhanced Security Configuration) from the Security Information summary on Server Manager, to see the asp page starting to work also on the server.

Amazingly, it seems that turning on the IE ESC is preventing server side vbscript from executing correctly on Windows Server 2008 R2.

The "one too many installed .Net framework" time bomb

Today, after installing "Microsoft .NET Framework 3.5 Service Pack 1 and .NET Framework 3.5 Family Update (KB951847) x86", the Microsoft Internet Explorer 7 in my machine was broken.

I wasn't able to start various web applications anymore.

Also, when trying to check the about screen, I was getting an "Not enough storage is available to complete this operation" error.

Thanks to this, I found out why, and I was able to work that around.

It seems that for each installed .Net framework an empty registry value is added on the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform.
Now, it seems that some Microsoft function is getting all the names of those values, it is concatenating them on a big string, adding 2 characters per name, and if the length of this string exceed 209, IE will stop to work properly.

The work around was as suggested to remove as much names as to shorten that string to a length lesser than 209 characters (counting the 2 already spent for each name!).

In my case, I was having the following names:

.NET CLR 1.1.4322
InfoPath.1
.NET CLR 2.0.50727
FDM
.NET CLR 3.0.04506.30
.NET CLR 3.0.04506.648
.NET CLR 3.5.21022
.NET CLR 3.0.4506.2152
.NET CLR 3.5.30729
MS-RTC LM 8
OfficeLiveConnector.1.3
OfficeLivePatch.0.0

They would result on 226 characters (202 + 2*12), which is 17 characters too much. I removed the last value, and everything started to work again I could have removed also just every character after the first 2 ("Of"), and everything would have worked as well, but if we add anything more, IE breaks.

In general, if we find in that key a single value with a name of 207 characters, as such (obviously unbroken):

12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
123456

With this IE7 will work, add a single character more, and IE7 will break.

Now, until Microsoft doesn't properly fix it, the issue at stake here is if this happen, which names(s) should we remove?
On my workstation, for now I removed OfficeLivePatch.0.0, but it may be needed by some other application, so I think we should exercise good sense, and trying to figure out case by case which version of .Net is less probable to be used on a given workstation/server.