Four modes of script execution are possible for the Exchange Management Shell to control how scripts are used, depending on how they are signed and if they are from known or unknown sources. The following table describes each script execution mode.

Script execution modes

To change the script execution mode from the default RemoteSigned script execution mode, use the Set-ExecutionPolicy cmdlet in the Exchange Management Shell. For example, to change the execution policy to AllSigned mode, run the following command:

	Copy Code
Set-ExecutionPolicy AllSigned

The Exchange Management Shell recognizes the change to the policy immediately.

Large organizations that want to set a consistent script execution mode for all computers that are running the Exchange Management Shell should apply the script execution mode setting by using an Active Directory group policy. You configure the Active Directory group policy to set the ExecutionPolicy value located under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell registry key to the desired script execution mode.

Caution:
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Digital signatures are created by using a public-key signature algorithm that uses two different cryptographic keys called a key pair: the public key and the private key. The private key is known only to its owner, and the public key is available to anyone. In digital signatures, the private key generates the signature, and the corresponding public key validates the signature.

A certificate is a digital document that is generally used for authentication and to help secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. Certificates are digitally signed by the issuing certification authority (CA). By using a code-signing certificate, the author of the script adds a digital signature to the script file. During this process, a one-way hash of the script is created and encrypted by using the private key. The encrypted hash is a digital signature string that is added to the script file. This digital signature string is commented out so that it does not interfere with script functionality.

When this script is run in an Exchange Management Shell environment where code signing is required, a new one-way hash of the script file is produced. The one-way hash is compared to the encrypted hash that is included with the script file after it is decrypted by using the public key. If the script wasn't altered in any way after it was signed, the hashes will match. The computer then tries to verify that the signature is from a trusted publisher by building a certificate chain to a trusted certification authority. If the trust is verified, the script runs.

Whether a script is from a trusted source depends on the origin of the code-signing certificate that was used to digitally sign the script. There are generally two types of certificates:

• Certificates that are issued by a trusted certification authority   The certification authority verifies the identity of requestor before it issues a code-signing certificate. The issuing authority can be an external, public third party that sells certificates or an internal certification authority that is hosted by your organization. If you sign a script by using this kind of certificate, you can share the script with users on other computers that recognize and trust the certification authority that issued the certificate.
  
  
• Self-signed certificates   For this kind of certificate, your computer is the authority that creates the certificate. The benefit of a self-signed certificate is you can write, sign, and run scripts on your computer. But you can't share your script to run on other computers because they don't recognize your computer as a trusted certification authority. If they don't trust your computer, they can't validate your self-signed signature and the script won't run.
  
  

The Exchange Management Shell includes two cmdlets for managing code signing. The Set-AuthenticodeSignature cmdlet is used to add digital signatures to script files. The Set-AuthenticodeSignature cmdlet takes the name of the file to be signed as its first positional parameter. If the file is not in the current working directory, you must provide the path of the file. The second input parameter for this cmdlet is the certificate that is used for signing. This certificate is stored in the local certificate store. You must provide this parameter in the form of a string that references the certificate. The certificate can be accessed through the Cert: drive.

The second cmdlet for managing code signing is the Get-AuthenticodeSignature cmdlet. Use the Get-AuthenticodeSignature cmdlet to check and confirm the current code-signing status for the file that is provided as a parameter input. If a problem occurs when you use a code-signed script, the output from the Get-AuthenticodeSignature cmdlet will provide useful troubleshooting information.

If you want to run scripts from outside sources, such as Microsoft, you must adapt the scripts according to the script execution mode of your environment. You can receive scripts as basic .txt files, rename them as .ps1 script files, and then, after you apply any required signing, run these scripts as if you had written the script yourself.

For more information about digital signing and script execution policies, in the Exchange Management Shell, run the following command: Get-Help About_Signing. This command returns help information that includes detailed instructions for digitally signing scripts.