Windows Server 2012 Administration Overview

Frequently Used Tools

Many utilities are available for administrating Windows Server 2012 systems. The tools you use the most include the following:

• Control Panel A collection of tools for managing system configuration. You can organize Control Panel in different ways according to the view you’re using. A view is simply a way of organizing and presenting options. You change the view by using the View By list. Category view is the default view, and it provides access to tools by category, tool, and key tasks. The Large Icons and Small Icons views are alternative views that list each tool separately by name.
• Graphical administrative tools The key tools for managing network computers and their resources. You can access these tools by selecting them individually from the Administrative Tools program group.
• Administrative wizards Tools designed to automate key administrative tasks. You can access many administrative wizards in Server Manager—the central administration console for Windows Server 2012.
• Command-line utilities You can launch most administrative utilities from the command prompt. In addition to these utilities, Windows Server 2012 provides others that are useful for working with Windows Server 2012 systems.

To learn how to use any of the .NET command-line tools, type NET HELP at a command prompt followed by the command name, such as NET HELP SHARE. Windows Server 2012 then provides an overview of how the command is used.

Windows PowerShell 3.0

For additional flexibility in your command-line scripting, you might want to use Windows PowerShell 3.0. Windows PowerShell 3.0 is a full-featured command shell that can use built-in commands called cmdlets, built-in programming features, and standard command-line utilities. A command console and a graphical environment are available.

Although the Windows PowerShell console and the graphical scripting environment are installed by default, several other PowerShell features are not installed by default. They include the Windows PowerShell 2.0 engine, which is provided for backward compatibility with existing PowerShell host applications, and Windows PowerShell Web Access, which lets a server act as a web gateway for managing the server remotely using PowerShell and a web client.

The Windows PowerShell console (Powershell.exe) is a 32-bit or 64-bit environment for working with Windows PowerShell at the command line. On 32-bit versions of Windows, you’ll find the 32-bit executable in the %SystemRoot%\System32\WindowsPowerShell\v1.0 directory. On 64-bit versions of Windows, you’ll find the 32-bit executable in the %SystemRoot%\SysWow64\WindowsPowerShell\v1.0 directory, and the 64-bit executable in the %SystemRoot%\System32\WindowsPowerShell\v1.0 directory.

On the desktop, you can open the Windows PowerShell console by tapping or clicking the PowerShell button on the taskbar. This option is included by default. On 64-bit systems, the 64-bit version of PowerShell is started by default. If you want to use the 32-bit PowerShell console on a 64-bit system, you must select the Windows PowerShell (x86) option.

You can start Windows PowerShell from a Windows command shell (Cmd.exe) by entering the following:

powershell

After starting Windows PowerShell, you can enter the name of a cmdlet at the prompt, and the cmdlet will run in much the same way as a command-line command. You can also execute cmdlets in scripts. Cmdlets are named using verb-noun pairs. The verb tells you what the cmdlet does in general. The noun tells you what specifically the cmdlet works with. For example, the Get-Variable cmdlet gets all Windows PowerShell environment variables and returns their values, or it gets a specifically named environment variable and returns its value. The common verbs associated with cmdlets are as follows:

• Get- Queries a specific object or a subset of a type of object, such as a specified performance counter or all performance counters
• Set- Modifies specific settings of an object
• Enable- Enables an option or a feature
• Disable- Disables an option or a feature
• New- Creates a new instance of an item, such as a new event or service
• Remove- Removes an instance of an item, such as an event or event log

At the Windows PowerShell prompt, you can get a complete list of cmdlets by typing get-help *-*. To get help documentation on a specific cmdlet, type get-help followed by the cmdlet name, such as get-help get-variable.

All cmdlets also have configurable aliases that act as shortcuts for executing a cmdlet. To list all aliases available, type get-item –path alias: at the Windows PowerShell prompt. You can create an alias that invokes any command by using the following syntax:

new-item -path alias:AliasName -value:FullCommandPath

Here AliasName is the name of the alias to create, and FullCommandPath is the full path to the command to run, such as

new-item -path alias:sm -value:c:\windows\system32\compmgmtlauncher.exe

This example creates the alias sm for starting Server Manager. To use this alias, you simply type sm and then press Enter when you are working with Windows PowerShell.

Windows Remote Management

The Windows PowerShell remoting features are supported by the WS-Management protocol and the Windows Remote Management (WinRM) service that implements WS-Management in Windows. Computers running Windows 7 and later, as well as Windows Server 2008 R2 or later include WinRM 2.0 or later. If you want to manage a Windows server from a workstation, you need to be sure that WinRM 2.0 and Windows PowerShell 3.0 are installed and that the server has a WinRM listener enabled. An IIS extension, installable as a Windows feature called WinRM IIS Extension, lets a server act as a web gateway for managing the server remotely using WinRM and a web client.

Enabling and Using WinRM

You can verify the availability of WinRM 2.0 and configure Windows PowerShell for remoting by following these steps:

1. Tap or click Start, and then point to Windows PowerShell. Start Windows PowerShell as an administrator by pressing and holding or right-clicking the Windows PowerShell shortcut and selecting Run As Administrator.

2. The WinRM service is configured for manual startup by default. You must change the startup type to Automatic and start the service on each computer you want to work with. At the Windows PowerShell prompt, you can verify that the WinRM service is running by using the following command:

   get-service winrm

   As shown in the following example, the value of the Status property in the output should be Running:

   Status   Name              DisplayName
   ------   ----              -----------
   Running  WinRM             Windows Remote Management

   If the service is stopped, enter the following command to start the service and configure it to start automatically in the future:

   set-service -name winrm -startuptype automatic -status running

3. To configure Windows PowerShell for remoting, type the following command:

   Enable-PSRemoting -force

   You can enable remoting only when your computer is connected to a domain or a private network. If your computer is connected to a public network, you need to disconnect from the public network and connect to a domain or private network and then repeat this step. If one or more of your computer’s connections has the Public Network connection type but you are actually connected to a domain or private network, you need to change the network connection type in Network And Sharing Center and then repeat this step.

In many cases, you are able to work with remote computers in other domains. However, if the remote computer is not in a trusted domain, the remote computer might not be able to authenticate your credentials. To enable authentication, you need to add the remote computer to the list of trusted hosts for the local computer in WinRM. To do so, type the following:

winrm set winrm/config/client '@{TrustedHosts"RemoteComputer"}'

Here RemoteComputer is the name of the remote computer, such as

winrm set winrm/config/client '@{TrustedHosts="CorpServer56"}'

When you are working with computers in workgroups or homegroups, you must use HTTPS as the transport or add the remote machine to the TrustedHosts configuration settings. If you cannot connect to a remote host, verify that the service on the remote host is running and is accepting requests by running the following command on the remote host:

winrm quickconfig

This command analyzes and configures the WinRM service. If the WinRM service is set up correctly, you’ll see output similar to the following:

WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

If the WinRM service is not set up correctly, you see errors and need to respond affirmatively to several prompts that allow you to automatically configure remote management. When this process is complete, WinRM should be set up correctly.

Whenever you use Windows PowerShell remoting features, you must start Windows PowerShell as an administrator by pressing and holding or right-clicking the Windows PowerShell shortcut and selecting Run As Administrator. When starting Windows PowerShell from another program, such as the command prompt, you must start that program as an administrator.

Configuring WinRM

When you are working with an elevated, administrator command prompt, you can use the WinRM command-line utility to view and manage the remote management configuration. Type winrm get winrm/config to display detailed information about the remote management configuration.

If you examine the configuration listing, you’ll notice there is a hierarchy of information. The base of this hierarchy, the Config level, is referenced with the path winrm/config. Then there are sublevels for client, service, and WinRS, referenced as winrm/config/client, winrm/config/service, and winrm/config/winrs. You can change the value of most configuration parameters by using the following command:

winrm set ConfigPath @{ParameterName ="Value"}

Here ConfigPath is the configuration path, ParameterName is the name of the parameter you want to work with, and Value sets the value for the parameter, such as

winrm set winrm/config/winrs @{MaxShellsPerUser="10"}

Here, you set the MaxShellsPerUser parameter under winrm/config/winrs. This parameter controls the maximum number of connections to a remote computer that can be active per user. (By default, each user can have only five active connections.) Keep in mind that some parameters are read-only and cannot be set in this way.

WinRM requires at least one listener to indicate the transports and IP addresses on which management requests can be accepted. The transport must be HTTP, HTTPS, or both. With HTTP, messages can be encrypted using NTLM or Kerberos encryption. With HTTPS, Secure Sockets Layer (SSL) is used for encryption. You can examine the configured listeners by typing winrm enumerate winrm/config/listener. As Listing 1-1 shows, this command displays the configuration details for configured listeners.

Listing 1-1 Sample Configuration for Listeners

Listener
    Address = *
    Transport = HTTP
    Port = 80
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 192.168.1.225

By default, your computer is probably configured to listen on any IP address. If so, you won’t see any output. To limit WinRM to specific IP addresses, the computer’s local loopback address (127.0.0.1) and assigned IPv4 and IPv6 addresses can be explicitly configured for listening. You can configure a computer to listen for requests over HTTP on all configured IP addresses by typing the following:

winrm create winrm/config/listener?Address=*+Transport=HTTP

You can listen for requests over HTTPS on all IP addresses configured on the computer by typing this:

winrm create winrm/config/listener?Address=*+Transport=HTTPS

Here, the asterisk (*) indicates all configured IP addresses. Note that the CertificateThumbprint property must be empty to share the SSL configuration with another service.

You can enable or disable a listener for a specific IP address by typing

winrm set winrm/config/listener?Address=IP:192.168.1.225+Transport=HTTP
@{Enabled="true"}

Or

winrm set winrm/config/listener?Address=IP:192.168.1.225+Transport=HTTP
@{Enabled="false"}

You can enable or disable basic authentication on the client by typing

winrm set winrm/config/client/auth @{Basic="true"}

Or

winrm set winrm/config/client/auth @{Basic="false"}

You can enable or disable Windows authentication using either NTLM or Kerberos (as appropriate) by typing

winrm set winrm/config/client @{TrustedHosts="<local>"}

Or

winrm set winrm/config/client @{TrustedHosts=""}

In addition to managing WinRM at the command line, you can manage the service by using Group Policy. As a result, Group Policy settings might override any settings you enter.