Server Management Overview

Windows Server 2008 provides new tools, technologies and installation options to
improve the management experience.
For local administration of a single server, Server Manager is an integrated Microsoft
Management Console that offers IT professionals a seamless, integrated experience for
adding, removing, and configuring server roles, role services, and features. It also acts as
a portal for ongoing server management, monitoring and operations, by exposing key
management tasks based on server role, and providing access to advanced administration
tools.

Overview
There are a variety of utilities in Windows Server 2008 designed to allow easy, efficient
management. This section will provide an overview of the primary and secondary
management tools available to you, as well as improvements to assist with printer
management.

Primary Management Tools

Initial Configuration Tasks and Server Manager are the primary features of Windows
Server 2008 that will be useful to IT professionals responsible for computer management
and security throughout your organization:
Initial Configuration Tasks. Initial Configuration Tasks is a new feature designed to
guide information technology (IT) administrators through the process of configuring
a new server. Prior to Windows Server 2008, Windows server-class operating
system setup paused for administrators to provide administrator account, domain, and
network information. Feedback indicated that this practice slowed the operating
system and server deployment process because the completion of operating system
installation would be delayed until administrators responded to the prompts and
provided this information. Initial Configuration Tasks allows administrators to
postpone these tasks until installation is complete, meaning fewer interruptions
during installation.
Product activation can be done within a grace period (typically 30 days), and is not
critical for the initial configuration of the server; therefore, the Activate Your Server
command, present on the Manage Your Server window in Windows Server 2003,
has been removed from Initial Configuration Tasks.

Server Manager. Server Manager is a new Microsoft Management Console (MMC)

snap-in that provides a consolidated view of the server, including information about
server configuration, status of installed roles, and links for adding and removing roles
and features. Server Manager makes server administration more efficient by
providing a single tool for administrators to do the following:
View and make changes to server roles and features installed on the server.
Perform management tasks associated with the operational life cycle of the server,
such as starting or stopping services, and managing local user accounts.
Perform management tasks associated with the operational life cycle of roles
installed on the server.
Determine server status, identify critical events, and analyze and troubleshoot
configuration issues or failures.
Server Manager replaces a number of features from Microsoft Windows
Server 2003 such as Manage Your Server, Configure Your Server, and Add or
Remove Windows Components.

Benefits of Using Initial Configuration Tasks/Server Manager

An administrator will benefit from using Initial Configuration Tasks and Server Manager
because they:
Provide an easy, systematic way to complete important configuration tasks for a new
server through a single interface. After you complete these tasks, your server should
be able to perform its intended server role (for example, as a file server or print
server).
Provide a method to add and remove server roles and features more securely and
reliably.
Provide a single local management tool to examine server role status, perform key
management tasks, and access advanced management tools.
Ensure service prerequisites are met.
Alternative Management Tools
Windows Server 2008 provides you with a variety of alternative tools for managing your
servers more effectively:
ServerManagerCmd.exe. This command line tool enables you to automate the
deployment of server roles and features in Windows Server 2008. The tool accepts
parameters to display a list of all roles, role services, and features both installed and
available for installation; you can use parameters to install/uninstall server roles with
their default settings. ServerManagerCmd.exe can also be used with an XML file to
expedite automated installations and to add/remove roles and features.
Windows PowerShell. Windows PowerShell is a new command line shell and taskbased
scripting technology that provides information technology (IT) administrators
comprehensive control and automation of system administration tasks, increasing
administrator productivity. Windows PowerShell includes numerous system
administration utilities, consistent syntax and naming conventions, and improved
navigation of common management data such as the registry, certificate store, or
Windows Management Instrumentation (WMI). Windows PowerShell also includes
an intuitive scripting language specifically designed for IT administration.
Remote Management.
Windows Remote Manager. Windows Remote Manager is the Microsoft
implementation of WS-Management Protocol, a standard SOAP-based protocol
that allows hardware and operating systems to interoperate. Unlike DCOM-based
remote access, Windows Remote Management and WS-Management uses
standard, fixed ports, providing an elevated level of security. You can use
Windows Remote Management scripting objects, the Windows Remote
Management command-line tool, or the Windows Remote Shell command-line
tool to obtain management data from local and remote computers about objects
(disks, network adapters, services, or processes).
Windows Remote Shell (WinSH). You can use this tool to remotely manage
servers or to obtain management data through Window Remote Management
(WinRM) and Windows Management Instrumentation (WMI) objects on remote
servers.
Event Subscriptions. Event Viewer enables you to view events on a single remote
computer. However, troubleshooting an issue might require you to examine a set of
events stored in multiple logs on multiple computers. Windows Server 2008 and
Windows Vista include the ability to collect copies of events from multiple remote
computers and store them locally. To specify which events to collect, you create an
event subscription. Among other details, the subscription specifies exactly which
events will be collected and in which log they will be stored locally. Once a
subscription is active and events are being collected, you can view and manipulate
these forwarded events as you would any other locally stored events. Using the event
collecting feature requires that you configure both the forwarding and the collecting
computers. The functionality depends on the Windows Remote Management
(WinRM) service and the Windows Event Collector (Wecsvc) service. Both of these
services must be running on computers participating in the forwarding and collecting
process.
Task Scheduling based on Events. The Windows Server 2008 Task Scheduler MMC
snap-in helps you schedule automated tasks. It maintains a library of all scheduled
tasks, which provides an organized, convenient point of access for managing them.
The two key concepts involved in scheduling a task are triggers and actions. In
Windows Server 2008, the triggers that can be used to initiate an action have been
expanded to include on an event. This trigger causes the task to run when specific
event entries are added to an event log. You can choose between specifying basic
event trigger settings or custom event trigger settings. If you choose the basic event
trigger settings, a single event from a specific event log will trigger the task. You
specify the event log that contains the event, the event publisher name, and the event
identifier. If you choose the custom event trigger settings, you can specify an XML
event query or a custom event filter to query for events that will trigger the task.
Microsoft System Center. With the System Center family of IT management solutions,
you have the power to more effectively and easily manage all of the components that
define IT, allowing you to focus more on delivering new business value for your
organization.

Print Management
Print Management Overview
Effective print management can save you a significant amount of time when installing
printers on client computers and in managing and monitoring printers. Windows
Server 2008 includes Print Management, which is an MMC snap-in that enables you to
manage, monitor, and troubleshoot all of the printers within your organization from a
single interface, even those in remote locations such as branch offices.
Print Management provides centralized administration of all of the printers in the
organization from any computer running Windows Server 2003 R2, Windows Vista,
or Windows Server 2008 operating systems. Print Management is also available for
Windows XP clients (x86 and x64).
Print Management provides up-to-the-minute details about the status of all printers and
print servers on the network from one console. Print Management can help find printers
that have error conditions, and can also send e-mail notifications, or run scripts when a
printer or print server needs attention. On printer models that provide a Web interface,
Print Management can access this additional data allowing information such as toner and
paper levels to be managed easily.
By using Print Management in conjunction with the Configure Your Server Wizard and
Terminal Services, you can automatically search for and install network printers on a
local print server in branch offices. This is helpful when branch office personnel are not
trained in administrative duties.

Integration with Group Policy

Rather than having to install and configure printer connections on individual computers,
Print Management can be used with Group Policy to automatically add printer
connections to client computers Printers and Faxes folder, saving you time. A printer
connection setting can be automatically added to an existing Group Policy object (GPO)
in Active Directory. When Group Policy processing runs on client computers, the
printer connection settings are applied to the users or computers associated with the GPO.
Printers deployed by using this method appear in the Deployed Printers object of Print
Management tree when the print server they are connected to is being monitored.
This method of installing a printer is useful in laboratory, classroom, or branch office
settings where every computer in the room or office needs access to the same printer. It is
also useful in large organizations, where computers and printers are often separated by
function, workgroup, or department. A printer connection that has been installed by using
a per-user connection is available to the user, no matter what computer the user logs on to.
A printer connection that has been installed by using a per-computer connection appears
in the Printers and Faxes folder and is available to any user of that computer.

Troubleshooting Printers
Print Management has several features that may help identify and resolve printer
problems, even in remote locations:
Setting pre-defined filters lets you easily find all printers that are not in Ready status
or that have print jobs backed up queue.
Many devices, regardless of manufacturer, provide rich status information, which is
readily available to Print Management. By closely monitoring the printers within the
organization, you may be able to resolve problems before they happen, such as
identifying when paper or toner is low.
E-mail message notifications can be set up to alert administrators when a printer
requires attention. This is especially useful when your organization has printers at
multiple locations with different people responsible for managing them. By using an
automated system to notify the IT staff when a printer or print server is down, the
problem may be resolved sooner reducing the impact of printer and print server
problems.

Technical Background
Initial Configuration Tasks
After Setup for Windows Server 2008 is complete, Initial Configuration Tasks guides
you through the procedures that are necessary to configure a new server, such as
specifying the administrator password, the computer name, the domain, and desired
server roles.
Initial Configuration Tasks replaces the Post-Setup Security Updates feature that was
introduced in Windows Server 2003 Service Pack 1 (SP1). Initial Configuration Tasks
extends the functionality of Post-Setup Security Updates by guiding you through all of
the tasks you must complete to configure a new server, not just those tasks that are
related to security.
With Initial Configuration Tasks, it is much easier to configure a new server with
Windows Server 2008 than it was to configure a new server with Windows Server 2003
operating systems. For example, during Setup you are asked for only minimal
information, such as product key information and an acceptance of the End-User License
Agreement. After you have installed the operating system, you can then use Initial
Configuration Tasks to configure the server. Setup assigns default values for other
configurations unless you specify otherwise. For example, by default, network cards are
configured to obtain an Internet Protocol (IP) address that is assigned by Dynamic Host
Configuration Protocol (DHCP). Also, by default, the server will be a member of a
workgroup.

To use Initial Configuration Tasks, you must be logged on to the computer as an

administrator. When you first install the operating system, you will automatically be
logged on as an administrator and the administrator password will be blank until
you configure it.
Tasks you can perform with Initial Configuration Tasks:
Create an administrator password.
Set time zone.
Configure networking.
Provide computer name and domain.
Enable automatic updating and feedback.
Download and install updates.
Add roles.
Add features.
Enable Remote Desktop.
Configure Windows Firewall.
Server Manager
Server Manager is designed to guide administrators through the process of installing,
configuring, and managing server roles and features that are part of the Windows
Server 2008 release. While adding and removing server roles and features is not new,
Server Manager unifies the functionality of multiple earlier tools in a single, simple,
MMC-based user interface.
Server Manager is launched automatically after you complete the tasks listed in Initial
Configuration Tasks. After that, it is also launched automatically when an administrator
logs on to the server. At any time Server Manager can be started using the following
methods:
On the Start menu
On the Start menu, right-click Computer, and then click Manage
On the Start menu, point to Administrative Tools, and then click Server Manager
Quick Launch toolbar available on the Windows taskbar
Server Manager is installed by default as part of the Windows Server 2008 setup
process. To use Server Manager, you must be logged on to the computer as an
administrator.

The main window of the Server Manager console contains the following four collapsible
sections:
Server Summary. This section includes two subsections, System Information and
Security Summary.
System Information displays the computer name, domain, local administrator
account name, network connections, and the product ID of the operating system.
Commands in the System Information subsection allow you to edit this
information.
Security Summary displays whether Windows Update and Windows Firewall are
enabled. Commands in the Security Summary subsection allow you to edit these
settings or view advanced options.
Roles Summary. This section contains a table indicating which roles are installed on
the server. Commands in this section allow you to add or remove roles, or go to a
more detailed console in which you can manage a specific role.
Features Summary. This section contains a table indicating which features are
installed on the server. Commands in this section allow you to add or remove features.
Resources and Support. This section displays whether this server is participating in
the feedback programs Windows Server CEIP and Windows Error Reporting.
Resources and Support is also designed to be a launch point for joining topical
newsgroups, or for locating additional Help and research topics available online.
Server Manager Wizards
The Server Manager collection of wizards allows you to add, remove, or augment
multiple roles in a single session, streamlining the task of deploying servers in your
enterprise by reducing the time required. Role configurations are configured with
recommended security settings by default; there is no requirement to run the Security
Configuration Wizard following role or feature installation unless it is necessary to
modify security defaults.
Earlier versions of Windows Server required you to use Configure Your Server, Manage
Your Server, or Add or Remove Windows Components to add or remove server roles or
other software. Dependency checks were limited, and Add or Remove Windows
Components limited administrators to the installation of only one role at a time. Before
you could add more roles, installation of each role had to complete. Windows
Server 2008 performs dependency checks as you progress through the Server Manager
wizards, ensuring that all the roles and role services needed by a role you select are
installed, and none are removed that might still be required by remaining roles or role
services.

In addition to Initial Configuration Tasks, Server Manager is composed of the following

elements, each with a corresponding wizard:
What Are Server Roles?
A server role describes the primary function of the server. Administrators may choose to
dedicate an entire server to one role, or install multiple server roles on a single computer.
Each role may include one or more role services, or optionally installable elements of the
role.
No server roles are installed by default.
Server Manager provides a single point of access to management snap-ins for all installed
roles. Adding a role automatically creates a management console home page in Server
Manager for that role, which displays events and service status for all services that are
part of the role. Role services, or subcomponents of a role, are listed in a section of this
page. Administrators can open wizards to add or remove role services by using
commands on this home page.

The following roles are available in Windows Server 2008 and can be installed and
managed through Server Manager:
What Are Features?
A feature does not generally describe the primary function of the server. Instead, it
describes an auxiliary or supporting function. Consequently, an administrator typically
installs a feature not as the primary function of the server, but to augment the
functionality of an installed role. For example, Failover Clustering is a feature that
administrators can choose to install after installing specific roles, such as File Server, in
order to make the File Server role more redundant.
The following features are available in Windows Server 2008 and can be installed by
using Server Manager:

New Management Group Policy Settings

You can use Group Policy to control the behavior of Initial Configuration Tasks and
Server Manager at startup by enabling the following policies:
Do not open Initial Configuration Tasks window automatically at logon.
Do not open Server Manager automatically at logon.

Implementation/Usage Scenarios
Improved New Server Deployment and Configuration
Windows Server 2008 installation procedures allow administrators to postpone nonessential
tasks until the installation is complete, meaning fewer interruptions during
the installation.
Initial Configuration Tasks provides an easy, secure way to complete important
configuration tasks and guides IT administrators through the process of configuring a
new server, ensuring that required tasks are performed.
Improved Security
Roles and features installed by using Server Manager are secure by default.
Administrators can subsequently run the Security Configuration Wizard to change
the default settings.
Improved Server Administration
The Server Manager console provides a single interface to:
Provide a consolidated view of the server, including information about server
configuration, status of installed roles and features.
Provide a method to add or remove roles and features from a server.
Perform management tasks associated with the operational lifecycle of the server,
such as starting or stopping services, and managing local user accounts.
Determine server status, identify critical events, and analyze and troubleshoot
configuration issues or failures.
ServerManagerCmd.exe allows you to automate the deployment of server roles and
features in Windows Server 2008. It can also be used with an XML file to expedite
automated unattended installations and to add/remove roles and features.

Server Core
Overview
Server Core Installation
Server core is not a separate version of Windows Server 2008; rather, it is a new
installation option which provides a minimal environment for running specific server
roles, reducing the maintenance and management requirements and the attack surface for
those servers. There are no changes to your environment or infrastructure required.
A server core installation supports the following server roles:
Active Directory Domain Services
Active Directory Lightweight Directory Services
DHCP Server
DNS Server
File Services
Print Services
Windows Media Services
Windows Virtualization Services
You can run Windows Server Virtualization (WSv) using a Server Core installation
of Windows Server 2008 as a host system. This will allow you to benefit from
Server Cores reduced software maintenance and file management needs and its
smaller footprint (less than 1GB of disk space is required for operating system
installation).
The server core installation option installs only the subset of the Server binaries that are
required by the above server roles. For example, the Explorer shell is not installed as part
of a server core installation. Instead, the default user interface for a server running a
server core installation is the command prompt.
A server core installation is ideal in situations where you need to:
Increase server stability.
Reduce server management.
Reduce the attack surface of a server.
Reduce software maintenance.
Reduce hardware requirements.
Benefits
A server core installation of Windows Server 2008 provides the following benefits:
Because a server core installation installs only what is required to run the supported
server roles:
Less servicing is required than on a full installation of Windows Server 2008 and
the server is more stable.
Less maintenance is required than on a full installation of Windows Server 2008.
Because fewer applications run on the server:
The attack surface of the server is decreased.
There is less to manage.
Hardware requirements are reduced because a server core installation requires less
disk space.
Do I need to change my code to work with Windows Server 2008?
Server Core is not an application platform; therefore, you cannot run or develop server
applications on a Server Core installation. A Server Core installation can only be used to
run the supported server roles and management tools. Server Core does, however, support
development of management tools and agents, which can be divided into two categories:
Remote Management tools. These tools do not require any changes, as long as they
use one of the protocols supported in Server Core to communicate with the remote
management workstation, such as RPC.
Local Management tools and agents. These tools might require changes to work with
Server Core, since they cannot have any shell or user interface dependencies, nor use
managed code.

Technical Background
Prerequisites for Deploying a Server Core Installation
An installation of Windows Server 2008 server core requires the following:
Windows Server 2008 media
A valid product key
A computer on which you can do a clean installation of server core
Only clean installations of Windows Server 2008 server core are supported.
There is no way to upgrade from a previous version of the Windows Server
operating system to a server core installation.
There is no way to upgrade from a full installation of Windows Server 2008 to a
server core installation.
There is no way to upgrade from a server core installation to a full installation of
Windows Server 2008.
Administrative credentialsif you are going to join the server core installation to an
existing Windows domain, you will need a user name and password for an account
that has the credentials to join a computer to the domain.
Deploying a Server Core installation
Because a server core installation does not include the Windows user interface, there is
no "Out of Box Experience" to allow you to complete the configuration of the server.
Instead you must manually complete the configuration using the command-line tools or
by performing an unattended install using
All commands in Server Core are case sensitive.
In addition to benefits typical of using an unattend file, performing an unattended install
of server core also provides the following benefits:
There is no need to perform the initial configuration using command-line tools.
You can include the settings in the unattend file to enable remote administration as
soon as setup is complete.
You can configure settings that cannot be easily modified from the command line,
such as display resolution.
The steps required for configuring a server core installation are as follows:
Set the password for the local administrator account.
In the command prompt, type net user administrator * and then press Enter. Type
the administrator password and press Enter.
Set a static IP address using standard NETSH commands (if you are not using
DHCP).
In the command prompt, type ipconfig /all and press ENTER. (The default setting
for the network configuration is displayed. By default Windows Server 2008 server
core uses DHCP configuration.)
In the command prompt, type netsh interface IPv4 show interface and then press
ENTER. (The list of network interfaces for the server are now shown. Note the Idx
value for the Local Area Connection.)
In the command prompt, type netsh interface ipv4 set address name=2
source=static address=192.168.1.50 mask=255.255.255.0 and press ENTER.
In the command prompt, type ipconfig /all and press ENTER. (The network
interface idx value was used as the name in the previous command. In addition,
the setting for gateway may be required in most circumstances. The return of the
ipconfig command reflects the new settings.)
In the command prompt, type netsh interface ipv4 add dnsserver name=2
address=192.168.1.1 index=1 and press ENTER. (The DNS Server setting has
been added to the interface. To add additional DNS server addresses, repeat the
command and increment the index value by 1.)

Join a domain (if the server will be a member) and activate the server.
In the command prompt, type netdom join NYC-CORE-01
/domain:woodgroovebank.com /userd:administrator /passwordD:* and press
ENTER.
When prompted, type the administrator password and press Enter.
In a production environment it would also be necessary to activate the server. From
the command line, this can be done by using: Slmgr.vba ato.
To complete the configuration, reboot the server.
View/Configure the Firewall.
In the command prompt type netsh and press Enter. Type advfirewall and press
Enter.
In the command prompt, type show mode and press ENTER. The returned value
indicate that the firewall is currently turned on.
You can configure rules via the netsh advfirewall firewall prompt.
Server Roles on a Server Core Installation
Once the server core installation is complete and the server is configured for use, you can
then install one of more of the supported server roles and associated features.
DNS Server. To install the DNS server role
From the command, type:
Start /w ocsetup DNS-Server-Core-Role
You can also uninstall roles and features with the ocsetup command, for example:
start /w ocsetup DNS-Server-Core-Role /uninstall
DHCP Server. To install at the command prompt, type:
Start /w ocsetup DHCPServerCore
Configure a DHCP scope from the command line using netsh, or remotely using
the DHCP snap-in.
If the DHCP server is installed in an Active Directory domain, dont forget to
authorize it in Active Directory.
File Server. This role is installed by default; however, there are a number of features
that you can install from the command line as follows:
File Replication Service: start /w ocsetup FRS-Infrastructure
Distributed File System: start /w ocsetup DFSN-Server
Distributed File System Replication: start /w ocsetup DFSR-Infrastructure-
ServerEdition
Network File System: start /w ocsetup ServerForNFS-Base
DFSR is a brand new replication engine. FRS still exists in Windows Server 2008
and is used by default for SYSVOL replication. Once clients have established a
Windows Server 2008 Domain Functional Mode they will be able to utilize DFSR
and remove FRS.
Media Services. To install this role, at the command prompt, type:
start /w ocsetup MediaServer
After installation, use the Media Services MMC to remotely configure media
services.
Active Directory Domain Services. To install this role, at the command prompt, type:
Dcpromo /unattend:Unattendfile where Unattendfile is the name of a dcpromo
unattend file

Optional Features on a Server Core Installation

Once the installation is complete and the server is configured for use, you can install
optional features. The server core installation of Windows Server 2008 supports the
following optional features, which can be installed from a command prompt by typing:
Start /w ocsetup featurename (where featurename is the name show in the following
table:
The following optional features require appropriate hardware: Failover Cluster,
Network Load Balancing, Multipath I/O, Removable Storage and Bitlocker Drive
Encryption.
Managing a Server Core Installation
A Server Core installation requires initial configuration from the command line, because
it does not include the traditional full graphical user interface. Once configured, the
server can be managed in the following ways:
Remotely via Terminal Server. Using another computer, you can use the Terminal
Server client to connect to the server running the server core installation and manage
it remotely. The shell in the Terminal Server session will be the command prompt.
To allow you to run cmd.exe in a window on your local computer rather than in the
full terminal services client, publish cmd.exe using Terminal Services Remote
Programs.
Remotely via Windows Remote Shell. Using another computer running
Windows Vista or Windows Server 2008, you can use Windows Remote Shell to run
command line tools and scripts on the server core-based server.
Remotely via MMC. Using an MMC snap-in, you can connect to a server running a
server core installation as you would any other computer running Windows.
Locally and remotely via the Command Prompt. Using the Windows command line
tools at the command prompt, you can manage servers running a server core
installation.
Not all tasks can be performed from the command line or remotely through an MMC
snap-in. To allow you to configure these settings, there is a script included with the server
core installation of Windows Server 2008 that can be used to:
Enable automatic updates.
Enable error reporting.
Enable Terminal Server Remote Admin Mode.
Enable Terminal Server clients on previous versions of Windows to connect to a
Windows server core-based computer.
Enable remote management of IPSec.
Configure DNS SRV record weight and priority.
 View a list of common command line tools.
The script, scregedit.wsf, is located in the \Windows\System32 folder of the server
running the server core installation.

Implementation/Usage Scenarios
Reduced Maintenance
Because a server core installation installs only what is required to run the supported
server roles, less maintenance is required than on a full installation of Windows
Server 2008.
Reduced Attack Surface
Because server core is a minimal installation, there are fewer applications run on the
server, thereby decreasing the attack surface.
Reduced Management
Because fewer applications and services are installed on a server running the server core
installation, there is less to manage.
Less Disk Space Required
Less disk space is required for a server core installation.

Windows PowerShell
Overview
What is Windows PowerShell?
Windows PowerShell is a new Windows command-line shell designed especially for
system administrators. The shell includes an interactive prompt and a scripting
environment that can be used independently or in combination. In Windows Server 2008,
it is installed as a feature.
Windows PowerShell is considered to be the new standard for command-line and
scripting for administrators. Future tools will be built around it and will generate scripts
for you so that you to use.
Windows PowerShell provides an easier way for you to perform administrative tasks. For
example, in the past in order to make a change to the registry you would need to import
or export files. With PowerShell you can simply write to the registry as though it were
any other file.
While Windows PowerShell is considered to be the new standard, it is not a
replacement for existing mechanisms, such as VBScript or WMI scripting.
What are PowerShell Cmdlets?
Windows PowerShell can still run any external command line utilities that you are used
to using, which means you can use it immediately, taking advantage of the knowledge
and experience you already have while learning to use the new power that PowerShell
provides.

Windows PowerShell introduces the concept of a cmdlet (pronounced "command-let"),

which is a single-feature command that manipulates objects in Windows PowerShell.
You can use each cmdlet separately, but their power is realized when you use these
simple tools in combination to perform complex tasks. Like many shells, Windows
PowerShell gives you access to the file system on the computer. In addition, Windows
PowerShell providers enable you to access other data stores, such as the registry and the
digital signature certificate stores, as easily as you access the file system.
You can recognize cmdlets by their name format -- a verb and noun separated by a dash
(-), such as Get-Help, Get-Process, and Start-Service.
Windows PowerShell includes more than one hundred basic core cmdlets; in
addition, you can write your own cmdlets and share them with other users.
Benefits
Windows PowerShell is designed to improve the command-line and scripting
environment by eliminating long-standing problems and adding new features:
Discoverability. Windows PowerShell makes it easy to discover its new features by
typing simple commands.
Consistency. Managing systems can be a complex endeavor and tools that have a
consistent interface help to control the inherent complexity. Unfortunately, neither
command-line tools nor scriptable COM objects have been known for their
consistency.
The consistency of Windows PowerShell is one of its primary assets. For example, if
you learn how to use the Sort-Object cmdlet, you can use that knowledge to sort the
output of any cmdlet. You do not have to learn the different sorting routines of each
cmdlet.
In addition, cmdlet developers do not have to design sorting features for their cmdlets.
Windows PowerShell gives them a framework that provides the basic features and
forces them to be consistent about many aspects of the interface. The framework
eliminates some of the choices that are typically left to the developer, but, in return, it
makes the development of robust and easy-to-use cmdlets much simpler.
Interactive and Scripting Environments. Windows PowerShell is a combined
interactive and scripting environment that gives you access to command-line tools
and COM objects, and also enables you to use the power of the .NET Framework
Class Library (FCL).
This environment improves upon the Windows Command Prompt, which provides an
interactive environment with multiple command-line tools. It also improves upon
Windows Script Host (WSH) scripts, which let you use multiple command-line tools
and COM automation objects, but do not provide an interactive environment.

By combining access to all of these features, Windows PowerShell extends the ability
of the interactive user and the script writer, and makes system administration more
manageable.
Object Orientation. Although you interact with Windows PowerShell by typing
commands in text, Windows PowerShell is based on objects, not text. The output of a
command is an object. You can send the output object to another command as its
input. As a result, Windows PowerShell provides a familiar interface to people
experienced with other shells, while introducing a new and powerful command-line
paradigm. It extends the concept of sending data between commands by enabling you
to send objects, rather than text.
Easy Transition to Scripting. Windows PowerShell makes it easy to transition from
typing commands interactively to creating and running scripts. You can type
commands at the Windows PowerShell command prompt to discover the commands
that perform a task. Then, you can save those commands in a transcript or a history
before copying them to a file for use as a script.
Security. Windows PowerShell provides for increased security because:
Scripts cannot be run by default.
Scripts can be configured to only if they are digitally-signed.
Scripts are not permitted to highjack a command name.
While the PS1 filename extension is assigned to PowerShell scripts, by default it
is not associated with PowerShell. If you double-click on a .ps1 file, it will open
it in Notepad rather than launching it.
PowerShell security is centrally-controllable. An Administrative (ADM) template
adds Windows PowerShell options to a Group Policy Object (GPO).
What can I do with Windows PowerShell?
With Windows PowerShell you can:
Automate administration of multiple servers through a task-oriented scripting
language.
Accelerate script authoring, testing and debugging and write customer tools in a new
command shell environment.
Utilize new scripts and Cmdlets.
Manage command-line services, processes, registry, and WMI data.
Manage and/or automate administration tasks for server roles such as IIS and Active
Directory.

Automate Terminal Server configuration changes by means of PowerShell scripts,

and examine configuration similarities and differences across a Terminal Server farm.
Manage an Internet Information Services 7.0 environment.
Remotely manage servers.
Prerequisites
Windows PowerShell requires the following programs:
Windows XP Service Pack 2, Windows 2003 Service Pack 1, or later versions of
Windows
Microsoft .NET Framework 2.0
If any version of Windows PowerShell is already installed on the computer, use
Add or Remove Programs in Control Panel to uninstall it before installing a new
version.

Technical Background
Native Support for Different Type Systems
Windows PowerShell adapts WMI, XML, ASDI, ADO, and COM objects to provide a
common syntax to access their properties and methods.
Working with Cmdlets
You can run Windows command-line programs in Windows PowerShell, and you can
start Windows programs that have a graphic user interface, such as Notepad and
Calculator, within the shell. You can also capture the text that programs generate and use
that text in the shell, in much the same way you would in Cmd.exe.
In traditional shells, commands are executable programs that range from the very simple
(such as attrib.exe) to the very complex (such as netsh.exe). In Windows PowerShell,
most cmdlets are very simple, and they are designed to be used in combination with other
cmdlets. For example, the "get" cmdlets only retrieve data, the "set" cmdlets only
establish or change data, the "format" cmdlets only format data, and the "out" cmdlets
only direct the output to a specified destination.
Each cmdlet has a help file that you can access by typing:
get-help <cmdlet-name> -detailed
The detailed view of the cmdlet help file includes a description of the cmdlet, the
command syntax, descriptions of the parameters, and example that demonstrate use of the
cmdlet.

A New Scripting Language

If you run particular commands or command sequences repeatedly, or if you develop a
series of commands to perform a complex task, you will want to save your commands in
a file and execute the command file, instead of typing commands at the prompt. A file of
commands is called a script.
Windows PowerShell uses its own language for scripting, rather than reusing existing
languages, for the following reasons:
Windows PowerShell needed a language for managing.NET objects.
The language needed to provide a consistent environment for using cmdlets.
The language needed to support complex tasks, without making simple tasks more
complex.
The language needed to be consistent with higher-level languages used in .NET
programming, such as C#.
In Windows PowerShell, script files have a .ps1 file name extension.
Important PowerShell Concepts
The Windows PowerShell design integrates concepts from many different environments.
Several of them are familiar to people with experience in specific shells or programming
environments, but very few people will know about all of them. Looking at some of these
concepts provides a useful overview of the shell.
Commands are not Text-based. Unlike traditional command-line interface commands,
Windows PowerShell cmdlets are designed to deal with objects - structured
information that is more than just a string of characters appearing on the screen.
Command output always carries along extra information that you can use if you need
it.
If you have used text-processing tools to process command-line data in the past, you
will find that they behave differently if you try to use them in Windows PowerShell.
In most cases, you do not need text-processing tools to extract specific information.
You can access portions of the data directly by using standard Windows PowerShell
object manipulation commands.
The Command Family is Extensible. Interfaces such as Cmd.exe do not provide a
way for you to directly extend the built-in command set. You can create external
command-line tools that run in Cmd.exe, but these external tools do not have services,
such as help integration, and Cmd.exe does not automatically know that they are
valid commands.

The native binary commands in Windows PowerShell can be augmented by cmdlets

that you create and that you add to Windows PowerShell by using snap-ins. Windows
PowerShell snap-ins are compiled, just like binary tools in any other interface. You
can use them to add Windows PowerShell providers to the shell, as well as new
cmdlets.
Windows PowerShell can run commands other than cmdlets. It supports scripts that
are analogous to Cmd.exe batch files, but have a .ps1 file name extension. Windows
PowerShell also allows you to create internal functions that can be used directly in
the interface or in scripts.
Windows PowerShell Handles Console Input and Display. When you type a
command, Windows PowerShell always processes the command-line input directly.
It also formats the output that you see on the screen. This is significant because it
reduces the work required of each cmdlet and ensures that you can always do things
the same way regardless of which cmdlet you are using.
If you run an graphic application in Windows PowerShell, the window for the
application opens. Windows PowerShell intervenes only when processing the
command-line input you supply or the application output returned to the console
window; it does not affect how the application works internally.
Windows PowerShell Pipeline
Pipelines act like a series of connected segments of pipe. Items moving along the pipeline
pass through each segment. To create a pipeline in Windows PowerShell, you connect
commands together with the pipe operator "|" and the output of each command is used as
input to the next command.
Pipelines are arguably the most valuable concept used in command-line interfaces.
Properly used, pipelines not only reduce the effort involved in entering complex
commands, but also make it easier to see the flow of work in the commands. A related
useful characteristic of pipelines is that since they operate on each item separately, you
do not have to modify them based on whether you will have zero, one, or many items in
the pipeline. Furthermore, each command in a pipeline (called a pipeline element) usually
passes its output to the next command in the pipeline item-by-item. This usually reduces
the resource demand of complex commands and allows you to begin getting the output
immediately.
Processing Objects. Technically, a .NET object is an instance of a .NET class that
consists of data and the operations associated with that data. But you can think of an
object as a data entity that has properties, which are like characteristics, and methods,
which are actions that you can perform on the object.

For example, when you get a service in Windows PowerShell, you are really getting
an object that represents the service. When you view information about a service, you
are viewing the properties of its service object. And, when you start a service, that is,
when you change the Status property of the service to "started," you are using a
method of the service object.
All objects of the same type have the same properties and methods, but each instance
of an object can have different values for the properties. For example, every service
object has a Name and Status property. However, each service can have a different
name and a different status.
Using Familiar Command Names (Aliasing)
Using a mechanism called aliasing, Windows PowerShell allows you to refer to
commands by alternate names. Aliasing allows users with experience in other shells to
reuse common command names that they already know to perform similar operations in
Windows PowerShell.
Aliasing associates a command name that you type with another command. For
example, Windows PowerShell has an internal function named Clear-Host that
clears the output window. If you type either the cls or clear command at a command
prompt, Windows PowerShell interprets that this is an alias for the Clear-Host
function and runs the Clear-Host function.
Aliasing helps you to learn Windows PowerShell. First, most users have a large
repertoire of commands that users already know by name, and although the Windows
PowerShell equivalents may not produce identical results, they are close enough in
form that users can use them to do work without having to first memorize the
Windows PowerShell names. Second, the major source of frustration in learning a
new shell when the user is already familiar with another shell is the errors that are
caused by "finger memory". If you have used Cmd.exe for years, when you have a
screen full of output and want to clean it up, you would reflexively type the cls
command and press the ENTER key. Without the alias to the Clear-Host function in
Windows PowerShell, you would simply get the error message "'cls' is not
recognized as a cmdlet, function, operable program, or script file" and be left with no
idea of what to do to clear the output.
Windows PowerShell Navigation
Folders, or directories as they are more commonly known, are a useful concept for
organizing files and other directories. This approach does not ensure that the content is
readable or usable by particular applications, but it does make it simpler to find specific
items. Tools that enumerate or search through files and folders work with these devices
as well. You can also address a specific item by using the path to the file that represents it.

Analogously, the Windows PowerShell infrastructure supports exposing virtually

anything that can be navigated like a standard Microsoft Windows disk drive as a
Windows PowerShell Drive. A Windows PowerShell Drive does not necessarily
represent a real drive, either locally or on the network.
This section primarily discusses navigation for file systems, but the concepts apply
to Windows PowerShell Drives that are not associated with file systems.
Managing the Current Location in PowerShell. When navigating folder systems in
Windows Explorer, you usually have a specific working location - namely, the
current open folder. Items in the current folder can be manipulated easily by clicking
them. For command-line interfaces such as Cmd.exe, when you are in the same
folder as a particular file, you can access it by specifying a relatively short name,
rather than needing to specify the entire path to the file. The current directory is
called the working directory.
Windows PowerShell uses the noun Location to refer to the working directory, and
implements a family of cmdlets to examine and manipulate your location.
Managing Windows PowerShell Drives. A Windows PowerShell drive is a data store
location that you can access like a file system drive in Windows PowerShell. The
Windows PowerShell providers create some drives for you, such as the file system
drives (including C: and D:), the registry drives (HKCU: and HKLM:), and the
certificate drive (Cert:), and you can create your own Windows PowerShell drives.
These drives are very useful, but they are available only within Windows
PowerShell. You cannot access them by using other Windows tools, such as
Windows Explorer or Cmd.exe.
Windows PowerShell uses the noun PSDrive for commands that work with Windows
PowerShell drives.
Working with Files, Folders and Registry Keys. Windows PowerShell uses the noun
Item to refer to things found on a Windows PowerShell drive. When dealing with the
Windows PowerShell FileSystem provider, an Item might be a file, a folder, or the
Windows PowerShell drive.
Manipulating Items Directly. The elements that you see in Windows PowerShell
drives, such as the files and folders in the file system drives, and the registry keys in
the Windows PowerShell registry drives, are called items in Windows PowerShell.
With PowerShell you can create, rename, move, copy, delete and execute items.
Working with Objects. The power of objects is that they provide you with access to a
lot of complex data and it is already correlated. With some simple techniques in
Windows PowerShell you can further manipulate objects to do even more work.
Using Windows PowerShell for Administration
The fundamental goal of Windows PowerShell is providing better, easier administrative
control over systems, either interactively or from script. PowerShell administrative
capabilities include:
Managing Local Processes. There are only two core Process cmdlets, Get-Process
and Stop-Process. Because it is possible to inspect and filter processes using either
parameters or the Object cmdlets, you can perform some complex tasks using only
these two cmdlets.
Managing Local Services. There are eight core Service cmdlets, designed for a wide
range of service tasks. You can get a list of Service cmdlets by using Get-Help *-
Service, and you can find information about each Service cmdlet by using Get-
Help<Cmdlet-Name>, such as Get-Help New-Service.
Collecting Information About Computers. Get-WmiObject is the most important
cmdlet for general system management tasks. All critical subsystem settings are
exposed via WMI. Furthermore, WMI treats data as objects that are in collections of
one or more items. Because Windows PowerShell also works with objects and has a
pipeline that allows you to treat single or multiple objects in the same way, generic
WMI access allows you to perform some advanced tasks with very little work.
Working with Software Installations. Applications correctly designed to use the
Windows Installer can be accessed through WMI's Win32_Product class, but not all
applications in use today use the Windows Installer. Applications that are installed by
copying the application files must be managed using the techniques for managing
files and folders.
Changing Computer State: Locking, Logging Off, Shutting Down, and Rebooting.
You can reset a computer in several different ways from Windows PowerShell, but in
the initial release you must use either a standard command-line tool or WMI.
Working with Printers. Printer management tasks can be performed in Windows
PowerShell with both WMI and the WScript.Network COM object from WSH.
Performing Networking Tasks. Most low-level network protocol administration tasks
involve TCP/IP, because TCP/IP is the most commonly used network protocol. A
variety of network tasks can be performed in PowerShell:
IP Configuration tasks
DHCP Configuration tasks
Working with network shares

Working with Files and Folders. Navigating through Windows PowerShell drives
and manipulating the items on them is similar to manipulating files and folders on
Windows physical disk drives.
Working with Registry Keys and Entries. Because registry keys are items on
Windows PowerShell drives, working with them is very similar to working with files
and folders. One critical difference is that every item on a registry-based Windows
PowerShell drive is a container, just like a folder on a file system drive. However,
registry entries and their associated values are properties of the items, not distinct
items.
Windows PowerShell Security
Scripting is a very powerful tool, but it can be misused for malicious purposes. To protect
user data and the integrity of the operating system, Windows PowerShell includes several
security features, among which are the execution policy and PowerShell profiles.
Execution Policy. The Windows PowerShell execution policy determines whether
scripts are allowed to run and, if they can run, whether they must be digitally signed.
It also determines whether configuration files can be loaded.
The default execution policy, Restricted, is the most secure of the execution policies.
It does not permit any scripts to run, and it does not permit any configuration files,
including a Windows PowerShell profile, to be loaded. You can still use Windows
PowerShell interactively; however, if you want to run scripts or load configuration
files, you would have to change the execution policy on your system.
Windows PowerShell Profiles. When you add aliases, functions, and variables to
Windows PowerShell, you are actually adding them only to the current Windows
PowerShell session. If you exit the session or close Windows PowerShell, the
changes are lost. To retain these changes, you can create a Windows PowerShell
profile and add the aliases, functions, and variables to the profiles. The profile is
loaded every time that Windows PowerShell starts.
To load a profile, your Windows PowerShell execution policy must permit you to
load configuration files. If it does not, the attempt to load the profile fails and
Windows PowerShell displays an error message.
You can have four different profiles in Windows PowerShell. The profiles are listed
in load order. The most specific profiles have precedence over less specific profiles
where they apply.
%windir%\system32\WindowsPowerShell\v1.0\profile.ps1 (This profile applies to
all users and all shells.)
%windir%\system32\WindowsPowerShell\v1.0\ Microsoft.PowerShell_profile.ps
1 (This profile applies to all users, but only to the Microsoft.PowerShell shell.)

%UserProfile%\My Documents\WindowsPowerShell\profile.ps1 (This profile

applies only to the to the current user, but affects all shells.)
%UserProfile%\\MyDocuments\WindowsPowerShell\Microsoft.PowerShell_prof
ile.ps1 (This profile applies only to the current user and the
Microsoft.PowerShell shell.)
You can create, share, and distribute profiles to enforce a consistent view of
Windows PowerShell in a larger enterprise.
The profiles are not created automatically. To create a profile, create a text file with
the specified name in the specified location.

Implementation/Usage Scenarios
Command-Line Services, Processes, Registry, and WMI Data
Management
Common as-needed server administration tasks, such as identifying running services or
processes, viewing the registry, and reading and changing settings stored in Windows
Management Instrumentation (WMI), are easier than ever with the built-in command-line
tools (cmdlets) get-service, get-process, get-wmiobject, and the registry provider for
Windows PowerShell.
Server Management
Windows PowerShell allows you to manage specific Windows Server 2008 roles, such as
Active Directory, Internet Information Services (IIS) 7.0 and Terminal Server, as well as
Exchange Server 2007 and Microsoft Operations Manager 2007. In addition, a number of
partners have provided Windows PowerShell commands that improve network
management, and provide rich charting and gauge capabilities.
Terminal Server Management. Because Terminal Server stores a wealth of data in
WMI, administrators can automate Terminal Server configuration changes by means
of Windows PowerShell scripts, and examine configuration similarities and
differences across a Terminal Server farm. There are numerous script examples in
Microsofts TechNet ScriptCenter.
Internet Information Services 7.0. Windows PowerShell is ideally suited to managing
IIS 7.0, including deploying and configuring IIS 7.0 across a web farm.

Windows Remote Management

Overview

Remote Hardware Management

Windows Remote Management hardware management is intended to reduce overall IT
administration costs by providing monitoring and control of remote hardware
components, especially before the system is started and after an operating system failure.
Original Equipment Manufacturers (OEMs) have developed a common architecture to
address the need for hardware management. An important piece of this architecture is the
baseboard management controller (BMC). A BMC is a specialized device that monitors
the state of the server computer.
The BMC provides remote control of server hardware, retrieves status data, and receives
notifications about critical errors and other hardware state changes. A script or
application that is monitoring a remote server can obtain data from the server either inband,
through the remote operating system, or out-of-band, directly from the BMC.
A BMC has sensors that can detect, for example, when the server computer is
overheating or when voltage is out of the acceptable range. Several standards exist to
define the architecture of BMC. The Intelligent Platform Management Interface (IPMI) is
one such standard that is used frequently. However, despite the IPMI standard,
management access to server hardware is proprietary and requires use of management
tools supplied by OEMs. Also, remote access to a BMC is provided using a specialized
wire protocol, Remote Management Control Protocol (RMCP), which has non-standard
security mechanisms for authentication of access.

The Microsoft IPMI provider and IPMI driver, allow you to obtain BMC data from
remote server computers through a standard WMI provider with WMI classes. While you
can write a normal WMI script that obtains remote data through DCOM, in many cases
the preferred method of obtaining IPMI data is through the WinRM command line utility,
the WinRM Scripting API, or WinRM C++ API.
The BMC also has an event database called the System Event Log (SEL) which records
events in the monitored computer. You cannot subscribe to have these events delivered to
a script as you can with WMI event classes. However, you can use the Wecutil.exe
command line tool to subscribe to them.
Windows Remote Management
Windows Remote Management (WinRM) is the Windows implementation of WSManagement,
an industry-standard Web services-based protocol. Windows Remote
Management provides a secure, efficient way for management applications and scripts to
communicate with local and remote computers. The Windows service that Windows
Remote Management installs and uses is called WinRM.
When a server is connected to a BMC that supports the WS-Management standard,
applications and scripts can use Windows Remote Management to communicate directly
with the BMC, even when the operating system is offline (pre-boot or post-failure).
When a server is not connected to a BMC, Windows Remote Management can still be
used to connect to WMI remotely in situations where DCOM communication is impeded
(for example, across a firewall). This is possible because the WS-Management standard is
firewall-friendly and uses a single port configurable by the system administrator.
Windows Remote Management exposes its own application programming interface (API)
for scripting, which can be used by scripts written in any Windows Script Hostcompatible
language. The scripting API communicates with WMI using syntax different
from standard WMI scripts. WinRM syntax is documented in the WinRM Software
Development Kit. Hardware Management uses a WMI plug-in to expose WMI classes to
WinRM. WS-Management is based on the following standard specifications: HTTPS,
SOAP over HTTP (WS-I profile), SOPA 1.2, WS-Addressing, ES-Transfer, WSEnumeration
and WS Eventing.
WinRM Command Line Tool (Winrm.cmd)
The command-line tool provided as the primary administrative interface for managing
WinRM is a batch file (Winrm.cmd) that runs a Visual Basic Scripting Edition
(VBScript) script named Winrm.vbs. Because it is a script, you can open it as a text file
and view the code to learn how it works. You can also write your own VBScript scripts
that take advantage of the WinRM scripting API. Winrm.vbs runs under Cscript.exe, the
command-line scripting engine of Windows Script Host.

Winrm.vbs enables system administrators to configure and manage WinRM. Because

WS-Management is a Web service that uses XML as its message format, Winrm.vbs
output is natively XML as well. The tool provides switches to output more readable XML
or plain text.
Prerequisites
WinRM is part of the operating system. However, to obtain data from remote computers,
you must configure a WinRM listener. If a BMC is detected at system startup, then the
IPMI provider loads; otherwise, the WinRM scripting objects and the WinRM commandline
tool are still available.
Windows Server 2003 R2: WinRM is not installed by default, but is available as the
Hardware Management feature through the Add/Remove System Components
feature in Control Panel under Management and Monitoring Tools.
Windows Server 2003 and Windows XP/2000/NT: WinRM is not available.
WinRM is dependent on WinHttp but no other services. If the IIS Admin Service is
installed on the same computer, you may see messages that indicate WinRM cannot be
loaded before IIS. However, WinRM does not actually depend on IIS: these messages
occur because the load order ensures that IIS service starts before the HTTP service.
WinRM does require that WinHTTP.dll be registered.
Benefits
With Windows Remote Management you can:
Perform local and remote server management by accessing multiple data
management stores such as WMI, ADSI, COM, Certificates, Registry, and XML
configuration files.
Automate the management of local and remote servers.
Obtain management data from local and remote computers that may have baseboard
management controllers (BMCs).
Utilize WMI on Windows systems.
Utilize WS-Management Protocol for non-windows systems.

Technical Background
Remote Management Architecture
The following components and features are supplied by WinRM and hardware
monitoring:
WinRM Scripting API. This scripting API enables you to obtain data from remote
computers using scripts that perform WS-Management protocol operations.
Winrm.cmd. This commandline tool for system management is implemented in a
Visual Basic Script file (Winrm.vbs) written using the WinRM scripting API. This
tool allows an administrator to configure WinRM and to get data or manage
resources.
Windows Server 2003 R2: For this command to work, the Hardware Management
feature had to be installed through Add/Remove System Components under
Management and Monitoring Tools in Control Panel.
Winrs.exe. This command line tool allows administrators to remotely execute most
Cmd.exe commands using the WS-Management protocol. For more information, see
the online help provided by the command line Winrs /?.
Windows Server 2003 R2: This command is not available.
Intelligent Platform Management Interface (IPMI) driver and WMI provider.
Hardware management through the Intelligent Platform Management Interface (IPMI
provider and driver allows you to control and diagnose remote server hardware
through BMCs when the operating system is not running or deployed.
WMI service. The WMI service continues to run side-by-side with WinRM and
provides requested data or control through the WMI plug-in. You can continue to
obtain data from standard WMI classes, such as Win32_Process, as well as IPMIsupplied
data.
WS-Management protocol. WS-Management protocol, a SOAP-based, firewallfriendly
protocol, was designed for systems to locate and exchange management
information. The intent of the WS-Management protocol specification is to provide
interoperability and consistency for enterprise systems that have computers running
on a variety of operating systems from different vendors.
WS-Management protocol is based on the following standard Web service
specifications: HTTPS, SOAP over HTTP (WS-I profile), SOAP 1.2, WSAddressing,
WS-Transfer, WS-Enumeration, and WS-Eventing.
Remote Management Installation
If Windows Remote Management is not installed and configured, WinRM scripts do not
run and the WinRM command line tool is unable to carry out data operations. The
Windows Remote Shell command line tool, WinRS, and event forwarding also depend on
WinRM configuration.
Default Configuration
WinRM and Intelligent Platform Management Interface (IPMI) WMI provider
components are installed by default with Windows Server 2008 and the WinRM
service starts automatically.
On Windows Vista, the service must be started manually.
On Windows Server 2003 R2, WinRM is not installed by default but is available as
the Hardware Management feature through the Add/Remove System Components
feature in the Control Panel under Management and Monitoring Tools.
By default, no WinRM listener is configured. Even if the WinRM service is running,
WS-Management protocol messages that request data cannot be received or sent.
Internet Connection Firewall (ICF) blocks access to ports.
You can use the Winrm command to locate listeners and the addresses by typing
the following command at a command prompt:
winrm e winrm/config/listener.
To check the state of configuration settings, type this command:
winrm get winrm/config.

Quick Default Configuration

With Windows Server 2008 and Windows Vista, you can enable the WS-Management
protocol on the local computer and set up the default configuration for remote
management with one command:
winrm quickconfig
Windows Server 2003 R2: The winrm quickconfig command is not available.
The winrm quickconfig command (or the abbreviated version) winrm qc, carries out the
following actions:
Starts the WinRM service and sets the service startup type to auto-start.
Configures a listener for the ports that send and receive WS-Management protocol
messages using either HTTP or HTTPS on any IP address.
Defines ICF exceptions for the WinRM service and opens the ports for HTTP and
HTTPS.
You can get information on customizing configuration, by typing winrm help config
at a command prompt.
To Configure WinRM with Default Settings
Run the following command at a command prompt:
Winrm quickconfig
If you are not running under the local computer Administraor account, you must
either select Run as Administrator from the Start menu or use the Runas command
at a command prompt.
When the tool displays Make these changes [y/n]?, type "y". If configuration is
successful, you see this output:
WinRM has been updated for remote management.
WinRM service type changed to delayed auto start.
WinRM service started.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on
this machine.

You can either leave the default settings for client and server components of WinRM
or customize them. For example, you may need to add certain remote computers to
the client configuration TrustedHosts list.
A trusted hosts list should be set up when mutual authentication cannot be
established. Kerberos allows mutual authentication but cannot be used in
workgroups, only domains. A best practice in setting up trusted hosts for a
workgroup is that the list should be as restricted as possible.
You can create an HTTPS listener by the following command:
winrm quickconfig - transport:https.
Be aware that you must open port 443 for HTTPS transport to work.
Windows Firewall and WinRM Ports
The default listener ports configured by winrm quickconfig are port 80 for HTTP
transport and port 443 for HTTPS. If you configure a custom port for a listener, you must
open the port before WinRM can send and receive messages.
The following example uses the netsh firewall command to open port 3190 for a listener
that uses that port.
netsh firewall add portopening TCP 3190 "Port 3190"
Configuring a Proxy Server for WinRM
WinRM uses HTTP and HTTPS to send messages between the client and server
computers. By default, the WinRM client is not configured to use a proxy server and
sends messages directly to the WinRM server computer. Be aware that the WinRM client
does not use the Internet Explorer proxy settings. If a proxy is required in order to reach
the server computer, the WinRM proxy configuration can be changed by using the
ProxyCfg.exe tool.
Scripting in WinRM
The Scripting API in WinRM and the accompanying COM API for C++ are designed to
reflect closely the operations of the WS-Management protocol.
The WinRM Scripting API in Windows Remote Management supports all the WSManagement
protocol operations except one. It does not allow subscriptions to events. To
subscribe to events from the BMC System Event Log, you must use the Wecutil or
Wevtutil command-line tools.
The WinRM Scripting API is called by Winrm.vbs, a command-line tool, which is written
in Visual Basic Scripting Edition (VBScript). Winrm.vbs provides examples of how to
use the WinRM Scripting API.
Using WSman Compared to Using WMI Scripting
WMI connects to remote computers through DCOM, which requires the configuration
described in Connecting to WMI on a Remote Computer. WinRM does not use DCOM to
connect to a remote computer. Instead, the WS-Management protocol sends SOAP
messages and the service uses a single port for HTTP and a port for HTTPS transport.
Unlike the WinRM command-line tool, scripts must provide the XML required to pass to
the WS-Management protocol messages. They must also provide URIs. The WMI
Scripting API works with objects, such as instances of Win32_LogicalDisk, which
represent resources on a computer. This WMI class is defined in Managed Object Format
(MOF) files, which are stored in binary form in the WMI repository. In WMI, a Get
operation for a single resource or a query for multiple instances returns WMI objects.
A WinRM script does not return objects, but rather streams of XML text.
WinRM Script and Winrm.cmd Output
The output from a WinRM script is encoded in Unicode. If you create a FileSystemObject
and write a file from the script, the resulting file is Unicode. However, if you redirect the
output to a file, the encoding is ANSI. If you redirect the output to an XML file and there
are Unicode characters in the output, the XML will be invalid. Be aware that the winrm
command-line tool outputs ANSI.
Windows Server 2003 R2: If a WMI class name, method, or property name
contains non-ASCII characters, then the data cannot be retrieved by WinRM.
However, the instance data can contain non-ASCII characters.
Authentication for Remote Connections
Windows Remote Management maintains security for communication between
computers by supporting several standard methods of authentication and message
encryption. The default credentials, user name and password, are the credentials for the
logged-on user account that runs the script.
Kerberos. Kerberos is the default method when the client is in a domain and the
remote destination string is not one of the following: localhost, 127.0.0.1, or [::1].
Negotiate. Negotiate is the default method when the client is not in a domain.
Negotiate is also the default method when the client is in domain, but the remote
destination string is one of the following: localhost, 127.0.0.1, or [::1].
You can control the authentication method being used by WinRM:
Basic Authentication. Basic authentication is disabled in the default configuration
settings for both WinRM client and WinRM server. To explicitly establish Basic
authentication in the call to WSMan.CreateSession, set the WSManFlagUseBasic and
WSManFlagCredUserNamePassword flags in the flags parameter.
Digest Authentication. To explicitly establish Digest authentication in the call to
WSMan.CreateSession, set the WSManFlagUseDigest flag in the flags parameter.
Digest is not supported, which means it cannot be configured, for the WinRM server
component.
Negotiate Authentication. To explicitly establish Negotiate authentication, also
known as Windows Integrated Authentication, in the call to WSMan.CreateSession,
set the WSManFlagUseNegotiate flag in the flags parameter.
With Windows Server 2008 and Windows Vista, User Account Control (UAC)
affects access to the WinRM service. When Negotiate authentication is used in a
workgroup, only the built-in Administrator account can access the service. To allow
all accounts in the Administrators group to access the service, set the following
registry key to 1:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalA
ccountTokenFilterPolicy
Kerberos Authentication. To explicitly establish Kerberos authentication in the call to
WSMan, set the WSManFlagUseKerberos flag in the flags parameter. Both the client
and the server computers must be joined to a domain. If you use Kerberos as the
authentication method, you cannot use an IP address in the call to
WSMan.CreateSession or IWSMan::CreateSession.
Windows Server 2003 R2: This type of authentication is not available.
Enabling Authentication Options
The default authentication option at system installation is Kerberos.
If your script or application requires a specific authentication method that is not enabled,
you must change the configuration to allow that. This change can be made using the
Winrm command line tool or through Group Policy for the Windows Remote
Management Group Policy Object. You may also choose to disable certain methods of
authentication.

Implementation/Usage Scenarios
Windows Server 2008 administrators will have the need to manage PCs in restricted
environments, collect information for asset and configuration management, remotely
manage servers, and monitor PC health. With Windows Remote Management you can do
all of these things. You can:
Perform local and remote server management by accessing multiple data
management stores such as WMI, ADSI, COM, Certificates, Registry, and XML
configuration files.
Automate the management of local and remote servers.
Obtain management data from local and remote computers that may have baseboard
management controllers (BMCs).
Utilize WMI on Windows systems.
Utilize WS-Management Protocol for non-windows systems.
Monitor PC health by forwarding events to a central collector.