.NET Framework failed to register Configuration Manager dll’s

I had a recent interesting experience where Configuration Manager 2012 SP1 setup completed successfully however there were problems lurking under the hood.  It was only until I proceeded to configure the environment and add additional roles that these came to light.  Several of the component installations failed, in particular those of the newer roles which require .NET 4.0 and their respective logs showed some very unusual errors I had never, ever, seen before.  The CloudMgr.log was absolutely full of instance creation errors.

At first I put this down to the Windows Server 2008 R2 virtual machine – it was based on an image and provided to me in a bit of a rush and with some history of a power failure/unexpected shutdowns – however a fresh DVD installation of the Operating System resulted in the same errors.  My attention then turned to the ISO media provided on the server that I extracted and performed the installation from – perhaps it was corrupt?  Not quite, but it was the cause of the problem.

The ISO file had been copied up to the server by somebody else over the network and for some reason the server took to marking the file in it’s properties with “This file came from another computer and might be blocked to help protect this computer” and gave me an unblock button.  I hadn’t noticed this and the result was that all of the subsequent extracted files were all marked the same.

windows-server-2012-unblock-file

The problem here is that the regasm.exe utility of .NET Framework 4.0, in it’s default configuration, will not permit the registration of dll’s that it perceives as coming from remote sources such as unc paths.

The answer here is not to proceed with the .config file editing solution offered by the only blog post I found regarding this error, it is simply to ensure that this attribute/property is not applied to any of the files from the Configuration Manager 2012 media before you start installation.  Attempting to patch the installation back together I am sure would be a futile and unsupportable task – there are simply too many possible errors introduced into the installation.  I even found that when you provision site roles on other site systems, the file attribute traveled with the dll’s copied to the remote site system and introduced role issues there.

It’s incredible, how something so random and inert could cause so many issues.

Advertisements

About madluka

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: