Share via

System.IO.FileLoadException for System.ServiceModel.dll in SharePoint 2013

  • Article

I came across an interesting situation recently when doing a fresh installation of SharePoint 2013 where once the installation was done no one could access the site - instead there was a tonne of errors in the ULS logs with the below exception:

The given assembly name or codebase, 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel\v4.0_4.0.0.0__b77a5c561934e089\System.ServiceModel.dll', was invalid.

It took a little bit of digging, but in my case this was actually caused by some very strict group policies that were being applied to the servers. When I had a machine with no policies my deployment ran fine - after some additional digging I narrowed it down to this setting specifically:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment - Impersonate a client after authentication

This impersonation right is needed for SharePoint to correctly work with Windows authentication, so to ensure that you environment behaves correctly you need to ensure that the service accounts that are running your application pools are in the list of accounts that are allowed this permission in your policy. Also you need to ensure that your farm account has this as well, as it is the account that will be used to run the application pool for your Central Admin website. In my case as soon as I added a new policy to override the default one (the new one applying just to the SharePoint servers that needed it) this exception went away and SharePoint behaved normally. As far as I'm aware this might not be the only cause of this exception, but it is worth looking in to if you are experiencing this - especially if you know a tight group policy strategy is in place.

Comments

  • Anonymous
    October 12, 2015
    Thanks! Had this exact issue after applying SP1 to our farm that had been running RTM. Good thing it was only in UAT...

  • Anonymous
    July 13, 2016
    THIS RESOLUTION WORKED FOR METhe local Administrator group was already part of the "Impersonate a client after authentication" policy.I added the SP account that I used to Install the Farm to the local ADMINISTRATOR group....and it worked. Thanks dude...

    • Anonymous
      July 13, 2016
      Hi Dev,Do not - and I can't stress this enough - Do not ever put the SharePoint service accounts in to the local administrator group. This will grant them the privilege that this article describes, but it also grants them many more things they do not net, and as such this becomes a security risk. The change should be made to the security policy as I describe here, not through giving local admin rights. - B