In PowerShell 3.0, Microsoft lets admins manage, install, or adapt virtually any service on a Windows server via the shell. In this article, I introduce some of the new and interesting commandlets (cmdlets) that can make an admin’s life easier. For example, the new Show-Command directive explains the use of other parameters in more detail, and with an Internet connection, you can update the help files in PowerShell using Update-Help.

Core Server with a GUI

For Windows Server 2012, installing as a core server is the recommended Microsoft approach and is selected by default. An important innovation in Windows Server 2012 is the ability to install the graphical interface in the PowerShell later on, which means you can convert a core server into a full-fledged server with a graphical interface, and the installed services will not be affected by the change. To do this, type powershell at the command prompt, and then type

Install-WindowsFeature Server-Gui-Shell

in the PowerShell session. After a few minutes, the server reboots, and you have Windows Server 2012.

If you install a Core Server, the server lacks the binaries for installing the graphical interface. You must either configure an Internet connection for the server so that it can download the required data from Windows Update or specify the folder containing the Windows Server 2012 installation files. To install on a Core Server, you need to run:

Install-WindowsFeature Server-Gui-Mgmt-Infra

You can also connect from a computer on the network using Server Manager. Alternatively, you can use the PowerShell commands:

Import-Module Dism
Enable-WindowsOptionalFeature -online -Featurename ServerCore-FullServer,Server-Gui-Shell,Server-Gui-Mgmt

The following command also installs the graphical interface:

Dism /online /enable-feature /featurename:ServerCore-FullServer /featurename:Server-Gui-Shell /featurename:Server-Gui-Mgmt

Until Windows Server 2008 R2, the binaries for features and server roles were also stored on the server, even if they were not installed. This approach had the advantage of quick feature installation, but the binaries unnecessarily used up storage space. Windows Server 2012 now lets you remove unneeded binaries with the Uninstall-WindowsFeature cmdlet. The process can be reversed using the installation media for Windows Server 2012 at any time. The Install-WindowsFeature cmdlet handles this procedure.

One benefit of this feature is the ability to roll out servers with the use of images. If you remove any unnecessary binaries before creating an image, you can save up to a gigabyte of storage space. If you want to remove a role or a feature completely, use the PowerShell Uninstall-WindowsFeature cmdlet with the -Remove option:

Uninstall-WindowsFeature Server-Gui-Shell -Remove

To install the appropriate role or feature, you will then need to access the installation media for Windows Server 2012.

You can use Server Manager or the PowerShell Install-WindowsFeature for the installation. The -Source option for this cmdlet lets you specify a path to a WIM image. If the server fails to find a WIM image, the installation wizard downloads the required files off the Internet from the Windows Update service.

Customizing Core Server and GUI Server

When configuring the IP settings, you will want to avoid using the netsh command-line tool from Windows Server 2008 R2 and instead use the cmdlets New-NetIPAddress and Get-NetIPConfiguration, as in:

New-NetIPAddress -InterfaceIndex 12 -IPAddress 192.168.178.2 -PrefixLength 24 -DefaultGateway 192.168.178.1

You can then enter the DNS servers like this:

Set-DnsClientServerAddress -InterfaceIndex 12 -ServerAddresses 192.168.178.4

Multiple DNS servers are separated by commas. The cmdlet

Set-DnsClientServerAddress -InterfaceIndex 12 -ResetServer

changes the setting to DHCP. Be sure to use the correct index number for each network adapter. This can be obtained using Get-NetIPConfiguration. To join a Windows domain, you need Add-Computer; using Rename-Computer lets you do just that.

Installing Server Roles and Features

Features and roles also can be installed in PowerShell. The Get-WindowsFeature Hyper-V* command, for example, tells you whether the role and management tools are already installed. With Windows Server 2012, you can use -computername to check the installation of remote servers on the network. To install Hyper-V or the Management Tools, you need the Install-WindowsFeature cmdlet (on Windows Server 2008 R2, this was called Add-WindowsFeature).

Using Install-WindowsFeature Hyper-V lets you install the Hyper-V server role, and the option -IncludeManagementTools does pretty much that. If you want the server to reboot automatically after this action, you can add the -Restart option. To install just the Management Tools, type:

Install-WindowsFeature Hyper-V-Tools

Then, you can install the feature using the Add-WindowsFeature <Features> command; for example, you could use

Add-WindowsFeature RSAT-AD-PowerShell, RSAT-AD-AdminCenter

to install the Active Directory Management Tools. These commands work in PowerShell 2.0 on Windows Server 2008 R2 and in the new PowerShell 3.0 for Windows Server 2012.

Besides specifying the role and feature names, you can use an XML control file in PowerShell; this file is created in the last of the Add Roles and Features Wizard windows (Figure 1).

Figure 1: Saving an XML file in Server Manager.

To install the same roles and features on a different server, just use PowerShell and specify the XML file:

Install-WindowsFeature -ConfigurationFilePath C:\Data\iis.xml

(Figure 2).

Figure 2: Installing server roles in PowerShell via an XML file.

Testing the Conditions for Active Directory

The cmdlet Test-ADDSDomainControllerInstallation tests whether the conditions for installing a domain controller are met. For a read-only domain controller, you would do the same thing using Test-ADDSReadOnlyDomainControllerAccountCreation.

To test the conditions for installing a new domain in Active Directory, you would instead use Test-ADDSDomainInstallation (Figure 3).

Figure 3: Successfully testing the conditions for installing a new domain controller.

Test-ADDSForestInstallation does the same for a new forest based on Windows Server 2012. To run the tests, you must still enter passwords in different places. The cmdlet here only accepts this as secure input. An example of the command is:

Test-ADDSDomainControllerInstallation -Domainname  -SafeModeAdministratorPassword 

To install a new domain controller, use the Install-ADDSDomainController cmdlet. For this command to work, you need to specify the name of the domain and configure the password for Directory Services Restore Mode as a SecureString. The following command does the trick:

Install-ADDSDomainController -DomainName  -SafeModeAdministratorPassword (read-host -prompt "Password" -assecurestring)

To demote a domain controller, again your best option is UnInstall-ADDSDomainController. You need to specify at least the local administrator’s password, which is defined as a SecureString. The syntax looks like this:

UnInstall-ADDSDomainController -LocalAdministratorPassword (read-host -prompt "Password" -assecurestring)

The get-help UnInstall-ADDSDomainController cmdlet gives you more information on the command. You can also name, reboot, and add servers to domains in PowerShell. To do this, PowerShell provides the following cmdlets:

• Rename-Computer -Name <Computername>
• Add-Computer -DomainName <domain name>
• Restart-Computer

You can also set up replication in PowerShell. For a list of the available commands, type get-command *adreplication*, and to display help for the cmdlets, use the get-help cmdlet.

You can also create sites in PowerShell with the use of the New-ADReplicationSite <location> command, and you can create new site links, for example, like this:

New-ADReplicationSiteLink CORPORATE-BRANCH1 -SitesIncluded CORPORATE,BRANCH1 -OtherAttributes @{'options'=1}

You can also set the metric of the time frame for synchronization in the same command line by setting the appropriate switches:

Set-ADReplicationSiteLink CORPORATE-BRANCH1 -Cost 100 -ReplicationFrequencyInMinutes 15

This call sets the metric to 100 and the replication interval to 15 minutes.

Testing Replication in PowerShell

To discover the replication status, you can use the Get-ADReplicationUpToDatenessVectorTable <server name> cmdlet. For a list of all your servers, do this:

Get-ADReplicationUpToDatenessVectorTable * | sort Partner,Server | ft Partner,Server,UsnFilter

Use the following two cmdlets to view the individual sites and the domain controllers at these sites:

• Get-ADReplicationSite -Filter * | ft <Name>
• Get-ADDomainController -Filter * | ft <Hostname>,<Site>

To view the replication connections in PowerShell, use the Get-ADReplicationConnection command. PowerShell will also give you detailed information on the individual sites on request. To do this, use Get-ADReplicationSite -Filter *. Other interesting cmdlets in this area are:

• Get-ADReplicationPartnerMetadata
• Get-ADReplicationFailure
• Get-ADReplicationQueueOperation

PowerShell Web Access

Windows PowerShell Web Access provides a web-based Windows PowerShell console. In this way, you can run PowerShell commands and scripts from a console in a web browser. You can even use PowerShell Web Access to access the PowerShell on your servers remotely on a smartphone or tablet, which means you can use all the cmdlets that are available on the server. When you install Windows PowerShell Web Access using PowerShell, the administration tools for IIS are not added:

Install-WindowsFeature -Name WindowsPowershellWebAccess -ComputerName  -IncludeManagementTools -Restart

The next step is to set up the gateway for PowerShell Web Access. The Install-PswaWebApplication cmdlet provides a quick approach to configuring this. You can install a self-signed SSL certificate with the option -UseTestCertificate. Running this cmdlet installs the PowerShell Web Access web application in the Default Web Site container of IIS; then, you can access the PSWA website on https://<servername>/pswa.

After installing PowerShell Web Access and setting up the gateway with the website and the certificate, you still need to allow users to access PowerShell via Web Access. In a PowerShell session that was opened with the administrative role, run the commands shown in Listing 1.

Listing 1: Allowing Web Access

$applicationPoolName = ""
$authorizationFile = "C:\windows\web\powershellwebaccess\data\AuthorizationRules.xml"
c:\windows\system32\icacls.exe $authorizationFile /grant ('"' + "IIS AppPool\$applicationPoolName" + '":R') > $null

Authorization rules allow a user to access a computer on the network. Access is limited to a specific session configuration. The cmdlet:

Add-PswaAuthorizationRule -UserName Contoso\administrator -ComputerName srv1.contoso.int -ConfigurationName microsoft.powershell

grants the “administrator” user in the “contoso” domain access for managing the “srv1.contoso.int” computer and use of the “Microsoft.PowerShell” session configuration.

PowerShell in Windows 7 and 8

To display the existing recovery points for a system in PowerShell (Figure 4), launch PowerShell via the Welcome page, then click the tile above the context menu and run PowerShell as administrator.

Figure 4: Managing recovery points in PowerShell.

To see the system restore points, you need to enter the command Get-ComputerRestorePoint.

Typing Restore-Computer <SequenceNumber> resets the computer at the time of the restore point specified in SequenceNumber. To discover this number, run Get-ComputerRestorePoint, after which, the wizard goes about its task without a prompt.

To create a recovery point in PowerShell, use:

Checkpoint-Computer -description 

However, you can only create one recovery point every 24 hours in this way. Later, you can manage the recovery point in the graphical interface, like all the others. Detailed help for the cmdlet is available on Microsoft TechNet. The PowerShell also lets you schedule the creation of system recovery points.

Managing Office 365 in PowerShell

Administrators can manage all editions of Office 365 in PowerShell, even without running local servers (Figure 5).

Figure 5: Office 365 can also be managed in PowerShell.

Microsoft provides the required cmdlets for free, with additional help online.

To manage Office 365, follow the Microsoft Online Services Module for Windows PowerShell link in the Microsoft Online Services program group or load the appropriate cmdlets with import-module MSOnline. The Connect-MSOLService cmdlet connects the console to Office 365, and get-command *mso* gives an overview of the available commands. Settings such as the password expiration date can be made with the Set-MSOLUser cmdlet.

The Author

Thomas Joos is a freelance IT consultant and has been working in IT for more than 20 years. In addition to his projects, he also writes hands-on books and papers on Windows and other Microsoft topics. Online, you can meet him at http://thomasjoos.spaces.live.com.