This will be a quick post. I kept seeing this pop up on Automation/PowerShell MVP blogs and as answers on TechNet over the past few years. System Center Orchestrator 2012-2016 is 32-bit application that leverages .NET such that the PowerShell .NET Script Activity natively executes scripts in PowerShell Version 2. At some point someone started suggesting that you could modify a regkey and instantly get Orchestrator to use the latest version of PowerShell without any complicated workarounds:
Being that I am generally mistrustful of things that seem to be too good to be true I have avoided this solution, and have used alternate slightly more involved workarounds to mitigate this issue. Recently a colleague asked on behalf of a customer if there was any reason they shouldn’t implement the regkey fix. After some quick searching the answer would be a resounding yea this could be a really bad/unsupported idea.
The regkey exists for .NET compatibility testing and debugging. It is not intended to ever be set in a production environment. While it does work insofar as it forces Orchestrator to use the latest version of PowerShell it also forces every single other 32-bit application on that server to use the latest version of .NET CLR. If one of those applications only supports some earlier version of .NET you will break it, and not necessarily in an obvious way. Turning that setting on in production is a ticking time bomb. It’s possible as more and more applications have shifted to 64-bit that the number of applications affected by this setting will continue to decrease and those who have implemented this change might have gotten lucky and haven’t seen obvious issues, but I would recommend against ever playing with this setting in a production environment.
Some examples of this setting unexpectedly breaking things: