Tip

PowerShell 4.0 further facilitates task automation for Windows admins

Has PowerShell finally grown up? A mature PowerShell 4.0 in Windows Server 2012 R2 brings with it new parameters, simpler implementation and more.

A new version of PowerShell is among the features in Windows Server 2012 R2. And with version 4.0, PowerShell feels like it's finally grown up -- with loads of new capabilities that will prove helpful for administrators, including changes to the default execution policy and several new parameters.

Desired State Configuration. The biggest change to PowerShell 4.0 is the inclusion of the new Windows PowerShell Desired State Configuration, a mechanism that collectively manages computers that perform similar functions to control the way the computers are configured.

Desired State Configuration functionality is based entirely on PowerShell -- there is no GUI interface. To use this feature, an administrator must create a PowerShell script specific to a particular computer role or function. The script defines the nodes to which the configuration should apply, the roles installed on those nodes and other configuration data.

A Microsoft Operations Framework (MOF) file is created when the script runs. At that point, MOF files can configure the specified nodes. MOF files are a mechanism used to transfer Windows Management Instrumentation settings or WMI objects between computers.

Default execution policy changes. The first big change Microsoft made was to alter the default execution policy. All previous PowerShell versions set the default execution policy to Disabled. In the past, PowerShell scripts could not run unless the administrator selected a different execution policy.

The default execution policy in PowerShell 4.0 is set to RemoteSigned in Windows Server 2012 R2, but it remains set to Disabled in Windows 8.1. This means Windows Server administrators can run PowerShell scripts without changing the execution policy as long as the scripts are signed. Windows 8.1 will continue to leave the execution policy set to Disabled to reduce the chance that consumers will fall victim to PowerShell-based scripting attacks.

PowerShell 4.0 parameters. Microsoft has also added a number of new parameters to PowerShell 4.0, including RepeatIndefinitely. This parameter is used to avoid having to specify a TimeSpan.MaxValue for the repeat duration when you want to run a scheduled job on a recurring basis.

Microsoft also created the RunNow parameter, which is linked to the Register-ScheduledJob and Set-ScheduledJob cmdlets. This parameter eases an immediate run of a scheduled job.

Another new parameter -- PipelineVariable -- will be especially useful to those who build PowerShell scripts. The PipelineVariable parameter builds on this building concept, allowing the results of a series of piped commands to be written to a variable. PowerShell treats PipelineVariable as a common parameter. This variable's contents can be referenced later in the script.

Another useful new parameter for creating PowerShell scripts is Passthru, which allows PowerShell to display any objects the command has modified. The Passthru parameter has been added to the Enable-JobTrigger and Disable-JobTrigger cmdlets.

Microsoft TechNet features a full list of changes to PowerShell 4.0.

PowerShell 4.0 initially will be compatible only with Windows Server 2012 R2 and Windows 8.1, but there are rumors that version 4.0 will eventually adapt to some earlier Windows releases.

You can download the PowerShell 4.0 preview as a part of the Windows Management Framework Preview; however, be careful when installing the Windows Management Framework as there are serious compatibility problems with Exchange Server, SharePoint Server, Windows Small Business Server and some of the System Center products. Microsoft likely will release patches in the future to address these incompatibilities.

About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as CIO for a nationwide chain of hospitals and health care facilities, and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.

Dig Deeper on