Ensuring you get the CLR version you want when remoting in Powershell

Posted on Updated on

This is an issue I ran into recently when trying to run some of our regular Powershell scripts recently – they were the same scripts we’d always run but now we were trying to run them remotely (instead of making a person log in over RDP and run a batch file. Very high-tech, I know.) but we were running into an issue to do with the CLR version that gets loaded with your Powershell session.

We’re using our own binaries (written in C#) in our Powershell scripts, and we need v4 of the CLR loaded to get them to run. Normally v2 is what you get, but we found that you can edit the file $pshome\powershell.exe.config with the contents:

<?xml version="1.0"?>
    <startup useLegacyV2RuntimeActivationPolicy="true">
         <supportedRuntime version="v4.0.30319"/>        
         <supportedRuntime version="v2.0.50727"/>        

This caused v4 of the CLR to be loaded, but only when you run Powershell locally. If you want to do the same when you remote into the machine, it doesn’t work.

I couldn’t find any documentation on this, but thanks to some nice people on StackOverflow I now have the answer. The configuration file contents above are still what you need, but you need to put them in another file. Two other files actually, if you’re on 64-bit. The files you need are located at c:\windows\System32\wsmprovhost.exe.config file and c:\windows\SysWOW64\wsmprovhost.exe.config.

That should be all you need!

One thought on “Ensuring you get the CLR version you want when remoting in Powershell

    withanHdammit said:
    2015-12-17 at 00:58

    Is this on the machine you are remoting from or the machine you are remoting to?

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 )

Facebook photo

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

Connecting to %s