2.6 Configuring the PowerShell Execution Policy

This section describes the procedure for configuring the Microsoft PowerShell Execution Policy. The PowerShell Execution Policy determines whether PowerShell scripts are allowed to run.

2.6.1 Understanding PowerShell Cmdlets

Microsoft SharePoint 2010 and later uses the Microsoft scripting and command environment known as PowerShell. PowerShell is made up of hundreds of executable objects called cmdlets, pronounced command-lets.

When running the SharePoint category of Knowledge Scripts, AppManager makes a series of calls to PowerShell and the SharePoint 2010 or later cmdlets. AppManager executes the cmdlets to manipulate SharePoint 2010 or later objects. For SharePoint 2007 objects, AppManager uses PowerShell scripts to call the SharePoint 2007 Application Programming Interface (API).

For more information about using PowerShell, see your Microsoft PowerShell documentation.

2.6.2 Configuring the PowerShell Execution Policy

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 SharePoint Knowledge Scripts. Although the scripts that ship with SharePoint 2007, or later are 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 SharePoint Knowledge Scripts, but with a .ps1 extension.

NOTE:The digital signature encoded in an SharePoint 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 a SharePoint 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.6.3, Trusting SharePoint PowerShell Scripts.

  • RemoteSigned, which allows local scripts to run regardless of signature, and requires trusted digital signatures only for remote scripts. SharePoint Knowledge Scripts are local scripts.

  • Unrestricted, which allows both local and remote scripts to run, regardless of signature.

To change the PowerShell Execution Policy:

  1. Open the SharePoint Command Shell on the agent computer.

  2. Run the following cmdlet:

    Set-ExecutionPolicy policy

    where policy is the name of the Execution Policy you choose.

  3. Repeat Step 1 and Step 2 on all agent computers that are members of the SharePoint server farm.

2.6.3 Trusting SharePoint PowerShell Scripts

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 SharePoint 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 SharePoint server in your environment.

You can import the digital certificate by running one of the SharePoint PowerShell scripts from the command line.

To import the digital certificate:

  1. Open the Windows PowerShell Command Shell on the agent computer.

  2. Change to the AppManager\bin\PowerShell\Scripts directory.

  3. Type .\SharePoint_GenericEventLog.ps1

  4. Press Enter.

  5. Type A at the prompt asking whether the script should be allowed to run.

  6. 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 SharePoint PowerShell scripts.

To extend trust to all other user accounts, see Section 2.6.4, Extending Trust to All User Accounts.

2.6.4 Extending Trust to All User Accounts

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.

Exporting the NetIQ Corporation Digital Signature Certificate

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:

  1. On the Start menu, click Run.

  2. In the Open field, type mmc.exe, and click OK.

  3. On the File menu in the Microsoft Management Console window, click Add/Remove Snap-in.

  4. Click Add and then select the Certificates snap-in.

  5. Click Add, select My user account, and then click Finish.

  6. Click Close and then click OK. The Certificates-Current User node is displayed in the tree view of the Console window.

  7. Expand Certificates - Current User.

  8. Expand Trusted Publishers and select Certificates.

  9. In the right pane, right-click the NetIQ certificate, select All Tasks, and then select Export.

  10. Click Next in the Certificate Export Wizard.

  11. Select DER encoded binary and then click Next.

  12. Click Browse, select the Desktop icon, type NetIQ in the File name field, and then click Save.

  13. Click Next, and then click Finish.

Importing the NetIQ Corporation Digital Signature

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:

  1. On the File menu in the Microsoft Management Console window, click Add/Remove Snap-in.

  2. Click Add and then select the Certificates snap-in.

  3. Click Add, select Computer account, and then click Next.

  4. Select Local computer and then click Finish.

  5. Click Close and then click OK.

  6. Expand Certificates (Local Computer) and select Trusted Publishers.

  7. Right-click in the right pane, select All Tasks, and then select Import.

  8. Click Next in the Certificate Import Wizard.

  9. Click Browse, click the Desktop icon, select NetIQ.cer, and then click Open.

  10. Click Next in the wizard.

  11. Select Place all certificates in the following store.

  12. Click Browse and then select Show physical stores.

  13. Expand Trusted Publishers and select Local Computer.

  14. Click OK.

  15. 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.