This chapter describes the procedure for configuring the Microsoft PowerShell Execution Policy. The PowerShell Execution Policy determines whether PowerShell scripts are allowed to run.
Microsoft Exchange Server uses the Microsoft scripting and command environment known as PowerShell. PowerShell is made up of hundreds of executable objects called cmdlets, pronounced command-lets. In addition to the base cmdlets provided by PowerShell, installation of the Exchange Management Console adds approximately 300 Exchange Server cmdlets.
When running the Exchange2007 category of Knowledge Scripts, AppManager makes a series of calls to PowerShell and the Exchange Server cmdlets. The combination of cmdlets depends on the version of Exchange Server. AppManager executes the cmdlets to manipulate Exchange Server objects such as Outlook Web Access, virtual directories, mailboxes, distribution groups, and storage groups (2007 only).
For more information about using Powershell, see your Microsoft PowerShell documentation.
The PowerShell Execution Policy determines whether PowerShell scripts are allowed to run. By default, the Execution Policy is set to Restricted. If you try to run scripts under the Restricted policy, AppManager generates error messages.
The Execution Policy directly affects the Exchange2007 Knowledge Scripts. Although the scripts that ship with AppManager for Microsoft Exchange Server and Exchange Online is written in VBScript and installed as <scriptname>.qml, the logic for the scripts is contained in complementary PowerShell scripts that are installed on the agent computer along with the module. The PowerShell scripts use the same name as the Exchange2007 Knowledge Scripts, but with a .ps1 extension.
NOTE:The digital signature encoded in an Exchange2007 Knowledge Script is tied to the contents of the script. If you change the script, the signature is no longer valid and you cannot execute the script. If you change an Exchange2007 Knowledge Script, you must do one of the following:
Re-sign the scripts using your own digital certificate.
Change the Execution Policy to either RemoteSigned or Unrestricted. A group policy that governs script execution overrides any policy changes you make with the Set-ExecutionPolicy cmdlet. For example, if the group policy forbids script execution, you cannot change the policy by running Set-ExecutionPolicy. First change the group policy to allow script execution, and then run Set-ExecutionPolicy to select a specific Execution Policy.
Before AppManager can execute the PowerShell scripts, you must change the Execution Policy from Restricted to one of the following policy options:
AllSigned, which allows execution of scripts that have been digitally signed by a trusted publisher. If you select the AllSigned policy, perform the steps outlined in Section 2.13.3, Trusting Exchange PowerShell Scripts.
RemoteSigned, which allows local scripts to run regardless of signature, and requires trusted digital signatures only for remote scripts. Exchange2007 Knowledge Scripts are local scripts.
Unrestricted, which allows both local and remote scripts to run, regardless of signature.
To change the PowerShell Execution Policy:
Open the Exchange Command Shell on the agent computer.
Run the following cmdlet:
Set-ExecutionPolicy <policy>
where <policy> is the name of the Execution Policy you choose.
Repeat Steps 1 and 2 on all agent computers, including Server role computers.
When a PowerShell script is executed under an AllSigned policy, PowerShell verifies that the script contains a digital signature and that the signature is associated with a trusted publisher. NetIQ Corporation signs the Exchange PowerShell scripts. If you use the AllSigned policy, you must choose to trust NetIQ Corporation by importing the NetIQ Corporation digital certificate into the local certificate store on each Exchange Server in your environment.
You can import the digital certificate by running one of the Exchange2007 PowerShell scripts from the command line.
To import the digital certificate:
Open the Exchange Command Shell on the agent computer.
Change to the AppManager\bin\PowerShell\Scripts directory.
Type .\Exchange2007_All_EventLog.ps1
Press Enter.
Type A at the prompt asking whether the script should be allowed to run.
Press Enter.
These steps allow the NetIQ Corporation digital certificate to be imported into the certificate store for the user running the script. Run any script once to establish trust.
At this point, trust is established only between NetIQ Corporation and the user running the script. Trust is not established for any other user. If the AppManager agent runs under a different user account such as Local System, a domain account, or a local computer account, the agent will not have a trust relationship and will not be allowed to execute the Exchange PowerShell scripts.
To extend trust to all other user accounts, see Section 2.13.4, Extending Trust to All User Accounts.
To establish trust between all users accounts and the Microsoft digital certificate, see Section 2.13.5, Establishing Trust for the Microsoft Certificate.
To execute PowerShell scripts under the AllSigned Execution Policy, extend trust to all user accounts. Extending trust is a two-phase process that involves exporting the digital certificate from the current user and importing the digital certificate to all users on the local computer.
To extend trust to all user accounts, first export the NetIQ Corporation digital signature certificate from the current user using the Microsoft Management Console.
To export the NetIQ Corporation digital signature certificate from the current user:
On the Start menu, click Run.
In the Open field, type mmc.exe, and then click OK.
On the File menu in the Microsoft Management Console window, click Add/Remove Snap-in.
Click Add and then select the Certificates snap-in.
Click Add, select My user account, and then click Finish.
Click Close and then click OK. The Certificates-Current User node is displayed in the tree view of the Console window.
Expand Certificates - Current User.
Expand Trusted Publishers and select Certificates.
In the right pane, right-click the NetIQ certificate, select All Tasks, and then select Export.
Click Next in the Certificate Export Wizard.
Select DER encoded binary and then click Next.
Click Browse, select the Desktop icon, type NetIQ in the File name field, and then click Save.
Click Next, and then click Finish.
The next phase of extending trust to all user accounts involves importing the NetIQ Corporation digital signature to all users on the local computer. Use the Microsoft Management Console to execute the import procedure.
To import the NetIQ Corporation digital certificate to all users on the local computer:
On the File menu in the Microsoft Management Console window, click Add/Remove Snap-in.
Click Add and then select the Certificates snap-in.
Click Add, select Computer account, and then click Next.
Select Local computer and then click Finish.
Click Close and then click OK.
Expand Certificates (Local Computer) and select Trusted Publishers.
Right-click in the right pane, select All Tasks, and then select Import.
Click Next in the Certificate Import Wizard.
Click Browse, click the Desktop icon, select NetIQ.cer, and then click Open.
Click Next in the Wizard.
Select Place all certificates in the following store.
Click Browse and then select Show physical stores.
Expand Trusted Publishers and select Local Computer.
Click OK.
Click Next in the Certificate Import Wizard, and then click Finish.
After you complete both the phases of the trust process, the NetIQ Corporation certificate is contained in the certificate store for the local computer, allowing all users to execute the PowerShell scripts.
The Exchange2007 Knowledge Scripts access a file called Exchange.Format.ps1xml, which Microsoft ships with Exchange Server. For the Exchange2007 Knowledge Scripts to run properly, the Microsoft digital signature certificate must have a trust relationship with the Microsoft digital signature certificate.
To create this trust relationship, perform the steps outlined in Section 2.13.4, Extending Trust to All User Accounts, with the following exceptions: