PowerShell Execution Policy While Upgrading To Exchange 2010 SP2
I will try to clarify the confusion out there about the execution policy that should be in place for a successful upgrade of Exchange 2010+ to SP2. The Microsoft KB article is not fully correct The KB article 2668686 lists that the execution policy should all be listed as “Undefined”, when you run Get-ExecutionPolicy –list…
I will try to clarify the confusion out there about the execution policy that should be in place for a successful upgrade of Exchange 2010+ to SP2. The Microsoft KB article is not fully correct 
The KB article 2668686 lists that the execution policy should all be listed as “Undefined”, when you run Get-ExecutionPolicy –list on the Exchange 2010 box to be upgraded.
Scope ExecutionPolicy ----- --------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser Undefined LocalMachine Undefined
If it is not, you will get the error below.
The following error was generated when "$error.Clear(); & $RoleBinPath\ServiceControl.ps1 EnableServices Critical
" was run: "AuthorizationManager check failed.". AuthorizationManager check failed.
I need to clarify that, the KB article info is not fully true. You don’t need to have the LocalMachine policy as Undefined, it will successfully install SP2 even if it is set to “RemoteSigned”. I think that is the default setting anyway (atleast on the few boxes that I have checked).
So, let me explain a bit further. The below screenshot is what you need for a successful upgrade to SP2.
You don’t have to worry too much about the KB article and try changing the local machine execution policy to undefined
With the settings above, I was successfully able to upgrade to SP2.
Let’s hope that Microsoft will update the KB article soon!
Hi Rajith,
Great post.
I am planning to install Exchange 2010 SP3 next week.
Our current Exchange environment consists of the following:
1 x CAS/HT Server
2 x Mailbox Server (members of a DAG)
The OS of the 3 servers is Windows Server 2008 R2 SP1. All servers are running Exchange 2010 SP1 Update Rollup 6.
The Execution Policies on our Exchange servers are set as follows:
– CAS/HT Server:
Scope ExecutionPolicy
—– —————
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Unrestricted
– Mailbox Servers:
Scope ExecutionPolicy
—– —————
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine RemoteSigned
I would be very grateful if you could help me with following question:
1- Do I have to change the execution policy on our Exchange servers before installing SP3? If I have to change a policy, what should I change? And how would you recommend I should do this?
Many thanks,
M
Hi M,
If you have not changed the PS execution policy on the servers manually or via GPO, you are fine to upgrade.
This article applies to environments where the PS executions are locked down. Generally it is not an issue at all.
Hi Rajith,
Thanks for getting back to me on this.
We haven’t set the Powershell execution policy via Group Policy.
We only configured the execution policy of “LocalMachine” to “Unrestricted” on the CAS/HT server using the “Set-ExecutionPolicy” command on the server.
The mailbox servers’ execution policies have not been changed and are set to those values by default.
I got confused when I read the “http://support.microsoft.com/kb/2668686″ and “http://support.microsoft.com/kb/2810617″ articles.
But looks like I shouldn’t worry as our current Powershell execution policies shouldn’t affect the upgrade.
Cheers,
M
If you have not played with execution policies on the server, it should be fine Muhajer ;-)
If Exchange devs were to simply insert a “get-executionpolicy” check as part of the pre-requisite SP2 update install, much pain would be avoided. The fact that the SP2 upgrade installer completely removes Exchange BEFORE failing, thus causing a ‘recover’ to be needed, is clearly a bug and from an Exchange admin and customer perspective and is extremely messy in a production environment.
Yes Mason. They should do a pre-check and alert the admin before proceeding with the install/upgrade.