User`s guide

Executing PowerShell Scripts
PowerShell contains built-in policies, which limit its use as an attack vector. The primary policy is for script
execution. By default the script execution policy is set to Restricted, which means that PowerShell can only
be used interactively or for executing commands directly from the command line. The additional policy
settings are as follows:
n
AllSigned: Any PowerShell script (.ps1 is the typical extension) must be signed by a verifiable certificate
(from the SPC certificate store)
n
RemoteSigned: Any PowerShell script that is downloaded from the Internet (by a supporting browser
such as Internet Explorer) must be signed. Script files that are created locally, or scripts that are
downloaded by a means that does not support flagging of the file source, do not need to be signed.
n
Unrestricted: All PowerShell script files will be executed regardless of whether they are signed.
In addition, PowerShell 2.0 adds the capability to set different script signing policies at the machine, user,
and process (single execution of powershell.exe) scopes.
WCI uses Script Type information in the collection filter definition to indicate how PowerShell should be
executed and how the script should be passed to it. The primary ways a WCI script may be passed to
PowerShell is either in-line or through a script file
n
In-line: Requires a collection script that can be represented as a single line of PowerShell code. In-line
scripts can be run regardless of the execution policy; because an in-line script is run on the PowerShell
command line rather than from a file, the execution policy does not apply. The default WCI filter uses
an in-line script to collect basic information about the PowerShell version, .NET version, and execution
policy settings of a system.
n
Script file: Requires that the execution policy be set to Remote Signed at the most restrictive, since the
script is being run from a file locally on the client system. Because of its additional ability to have
execution policy set at the process level, PowerShell 2.0 is the base requirement for WCI in VCM. The
default script type command line used for script based filters in WCI includes options to set the process-
level execution policy to Remote Signed. This allows WCI to execute collection scripts against systems
whose machine and user level signing policies may be anything, without having to change the setting.
Out-of-the-box VCM WCI non-in-line collection filters will fail if executed against PowerShell 1.0 client
systems.
VMware recommends that you upgrade from PowerShell 1.0 to PowerShell 2.0, which introduced a
number of useful functions. PowerShell 2.0 is also supported on all platforms that support PowerShell 1.0.
It is possible to execute WCI PowerShell collection scripts against PowerShell 1.0 systems as well, although
it has not been tested, and is not officially supported. In-line WCI filters that do not employ PowerShell 2.0
commands should work directly. For script file based filters to work, you must create them with the
PowerShell v1.0 Text Output script type, and the system must already have its execution policy set to
Remote Signed, at the most restrictive, with un-signed scripts, or to All Signed with signed scripts (see
below). This setting can be accomplished by the Group Policy Object (GPO), through the use of a VCM
Remote Command, or by using a registry change action or enforceable compliance to set the policy
directly. For example:
HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
"ExecutionPolicy"="RemoteSigned"
vCenter Configuration Manager Installation and Getting Started Guide
92 VMware, Inc.