Administer Windows Server

Table of Contents
Administer Windows Server
Get started with Setup and Boot Event Collection
Microsoft Server Performance Advisor
Server Performance Advisor User's Guide
Server Performance Advisor Pack Development Guide
Server Performance Advisor Pack for Tiered Storage Spaces
Performance Tuning Guidelines
Remote Server Administration Tools
Server Management Tools (Azure)
Server Manager
Manage the Local Server and the Server Manager Console
Configure Remote Management in Server Manager
Add Servers to Server Manager
Install or Uninstall Roles, Role Services, or Features
View and Configure Performance, Event, and Service Data
View Task details and Notifications
Run Best Practices Analyzer Scans and Manage Scan Results
Create and Manage Server Groups
Filter, sort, and query Data in Server Manager Tiles
Keyboard Shortcuts for Server Manager
Software Inventory Logging (SIL)
Manage Software Inventory Logging
Software Inventory Logging Aggregator
User Access Logging (UAL)
Manage User Access Logging
Windows Server Update Services (WSUS)
Deploy Windows Server Update Services
Update Management with Windows Server Update Services
Express update delivery ISV support
Migrating the WSUS database from Windows Internal Database (WID) to SQL
Windows Commands
A-Z list
Command-Line Syntax Key
Commands by Server Role
Administer Windows Server 2016
5/23/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Administration features and tools help IT pros run and manage Windows Server.
Microsoft Server Performance Advisor
With Microsoft Server Performance Advisor (SPA), you can collect metrics to diagnose performance issues on
Windows servers unobtrusively without adding software agents or reconfiguring production servers. SPA
generates comprehensive performance reports and historical charts with recommendations.
Server Manager
The content in this section describes how to use Server Manager in Windows Server to manage both local and
remote Windows-based servers from desktop computers.
Software Inventoy Logging (SIL)
Software Inventory Logging in Windows Server is a feature with a simple set of PowerShell cmdlets that help
server administrators retrieve a list of the Microsoft software that is installed on their servers. It also provides the
capability to collect and forward this data periodically over the network to a target web server, using the HTTPS
protocol, for aggregation. Managing the feature, primarily for hourly collection and forwarding, is also done with
PowerShell commands.
User Access Logging (UAL)
User Access Logging aggregates unique client device and user request events that are logged on a computer
running Windows Server 2012 or 2016 into a local database. These records are then made available (through a
query by a server administrator) to retrieve quantities and instances by server role, by user, by device, by the local
server, and by date. In addition, UAL also enables non-Microsoft software developers to instrument their UAL
events to be aggregated.
Windows Server Update Services (WSUS)
The content in this section describes how to configure and manage WSUS. In this section you will find information
about installing the WSUS Server Role, configuring WSUS servers, as well as managing updates, and managing
WSUS client computers and WSUS computer groups.
Windows Commands
The Windows command-line tools are used to perform administrative tasks in Windows. You can use the command
reference to familiarize yourself with the command-line tools, to learn about the command shell, and to automate
command-line tasks by using batch files or scripting tools.
See Also
Manage connections from Windows operating system components to Microsoft services
Configure Windows telemetry in your organization
Get started with Setup and Boot Event Collection
4/24/2017 • 21 min to read • Edit Online
Applies To: Windows Server
Overview
Setup and Boot Event Collection is a new feature in Windows Server 2016 that allows you to designate a "collector"
computer that can gather a variety of important events that occur on other computers when they boot or go
through the setup process. You can then later analyze the collected events with Event Viewer, Message Analyzer,
Wevtutil, or Windows PowerShell cmdlets.
Previously, these events have been impossible to monitor because the infrastructure needed to collect them doesn't
exist until a computer is already set up. The kinds of setup and boot events you can monitor include:
Loading of kernel modules and drivers
Enumeration of devices and initialization of their drivers (including "devices" such as CPU type)
Verification and mounting of file systems
Starting of executable files
Starting and completions of system updates
The points when the system becomes available for logon, establishes connection with a domain controller,
completion of service starts, and availability of network shares
The collector computer must be running Windows Server 2016 (it can be in either Server with Desktop Experience
or Server Core mode). The target computer must be running either Windows 10 or Windows Server 2016. You can
also run this service on a virtual machine which is hosted on a computer that is not running Windows Server 2016.
The following combinations of virtualized collector and target computers are known to work:
VIRTUALIZATION HOST
COLLECTOR VIRTUAL MACHINE
TARGET VIRTUAL MACHINE
Windows 8.1
yes
yes
Windows 10
yes
yes
Windows Server 2016
yes
yes
Windows Server 2012 R2
yes
no
Installing the collector service
Starting with the Windows Server 2016, the event collector service is available as an optional feature. In this
release, you can install it using DISM.exe with this command at an elevated Windows PowerShell prompt:
dism /online /enable-feature /featurename:SetupAndBootEventCollection
This command creates a service called BootEventCollector and starts it with an empty configuration file.
Confirm that the installation succeed by checking
get-service -displayname *boot*
. The Boot Event Collector
should be running. It runs under the Network Service Account and creates an empty configuration file (Active.xml)
in %SystemDrive%\ProgramData\Microsoft\BootEventCollector\Config.
You can also install the Setup and Boot Event Collection service with the Add Roles and Features wizard in Server
Manager.
Configuration
You need to configure two items to collect setup and boot events.
On the target computers which will send the events (that is, the computers whose setup and boot you want
to monitor), enable the KDNET/EVENT-NET transport and enable the forwarding of events.
On the collector computer, specify which computers to accept events from and where to save them.
NOTE
You cannot configure a computer to send the startup or boot events to itself. But if you want to monitor two computers, you
can configure them to send the events to each other.
Configuring a target computer
On each target computer, you first enable the KDNET/EVENT-NET transport, then enable sending of ETW events
through the transport, and then restart the target computer. EVENT-NET is an in-kernel transport protocol which is
similar to KDNET (the kernel debugger protocol). EVENT-NET only transmits events and doesn't allow debugger
access. These two protocols are mutually exclusive; you can only enable one of them at a time.
You can enable event transport remotely (with Windows PowerShell) or locally.
To e n a b l e e v e n t t r a n sp o r t r e m o t e l y
1. If you have already set up Windows PowerShell Remoting to the target computer, skip to Step 3. If not, then
on the target computer, open a command prompt and run the following command:
winrm quickconfig
2. Respond to the prompts and then restart the target computer. If the target computers are not in the same
domain as the collector computer, you might need to define them as trusted hosts. To do this:
3. On the collector computer, run either of these commands:
In a Windows PowerShell prompt:
, followed by
where <target1>, etc. are the names
Set-Item -Force WSMan:\localhost\Client\TrustedHosts "<target1>,<target2>,..."
Set-Item -Force WSMan:\localhost\Client\AllowUnencrypted true
or IP addresses of the target computers.
Or in a command prompt: winrm set winrm/config/client @{TrustedHosts="<target1>,
<target2>,...";AllowUnencrypted="true"}
IMPORTANT
This sets up unencrypted communication, so don't do this outside of a lab environment.
4. Test the remote connection by going to the collector computer and running one of these Windows
PowerShell commands:
If the target computer is in the same domain as the collector computer, run
New-PSSession -Computer <target> | Remove-PSSession
If the target computer is not in the same domain, run
New-PSSession -Computer <target> -Credential Administrator | Remove-PSSession
, which will prompt you for
credentials.
If the command doesn't return anything, remoting was successful.
5. On the target computer, open an elevated Windows PowerShell prompt and run this command:
Enable-SbecBcd -ComputerName <target_name> -CollectorIP <ip> -CollectorPort <port> -Key <a.b.c.d>
Here is the name of the target computer, <ip> is the IP address of the collector computer. <port> is the port
number where the collector will run. The Key is a required encryption key for the communication,
comprising four alphanumeric strings separated by dots. This same key is used on the collector computer. If
you don't enter a key, the system generates a random key; you'll need this for the collector computer, so
make a note of it.
6. If you already have a collector computer set up, update the configuration file on the collector computer with
the information for the new target computer. See the "Configuring the collector computer" section for
details.
To e n a b l e e v e n t t r a n sp o r t l o c a l l y o n t h e t a r g e t c o m p u t e r
1. Start an elevated command prompt, and then run these commands:
bcdedit /event yes
bcdedit /eventsettings net hostip:1.2.3.4 port:50000 key:a.b.c.d
Here "1.2.3.4" is an example; replace this with the IP address of the collector computer. Also replace "50000"
with the port number where the collector will run and "a.b.c.d" with the required encryption key for the
communication. This same key is used on the collector computer. If you don't enter a key, the system
generates a random key; you'll need this for the collector computer, so make a note of it.
2. If you already have a collector computer set up, update the configuration file on the collector computer with
the information for the new target computer. See the "Configuring the collector computer" section for
details.
Now that event transport itself is enabled, you must enable the system to actually send ETW events
through that transport.
To e n a b l e se n d i n g o f E T W e v e n t s t h r o u g h t h e t r a n sp o r t r e m o t e l y
1. On the collector computer, open an elevated Windows PowerShell prompt.
2. Run
Enable-SbecAutologger -ComputerName <target_name>
, where is the name of the target computer.
If you aren't able to set up Windows PowerShell Remoting, you can always enable sending of events directly on the
target computer.
To e n a b l e se n d i n g o f E T W e v e n t s t h r o u g h t h e t r a n sp o r t l o c a l l y
1. On the target computer, start Regedit.exe and find this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\AutoLogger. Various log sessions
are listed as sub-keys under this key. Setup Platform, NT Kernel Logger, and Microsoft-Windows-Setup
are possible choices for use with Setup and Boot Event Collection, but the recommended option is
EventLog-System. These keys are detailed in Configuring and Starting an AutoLogger Session.
2. In the EventLog-System key, change the value of LogFileMode from 0x10000180 to 0x10080180. For
more information about the details of these settings, see Logging Mode Constants.
3. Optionally, you can also enable forwarding of bug check data to the collector computer. To do this, find the
registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager and create the
key Debug Print Filter with a value of 0x1.
4. Restart the target computer.
Choosing the network adapter
If the target computer has more than one network adapter, the KDNET driver will choose the first supported one
listed. You can specify a particular network adapter to use for forwarding setup events with these steps:
To sp e c i fy a n e t w o r k a d a p t e r
1. On the target computer, open Device Manager, expand Network Adapters, find the network adapter you
want to use, and right-click it.
2. In the menu that opens, click Properties, and then click the Details tab. Expand the menu in the Property
field, scroll to find Location information (the list is probably not in alphabetical order), and then click it. The
value will be a string of the form PCI bus X, device Y, function Z. Make note of X.Y.Z; these are the bus
parameters you need for the following command.
3. Run either one of these commands:
From an elevated Windows PowerShell prompt:
Enable-SbecBcd -ComputerName <target_name> -CollectorIP <ip> -CollectorPort <port> -Key <a.b.c.d> BusParams <X.Y.Z>
From an elevated command prompt: bcdedit /eventsettings net hostip:aaa port:50000 key:bbb
busparams:X.Y.Z
Validate target computer configuration
To check settings on the target computer, open an elevated command prompt and run bcdedit /enum. When this
is finished, then run bcdedit /eventsettings. You can double-check the following values:
Key
Debugtype = NET
Hostip = <IP address of the collector>
Port = <port number you specified for the collector to use>
DHCP = yes
Also check that you have enabled bcdedit /event, since /debug and /event are mutually exclusive. You can only
run one or the other. Similarly, you can't mix /eventsettings with /debug or /dbgsettings with /event.
Note also that event collection doesn't work if you set it to a serial port.
Configuring the collector computer
The collector service receives the events and saves them in ETL files. These ETL files can then be read by other tools,
such as Event Viewer, Message Analyzer, Wevtutil, and Windows PowerShell cmdlets.
Since the ETW format doesn't allow you to specify the target computer name, the events for each target computer
must be saved to a separate file. The display tools might show a computer name but it will be the name of the
computer on which the tool runs.
More exactly, each target computer is assigned a ring of ETL files. Each file name includes an index from 000 to a
maximum value that you configure (up to 999). When the file reaches the maximum configured size, it switches
writing events to the next file. After the highest possible file it switches back to file index 000. In this way, the files
are automatically recycled, limiting usage of disk space. You can also set additional external retention policies to
further limit disk usage; for example, you can delete files older than a set number of days.
Collected ETL files are typically kept in the directory c:\ProgramData\Microsoft\BootEventCollector\Etl (which
might have additional subdirectories). You can find the most recent log file by sorting them by the last modification
time. There is also a status log (typically in c:\ProgramData\Microsoft\BootEventCollector\Logs), which
records whenever the collector switches writing to a new file.
There is also a collector log, which records information about the collector itself. You can keep this log in the ETW
format (in which events are reported to the Windows log service; this is the default) or in a file (normally in
c:\ProgramData\Microsoft\BootEventCollector\Logs). Using a file could be useful if you want to enable
verbose modes that produce a lot of data. You can also set the log to write to a standard output by running the
collector from the command line.
Creating the collector configuration file
When you enable the service, three XML configuration files are created and stored in c:\ProgramData\Microsoft\
BootEventCollector\Config:
Active.xml This file contains the current active configuration of the collector service. Right after installation,
this file has the same contents as Empty.xml. When you set a new collector configuration you save it to this
file.
Empty.xml This file contains the minimum configuration elements needed with their default values set. It
does not enable any collection; it only allows the collector service to start in an idle mode.
Example.xml This file provides examples and explanations of the possible configuration elements.
Choosing a file size limit
One of the decisions you have to make is to set a file size limit. The best file size limit depends on the expected
volume of events and available disk space. Smaller files are more convenient from the standpoint of cleaning the
old data. However, each file carries with it the overhead of a 64KB header and reading many files to get the
combined history might be inconvenient.The absolute minimum file size limit is 256 KB. A reasonable practical file
size limit should be over 1 MB, and 10 MB is probably a good typical value. A higher limit might be reasonable if
you expect many events.
There are several details to keep in mind regarding the configuration file:
The target computer address. You can use its IPv4 address, a MAC address, or a SMBIOS GUID. Keep these
factors in mind when choosing the address to use:
The IPv4 address works best with static assignment of the IP addresses. However, even static IP
addresses must be available through DHCP.
A MAC address or SMBIOS GUID is convenient when they are known in advance but the IP addresses
are assigned dynamically.
IPv6 addresses are not supported by the EVENT-NET protocol.
It is possible to specify multiple ways to identify the computer. For example, if the physical hardware
is about to be replaced, you can enter both the old and the new MAC addresses, and either will be
accepted.
The encryption key used for the communication with the collector computer
The name of the target computer. You can use the IP address, host name, or any other name as the computer
name.
The name of the ETL file to use and the ring size configuration for it
To c r e a t e t h e c o n fi g u r a t i o n fi l e
1. Open an elevated Windows PowerShell prompt and change directories to
%SystemDrive%\ProgramData\Microsoft\BootEventCollector\Config.
2. Type
notepad .\newconfig.xml
and press ENTER.
3. Copy this example configuration into the Notepad window:
<collector configVersionMajor="1"
statuslog="c:\ProgramData\Microsoft\BootEventCollector\Logs\statuslog.xml">
<common>
<collectorport value="50000"/>
<forwarder type="etl">
<set name="file" value="c:\ProgramData\Microsoft\BootEventCollector\Etl\{computer}\
{computer}_{#3}.etl"/>
<set name="size" value="10mb"/>
<set name="nfiles" value="10"/>
<set name="toxml" value="none"/>
</forwarder>
<target>
<ipv4 value="192.168.1.1"/>
<key value="a.b.c.d"/>
<computer value="computer1"/>
</target>
<target>
<ipv4 value="192.168.1.2"/>
<key value="d1.e2.f3.g4"/>
<computer value="computer2"/>
</target>
</common>
</collector>
NOTE
The root node is <collector>. Its attributes specify the version of the configuration file syntax and the name of the
status log file.
The <common> element groups together multiple targets specifying the common configuration elements for them,
very much like a user group can be used to specify the common permissions for multiple users.
The <collectorport> element defines the UDP port number where the collector will listen for incoming data. This is the
same port as was specified in the target configuration step for Bcdedit. The collector supports only one port and all
the targets must connect to the same port.
The <forwarder> element specifies how ETW events received from the target computers will be forwarded. There is
only one type of forwarder, which writes them to the ETL files. The parameters specify the file name pattern, the size
limit for each file in the ring, and the size of the ring for each computer. The setting "toxml" specifies that the ETW
events will be written in the binary form as they were received, without conversion to XML. See the "XML event
conversion" section for information about deciding whether to confer the events to XML or not. The file name pattern
contains these substitutions: {computer} for the computer name and {#3} for the index of file in the ring.
In this example file, two target computers are defined with the <target> element. Each definition specifies the IP
address with <ipv4>, but you could also use the MAC address (for example, or ) or SMBIOS GUID (for example, ) to
identify the target computer. Also note the encryption key (the same as was specified or generated with Bcdedit on
the target computer), and the computer name.
4. Enter the details for each target computer as a separate <target> element in the configuration file, and then
save Newconfig.xml and close Notepad.
5. Apply the new configuration with $result = (Get-Content .\newconfig.xml | Set-SbecActiveConfig); $result .
The output should return with the Success field "true." If you get another result, see the Troubleshooting
section of this topic.
You can always check the current active configuration with
(Get-SbecActiveConfig).text
.
You can perform a validity check on the configuration file with
$result = (Get-Content .\newconfig.xml | Check-SbecConfig); $result
.
Though the Windows PowerShell command to apply a new configuration automatically updates the service without
requiring you to restart it, you can always restart the service yourself with either of these commands:
With Windows PowerShell:
Restart-Service BootEventCollector
In an ordinary command prompt: sc stop BootEventCollector; sc start BootEventCollector
Configuring Nano Server as a target computer
The minimal interface offered by Nano Server can sometimes make it hard to diagnose issues with it. You can
configure your Nano Server image to participate in Setup and Boot Event Collection automatically, sending
diagnostic data to a collector computer without further intervention from you. To do this, follow these steps:
To configure Nano Server as a target computer
1. Create your basic Nano Server image. See Getting Started with Nano Server for details.
2. Set up a collector computer as in the "Configuring the collector computer" section of this topic.
3. Add AutoLogger registry keys to enable sending diagnostic messages. To do this, you mount the Nano
Server VHD created in Step 1, load the registry hive, and then add certain registry keys. In this example, the
Nano Server image is in C:\NanoServer; your path might be different, so adjust the steps accordingly.
a. On the collector computer, copy the
..\Windows\System32\WindowsPowerShell\v1.0\Modules\BootEventCollector folder and
paste it into the ..\Windows\System32\WindowsPowerShell\v1.0\Modules directory on the
computer you are using to modify the Nano Server VHD.
b. Start a Windows PowerShell console with elevated permissions and run
Import-Module BootEventCollector .
c. Update the Nano Server VHD registry to enable AutoLoggers. To do this, run
. This adds a basic list of
the most typical setup and boot events; you can research others at Controlling Event Tracing Sessions.
Enable-SbecAutoLogger -Path C:\NanoServer\Workloads\IncludingWorkloads.vhd
4. Update BCD settings in the Nano Server image to enable the Events flag and set the collector computer to
ensure diagnostic events are sent to the right server. Note the collector computer's IPv4 address, TCP port,
and encryption key you configured in the collector's Active.XML file (described elsewhere in this topic). Use
this command in a Windows PowerShell console with elevated permissions:
Enable-SbecBcd -Path C:\NanoServer\Workloads\IncludingWorkloads.vhd -CollectorIp 192.168.100.1 CollectorPort 50000 -Key a.b.c.d
5. Update the collector computer to receive event sent by the Nano Server computer by adding either the IPv4
address range, the specific IPv4 address, or the MAC address of the Nano Server to the Active.XML file on the
collector computer (see the "Configuring the collector computer" section of this topic).
Starting the event collector service
Once a valid configuration file is saved on the collector computer and a target computer is configured, as soon as
the target computer is restarted, the connection to the collector is made and events will be collected.
The log for the collector service itself (which is distinct from the setup and boot data collected by the service) can be
found under Microsoft-Windows-BootEvent-Collector/Admin . For a graphical interface for the events, use Event
Viewer. Create a new view; expand Applications and Services Logs, then expand Microsoft and then Windows.
Find BootEvent-Collector, expand it, and find Admin.
With Windows PowerShell:
Get-WinEvent -LogName Microsoft-Windows-BootEvent-Collector/Admin
In an ordinary command prompt: wevtutil qe Microsoft-Windows-BootEvent-Collector/Admin
Troubleshooting
Troubleshooting installation of the feature
ERROR
ERROR DESCRIPTION
SYMPTOM
POTENTIAL PROBLEM
Dism.exe
87
The feature-name
option is not
recognized in this
context
- This can happen if
you misspell the
feature name. Verify
that you have the
correct spelling and
try again.
- Confirm that this
feature is available on
the operating system
version you are using.
In Windows
PowerShell, run dism
/online /getfeatures | ?{$_ match "boot"}. If no
match is returned,
you're probably
running a version that
doesn't support this
feature.
Dism.exe
0x800f080c
Feature <name> is
unknown.
Same as above
Troubleshooting the collector
Logging:
The Collector logs its own events as ETW provider Microsoft-Windows-BootEvent-Collector. It's the first place you
should look for troubleshooting problems with the collector. You can find them in Event Viewer under Applications
and Services Logs > Microsoft > Windows > BootEvent-Collector > Admin, or you can read them in a command
window with either of these commands:
In an ordinary command prompt: wevtutil qe Microsoft-Windows-BootEvent-Collector/Admin
In a Windows PowerShell prompt: Get-WinEvent -LogName Microsoft-Windows-BootEvent-Collector/Admin (you can
append -Oldest to return the list in chronological order with oldest events first)
You can adjust the level of detail in the logs from "error," through "warning," "info" (the default), "verbose," and
"debug." More detailed levels than "info" are useful for diagnosing problems with target computers not connecting,
but they might generate a large amount of data, so use them with care.
You set the minimum log level in the <collector> element of the configuration file. For example: .
The verbose level logs a record for every packet received as it is processed. The debug level adds more processing
detail and dumps the contents of all received ETW packets as well.
At the debug level, it might be useful to write the log into a file rather than trying to view it in the usual logging
system. To do this, add an additional element in the <collector> element of the configuration file:
A suggested approach to troubleshooting the Collector:
1. First of all, verify that the collector has received the connection from the target (it will create the file only when
the target starts sending the messages) with
Get-SbecForwarding
If it returns that there is a connection from this target then the problem might be in the autologger settings. If it
returns nothing, the problem is with the KDNET connection to start with. To diagnose KDNET connection
problems, try checking the connection from both ends (that is, from the collector and from the target).
1. To see extended diagnostics from the Collector, add this to the <collector> element of the configuration file:
<collector ... minlog="verbose">
This will enable messages about every received packet.
2. Check whether any packets are received at all. Optionally, you might want to write the log in verbose mode
directly to a file rather than through ETW. To do this, add this to the <collector> element of the configuration
file:
<collector ... minlog="verbose" log="c:\ProgramData\Microsoft\BootEventCollector\Logs\log.txt">
3. Check the event logs for any messages about the received packets. Check whether any packets are received
at all. If the packets are received but incorrect, check event messages for details.
4. From the target side, KDNET writes some diagnostic information into the registry. Look in
HKLM\SYSTEM\CurrentControlSet\Services\kdnet for messages.
KdInitStatus (DWORD) will = 0 on success and show an error code on error
KdInitErrorString = explanation of the error (also contains informational messages if no error)
5. Run Ipconfig.exe on the target and check for the device name it reports. If KDNET loaded properly, the device
name should be something like "kdnic" instead of the original vendor's card name.
6. Check whether DHCP is configured for the target. KDNET absolutely requires DHCP.
7. Confirm that the collector is on the same network as the target. If not, check whether the routing is configured
correctly, especially the default gateway setting for DHCP.
Connection status
You can check the current list of established connections and information on where the data is being forwarded
with Get-SbecForwarding .
You can also get the recent history of status changes in connections with
Get-SbecHistory
.
Troubleshooting setting a new configuration
If you applied the configuration with the Windows PowerShell command
, then the variable $result will contain
information about the deployment. You can query this variable to get different information out of it:
$result = (Get-Content .\newconfig.xml | Set-SbecActiveConfig); $result
Get information about errors with $result.ErrorString . If any errors are reported here, the new configuration will
not have been applied and the old configuration will be unchanged.
Get warnings with
$result.WarningString
.
Get information on the details of the configuration with
$result.InfoString
You can get the complete result with $result | fl * .
Alternately, if you don't want to save the result in a variable, you can use
Get-Content .\newconfig.xml | Set-SbecActiveConfig | fl * .
Troubleshooting target computers
.
ERROR
Target computer
ERROR DESCRIPTION
SYMPTOM
Target is not
connecting to the
Collector
POTENTIAL PROBLEM
- The target computer
didn't get restarted
after it was
configured. Restart
the target computer.
- The target computer
has incorrect BCD
settings. Check the
settings in the
"Validate target
computer settings"
section. Correct as
necessary, and then
restart the target
computer.
- The KDNET/EVENTNET driver was not
able to connect to a
network adapter or
connected to the
wrong network
adapter. In Windows
PowerShell, run
gwmi
Win32_NetworkAdapter
and check the output
for one with the
ServiceName kdnic. If
the wrong network
adapter is selected,
re-do the steps in "To
specify a network
adapter." If the
network adapter
doesn't appear at all,
it could be that the
driver doesn't support
any of your network
adapters.
See also "A
suggested approach
to troubleshooting
the Collector" above,
especially Steps 5
through 8.
Collector
I am no longer seeing
events after migrating
the VM my collector
is hosted on.
Collector
The ETL files are not
created.
Verify that the IP
address of the
collector computer
has not changed. If it
has, review "To enable
sending of ETW
events through the
transport remotely."
GetSbecForwarding
shows that the target
has connected, with
no errors, but the ETL
files are not created.
The target computer
has probably not sent
any data yet; ETL files
are only created when
data is received.
ERROR
Collector
ERROR DESCRIPTION
SYMPTOM
POTENTIAL PROBLEM
An event is not
showing in the ETL
file.
The target computer
has sent an event but
when the ETL file is
read with Event
Viewer of Message
Analyzer, the event is
not present.
- The event could still
be in the buffer.
Events aren't written
to the ETL file until a
full 64 KB buffer is
collected or a timeout
of about 10-15
seconds with no new
events has occurred.
Either wait for the
timeout to expire or
flush the buffers with
Save-SbecInstance .
- The event manifest
is not available on the
collector computer or
the computer where
the Event Viewer or
Message Analyzer
runs. In this case, the
Collector might not
be able to process the
event (check the
Collector log) or the
viewer might not be
able to show it. It is a
good practice to have
all the manifests
installed on the
collector computer
and install updates on
the collector
computer before
installing them on the
target computers.
Microsoft Server Performance Advisor
4/24/2017 • 2 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Download Microsoft Server Performance Advisor (SPA) to help diagnose performance issues in a Windows Server
2012 R2, Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008 deployment. SPA generates
comprehensive diagnostic reports and charts and provides recommendations to help you quickly analyze issues
and develop corrective actions.
Overview of Server Performance Advisor
Download Server Performance Advisor
Server Performance Advisor User's Guide
Server Performance Advisor Pack Development Guide
Overview of Server Performance Advisor
Server Performance Advisor is composed of two parts, the SPA framework and the SPA Advisor Packs.
The Server Performance Advisor framework
The engine that is responsible for collecting data that is designated by the advisor packs, writing the collected data
into a Microsoft SQL Server database, creating an IT-friendly environment to run scripts for SPA Advisor Packs, and
showing the final reports. You only need to install the SPA framework on the SPA console. The SPA console can
either be installed on a standalone computer to remotely access the servers under test or be installed on a server
under test.
Server Performance Advisor Packs
SPA Advisor Packs are the center of all tuning rules, which consist of a series of metadata and SQL script files. SPA
ships with the following Advisor Packs:
The Core OS advisor pack analyzes the performance of general operating system functions, independent of
specialized server roles.
The Internet Information Server (IIS) advisor pack tracks the performance of IIS.
The Hyper-V Advisor Pack analyzes the general performance of the Hyper-V server role.
Note The Hyper-V Advisor Pack does not analyze guest operating systems.
The active directory advisor pack analyzes the general performance of the active directory role.
SPA also offers an extensible model for non-Microsoft developers to write advisor packs to suit their needs.
Note SPA cannot understand all hardware and user scenario contexts. You should use the recommendations that
are provided by the tool to help you make decisions and understand the consequences of any potential changes
that are made to the servers.
Download Server Performance Advisor
Use the following links to download Server Performance Advisor for Windows Server 2012 R2, Windows Server
2012, Windows Server 2008 R2, or Windows Server 2008:
Microsoft Server Performance Advisor 3.1 (32-bit)
Microsoft Server Performance Advisor 3.1 (64-bit)
You can extract the files in the CAB file by using the following commands:
for the x86 version: **extrac32.exe /e /a /l d:\SPA d:\SPA\SPAPlus_x86.cab **
for the x64 version: **extrac32.exe /e /a /l d:\SPA d:\SPA\SPAPlus_amd64.cab **
Caution When you extract the .cab file, SPA must preserve the hierarchical directory structure to function correctly.
Depending on the CAB tools that are installed on your server, extraction may result in a non-operational directory
structure. To retain the hierarchical directory structure, you can use a CAB extraction utility tool that extracts a file
directory structure.
if the CAB extraction tool properly extracted the files, subfolders will automatically appear in the extraction target
folder.
SPA prerequisites
The SPA Console requires that the following software is installed:
Microsoft .NET Framework 4
SQL Server 2008 R2 Express SP1 or Microsoft SQL Server 2008 R2 SP1
Newer versions may be compatible. Any known product incompatibilities with SPA Console will be noted.
Server Performance Advisor User's Guide
4/24/2017 • 59 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
This user s guide for Microsoft Server Performance Advisor (SPA) provides guidelines about how you can use SPA
to help them identify performance bottlenecks in their systems for various server roles.
SPA can help you with the following things:
helps you manage your server performance and troubleshoot server performance issues.
Provides data reports and recommendations about common configuration and performance issues.
Provides recommendations based on the data that it collects from the server and by applying rules which
capture best practices.
Note The SPA Console does not make any changes to the servers.
This guide can be used to run analysis on the following versions of Windows Server:
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008
However, you can run the SPA console on any of the following:
Windows 8.1
Windows 8
Windows 7
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008
for more info about developing SPA Advisor Packs, see Server Performance Advisor Pack Development Guide.
Server Performance Advisor overview
This section explains the history of SPA, describes its target audience and scenarios, and presents an architectural
overview of the tool.
History of SPA
The original version of Microsoft Server Performance Advisor (SPA) was released in 2005-2006. It primarily
targeted Windows Server 2003, including the core operating system and server roles such as Internet Information
Services (IIS) and active directory. The goal of the tool is to help you assess your server performance and
troubleshoot server performance issues.
SPA provides data reports and recommendations to system administrators about common configuration and
performance issues. SPA gathers performance-related data from various sources on servers, for example,
performance counters, registry keys, WMI queries, configuration files, and Event Tracing for Windows (ETW). Based
on the server performance data that it collects, SPA can provide an in-depth look at the current server performance
situation and issue recommendations about what can be improved.
There have been more than one million downloads of the original SPA tool, and it helped many system
administrators manage the performance of their servers. It has been a very successful performance
troubleshooting tool.
Since the release of the original SPA, there are several major changes in the server performance world. Most
notably, the release of Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, and Windows
Server 2008, with new versions of corresponding server roles such as Internet Information Services (IIS) 8.5. Newer
versions of Server Performance Advisor extend the capability of the original SPA to the recent server operating
systems and server roles.
Although SPA 3.1 shares the same design goals and performance analysis paradigm as the original tool, it has
been rewritten with the latest technology. It also has the following key improvements:
Can perform analysis against servers running Windows Server 2012 R2, Windows Server 2012, Windows
Server 2008 R2, and Windows Server 2008.
Supports remote analysis capability, which allows SPA 3.1 to collect and analyze data from a central console,
with no need to install code on the servers to be analyzed.
Uses a Microsoft SQL Server for data analysis and storage, which enables processing and storing large
amount of data.
Separates the tool from the Advisor Packs. Performance analysis logic for each server role is released in the
form of an advisor pack, which can be released or updated separately from the tool.
Provides Advisor Packs that are developed in SQL scripts with an open architecture. Non-Microsoft parties
can develop advisor packs or extend the existing advisor packs from Microsoft to cover special needs.
Supports new features like side-by-side comparison reports, and trend and historical charts to help you find
abnormalities.
Provides features such as modify, import, and export thresholds to help you fine tune the reports and
notifications and share those tunings with other SPA users.
Supports multiple projects, which can be used to group targeted servers.
Provides recurring data collection from within the SPA console.
Enables custom queries and report generation by using Microsoft SQL Server (for advanced users).
Customized Windows PowerShell cmdlets are available to use with SPA
Backward compatible for importing and viewing reports from a SPA 3.0 database
Target audience
The SPA tool is primarily designed for system administrators who manage fewer than 100 servers in various
server roles. It can also be used by support engineers to gather performance data and to troubleshoot performance
issues for customers.
SPA offers recommendations to help you solve performance problems; however, it is based on assumptions that
may not be applicable to your specific server environment. The recommendations that are offered through SPA
should be considered suggestions. We expect that SPA users have a good understanding of their system
configuration, use cases, and the impact of system tuning on the overall system behavior. System administrators
should decide if the SPA recommendations should be applied to their environment.
What s new in SPA 3.1?
The following features and enhancements were added in SPA 3.1:
active directory Advisor Pack helps analyze the general performance of the server s active directory Domain
Services server role.
Support for developers to add lost ETW event notifications alert in the advisor packs and making the alert
visible when a report has been generated and events were lost due to high frequency logging on a slow or
heavily contended disk
Target scenarios
The following are the target scenarios for SPA:
Server environment
SPA is designed to easily set up and maintain. It applies to server environments that use 1 to 100 servers.
SPA will not scale well if you are trying to manage performance for more than 100 servers. For larger or
more sophisticated environments, you should consider using System Center Operations Manager.
Performance troubleshooting
You can use SPA as a performance troubleshooting tool. It provides the ability to collect high-level
performance data, it performs a thorough post processing on the data to give you a better understanding of
their overall system behavior, and it flags any anomalies. When a performance issue is suspected by a
customer, you can use SPA to collect and analyze performance data from the server.
SPA generates a report that you can view. SPA reports provide a notification list that highlights potential
issues, and a data section that includes various performance index, configurations, and settings for the
server. You can use this report to identify the specific performance issue and use the recommendations to
find solutions for the issue. Reports can be compared with other reports that were generated at a different
time or by a different server. Using this side-by-side comparison, you can determine differences between
baseline normal versus abnormal behavior.
Note SPA is not designed to be a debugging or metering tool. Furthermore, from the perspective of the
servers, it can be considered a read-only tool, and it does not modify the servers configurations.
Performance index monitoring
You can use SPA to monitor the performance index of servers. You can choose to run SPA routinely on
servers to collect performance data, and then run a trend chart or an historical chart to spot the
abnormalities. You can view the report for a particular analysis, find out more information about the
performance issue, and then use the recommendations or other report data to resolve the issue.
SPA architecture
The SPA data collection logic is built on a protocol in Windows called Performance Logs and Alerts (PLA). PLA
allows programs to collect performance data from local or remote servers, such as performance counters, WMI
queries, ETW traces, registry keys, and configuration files. When SPA runs performance analysis on a targeted
server, it creates a PLA data-collector set based on the specific SPA Advisor Pack that you selected. The advisor
pack contains the data source to be collected and the file share where the logs are to be stored. SPA data collection
only stores a single user account; the same user account used by PLA is also used to write the logs.
SPA uses a SQL Server database to store the performance logs that are collected from targeted servers. SPA
imports all the performance logs from the file share to the database and then uses the data analysis logic inside
each advisor pack to process the data and generate the reports. An advisor pack analyzes the performance data
that was collected from target servers and generates the SPA reports. For more info on building an advisor pack,
see Server Performance Advisor Pack Development Guide.
The SPA console user interfaces and interactions are built as part of the SPAConsole.exe. You can use the console
to create to a database, add or remove advisor packs, manage target servers, run performance analysis, and view
performance reports.
The SPA console can run on the following operating systems:
Windows 8.1
Windows 8
Windows 7
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008
In a typical business application, there are three tiers: the presentation layer, the business logic layer, and the
storage layer. SPA is designed as a two tier product the console and the database. The console serves as a
presentation layer with certain process-related logic included, and the database serves as the storage layer and the
business logic layer. The console captures user input, and it controls the steps for data collection, data processing,
and report generation. SPA does not depend on Windows system services.
The following diagram shows the high-level architecture of the SPA system. The process is:
1. From the SPA console, you run performance analysis on the specified servers.
2. When the performance data is collected, PLA on the targeted servers writes the logs back to the file share
that is specified by the data collector set.
3. After the data collection is complete on a target computer, the SPA console imports the logs to the SQL
Server database.
4. The console invokes the data processing logic of specific advisor pack.
5. The advisor pack processes the data and calls SPA APIs to insert records into the system report tables that
are defined by the SPA framework.
6. You can use the report viewer inside the console to view the reports that generated. To help you
troubleshoot performance issues, SPA provides three types of reports: single reports, side-by-side reports,
and trend or historical charts. For more info on reports, see Viewing reports.
Getting started with SPA
Requirements
The SPA console can be installed on Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows
Server 2012, Windows Server 2008 R2, and Windows Server 2008. Running SPA on earlier versions of the
Windows Server operating system is not supported. SPA runs on x86 or x64, but it does not support the IA64 or
ARM architectures.
SPA is built on Windows Presentation Foundation (WPF) 2.0, which is part of the Microsoft .NET Framework 4, so
.NET Framework 4 is required.
You also need to install SQL Server 2008 R2 Express on the same computer where SPA is installed. SQL Server
2008 R2 Express is a free database engine that is released by Microsoft. You can download Microsoft SQL Server
2008 R2 Express from the Microsoft Download Center. While we suggest SQL Server 2008 R2 Express, newer
versions of SQL Server may also be compatible with SPA.
Note SPA does not include SQL Server or the .NET Framework as part of the SPA installation package. After
installing Microsoft SQL Server 2008 R2 and .NET Framework 4.0, we recommend that you run Windows Update
before installing SPA.
Because users can create and manage databases with SPA, the user account that is used to run SPA should have
the same administrator privileges as SQL Server.
Setting up SPA
SPA is packaged as a .cab file that includes all the binaries for the SPA framework, the Windows PowerShell
cmdlets that are used in advanced scenarios, and the following advisor packs: Core OS, Hyper-V, active directory,
and IIS. After you extract the .cab file to a folder, no additional installation is required. However, to run SPA, you
need to enable data collection from the target servers as follows:
To run PLA data collection, the user account that you use to run the SPA console must be part of the
Administrators security group on the target server. If the target server and the console are in the same
domain, the domain user account must be part of the Administrators security group on the target server. If
the target server and the console are not in the same domain, create an administrative user account on the
target server with the same user name and password as the user account that you use to run the SPA
console.
create a shared folder for results on the server.
Make sure that the user account you use to run the SPA console has read and write permissions to the
shared folder. PLA will use this account to write logs to the folder, and the SPA console will use the same
account to read logs and import them into database.
Note ETW implements a circular buffer to store the trace and moves them to the shared folder when
possible. If the server is busy or the write operation is slow, ETW drops the traces when the buffer is full. It is
IMPORTANT that the shared folder is located on a server with fast I/O access. We recommend that each
target server has a shared folder to minimize data loss caused by slow file I/O.
for PLA to access target servers, set the Windows Firewall to allow remote Performance Logs and Alerts
access on target servers. PLA uses TCP port 139.
Make sure the Performance Logs & Alerts Service is running.
if the console and target server are located in different subnets, you also need to set the remote IP address
field in the inbound firewall rules in the Scope settings on the Performance Logs and Alerts page, as
shown here.
Turn on Network Discovery on the console and on each of the target servers.
if the target server is not joined to a domain, enable the following registry setting:
HKLM\SOFTWARE\Microsoft\Windows\Currentversion\Policies\system\LocalAccountTokenFilterP
olicy.
Note By default, SPA writes diagnostic logs to the folder where SpaConsole.exe is located. If SPA is installed under
the Program Files folder, SPA will only be able to write the log when SpaConsole.exe is ran as an administrator.
if you want to run data analysis against the console computer, you need to run SPA as an administrator. PLA goes
through a different code path when running against a local computer, which requires administrator privileges.
if you want to run the IIS SPA Advisor Pack against your servers, you need to enable WMI query and ETW trace for
the IIS server. You can do this by enabling Tracing under the Health and Diagnostics role service and IIS
Management Scripts and Tools under Management Tools of the Web Server (IIS) server role.
Creating your first project
After everything is set up, you can create your first SPA project. As described in the previous section, SPA stores
everything that is related to performance data analysis inside a database. Each SPA project corresponds to a single
database. The First time Use Wizard guides you through the following steps.
To create a SPA project
1. Launch SpaConsole.exe. The console enters a disconnected mode, where SPA is not connected to any
database, and the main window is blank.
2. To create a new project, click File, and then click New project. This launches the First time Use Wizard. The
first page shows the steps that you will follow while using the wizard:
create a database
Provision advisor packs
add servers to the target server list
3. Click Next. The create project database page asks you to provide the name of the Microsoft SQL Server
instance where you want to create your database. For example, if it is on the same computer as the console,
you can use localhost\<your SQL server name>.
Note The default instance name for a SQL Server 2008 R2 Express installation will be SQLExpress. For an
instance of SQL Server 2008 R2 Express that is installed on the local computer, the database would typically
default to localhost\SQLExpress. However, it may have been changed during SQL Server installation, so
you need to make sure that you use the right SQL Server instance name.
4. Provide the database name. Only letters, digits, and underscores (_) are allowed as valid characters for a
database name. A reasonable suggestion for the SPA database name would be SPA. If you enter an invalid
name, a red error icon appears. The associated tooltip gives the reason for the validation failure.
Note It is IMPORTANT to remember the database name and the server instance name, because these are
the only identifiers for your project. You need to provide this information if you want to switch to this
database.
5. After you provide the server instance name and database name, the First time Use Wizard generates the
location for the database file.
6. On the create project database page, click Next. The First time Use Wizard will try to create a database
and generate all SPA-related database schema, functions, and stored procedures in the database. This step
could take several seconds depending on the hardware and network speed.
Note if this step fails, an error message appears. Some of the common issues are: Console cannot connect
to the SQL Server instance, insufficient privileges to create database, or the database name already exists.
7. When the previous step succeeds, you will see the Provision advisor pack page. It lists all the advisor
packs that are available on your computer. SPA automatically scans the folder named APs under the SPA
root directory. It lists the full name, version, and author for each advisor pack.
Note for more info about how the full name and version are used in SPA, see Managing advisor packs
8. Choose which advisor packs you want to provision in the project database, and then click Next. Or you can
click Skip to move to the next step without provisioning any advisor packs.
Note You can provision advisor packs any time you are using the tool. For more information, see Managing
advisor packs.
9. On the add servers page, for each server to be added to the target server list, there are two mandatory
fields to fill: Name of the server and File Share Location.
Note There is also a remark field, which is primarily used to classify or find the server. In instances where
you have many servers, you can import a comma separated value (.csv) file which contains the server name,
result folder, and optional remark field. The remark field is used to describe the server and the term can be
used to filter servers for data collection. If you are initializing the servers through the .csv file, a parsing error
within the file will not load the servers.
10. Several configurations need to be set to enable PLA data collection, as described in Setting up SPA. The add
server page provides a test configuration capability to help you troubleshoot configuration issues. select the
check box associated with the computer, and then click Test Connectivity. SPA tries to generate a data
collector set on target servers, and it tries import the results back to the database. If everything is correct, the
Status shows Pass. If it fails, a tooltip appears that describes the reason for the failure.
11. Each of the servers is automatically added to the database even if it does not pass the configuration test. To
remove servers from the list, select the server name and click remove.
12. When everything completes, click Finish to close the First time Use Wizard. If you close the First time Use
Wizard before finishing it, all the previous steps persist and none of them roll back automatically. You need
to make future changes manually.
Running analysis
After setting up the database, you can run performance analysis on the servers.
Every time the SPA console launches, the last project that was used by the current user opens automatically. The
main window contains a list of servers. Each server has four properties: Server Name, Analysis Result, Current
Status, and remark.
Server Name The name of the server, which is the identifier for server. No duplicate names are allowed.
Analysis Result By default, it shows the result of the latest performance analysis run against the server. If
there has not been any performance analysis run against the server, it shows No report. If there is a
warning raised by the report, it shows Warning and the time stamp when the latest report was generated. If
no issue was found during the latest analysis on the server, it shows OK and the time stamp.
Note if you recently changed a system setting, we recommend that you run the analysis again to evaluate
the overall impact of the change and get an updated report of the system state. SPA does not track
configuration changes to the system under test.
Current Status Shows the status of performance analysis tasks currently running on the server. You can
cancel a running task by clicking the Cancel icon, which is designated by a red X.
remark Describes the current target server. For example, you can describe your server by using the server
role (for example, SQL Server ) or a location (for example, Kent ). SPA uses the Server name and remark to
help search and find the proper server. You can type in the search text box. If the Server name or remark
columns contains the exact string that you entered in the search box, the server will be displayed in the
server list.
The following controls are also available on the console:
Repeat A check box that describes the ability to regularly repeat a collection, based on a time interval. For
most server installations, you would want to have a SPA collection repeat hourly to have sufficient history
for analysis. If you want to run the collection only once, you should not select the Repeat check box.
remove Recurrence A button that enables you to cancel an ongoing repeat collection job. It cancels the
repeat collection, but not the current collection (if any) is in progress. This option allows you to reset a new
repeat collection interval or run the collection manually.
Before you start the performance analysis, select the data collection duration. Although collecting more data helps
provide a more accurate image of the server performance situation, it also generates a larger number of logs, and
it could have more potential impact on the server. Choose the proper data collection duration based on your
specific need. Each advisor pack defines a minimum valid duration. The data collection duration that you choose
must be longer than the minimum duration of the selected advisor packs.
To run performance analysis on target servers, select the servers that you want to run performance analysis
against, and click **Run analysis ** A dialog box appears and asks you to select the advisor packs to be run on the
servers. The selected advisor packs run simultaneously. The reports that are generated are based on the
performance data that is collected during the same time period.
Note if you select a server that has a recurring performance analysis running, the remove Recurrence button
allows you to cancel the recurring data collection. SPA does not allow multiple data collection sessions at the same
time on the same computer.
Viewing reports
In SPA, there are three types of performance analysis report: Single report, side-by-side report, and trend and
historical graphs.
After running performance analysis, a report is generated for each of the advisor packs run on the target computer.
From the server list in the main window, you can expand Analysis Result to see all the advisor packs that have
been run on the specific server. You can click a report name to view a single report.
There are three icons next to the advisor pack name that show the status of latest analysis run on the server:
The Latest icon shows the report that was generated by the latest performance analysis on this server for
the advisor pack.
The find icon shows the list of performance analysis reports, which enables you to pick the correct report.
The Advisor pack and Target server fields are prefilled with the current advisor pack and target server
information. The default time range is set to one week, and the end date is set to today. If you click the
Search button in the upper-right corner, you can get a list of all the performance analysis reports for the
selected server and advisor pack within the time range.
The View Charts icon opens the trend and historical chart view.
The following figure shows the Latest, find, and View Charts icons after each advisor pack:
Searching for and within reports
Searching for reports is done by using Report Explorer. This enables you to search for reports by date range,
server name, and advisor pack. This is the recommended way to find a report of interest other than the last run
report. The last run report is available through View Report for that server.
When you view a specific report, you can easily navigate to the next and previous report by time or look at a
related report, such as a different AP running at the same time. These options are available under Actions.
Searching within a report is also possible. A number of the reports will have a find string search box available for
quick text string search within the report. To remove the text box, you can dismiss it. To activate a search box (in
windows that have text search), you can use the Control + F shortcut. The find box allows the user to specify a
case-sensitive search as appropriate with the Match Case option.
The following figure shows the find search box with the string Power on the Report tab.
Single report
A single report shows the performance analysis results from a single run of an advisor pack on a single computer.
The report displays the name of the advisor pack, the name of the target server, the time the report generated, and
the duration for data collection.
A single report contains a notification section and the data sections.
Notification section
The notification section consists of a set of performance analysis rules. Each notification contains some data source,
some threshold values, and some business logic. When you run performance analysis, the business logic evaluates
the data sources against the thresholds to determine whether the rule passes or not. If not, a warning appears to
inform you about a potential performance issue. It also provides recommendations to help you solve the issue. The
notification section is always the first tab in the single report view.
The notification section is divided into two parts: Warning and Other notifications.
if the data source for a rule meets certain conditions based on the logic and threshold settings, a warning appears
in the Warning area. A warning includes the following parts:
A warning icon indicates the existence of a potential issue.
The name of the rule. For example, Network receive packet drops is a link that points to the rule detail
page, as described in Managing advisor packs.
A simple description about the potential issue.
A recommendation for a possible solution to the potential performance issue.
Different servers can have dramatically different configuration and usage patterns, and it is impossible to set the
thresholds and rules that are applicable for all servers under all conditions. SPA provides the capability to modify
the thresholds. You can also choose to disable a rule if the rule does not apply to your scenario. By default, all rules
are enabled. A disabled rule will not show up in the notification area. For more info, see Managing advisor packs.
The Other notifications area contains all the other rules, where no warning is raised or the rule is not applicable.
It contains similar parts as found in the Warning area. The biggest difference is that if no warning is raised or the
rule is not applicable, usually no recommendation is provided.
Data sections
Data sections contain the performance data that the advisor pack generates based on the raw data collected from
the target servers. Data sections include a set of top-level sections and multiple levels of subsections. The top-level
sections are presented as tabs. All the subsections under the top-level sections are presented in expandable areas.
You can collapse or expand each of the sections to help focus on area of interests, as shown in the following figure.
The Core OS SPA Advisor Pack and the IIS SPA Advisor Pack contain a System overview section. This section
includes the top-level information about the resource usage and configuration. Other top-level sections represent
areas of performance data. SPA presents report data in the following ways:
Single value A key/value pair. The key is a string, which represents the meaning of the value. The value can
be a string, a numeric value, or a Boolean value. This is often used to show static information, like
configuration for example, the CPU architecture, the total memory size, and the BIOS version, which do not
change over time.
list value This is sometimes a key/value pair, but the list value can contain multiple fields. For example, the
attribute of the CPU can be shown in a table with multiple columns and multiple rows. Each row represents
one CPU, and each column represents an attribute of the CPU.
Statistics Can be considered a special type of single value. It can only contain numeric data. During the time
of data collection, many of the numeric data points fluctuate instead of stay constant. For example, the CPU
usage changes each time the PLA collects the performance counter. Showing only a single value cannot
accurately reflect the performance situation. Instead of showing only one value, average, maximum,
minimum, and 90% value are used for such dynamic numeric data points. The 90% value represents activity
at or above the 90th percentile across all events for that counter in that given collection interval.
Top list Usually contains the top consumers of a specific resource or the top entities that experienced
certain events. For example, Top 10 processes in terms of average CPU usage includes the top ten
processes with highest average CPU usage during the time of data collection. Because CPU usage is also a
dynamic numeric data point, other statistics like maximum, minimum, and 90% value are also included in
the list to give the user a more complete picture of the CPU consumption.
As mentioned in previous sections, SPA relies on PLA to collect ETW trace, WMI queries, performance counters,
registry keys, and configuration files to generate the report. It is IMPORTANT to understand the data source behind
each data point in the report. SPA provides such information through tooltips. You can hover over the key columns
or rows to view the data-source tooltip. For example, WMI:Win32_DisDrive:Caption means that the data source
is from a WMI query, the WMI class name is Win32_DiskDrive, and the property is Caption.
Side -by-side report
Single reports provide notifications and a data section to help the user find potential performance issues, but it is
often difficult to identify a potential performance issue by directly looking at a single report. A single report might
contain too many data points, which makes it hard to find the potential issues.
To solve this problem, SPA provides the capability to compare two reports. You can compare a report with a
potential problem to a baseline report to help find the differences.
Side-by-side reports can be launch from a single-report viewer. Users can click Actions, and then click compare
Reports to select the reports. It is only meaningful to compare reports from the same advisor pack. You can
choose to compare the report with a previous report in time, the next report in time, or an arbitrary report that is
selected through search capabilities. For example, to isolate abnormal behavior, you can compare a baseline server
report to a report that was generated at a different time on the same computer, or to a report that was generated
on a different computer that has a similar server role and load.
A side-by-side report looks very much like the single report. It contains a notification section and data sections. It
contains the same number of notifications and data sections as the single report viewer. The only difference is that
the reports are shown in a side-by-side manner. Each section contains the data from the source report (report 1)
and the destination report (report 2).The side-by-side report displays the name of the advisor pack, the name of the
target server (report 1 on the left and report 2 on the right), the time that the report was generated, and the
duration of the data collection for each report.
if you dismiss the find dialog box, you can reactivate it by typing Control + F. This dialog will find and highlight
text strings within the current section.
In the notification section, if any of the results from the two reports that are compared is a warning, it will be listed
in the Warning area. Otherwise, the results will be listed in the Other Notifications area. Because the key for a
side-by-side report is to identify differences between reports, no detailed information about a rule is displayed.
Users can click the rule name to bring up the rule detail form for more information about the rule.
In the data sections, the data is presented in a side-by-side manner with data from report 1 on the left and data
from report 2 on the right. SPA shows single values in the same table, but instead of labeling the columns Value,
they are named Report 1 and Report 2 respectively. The side-by-side report shows all other forms of data in sideby-side tables.
The side-by-side report viewer also provides tooltips about the data source.
Historical and trend charts
It only makes sense to show trend and historical charts for a specific server and specific advisor pack. You need to
choose the time range (which is defaulted to the last week), and then click OK to bring up the trend and historical
chart viewer.
The trend and historical chart viewer has three tabs: historical chart, 24-hour trend chart, and 7-day trend chart.
Historical chart
The historical chart shows a series of values for a numeric data point through the given time frame. For example,
the Average request latency for IIS on a single server for the last 15 days. Each data point in an historical chart
represents the value of a specific data source taken in one performance analysis session.
There are a couple of ways to use a historical chart:
1. To help find abnormalities at a certain time for a data point for example, at 2:00 AM each day, the Average
request latency of IIS jumps from around 200 ms to 500 ms.
2. To help correlate multiple data points. For example, showing Average request latency and Average
request count together for the last 15 days. The report might show that the request latency and request
count increase at the same time spot, which could indicate that the request latency increase is caused by an
increase in request count.
In an historical chart, users can do the following:
Show multiple data series in the chart area. Each data series is shown as a line chart in the report viewer.
Each line chart is automatically scaled to fit in the report viewer.
add or remove a data series from the data series list at the bottom of the historical chart viewer.
Show or hide a data series in the data series list. Users can click a specific data series in the list to highlight
the corresponding line chart in the chart area.
Zoom in to a certain time period by selecting the time period inside the chart area. To zoom out, click the
button that is located in the bottom-left corner of the chart.
Investigate a single report by double-clicking a particular data point.
copy the data and make it available for other programs, such as Microsoft Excel. This allows you to utilize
Microsoft Excel charting capabilities, when appropriate.
Trend charts
Many repetitive performance issues are caused by periodic tasks running on or against target servers. For example,
an entertainment-oriented website might get more hits during the weekend, or a schedule disk backup task might
bring down the performance of a server every day at 2:00 AM.
A trend chart is designed to help you find such performance issues. Performance issues can happen repetitively in
various patterns. The most common patterns are daily patterns and weekly patterns where performance issues
happen during the same hour of a day or same day of a week. Therefore, SPA provides a 24-hour trend chart and a
7-day trend chart.
The trend analysis graph provides a deeper level of investigation on a set of data, and it looks for trends based on
the time of day. The X-axis is set to a 24-hour period, starting at 0:00 (midnight) and ending at 23:59. SPA does not
show trends for multiple data series at the same time. You can click Pick data series to select a data series to view.
To process the data, SPA looks for all snapshots taken between 0:00 and 0:59 for each hour. SPA determines the
minimum, maximum, average, and sigma values for the set of snapshots taken during that hour, and graphs them
as candlestick charts. SPA repeats the process for snapshots taken between 1:00 to 1:59, then 2:00 to 2:59, and so
on. If no snapshots exist for the given hour, SPA leaves that hour blank on the graph and proceeds to the next hour.
A 7-day trend chart is very similar to the 24-hour trend chart. The only difference is that it groups a data series
based on the day of a week instead of hour of a day.
The data series that you select in trend and historical charts are stored as a user preference. The next time that the
trend and historical chart viewer is opened for the same advisor pack, the same set of data series will be listed as
the default.
Managing reports
deleting reports
Reports can be removed to minimize the number of reports that need to be managed by SPA. Depending on the
frequency of reports and the number of servers, we recommend deleting unnecessary reports. While SPA does not
have a limit on reports that it can manage, the underlying database may have a size limitation.
Note deleted reports cannot be undeleted.
Exporting and importing reports
Reports can be exported to an XML file to transport to another SPA console or to email to another user. Exporting
the report does not delete the report. To export the currently viewed report, from Report Viewer, click Actions,
and then click Export. To export multiple reports, from Report Explorer, click Enable Multiple selection, select
multiple reports from the selection box, and then click Export. This will export the reports in XML format into the
selected destination directory.
An exported report can be viewed in SPA. imported reports are not added to the SPA database. They are primarily
meant to serve as a XML viewer application for the exported report. The server for the imported report does not
need to have the same advisor packs installed as the original exported report SPA console.
Managing advisor packs
SPA includes advisor packs for the core operating system, Hyper-V, active directory, and IIS. SPA provides an open
architecture for developing advisor packs by using SQL, so it is also possible for non-Microsoft developers to build
versions of advisor packs. There are four options for managing an advisor pack: provision, customize, reset, or
remove.
Provision new advisor packs
New advisor packs can be released by Microsoft or by non-Microsoft developers. An advisor pack includes a
provisionMetaData.xml and a set of SQL scripts that describe the logic.
To provision a new advisor pack
1. copy all the content of the advisor pack under the %SpaRoot%\APs directory.
2. In the main window, click Configuration, and then click Configure Advisor Packs. The Configure
Advisor Packs dialog box opens.
Note This dialog box is similar to the Provision advisor pack page in the First time Use Wizard. It shows a
list of advisor packs that are available to manage. Each advisor pack in the list has properties such as name,
installed version, version, and author. Name is the full name of the advisor pack, and installed version is the
version of this advisor pack that has already been provisioned in the project. If the advisor pack is not
provisioned in the current database, the installed version text box will display Not Installed. The version
field indicates the version of this advisor pack, which is filed under the advisor packs folder.
3. select the advisor pack from the list. If the advisor pack has not been provisioned or if there is a newer
version in the advisor packs folder than the one in the database, the Provision button will be enabled. Click
the Provision button.
4. When provisioning is complete, the Installed version field for the selected advisor pack will contain the
new version information.
Customize advisor packs
SPA defines an open architecture that allows users to modify the advisor packs. Users can modify the advisor pack
files by changing thresholds, sharing thresholds, and enabling or disabling rules.
for more info about how to change and build advisor packs, see Server Performance Advisor Pack Development
Guide.
Changing thresholds
Thresholds are used in SPA to determine whether the trigger condition of a rule is met. The actual thresholds for
real customer scenarios can vary dramatically because of the workload, hardware environment, and business
needs. The default thresholds might not be proper for the current user case, so SPA provides the capability to
modify the existing threshold.
You can modify threshold values by clicking the rule name in a single or side-by-side report. Or to manage all the
rules of a particular advisor pack, they can modify threshold values from the Configuration menu.
To change a threshold value
1. In the Configuration menu, click Configure Advisor Packs, click the name of the advisor pack to be
modified, and then click Configure.
Note You are presented with a list of all rules that are included in the advisor pack. The check box on the left
of the advisor pack name indicates if the rule is enabled. If a rule is disabled, it will be hidden from all
reports.
2. Click the specific rule that you want to modify. The Rule details form for the selected rule opens.
The Rule details form contains detailed information about a specific rule. It includes the name, description, status,
possible results, and thresholds. SPA supports two types of rule results, Warning and OK. For each type, there is
recommendations text and a recommendation.
Some of the rules do not have thresholds defined. For example, the HTTP Keep Alive rule checks for a Boolean
setting for IIS. So the thresholds list might be empty. Otherwise, all the thresholds that are used by the current rule
will be listed. A detailed description about how a threshold is used in the rule is included as part of the description.
if the Rule details form is launched from the Configuration menu, the threshold list will have three columns:
name, original setting, and change setting. If it is launched from a single or side-by-side report, the threshold
values that are used by the report will also be included. Users can modify the current threshold values by changing
the value in change setting column, and then clicking Save to save the changes to database.
All the changes that are made to thresholds will only be applied to reports that are generated after the changes.
Existing reports will not be affected by these changes.
Sharing thresholds
if you manage your servers under similar situations, you can choose to use the same set of thresholds. You can
export and import thresholds for a specific advisor pack by using the Configuration menu. You can select the
specific advisor pack, and then click Configure. The exported threshold file is in an XML format.
When importing a threshold, SPA validates the XML file format and verifies that the file matches the selected
advisor pack. If this is successful, SPA imports all the values from the threshold file into the current project
database. Similar to the previous changing thresholds scenario, all the threshold value changes will only take effect
on reports that are generated in the future. Existing reports are not affected.
Enable or disable rules
A rule can be enabled or disabled from the Rule details form. You need to click Save to persist the changes made.
If a rule is disabled, it will not be displayed in any of the reports. But the underlying business logic is triggered
while generating the report, so when you choose to re-enable the rule, it will show up in reports again.
reset advisor packs to original state
You might decide to modify a provisioned advisor pack in the database. Other than changing the thresholds, you
might also change the SQL scripts. SPA does not support changing report metadata, or adding or removing rules
for a provisioned advisor pack. Manually modifying those areas could cause unexpected behavior.
for more info about changing a provisioned advisor pack, see the Server Performance Advisor Pack Development
Guide.
if you want to roll back changes that were made on a provisioned advisor pack, you can choose to reset the advisor
pack. This will overwrite all the SQL scripts that are related to the advisor pack and reset all the default thresholds
values. This will keep all the existing reports.
resetting the advisor pack can be done by using the Configure Advisor Packs form. You need to select the
advisor pack to be reset, and then click reset.
remove advisor packs
When an advisor pack is no longer needed, users can remove it from the database. removing the advisor pack will
remove everything about the advisor pack from the database, including the rules and thresholds, all SQL scripts,
and all the reports. None of the actions can be rolled back.
removing the advisor pack can be done by using Configure Advisor Packs form. You need to select the advisor
pack to be removed, and then click Deprovision.
Update existing advisor packs
Updating existing advisor packs is very similar to resetting the advisor pack to its original state. To update the
advisor pack to a newer version, copy the new advisor pack to the advisor pack folder. An advisor pack is
considered an update to an existing advisor pack only when there is no report metadata change. The report and the
rules IDs have to be identical. Otherwise, they should be treated as two different advisor packs.
if there are only business logic changes and no report metadata changes for an advisor pack, it should be given a
new version number, for example from 1.0 to 2.0. If there is report metadata change, the advisor pack should be
given a different full name. For example, Microsoft.ServerPerformanceAdvisor.IIS.V1 could be changed to
Microsoft.ServerPerformanceAdvisor.IIS.V2.
if a newer version of the advisor pack exists, the list in the Configure Advisor Packs form will automatically fill
the version column with the latest version of the advisor pack. You can select the advisor pack, and then click the
reset. The advisor pack updates with the new business logic and thresholds. All the reports for this advisor pack
are preserved.
Managing servers
SPA provides basic capabilities for managing target servers. You can choose to add new servers to the target
server list, remove servers from the list, or modify remarks for servers.
To add or remove servers or modify server information
1. Click the Configuration menu, click Configure Servers.
2. In the list of servers that currently exist in the project database, the last row is empty. Click the row and fill in
the fields. The Server name and File Share Location folder fields are mandatory, and the server name has
to be unique.
3. Enter other server information in the remark column for each server.
Note This field uses a free text format, so you can use it as a description field. Or use this field to tag the
servers so they can be found easily in the main window, or to group servers, for example, by location or
server role.
4. if you want to use SPA with a large number of servers, SPA supports a Comma Separated Value (.csv)
format for import. The file must contain at least two fields: Server and File Share Location. The third field,
remark is optional, but it is recommended to organize your servers. You can also export the server list to a
.csv file to determine the appropriate format or back up your server configuration.
Searching and filtering
if you manage more than a few servers, SPA provides basic support to quickly find the servers in the main window.
You can click the column header to sort based on the server name, analysis results, current task status, or remarks.
You can also choose to use the search functionality. In the top right corner of the main windows, you can type a
string to search for. The Target server list in the main window will use the string to filter the servers and to only
display servers with name or remark fields that contains the search string.
The following figure shows how the string delL matches servers with the string delL or servers with remark field
that contains delL.
Advanced functionality
Working with SPA Windows PowerShell cmdlets
The SPA console has support through the UI for recurring data collection. If that functionality is not sufficient for
your environment, there are Windows PowerShell cmdlets that an advanced administrator can use to customize
data collection. These Windows PowerShell cmdlets enable system administrators to automatically run
performance analysis on target servers and use SPA for remote customer support. For example, system
administrators can write scripts to invoke SPA cmdlets within certain time intervals to periodically sample the
performance condition of target servers.
We recommend closing the SPAConsole.exe application before using these cmdlets.
Before you run any Windows PowerShell cmdlets, you need to register the cmdlets on the console computer.
To register the Windows PowerShell cmdlets
1. From an elevated Windows PowerShell command prompt, type registerSpaCmdlets.cmd. The register
SPA cmdlets successfully message appears.
2. Run SPA-PowerShell.cmd. If you pass the path to a Windows PowerShell script file, it will automatically
execute the scripts. Otherwise, it will open a Windows PowerShell command prompt, which is ready to run
SPA Windows PowerShell cmdlets.
The following table describes the SPA Windows PowerShell cmdlets:
CMDLET NAME
start-SpaAnalysis
PARAMETERS
-ServerName Name of the
target server
DESCRIPTION
starts a SPA data collection session
on the specified server.
-AdvisorPackName Full
name of the advisor pack to
be queued on server. When
more than one pack is
scheduled to run at the
same time, the value of the
parameter should be
formatted as AP1name ,
AP2name.
-Duration Duration for the
data collection
-Credential User
credentials for the account
that will run data collection
on the target server
-SqlInstanceName Name
of the SQL Server instance
-SqlDatabaseName Name
of the SPA project database
Stop-SpaAnalysis
-SqlInstanceName Name
of the SQL Server instance
-SqlDatabaseName Name
of the SPA project database
attempts to stop a running SPA
session. If a session is already
complete, it will return without
doing anything.
-ServerName Name of the
target server
Get-SpaServer
-SqlInstanceName Name
of the SQL Server instance
-SqlDatabaseName Name
of the SPA project database
Get-SpaAdvisorPacks
-SqlInstanceName Name
of the SQL Server instance
-SqlDatabaseName Name
of the SPA project database
Gets the server list in the database.
It returns a list of objects, including
these properties: Name, Status,
FileShare, and remark.
Gets the advisor pack list in the
database. It returns a list of objects,
including these properties: Name,
DisplayName, Author, and version.
Windows PowerShell provides the capability to pass credentials through encrypted files to enable automation
scenarios. For more info about using encrypted files to pass credentials to a cmdlet, see create Windows
PowerShell Scripts that Accept Credentials.
Automating SPA report collection by using Windows PowerShell
The following procedures represent an example for how to automate a SPA report collection by using the SPA
Windows PowerShell cmdlets.
User credentials can be encrypted and cached through Windows PowerShell. These credentials are used to log on
to remote servers. Although not specific to SPA, the following example demonstrates this technique:
$fileName = 'D:\temp\operator.txt'
$userName = 'domainname\operator'
# save credential to file
$(Get-Credential).Password | convertFrom-SecureString | Set-Content $fileName
# load credential from file
$credential = New-Object System.Management.Automation.PsCredential $userName, $(Get-Content $fileName |
convertTo-SecureString)
# run command
.\start-SpaAnalysis ServerName: Server1 Credential: $credential
AdvisorPackName:Microsoft.ServerPerformanceAdvisor.CoreOS.V1 10 Duration:10 SqlInstanceName: .\SQLExpress
SqlDatabaseName:SPA8294
Before you can run this file, you must run set-executionpolicy remoteSigned
You can run it from a batch file by using the following command:
PowerShell -command "& '.\RunSpa.ps1' "
Use T -SQL to generate reports
SPA report data can be extracted by using SQL to build custom reports not that are provided within the
SPAConsole.exe.
for example, the following T-SQL command provides a Top 10 list of servers by CPU for the timeframe covering
the past three days:
select TOP 10
MachineName,
AverageCpu
FROM (
select
__MachineName MachineName,
AVG(AverageValue) AverageCpu
FROM [SPA].[Microsoft.ServerPerformanceAdvisor.CoreOS.V1].vwCpuPerformance
WHERE __Creationtime > dateadd(DAY, -3, GETUTcdate())
AND Name = N'% Processor time' AND CpuId = N'_Total'
GROUP BY __MachineName
) t
OrdER BY t.AverageCpu DESC
Working with multiple projects
In some instances, you may want to partition the SQL Server databases that are used by SPA. This can help reduce
the data size of the SQL Server database or help you logically partition the servers. In these cases, the SPA console
supports multiple projects. You can create a new project database by clicking File, and then clicking New Project.
The First time Use Wizard appears to help create the new project database.
After the projects are created, you can click File, and then click Open Project to switch between projects. The SPA
console does not allow switching databases when outstanding performance analysis is running within the
currently opened project. This is to protect the integrity of the performance data.
When you choose to create a new project database or open a different project database, the current project is
closed. All the open reports are closed when the current project is closed.
Note SQL Server 2008 R2 Express has a 10 GB database limit. By using multiple projects, you can use one or more
SQL Server databases and stay under the 10 GB SQL Server 2008 R2 Express limit.
Logging and debugging
SPA provides basic logging functionality. It only allows logs to be written to a log file, which is located in the same
folder as SPAConsole.exe. The user account that runs the SPA console needs to have Write permission to the folder
where SPA was installed to make sure the logs can be written to the log file.
SPA contains the following valid log levels:
Informational Dumps logs for every action that the SPA console takes, and it is primarily designed for
debugging purposes.
Warning Logs all the failures and exceptions that happen inside the SPA console. Some of the failures are
simply validation failures that can be handled by the SPA console.
Critical Logs only failures and exceptions that cannot be handled by the SPA console. These failures will
cause the SPA console to crash. The logs provide the context information for such failures.
By default, the log level is Warning, which means that SPA will only log failures and exceptions that happen in SPA.
The log level can be changed by editing the SpaConsole.exe.config file in the same folder as SpaConsole.exe is
located. All the logs are written to log.txt file in the same folder.
SPA also provides some basic capability for debugging. To turn on debugging for SPA, users need to manually
modify the SPA project database. The setting is stored in a Configurations table. User need to run the following
SQL script to change the SPA project to debug mode:
UPdate [Configurations] SET Value = N'true' WHERE Name = N'Debugmode'.
In debug mode, the SPA framework preserves all the temporary data that is generated during performance
analysis so you can troubleshoot issues in the advisor packs. This script is primarily designed to be used by advisor
pack developers.
for more info about the debugging capabilities in SPA, see the Server Performance Advisor Pack Development
Guide.
Managing the database
Backup and restore the database
The SPA console does not provide functionality to back up and restore the SPA database. You should use standard
Microsoft SQL Server tools and scripts to back up and restore databases.
clean up the database
The SPA project databases can grow in size as more performance analysis is run. By default, SPA keeps all the
reports. You may want to remove old reports to help improve the performance. You can delete reports through the
Report Explorer interface.
Privacy and security
SPA only supports data collection from target servers to the SPA console. It is not designed to send any
information to Microsoft or non-Microsoft developers. For more info about SPA privacy, refer to the Microsoft
Software License Terms for Server Performance Advisor.
All the data that is collected by SPA is stored in the project databases. Because of the nature of some of the ETW
traces, SPA might collect sensitive information that could have high business importance. You should be aware of
the potential risk associated with sharing access to the SPA project databases. Temporary log files are saved under
the shared folders that are specified on each target computer. Even though SPA will try to delete those temporary
log files when the data import completes, there is no guarantee that those log files will always be deleted. You
should make sure that the shared folders are located in secure locations.
SPA advisor packs contains SQL scripts to parse and analyze performance logs to generate performance reports.
SPA tries to limit the privilege those scripts run under. However, there is still a possibility that the scripts can collect
sensitive information through SPA from target servers, or get or modify sensitive information that is stored in the
same SPA project database. You need to make sure that all the advisor packs that are provisioned to the SPA
project database are from trusted sources.
Errors and troubleshooting
SPAConsole.exe does not start or write log file
When you try to run SPAConsole.exe for the first time, if the .NET Framework is not installed, the application will
not start or write a log file. Ensure that a compatible.NET Framework is installed and working properly before you
start SPA.
Locating log information
SPA stores failure information in the log.txt file under the SPA folder. detailed error messages and call stack
information are written to this folder. If you are experiencing failures that need more information to interpret, you
can open log.txt file to see the error details.
Database size limitations for SQL Server Express
SQL Server Express has a size limit of 10 GB for a user database. This size database has the capacity to store
20,000-30,000 reports. To reduce the possibility of reaching this database limit, we recommend deleting reports
regularly and/or using another version of SQL Server that does not have the 10 GB user database limitation.
SQL Server Express log size and disk capacity
if you are using SQL Server Express, the user database is limited to 10 GB, but the corresponding log file can
exceed 70 GB. For these reasons, we recommend 100 GB or more of free disk space for SQL Server Express. This
disk space should be sufficient to store approximately 20,000 to 30,000 reports. This log file is named
SPADB_log.ldf, and it is found at %Program Files%\Microsoft SQL
Server\MSSQL10.SQLEXPRESS\MSSQL\DatA.
Failure to connect to target server
When you run performance analysis on target servers, the user account that runs the SPA console needs to have
certain privileges to queue the data collector set to PLA on the target servers. Windows Firewall settings also need
to be changed to allow PLA communications to pass through. For detailed configuration instructions, see Setting
up SPA.
Failure to create PLA Data Collection Set on the target server
if you get a Cannot create PLA Data Collection Set on target server message, make sure to do the following:
Make sure the Performance Logs & Alerts service is running
The security setting Network access: Do not allow storage of passwords and credentials for network
authentication is disabled. The security setting must be disabled because SPA needs to use the user
credentials to create the Data Collection Set on the target server.
Running SPA against the console
PLA goes through a different channel if the target server is the same as the SPA console. Even if the user account is
running the SPA console with administrator privileges, PLA will fail. If the SPA console is installed on a target
server, users need to launch SPA as an administrator to make sure the performance analysis task can run on the
console.
Running multiple consoles at the same time
SPA does not support multiple consoles running against the same SPA project database at the same time. SPA also
does not provide the lock and synchronization mechanism to prevent it from happening. If two SPA consoles are
running at the same time, the console will behave inconsistently depending on the time sequence that these SPA
consoles are running. To prevent this, all queued performance analysis sessions should be removed from the list
before it is processed by the console that starts the analysis.
SPA protects the integrity of each report that is successfully generated by SPA. at the same time, SPA does not
guarantee that all the queued analysis tasks will be completed. If you are seeing inconsistent status changes for
performance analysis sessions or errors that claim the system cannot find performance logs that are generated by
data collector set, it is likely to be caused by multiple SPA console instances running against the same SPA project
database.
Running SPA Windows PowerShell cmdlets could also be affected by an SPA console that is running against the
same SPA database. We recommend that you close the SPA console before you run the SPA Windows PowerShell
cmdlets.
SPAConsole.exe recurring collection is disrupted
When you run the SPAConsole.exe and you use a recurring data collection (for example, an hourly collection), the
server that runs the SPAConsole.exe should not be in Power Save mode such that it can suspend. SPA will not
check for a power save policy. This suspended activity may disrupt the regular recurring data collection.
Lost ETW events
To create minimum performance impact on target servers, PLA is designed to run with low priority while it is
collecting performance information. If the target server is busy, PLA will drop some of the data collection tasks to
yield to high-priority tasks that are running on target servers. You should consider setting up the shared folder
where the events get written on a disk that doesn t conflict with the workload s I/O or a faster drive, such as an
SSD. When events are dropped, they are reported in the report view since lost events can impact the reliability of
the generated performance metrics.
Certain permission issues could also cause registry or WMI queries to be skipped. However, this is much less likely
to happen than ETW event loss. As a result, the data collector set results sometimes do not contain all the values
that are requested. You need to make sure that the situation is handled by the T-SQL scripts for all advisor packs. If
the data does not exist in the data collection result, it will be marked as no data in the reports.
Because ETW event loss is common for PLA, data points that are generated based on an ETW trace might not be
consistent with data points that are generated based on, for example, performance counters. For example, it is
possible to see that the total CPU usage by IIS is 80% (which comes from performance counters), and that the top
URLs only use 10% of all the CPU time (which is a data point that comes from the ETW trace). Usually, the data
source for one data point can be viewed through the tooltip of the data point. You should be aware of the impact of
such data loss.
To avoid such event loss, the Result folder should be closed to the target server.
if the data collector results contain incomplete data other than ETW trace loss and the advisor pack developer had
added support for ETW event loss notification, an information bar is shown on top of the single report to notify the
user about the potentially inconsistent report caused by data loss. detailed data loss information can be found in
the log.txt file.
Glossary
Here are some of the terms used with SPA:
Advisor pack A collection of metadata and T-SQL scripts that process the performance logs that are
collected from the target server. The advisor pack then generates reports from the performance log data.
The metadata in the advisor pack defines the data to be collected from the target server for performance
measurements. The metadata also defines the set of rules, the thresholds, and the report format. Most often,
an advisor pack is written specifically for a single server role, for example, Internet Information Services (IIS).
SPA console SpaConsole.exe, which is the central part of SPA. SPA does not need to run on the target
server that you are testing. The SPA console contains all the user interfaces for SPA, from setting up the
project to running analysis and viewing reports. By design, SPA is a two-tier application. The SPA console
contains the UI layer and part of the business-logic layer. The SPA console schedules and processes
performance analysis requests.
SPA framework Provides all the user interfaces, performance log processing, configuration, error handling,
and database APIs, and management procedures.
SPA project A database that contains all the information about the target servers, advisor packs, and
performance analysis reports that are generated on the target servers for the advisor packs. You can
compare and view history and trend charts within the same SPA project. You can create more than one
project. The SPA projects are independent of one another, and there is no data shared across projects.
Target server The physical computer or virtual machine that runs Windows Server with certain server roles,
such as IIS.
Data analysis session A performance analysis on a specific target server. A data analysis session can
include multiple advisor packs. The data collector sets from those advisor packs are merged into a single
data collector set. All performance logs for a single data analysis session are collected during the same time
period. Analyzing reports that are generated by advisor packs running in the same data analysis session can
help users understand the overall performance situation and identify root causes for performance issues.
Event Tracing for Windows A high-performance, low-overhead, scalable tracing system that is provided
in Windows. It provides profiling and debugging capabilities, which can be used to troubleshoot a variety of
scenarios. SPA uses ETW events as a data source for generating the performance reports. For general
information about ETW, see Improve Debugging and Performance Tuning with ETW.
Windows Management Instrumentation (WMI) The infrastructure for management data and operations
in Windows. You can write WMI scripts or applications to automate administrative tasks on remote
computers. WMI also supplies management data to other parts of the operating system and to products.
SPA uses WMI class information and data points as sources for generating performance reports.
Performance counters Used to provide information about how well the operating system or an
application, service, or driver is performing. The performance counter data can help determine system
bottlenecks, and fine-tune system and application performance. The operating system, network, and devices
provide counter data that an application can consume to provide users with a graphical view of how well the
system is performing. SPA uses performance counter information and data points as sources to generate
performance reports.
Performance Logs and Alerts (PLA) Collects performance logs and traces and raises performance alerts
when certain triggers are met. PLA can be used to collect performance counters, event tracing for Windows
(ETW), WMI queries, registry keys, and configuration files. PLA also supports remote data collection through
remote procedure calls (RPC). The user defines a data collector set, which includes information about the
data to be collected, frequency of data collection, data collection duration, filters, and a location for saving
the result files. SPA uses PLA to collect all the performance data from the target servers.
Single report A SPA report that is generated based on one data analysis session for one advisor pack on a
single target server. It can contain notifications and various data sections.
Side-by-side report A SPA report that compares two single reports for the same advisor pack. The two
reports can be generated from different target servers or from separate performance analysis runs on the
same target server. The side-by-side report creates the capability to compare two reports to help users
identify abnormal behaviors or settings in one of the reports. A side-by-side report contains notifications
and various data sections. In each section, data from both reports are listed side-by-side.
Trend chart A SPA report that is used to investigate repetitive patterns of performance issues. Many
repetitive performance issues are caused by scheduled server load changes from the server or from client
computers, which can happen daily or weekly. SPA provides a 24-hour trend chart and a 7-day trend chart
to identify these issues.
The user can choose one or more data series at a time, which is a numeric value inside the single report,
such as Average total CPU usage. more specifically, a numeric value is a scalar value from a single server
that is generated by a single AP at a given time instance. SPA groups those values into 24 groups, one for
each hour of the day (seven for a 7-day report, one for each day of the week). SPA calculates average,
minimum, maximum, and standard deviations for each group.
Historical chart A SPA report that is used to show changes in certain numeric values inside single reports
for a given server and advisor pack pair over time. The user can choose multiple data series and show them
together in the historical chart to understand the correlation between different data series.
Data series Numeric data that is collected from the same data source over a period of time. The same
source means that the data has to come from the same target server, such as the average request queue
length for IIS on one server.
Rules Combinations of logic, thresholds, and descriptions. They represent a potential performance issue.
Each advisor pack contains multiple rules. Each rule is triggered by a report generation process. A rule
applies the logic and thresholds to the data in single report. If the criteria are met, a warning notification is
raised. If not, the notification is set to the OK state. If the rule does not apply, the notification is set to the Not
Applicable (NA) state.
Notifications Information that a rule displays to users. It includes the status of the rule (OK, NA, or a
Warning), the name of the rule, and possible recommendations to address the performance issues.
Server Performance Advisor Pack Development
Guide
4/24/2017 • 42 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
This development guide for Microsoft Server Performance Advisor (SPA) provides guidelines to help developers
and system administrators develop advisor packs to analyze server performance.
It assumes you are familiar with Performance Logs and Alerts (PLA), performance counters, registry settings,
Windows Management Instrumentation (WMI), Event Tracing for Windows (ETW), and Transact SQL (T-SQL).
This guide applies to the following versions of Windows Server:
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008
This guide applies to the following versions of Windows:
Windows 8.1
Windows 8
Windows 7
for more info about using SPA, see Server Performance Advisor User's Guide.
SPA Advisor Pack Overview
An advisor pack is typically designed for a particular server role, and it defines the following:
Data to be collected through PLA, including Windows Management Instrumentation (WMI), performance
counters, registry settings, files, and Event Tracing for Windows (ETW)
Rules, which shows alerts and recommendations
Data to be shown (collected raw data, aggregated data, or top 10 lists)
Statistics to view a value that changes over the time
Statistics values that can be trended
An advisor pack includes the following elements:
XML metadata (ProvisionMetadata.xml)
Performance Logs and Alerts (PLA) data collector set
Report layout
SQL scripts
A main stored procedure
SQL objects, such as stored procedures and user-defined functions
ETW schema file (Schema.man) this is optional
Advisor pack workflow
In this flowchart, the green circles represent advisor packs. All other circles represent the phases that are running
in the process of the SPA framework. SPA uses an advisor pack to collect data, import the data into the database,
initialize execution environment, and run SQL scripts.
Collect data
When an advisor pack is queued for a particular server by using SPA, the data collection module queries the data
collector set XML from the advisor pack and collects data from the target server. The raw data is stored in a userspecified file share. The data collection will not stop until the SPA run duration designated by the user is exceeded.
import data into the database
After the data collection is completed, each type of data is imported into a corresponding table in the SQL Server
database. For example, registry settings are imported into a table called #registryKeys.
importing ETW file requires an ETW schema file for decoding the .etl file. The ETW schema file is an XML file. It can
be generated by using tracerpt.exe, which is included with Windows. The ETW schema file is only required when
the advisor pack needs to import ETW data.
Switch to low user rights
The SPA framework automatically adjusts privileges to minimize the required security access level. Because
advisor packs can be developed or modified by anyone, it is possible for an advisor pack to contain tampered SQL
scripts. To mitigate the security risk, any SQL script for an advisor pack should be run with low user rights. It can
only access limited database objects, such as temporary tables and SPA APIs exposed as stored procedures. The
SQL scripts in an advisor pack can call those store procedures to interact with the SPA framework.
Initialize execution environment
Advisor packs can generate different types of output, such as notifications, recommendations, fact tables,
statistics, and charts for statistics. The SQL scripts perform certain calculations against the collected data. The
yielded results are stored in temporary tables through SPA public APIs. at the initialization stage, these temporary
tables and other system resources need to be provisioned.
Run SQL scripts
There is a main stored procedure, which is named by the advisor pack developer. The SPA framework calls this
stored procedure to initiate the calculation. The stored procedure consumes the collected data and communicates
the end result to the SPA framework.
Switch to administrative rights
Administrator rights are required to generate a report. Report generation is fully controlled by SPA. It is less likely
to be tampered with.
Generate a report
Before the main stored procedure completes for an advisor pack, all the calculated results, such as notifications
and statistics, are not persisted. During this phase, the SPA framework transfers the end results from temporary
tables to tables in a particular format. After this phase is complete, you can view the reports by using the SPA
console.
Authoring an advisor pack
Quick guidelines
The following flowchart describes the steps for you to develop a fully functional advisor pack. This section also
includes step-by-step examples to better explain each step.
An advisor pack is usually structured in the following way:
Advisor pack
ProvisionMetadata.xml
Scripts
main.sql
func.sql
Schema.man
Every advisor pack must have a file called ProvisionMetadata.xml. It defines basic advisor pack information, what
data to collect, notifications and rules, and how the report needs to be stored and displayed. The SPA framework
uses this information to generate a temporary table and then transfer the results in the temporary table into a
table that users can access.
All report SQL scripts must be saved in a subfolder called Scripts. For maintenance purposes, we recommend that
you save different database objects in different SQL Server files. There must be at least one stored procedure as a
main entry point.
Note The schema.man file is not required unless your advisor pack collects ETW traces. This schema file is used to
describe the schema of the ETW events and to decode ETW events.
Defining basic information
This section describes some of the basic elements that make up an advisor pack, including ProvisionMetadata.xml
and attributes.
The following is an example header for the ProvisionMetadata.xml file:
<advisorPack
xmlns="http://microsoft.com/schemas/ServerPerformanceAdvisor/ap/2010"
name="Microsoft.ServerPerformanceAdvisor.CoreOS.V2"
displayName="Microsoft CoreOS Advisor Pack V2"
description="Microsoft CoreOS Advisor Pack"
author="Microsoft"
version="1.0"
frameworkversion="3.0"
minOSversion="6.0"
reportScript="ReportScript">
</advisorPack>
Advisor pack version
attribute name: version
Advisor pack developers can define major and minor versions for the advisor pack:
A major version usually involves significant improvements. The results that are generated by an old
version might not be compatible with the new one. We strongly recommend including the major version in
the advisor pack name.
SPA allows minor version upgrades when there are only minor changes with no data incompatibility
issues.
for more info about versioning, see Advanced topics.
Script entry point
attribute name: reportScript
The SPA framework looks for the main stored procedure name from the script entry point and runs it in a secured
manner.
Other attributes
Here are some other attributes that can be used to identify an advisor pack:
Display name: displayName
Description: description
Author: author
Framework version: frameworkversion (defaults to 3.0)
Minimum operating system version: minOSversion (this is reserved for future extensibility)
Lost event notification: showEventLostWarning
Defining the data collector set
A data collector set defines the performance data that the SPA framework should collect from the target server. It
supports registry settings, WMI, performance counters, files from the target server, and ETW.
<advisorPack>
<dataSourceDefinition xmlns="http://microsoft.com/schemas/ServerPerformanceAdvisor/dc/2010">
<dataCollectorSet duration="10">
<registryKeys>
?<registryKey>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes\\</registryKey>
</registryKeys>
<managementpaths>
?<path>Root\Cimv2:select * FROM Win32_DiskDrive</path>
</managementpaths>
<performanceCounters interval="2">
?<performanceCounter>\PhysicalDisk(*)\Avg. Disk sec/Transfer</performanceCounter>
</performanceCounters>
<files>
?<path>%windir%\System32\inetsrv\config\applicationHost.config</path>
</files>
<providers>
?<provider session="NT Kernel Logger" guid="{9E814AAD-3204-11D2-9A82-006008A86939}" keywordsany="06010201"
keywordsAll="00000000" level="00000000" />
</providers>
</dataCollectorSet>
</dataSourceDefinition>
</advisorPack>
The duration attribute of <dataCollectorSet/> in the previous example defines the duration of data collection
(the unit of time is seconds). duration is a required attribute. This setting controls the collection duration that is
used by performance counters and ETW.
Collect registry data
You can collect registry data from the following registry hives:
HKEY_CLASSES_ROOT
HKEY_CURrenT_CONFIG
HKEY_CURrenT_USER
HKEY_LOCAL_MACHINE
HKEY_USERS
To collect a registry setting, specify the full path to the value name: HKEY_LOCAL_MACHINE\MyKey\MyValue
To collect all of the settings under a registry key, specify the full path to the registry key:
HKEY_LOCAL_MACHINE\MyKey\
To collect all the values under a registry key and its sub-keys (PLA recursively collects the registry data), use two
backslashes for the last path delimiter: HKEY_LOCAL_MACHINE\MyKey\\
To collect registry information from a remote computer, include the computer name at the beginning of the
registry path: HKEY_LOCAL_MACHINE\MyKey\MyValue
for example, you may have a registry key that appears as follows:
Windows registry editor version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes]
"activePowerScheme"="db310065-829b-4671-9647-2261c00e86ef"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes\db310065-829b-4671-96472261c00e86ef]
"Description"=
FriendlyName = Power Source Optimized
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes\db310065-829b-4671-96472261c00e86ef \0012ee47-9041-4b5d-9b77-535fba8b1442\6738e2c4-e8a5-4a42-b16a-e040e769756e
"ACSettingIndex"=dword:000000b4
"DCSettingIndex"=dword:0000001e
Example 1: Return only the active PowerSchemes and their values:
<registryKey>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes</registryKey>
Example 2: Returns all the key value pairs under this path:
Note PLA runs under user credentials. Some registry keys require administrative credentials. The enumeration
stops when it fails to access any of the sub-keys.
<registryKey>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes\\</registryKey>
All collected data will be imported into a temporary table called #registryKeys before a SQL report script is run.
The following table shows the results for example 2:
KEYNAME
KEYTYPEID
VALUE
HKEY_LOCAL_MACHINE...\PowerSc
hemes
1
db310065-829b-4671-96472261c00e86ef
\db310065-829b-4671-96472261c00e86ef\Description
2
\db310065-829b-4671-96472261c00e86ef\FriendlyName
2
Power Source Optimized
...\6738e2c4-e8a5-4a42-b16ae040e769756e\ACSettingIndex
4
180
...\6738e2c4-e8a5-4a42-b16ae040e769756e\DCSettingIndex
4
30
The schema for the #registryKeys table is as follows:
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
KeyName
Nvarchar(300) NOT NULL
registry key full path name
KeytypeId
Smallint NOT NULL
Internal type Id
Value
Nvarchar(4000) NOT NULL
All the values
The KeytypeID column can have one of the following types:
ID
TYPE
1
String
2
expandString
3
Binary
4
DWord
5
DWordBigEndian
6
Link
7
MultipleString
8
Resourcelist
9
FullResourceDescriptor
10
ResourceRequirementslist
11
Qword
Collect WMI
You can add any WMI query. For more info about writing WMI queries, see WQL (SQL for WMI).The following
example queries a page file location:
<path>Root\Cimv2:select * FROM Win32_PageFileUsage</path>
The query in the above example returns one record:
CAPTION
NAME
PEAKUSAGE
C:\pagefile.sys
C:\pagefile.sys
215
Because WMI returns a table with different columns, when the collected data is imported into a database, SPA
performs data normalization and is added to the following tables:
#WMIObjects table
SEQUENCEID
NAMESPACE
CLASSNAME
RELATIVEPATH
WMIQUERYID
10
Root\Cimv2
Win32_PageFileU
sage
Win32_PageFileU
sage.Name=
1
"C:\pagefile.sys"
#WmiObjectsProperties table
ID
QUERY
1
Root\Cimv2:select * FROM Win32_PageFileUsage
#WmiQueries table
ID
QUERY
1
Root\Cimv2:select * FROM Win32_PageFileUsage
#WmiObjects table schema
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
SequenceId
Int NOT NULL
Correlate the row and its
properties
Namespace
Nvarchar(200) NOT NULL
WMI namespace
ClassName
Nvarchar(200) NOT NULL
WMI class name
Relativepath
Nvarchar(500) NOT NULL
WMI relative path
WmiqueryId
Int NOT NULL
Correlate the key of #WmiQueries
SQL DATA TYPE
DESCRIPTION
#WmiObjectProperties table schema
COLUMN NAME
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
SequenceId
Int NOT NULL
Correlate the row and its
properties
Name
Nvarchar(1000) NOT NULL
Property name
Value
Nvarchar(4000) NULL
The value of the current property
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
Id
Int NOT NULL
Unique query ID
query
Nvarchar(4000) NOT NULL
Original query string in the
provision metadata
#WmiQueries table schema
Collect performance counters
Here s an example of how to collect a performance counter:
<performanceCounters interval="1">
<performanceCounter>\PhysicalDisk(*)\Avg. Disk sec/Transfer</performanceCounter>
</performanceCounters>
The interval attribute is a required global setting for all performance counters. It defines the interval (the unit of
time is seconds) of collecting performance data.
In the previous example, counter \PhysicalDisk(*)\Avg. Disk sec/Transfer will be queried every second.
There could be two instances: _Total and 0 C: D:, and the output could be as follows:
TIMESTAMP
CATEGORYNAME
COUNTERNAME
INSTANCE VALUE OF
_TOTAL
INSTANCE VALUE OF 0
C: D:
13:45:52.630
PhysicalDisk
Avg. Disk
sec/Transfer
0.001000083624
73995
0.001000083624
73995
13:45:53.629
PhysicalDisk
Avg. Disk
sec/Transfer
0.002800234149
27187
0.002800234149
27187
13:45:54.627
PhysicalDisk
Avg. Disk
sec/Transfer
0.003859998532
30048
0.003859998532
30048
13:45:55.626
PhysicalDisk
Avg. Disk
sec/Transfer
0.000933297607
934224
0.000933297607
934224
To import the data to the database, the data will be normalized into a table called #PerformanceCounters.
CATEGORYDISPLAYNAME
INSTANCENAME
COUNTERDISPLAYNAME
VALUE
PhysicalDisk
_Total
Avg. Disk sec/Transfer
0.00100008362473995
PhysicalDisk
0 C: D:
Avg. Disk sec/Transfer
0.00100008362473995
PhysicalDisk
_Total
Avg. Disk sec/Transfer
0.00280023414927187
PhysicalDisk
0 C: D:
Avg. Disk sec/Transfer
0.00280023414927187
PhysicalDisk
_Total
Avg. Disk sec/Transfer
0.00385999853230048
PhysicalDisk
0 C: D:
Avg. Disk sec/Transfer
0.00385999853230048
PhysicalDisk
_Total
Avg. Disk sec/Transfer
0.00093329760793422
4
PhysicalDisk
0 C: D:
Avg. Disk sec/Transfer
0.00093329760793422
4
Note The localized names, such as CategoryDisplayName and CounterdisplayName, vary based on the
display language used on the target server. Avoid using those fields if you want to create a language-neutral
advisor pack.
#PerformanceCounters table schema
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
timestamp
datetime2(3) NOT NULL
The collected date time in UNC
CategoryName
Nvarchar(200) NOT NULL
Category name
CategoryDisplayName
Nvarchar(200) NOT NULL
Localized category name
InstanceName
Nvarchar(200) NULL
Instance name
CounterName
Nvarchar(200) NOT NULL
Counter name
CounterdisplayName
Nvarchar(200) NOT NULL
Localized counter name
Value
Float NOT NULL
The collected value
Collect files
The paths can be absolute or relative. The file name can include the wildcard character (*) and the question mark
(?). For example, to collect all the files in the temporary folder, you can specify c:\temp\*. The wildcard character
applies to files in the specified folder.
if you want to also collect files from the subfolders of the specified folder, use two backslashes for the last folder
delimiter, for example, c:\temp\\*.
Here s an example that queries the applicationHost.config file:
<path>%windir%\System32\inetsrv\config\applicationHost.config</path>
The results can be found in a table called #Files, for example:
QUERYPATH
FULLPATH
PARENTPATH
FILENAME
CONTENT
%windir%...\applic
ationHost.config
C:\Windows
C:\Windows
0x3C3F78
...\applicationHost
.config
...\config
applicationHost.c
onfig
#Files table schema
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
querypath
Nvarchar(300) NOT NULL
Original query statement
Fullpath
Nvarchar(300) NOT NULL
Absolute file path and file name
Parentpath
Nvarchar(300) NOT NULL
File path
FileName
Nvarchar(300) NOT NULL
File name
Content
Varbinary(MAX) NULL
File content in binary
Defining rules
After enough data is collected by using PLA from a target server, the advisor pack can use this data for validation,
and show a quick summary to the system administrators.
Rules give a quick overview about the server s performance. They highlight issues and provide recommendations.
You can list all the rules that you want to validate for an advisor pack. For example, if you want to develop a core
operating system advisor pack, the possible rules could include:
Whether the CPU power mode is power saving
Whether the server is in a virtualized environment
Whether there is disk I/O pressure
Rules contain the following elements:
Dependent threshold (a configurable part of a rule)
Rule definition (alerts and recommendations)
Here s an example of a simple rule:
<advisorPack>
<reportDefinition>
<thresholds>
<threshold />
</thresholds>
<rules>
<rule />
</rule>
</rules>
</reportDefinition>
</advisorPack>
Threshold
Threshold is a configurable factor that enables the system administrators to decide when a rule should show a
good or a bad status. The following example shows a rule to detect free space on a system drive and a warning
when free space is less than 10 GB.
<threshold name="freediskSize" caption="Free Disk Size (GB)" description="Free Disk Size value="10" />
However, in this case, the system administrator has a smaller hard drive. He thinks 5 GB of free space might still
be a good condition, and he does not want to see a warning. He can update the default value from 10 to 5
through the SPA console without having to understand how to develop an advisor pack.
Introducing a threshold helps system administrators quickly change the value without having to modify the
advisor pack.
In the example, all attributes except description are required. You can use any number for value.
A threshold can be shared across the rules.
Alerts and recommendations
The rule definition does not involve any logic calculations. It defines how the UI might look and how the SQL
Server report script communicates the results to the UI.
A rule has three parts:
Alert (rule caption)
Recommendation (advice)
associated threshold (optional information about dependencies)
Here s an example of a rule:
<rule name="freediskSize" caption="Free Disk Size on System Drive" description="This rule checks free disk
size on system drive ">
<advice name="SuccessAdvice" level="Success" message="No issue found.">No Recommendation.</advice>
<advice name="WarningAdvice" level="Warning" message="Not enough free space on system drive.">
Install OS on larger disk.</advice>
<dependencies>
<threshold ref="freediskSize"/>
</dependencies>
</rule>
You can define as much advice as you want, and you usually would define recommendations. The level of advice
can be Success or Warning.
You can link to as many thresholds as you want. You can even link to a threshold that is irrelevant to the current
rule. Linking helps the SPA console easily manage thresholds.
The rule name and the recommendations are keys, and they are unique in their scope. No two rules can have the
same name, and no two recommendations within one rule can have the same name. These names will be very
IMPORTANT when you write an SQL script report. You can call the [dbo].[SetNotification] API to set the rule
status.
Defining UI display elements
After the rules are defined, system administrators can see the report summary. However, often system
administrators are interested in the aggregated data, and they want to check the data sources that were used in
the performance rules.
Continuing with the previous example, the user knows whether there is enough free disk space on the system
drive. Users might also be interested in the actual size of the free space. A single value group is used to store and
display such results. Multiple single values can be grouped and shown in a table in the SPA console. The table has
only two columns, Name and Value, as shown here.
NAME
VALUE
Free Disk Size On System Drive (GB)
100
Total Disk Size Installed (GB)
500
if a user wants to see a list of all hard drives that are installed on the server and their disk size, we could call a list
value, which has three columns and multiple rows, as shown here.
DISK
FREE DISK SIZE (GB)
TOTAL SIZE (GB)
0
100
500
1
20
320
In an advisor pack, there could be many tables (single value groups and list value tables). We can use a section to
organize and categorize these tables.
In summary, there are three types of UI elements:
Sections
Single value groups
list value tables
Here s an example that shows the UI elements:
<advisorPack>
<dataSourceDefinition/>
<reportDefinition>
<datatypes>
<datatype .../>
</datatypes>
<thresholds/>
<rule/>
<sections>
<section .../>
</sections>
<singleValues>
<singleValue .../>
</singleValues>
<listValues>
<listValue .../>
</listValues>
</reportDefinition>
</advisorPack>
Sections
A section is purely for the UI layout. It does not participate in any logical calculations. Each single report contains a
set of top-level sections that do not have a parent section. The top-level sections are presented as tabs in the
report. Sections can have subsections, with a maximum of 10 levels. All the subsections under the top-level
sections are presented in expandable areas. A section can contain multiple subsections, single value groups, and
list value tables. Single value groups and list value tables are presented as tables.
Here is an example of top-level section.
<section name="CPU" caption="CPU"/>
A section name must be unique. It is used as a key that can be linked to by other sections, single value groups, and
list value tables.
The following example has an attribute, parent, and it is pointing to the section CPU. CPUFacts is a child of the
section named CPU. parent must refer to a previous section name; otherwise, it can result in a loop.
<section name="CPUFacts" caption="Facts" parent="CPU"/>
The following single-value group has an attribute, section, and it can point to any section, based on your UI
design.
<singleValue name="CPUInformation" section="CPUFacts" caption="Physical CPU Information"> </singleValue>
Data types
A single value group and a list value table contain different types of data, such as string, int, and float. Because
these values are stored in the SQL Server database, you can define an SQL data type for each data property.
However, defining an SQL data type is quite complicated. You have to specify the length or precision, which might
be prone to change.
To define logical data types, you can use the first child of <reportDefinition/>, which is where you can define a
mapping of the SQL data type and your logical type.
The following example defines two data types. One is string and the other is companyCode.
<datatype name="string" = sqltype="nvarchar(4000)" />
<datatype name="companyCode" sqltype="nvarchar(100)" />
A data type name can be any valid string. Here s a list of allowed SQL data types:
bigint
binary
bit
char
date
datetime
datetime2
datetimeoffset
decimal
float
int
money
nchar
numeric
nvarchar
real
smalldatetime
smallint
smallmoney
time
tinyint
uniqueidentifier
varbinary
varchar
for more info about these SQL data types, see Data types (Transact-SQL).
Single value groups
A single value group groups multiple single values together to present in a table as shown here.
<singleValue name="Systemoverview" section="SystemoverviewSection" caption="Facts">
<value name="OsName" type="string" caption="Operating system" description="WMI:
Win32_OperatingSystem/Caption"/>
<value name="Osversion" type="string" caption="OS version" description="WMI: Win32_OperatingSystem/version"/>
<value name="OsLocation" type="string" caption="OS location" description="WMI:
Win32_OperatingSystem/SystemDrive"/>
</singleValue>
In the previous example, we defined a single value group. It is a child node of the section
SystemoverviewSection. This group has single values, which are OsName, Osversion, and OsLocation.
A single value must have a global unique name attribute. In this example, the global unique name attribute is
Systemoverview. The unique name will be used to generate a corresponding view for custom report. Each view
contains the prefix vw, such as vwSystemoverview.
Although you can define multiple single value groups, no two single value names can be the same, even if they
are in different groups. The single value name is used by the SQL script report to set the value accordingly.
You can define a data type for each single value. The allowed input for type is defined in <datatype/>. The final
report could look like this:
Facts
NAME
VALUE
Operating system
<a value will be set by report script>
OS version
<a value will be set by report script
OS location
<a value will be set by report script>
The caption attribute of <value/> is presented in the first column. Values in the value column are set in the
future by the script report through [dbo].[SetSingleValue]. The description attribute of <value/> is shown in a
tooltip. Usually the tooltip shows users the source of the data. For more info on tooltips, see Tooltips.
list value tables
Defining a list value is as the same as defining a table.
<listValue name="NetworkAdapterInformation" section="NetworkIOFacts" caption="Physical network adapter
information">
<column name="NetworkAdapterId" type="string" caption="ID" description="WMI: Win32_NetworkAdapter/DeviceID"/>
<column name="NetworkAdapterName" type="string" caption="Name" description="WMI: Win32_NetworkAdapter/Name"/>
<column name="type" type="string" caption="type" description="WMI: Win32_NetworkAdapter/Adaptertype"/>
<column name="Speed" type="decimal" caption="Speed (Mbps)" description="WMI: Win32_NetworkAdapter/Speed"/>
<column name="MACaddress" type="string" caption="MAC address" description="WMI:
Win32_NetworkAdapter/MACaddress"/>
</listValue>
The list value name must be globally unique. This name will become the name of a temporary table. In the
previous example, the table named #NetworkAdapterInformation will be created at the execution environment
initialization stage, which contains all the columns that are described. Similar to a single value name, a list value
name is also used as part of custom view name, for instance, vwNetworkAdapterInformation.
@type of <column/> is defined by <datatype/>
The mock UI of the final report could look as follows:
Physical network adapter information
ID
NAME
TYPE
SPEED (MBPS)
MAC ADDRESS
The caption attribute of <column/> is shown as a column name, and the description attribute of <column/> is
shown as a tooltip for the corresponding column header. Usually the tooltip shows the user the source of the
data. For more info, see Tooltips.
In some cases, a table may have a lot of columns and only a few rows, so swapping the columns and rows would
make the table look much better. To swap the columns and rows, you can add the following style attribute:
<listValue style="Transpose"
Defining charting elements
You can pick any statistics key and view the values in an historical chart or a trend chart. There are two types of
statistics:
Static statistics A single value, which is known at design time. For example, the free disk space on a
system drive would be a static statistic.
Dynamic statistics Might be unknown at design time. For example, the average CPU usage of each core is
a dynamic statistic because you do not know how many CPU cores could in the system at design time.
The statistics key has a limitation that the data must be compatible with double data type. It can be an integer,
decimal, or a string that can be converted to double.
SPA uses a single value group to support static statistics and a list value table to support dynamic statistics. The
following sections describe how to define static statistic and dynamic statistic keys.
Static statistics
As mentioned previously, a static statistic is a single value. Logically, any single value could be defined as a static
statistic. However, it is meaningless to view a single value that cannot be cast to a number type. To define a static
statistic, you can simply add the attribute trendable to the corresponding single value key as shown below:
<value name="freediskSize" type="int" trendable="true"
Dynamic statistics
Dynamic statistic keys are not known at design time, so the number of possible values is unknown. However,
because list values are stored in multiple rows, it would be easy to use a list value table to store dynamic statistics.
for example, if we need to show charts for the average CPU usage of different cores, we could define a table with
columns for CpuId and AverageCpuUsage:
<listValue name="CpuPerformance">
<column name="CpuId" type="string" caption="CPU ID" columntype="Key"/>
<column name="AverageCpuUsage" type="decimal" caption="Average" columntype="Value"/>
</listValue>
Another attribute, columntype, can be Key, Value, or Informational. The data type of the Key column must be
double or double convertible. In a Key column, you cannot insert the same keys into a table. Value or
Informational columns do not have this limitation.
The statistics values are stored in Value columns.
Informational columns are like ordinary columns in normal list value tables. Informational is the default
column type if you do not specify one. Such columns will not affect the number of statistics keys or participate in
statistics-related calculations.
Continuing with the previous example, if a server has two CPU cores, the result in the table could look like this:
CPUID
AVERAGECPUUSAGE
0
10
1
30
at the same time, two statistics keys are generated by the SPA framework. One is for CPU 0 and the other is for
CPU 1.
As the following example indicates multiple Value columns with multiple Key columns is supported.
COUNTERNAME
INSTANCENAME
AVERAGE
SUM
% Processor time
_Total
10
20
% Processor time
CPU0
20
30
In this example, you have two Key columns and two Value columns. SPA generates two statistics keys for the
Average column and another two keys for the Sum column. The statistics keys are:
CounterName (% Processor time) / InstanceName (_Total) / Average
CounterName (% Processor time) / InstanceName (CPU0) / Average
CounterName (% Processor time) / InstanceName (_Total) / Sum
CounterName (% Processor time) / InstanceName (CPU0) / Sum
CounterName and InstanceName are combined as one key. The combined key cannot have any duplication.
SPA generates many statistics keys. Some of them might not be interesting to you, and you may want to hide
them from the UI. SPA enables developers to create a filter to show only useful statistics keys.
for the previous example, the system administrators may only be interested in keys in which the InstanceName is
_Total or CPU1. The filter can be defined as follows:
<listValue name="CpuPerformance">
<column name="CounterName" type="string" columntype="Key"/>
<column name="InstanceName" type="string" columntype="Key">
<trendableKeyValues>
<value>_Total</value>
<value>CPU1</value>
</trendableKeyValues>
</column>
<column name="Average" type="decimal" columntype="Value"/>
<column name="Sum" type="decimal" columntype="Value"/>
</listValue>
<trendableKeyValues/> can be defined under any Key column. If more than one Key column has such a filter
configured, AND logic will be applied.
Developing report scripts
After the provision metadata is defined, we can start to write the report script, which is a T-SQL stored procedure.
There are name and reportScript attributes in the provision metadata header, as shown here:
<advisorPack name="Microsoft.ServerPerformanceAdvisor.CoreOS.V1" reportScript="ReportScript"
The main report script is named by combining the name and reportScript attributes. In the following example, it
will be [Microsoft.ServerPerformanceAdvisor.CoreOS.V2].[ReportScript].
create PROCEDURE [Microsoft.ServerPerformanceAdvisor.CoreOS.V2].[ReportScript] AS SET NOCOUNT ON
- Set alert and notification
- Prepare data for report view
The name attribute will be used as a database schema name, such as a namespace. This rule applies to all other
database objects that belong to the current advisor pack, such as list value and stored procedures.
Benefits to having this schema name in front of the database objects include:
Avoiding naming conflict for different advisor packs
Providing greater security
In the SQL Server database, the default schema name is dbo. Database owner credentials are usually required to
operate database objects under dbo. If we do not create a schema for each advisor pack, it is likely that two
advisor packs will define a list value with the same name. This should be irrelevant because you can introduce a
schema name to solve this issue. In addition, deprovisioning an advisor pack is much easier. Because the advisor
pack object belongs to a schema other than dbo, this allows SPA to use a lower user privilege to access them.
A normal report script does the following:
Accesses raw collected data
Performs calculations based on the raw data
changes alerts and recommendations
Prepares data for the report view
Access raw collected data
All collected data is imported into the following corresponding tables. For more info about the table schema, see
Defining the data collector set.
registry
#registryKeys
WMI
#WMIObjects
#WmiObjectProperties
#WmiQueries
Performance counter
#PerformanceCounters
File
#Files
ETW
#Events
#EventProperties
Set rule status
The [dbo].[SetNotification] API sets the rule status, so you can see a Success or Warning icon in the UI.
@ruleName nvarchar(50)
@adviceName nvarchar(50)
The alert and recommendation messages are stored in the provision metadata XML file. This makes the report
script easier to manage.
Initially, every rule status is N/A. You can use this API to set a rule status by specifying an advice name. The level
of the advice name will be used as the rule status.
Recall that we defined the following rule earlier:
<rule name="freediskSize" caption="Free Disk Size on System Drive" description="This rule checks free disk
size on the system drive ">
<advice name="SuccessAdvice" level="Success" message="No issue found.">No recommendation.</advice>
<advice name="WarningAdvice" level="Warning" message="Not enough free space on system drive.">Install the
operating system on a larger disk.</advice>
</rule>
Assuming the free space is less than 2 GB, we need set the rule to the Warning level. The SQL script will be as
follows:
if (@freediskSizeInGB < 2)
BEGIN
exec dbo.SetNotification N'freediskSize', N'WarningAdvice'
END
ELSE
BEGIN
exec dbo.SetNotification N'freediskSize', N'SuccessAdvice'
END
Get threshold value
The [dbo].[GetThreshold] API gets the thresholds:
@key nvarchar(50)
@value float output
Note The thresholds are name-value pairs, and they can be referenced in any rules. The system administrators
can use the SPA console to adjust the thresholds.
Continuing with the previous example, for a threshold, the definition will be as follows:
<thresholds>
<threshold name="freediskSize" caption="Free Disk Size (GB)" description="Free Disk Size value="10" />
</thresholds>
<rule name="freediskSize" caption="Free Disk Size on System Drive" description="This rule checks free disk
size on system drive ">
<advice name="SuccessAdvice" level="Success" message="No issue found.">No recommendation.</advice>
<advice name="WarningAdvice" level="Warning" message="Not enough free space on the system drive.">
Install the operating system on a larger disk.</advice>
<dependencies>
<threshold ref="freediskSize"/>
</dependencies>
</rule>
The report script can be modified as shown here:
DECLARE @freediskSize FLOat
exec dbo.GetThreshold N freediskSize , @freediskSize output
if (@freediskSizeInGB < @freediskSize)
Set or remove the single value
The [dbo].[SetSingleValue] API sets the single value:
@key nvarchar(50)
@value sql_variant
This value can execute multiple times for the same single value key. The last value is saved.
The following example shows some defined single values:
<singleValue section="Systemoverview" caption="Facts">
<value name="OsName" type="string" caption="Operating System" description="WMI:
Win32_OperatingSystem/Caption"/>
<value name="Osversion" type="string" caption="OS version" description="WMI: Win32_OperatingSystem/version"/>
<value name="OsLocation" type="string" caption="OS Location" description="WMI:
Win32_OperatingSystem/SystemDrive"/>
</singleValue>
You can then set the single value as shown here:
exec dbo.SetSingleValue N OsName , Windows 7
exec dbo.SetSingleValue N Osversion , 6.1.7601
exec dbo.SetSingleValue N OsLocation , c:\
In rare cases, you may want to remove the result that you previously set by using the [dbo].[removeSingleValue]
API.
@key nvarchar(50)
You can use the following script to remove the previously set value.
exec dbo.removeSingleValue N Osversion
Get data collection information
The [dbo].[GetDuration] API gets the user designated duration in seconds for the data collection:
@duration int output
Here s an example report script:
DECLARE @duration int
exec dbo.GetDuration @duration output
The [dbo].[GetInternal] API gets the interval of a performance counter. It could return NULL if the current report
does not have performance counter information.
@interval int output
Here s an example report script:
DECLARE @interval int
exec dbo.GetInterval @interval output
Set a list value table
There is no API for updating list value tables. However, you can directly access the list value tables. at the
initialization stage, a corresponding temporary table will be created for each list value.
The following example shows a list value table:
<listValue name="NetworkAdapterInformation" section="NetworkIOFacts" caption="Physical Network Adapter
Information">
<column name="NetworkAdapterId" type="string" caption="ID" description="WMI: Win32_NetworkAdapter/DeviceID"/>
<column name="NetworkAdapterName" type="string" caption="Name" description="WMI: Win32_NetworkAdapter/Name"/>
<column name="type" type="string" caption="type" description="WMI: Win32_NetworkAdapter/Adaptertype"/>
<column name="Speed" type="decimal" caption="Speed (Mbps)" description="WMI: Win32_NetworkAdapter/Speed"/>
<column name="MACaddress" type="string" caption="MAC address" description="WMI:
Win32_NetworkAdapter/MACaddress"/>
</listValue>
You can then write a SQL script to insert, update, or delete the results:
INSERT INTO #NetworkAdapterInformation (
NetworkAdapterId,
NetworkAdapterName,
type,
Speed,
MACaddress
)
VALUES (
)
Development and debugging
Writing logs
if there is any further information that you want to communicate to the system administrators, you can write logs.
If there is any log for a particular report, a yellow banner will be shown in the report header. The following
example shows how you can write a log:
exec dbo.WriteSystemLog N'Any information you want to show to the system administrators , N Warning
The first parameter is the message you want show in the log. The second parameter is the log level. The valid
input for the second parameter could be Informational, Warning, or Error.
Debug
The SPA console can run in two modes, Debug or Release. Release mode is the default, and it cleans up all the
collected raw data after the report is generated. The Debug mode keeps all raw data in the file share and database,
so that you can debug the report script in the future.
To debug a report script
1. Install Microsoft SQL Server Management Studio (SSMS).
2. After SSMS is launched, connect to localhost\SQLExpress. Be aware that you must use localhost, instead of .
. Otherwise, you might not be able to start the debugger in SQL Server.
3. Run the following script to enable Debug mode:
USE SPADB
UPdate dbo.Configurations
SET Value = N'true'
WHERE Name = N'Debugmode'
4. Launch the SPA console and run the advisor pack that you want to debug.
5. Wait for the task to complete. If the report is successfully generated, switch back to SSMS and look for the
latest task.
select TOP 1 * FROM dbo.Tasks OrdER BY Id DESC
for example, the output might be:
ID
SESSIONID
ADVISORYPACKA
GEID
REPORTSTATUSI
D
LASTUPDATETIM
E
THRESHOLDVERS
IONID
12
17
1
2
2011-0511
05:35:24.38
7
1
6. You can run the following script as many times as you want to execute the report script for Id 12:
exec dbo.DebugReportScript 12
Note You can also press F11 to step into the previous statement and debug.
Running [dbo].[DebugReportScript] returns multiple result sets, including:
1. Microsoft SQL Server messages and advisor pack logs
2. Results of rules
3. Statistics keys and values
4. Single values
5. All list value tables
Best practices
Naming convention and styles
Use Pascal casing for any names in ProvisionMetadata.xml.
Use Pascal casing for stored procedures, functions, and view names.
Use Pascal casing for temporary table names.
Use camel casing for parameter names.
Use camel casing for local variables.
Use uppercase for all SQL reserved keywords.
Other recommendations
move the most logical pieces into other stored procedures and user-defined functions.
Make your main script as brief as possible for maintenance purposes.
Use the full name of the SQL object.
Treat your SQL code as case sensitive.
add SET NOCOUNT ON to the beginning of every stored procedure.
Consider using temporary tables to transfer huge amount of data.
Consider using SET XACT_ABORT ON to terminate the process if an error occurs.
Always include major version number in the advisor pack display name.
Advanced topics
Run multiple advisor packs simultaneously
SPA supports running multiple advisor packs at the same time. This is especially useful when you want to look at
Internet Information Services (IIS) and core operating system performance at the same time. Many data collectors
that are used by the IIS advisor pack might also be used by the Core OS advisor pack. When two or more advisor
packs are running on the same target computer, SPA does not collect the same data twice.
The following example shows the workflow for running two advisor packs.
The Merger Data Collector Set is only for collecting performance counter and ETW data sources. The following
merge rules apply:
1. SPA takes the biggest duration as the new duration.
2. Where there are merge conflicts, the following rules are followed:
a. Take the smallest interval as the new interval.
b. Take the super set of the performance counters. For example, with Process(*)\% Processor time
and Process(*)\*,\Process(*)\\* returns more data, so Process(*)\% Processor time and
Process(*)\\* is removed from the merged data collector set.
Collect dynamic data
SPA needs a defined data collector set at design time. It is not always possible to know which data is needed for
report generation because the dynamic data and query path are not known until its dependent data is available.
for example, if you want to list all the friendly names of network adapters, you must first query WMI to enumerate
all the network adapters. Each returned WMI object has a registry key path, where it stores the friendly name. The
registry key path is unknown at design time. In this case, we need dynamic data support.
To enumerate all network adapters, you can use the following WMI query by using Windows PowerShell:
Get-WmiObject -Namespace Root\Cimv2 -query "select PNPDeviceID FROM Win32_NetworkAdapter" | forEach-Object {
Write-Output $_.PNPDeviceID }
It returns a list of network adapter objects. Each object has a property called PNPDeviceID, which maintains a
relative registry key path. Here s a sample output from the previous query:
ROOT\*ISatAP\0001
PCI\VEN_8086&DEV_4238&SUBSYS_11118086&REV_35\4&372A6B86&0&00E4
ROOT\*IPHTTPS\0000
To find the FriendlyName value, open registry editor and navigate to registry setting by combining
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ with each line in the previous sample. , for
example: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ ROOT\*IPHTTPS\0000.
To translate the previous steps into SPA provision metadata, add the script in the following code sample:
<advisorPack>
<dataSourceDefinition xmlns="http://microsoft.com/schemas/ServerPerformanceAdvisor/dc/2010">
<dataCollectorSet >
<registryKeys>
?
<registryKey>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\$(NetworkAdapter.PNPDeviceID)\FriendlyName</reg
istryKey>
</registryKeys>
<managementpaths>
?<path name="NetworkAdapter">Root\Cimv2:select PNPDeviceID FROM Win32_NetworkAdapter</path>
</managementpaths>
In this example, you first add a WMI query under managementpaths and define the key name NetworkAdapter.
Then you add a registry key and refer to NetworkAdapter by using the syntax,
$(NetworkAdapter.PNPDeviceID).
The following table defines if a data collector in SPA supports dynamic data and whether it can be referenced by
other data collectors:
DATA TYPE
SUPPORT DYNAMIC DATA
CAN BE REFERENCED
registry key
Yes
Yes
WMI
Yes
Yes
File
Yes
No
Performance counter
No
No
ETW
No
No
for a WMI data collector, each WMI object has many attached attributes. Any type of WMI object always has three
attributes: __NAMESPACE, __CLASS, and __RELpath.
To define a data collector that is referenced by other data collectors, assign the name attribute with a unique key
in the ProvisionMetadata.xml. This key is used by dependent data collectors to generate dynamic data.
Here s an example for registry key:
<registryKey name="registry">HKEY_LOCAL_MACHINE </registryKey>
And an example for WMI:
<path name="wmi">Root\Cimv2:select PNPDeviceID FROM Win32_NetworkAdapter</path>
To define a dependent data collector, the following syntax is used: $({name}.{attribute}).
{name} and {attribute} are placeholders.
When SPA collects data from a target server, it dynamically replaces the pattern $(*.*) with the actual collected
data from its reference data collector (registry key / WMI), for example:
<registryKey>HKEY_LOCAL_MACHINE\$(registry.key)\ </registryKey>
<registryKey name="registry">HKEY_LOCAL_MACHINE\$(wmi.Relativeregistrypath)\ </registryKey>
<path name="wmi"> </path>
<file>$(wmi.FileName)</file>
Note SPA supports an unlimited depth of reference, but be aware of performance overhead if you have too many
levels. Make sure there is no circular reference or self-reference that is not supported.
versioning limitations
SPA supports reset and minor version updates. These processes use the same algorithm. The process is to refresh
all the database objects and threshold settings but keep the existing data. This can be upgrading to a higher
version or downgrading to lower version. select the advisor pack, and then click reset in the Configure Advisor
Packs dialog box in SPA to reset or apply or the updates.
This feature is mainly for minor updates. You cannot dramatically change the UI display elements. If you want to
make significant changes, you have to create a different advisor pack. You should include the major version in the
advisor pack name.
The limitations of minor version modifications are:
Cannot change the schema name
Cannot change the data type of any single value group or the columns of a list value table
Cannot add or remove thresholds
Cannot add or remove rules
Cannot add or remove advice
Cannot add or remove single values
Cannot add or remove list values
Cannot add or remove a column of list values
Tooltips
Almost all description attributes will be shown as a tooltip in the SPA console.
for a list value table, a row-based tooltip can be achieved by adding the following attribute:
<listValue descriptionColumn="Description">
<column name="Name"/>
<column name="Description"/>
</listValue>
The descriptionColumn attribute refers to the name of the column. In this example, the description column does
not show as a physical column. However, it shows as a tooltip when you mouse over each row of the first column.
We recommend that the tooltip show the data source to the user. Here are the formats for showing the data
sources:
DATA SOURCE
FORMAT
EXAMPLE
WMI
WMI: <wmiclass>/<Field>
WMI:
Win32_OperatingSystem/Caption
DATA SOURCE
FORMAT
EXAMPLE
Performance counter
Perfcounter:
<CategoryName>/<InstanceName
>
Perfcounter: Process/% Processor
time
registry
registry: <registerKey>
registry:
HKLM\SOFTWARE\Microsoft
\ASP.NET\Rootver
Configuration file
ConfigFile: <Filepath>[; Xpath:
<Xpath>]
Note
Xpath is optional and it is valid
only when the file is an xml file.
ConfigFile:
%windir%\System32\inetsrv\config\
applicationHost.config
Xpath:
configuration/system.webServer
/httpProtocol/@allowKeepAlive</p
></td>
ETW
ETW: <Provider>(Keywords)
ETW: Windows Kernel Trace
(process, net)
Table collation
When an advisor pack becomes more complicated, you can create your own variable tables or temporary tables
to store intermediate results in the report script.
Collating string columns may be problematic because the table collation that you create might be different than
the one that is created by the SPA framework. If you correlate two string columns in different tables, you may see
a collation error. To avoid this issue, you should always define the string for a column collation as
SQL_Latin1_General_CP1_CI_AS when you define a table.
Here s how to define a variable table:
DECLARE @filesIO TABLE (
Name nvarchar(500) COLLatE SQL_Latin1_General_CP1_CI_AS,
AverageFileAccessvolume float,
AverageFileAccessCount float,
Filepath nvarchar(500) COLLatE SQL_Latin1_General_CP1_CI_AS
)
Collect ETW
Here s how to define ETW in a ProvisionMetadata.xml file:
<dataSourceDefinition>
<providers>
<provider session="NT Kernel Logger" guid="{9E814AAD-3204-11D2-9A82-006008A86939}"/>
</providers>
</dataSourceDefinition>
The following provider attributes are available to use for collecting ETW:
ATTRIBUTE
TYPE
DESCRIPTION
guid
GUID
Provider GUID
session
string
ETW session name (optional, only
required for kernel events)
keywordsany
Hex
Any keywords (optional, no 0x
prefix)
keywordsAll
Hex
All keywords (optional)
properties
Hex
Properties (optional)
level
Hex
Level (optional)
bufferSize
Int
Buffer size (optional)
flushtime
Int
Flush time (optional)
maxBuffer
Int
Maximum buffer (optional)
minBuffer
Int
Minimum buffer (optional)
There are two output tables as shown here.
#Events table schema
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
SequenceID
Int NOT NULL
Correlation sequence ID
EventtypeId
Int NOT NULL
Event type ID (refer to [dbo].
[Eventtypes])
ProcessId
BigInt NOT NULL
Process ID
ThreadId
BigInt NOT NULL
Thread ID
timestamp
datetime2 NOT NULL
timestamp
Kerneltime
BigInt NOT NULL
Kernel time
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
Usertime
BigInt NOT NULL
User time
COLUMN NAME
SQL DATA TYPE
DESCRIPTION
SequenceID
Int NOT NULL
Correlation sequence ID
Name
Nvarchar(100)
Property name
Value
Nvarchar(4000)
Value
#EventProperties table schema
ETW schema
An ETW schema can be generated by running tracerpt.exe against the .etl file. A schema.man file is generated.
Because the format of the .etl file is computer dependent, the following script only works in the following
situations:
1. Run the script on the computer where the corresponding .etl file is collected.
2. Or run the script on a computer with same operating system and components installed.
tracerpt *.etl -export
Glossary
The following terms are used in this document:
Advisor pack
An advisor pack is a collection of metadata and SQL scripts that process the performance logs that are collected
from the target server. The advisor pack then generates reports from the performance log data. The metadata in
the advisor pack defines the data to be collected from the target server for performance measurements. The
metadata also defines the set of rules, the thresholds, and the report format. Most often, an advisor pack is written
specifically for a single server role, for example, Internet Information Services (IIS).
SPA console
The SPA console refers to SpaConsole.exe, which is the central part of Server Performance Advisor. SPA does not
need to run on the target server that you are testing. The SPA console contains all the user interfaces for SPA,
from setting up the project to running analysis and viewing reports. By design, SPA is a two-tier application. The
SPA console contains the UI layer and part of the business-logic layer. The SPA console schedules and processes
performance analysis requests.
SPA framework
SPA contains two major parts, the framework and the advisor packs. The SPA framework provides all the user
interfaces, performance log processing, configuration, error handling, and database APIs, and management
procedures.
SPA project
A SPA project is a database that contains all the information about the target servers, advisor packs, and
performance analysis reports that are generated on the target servers for the advisor packs. You can compare and
view history and trend charts within the same SPA project. The user can create more than one project. The SPA
projects are independent of one another, and there is no data shared across projects.
Target server
The target server is the physical computer or virtual machine that runs the Windows Server with certain server
roles, such as IIS.
Data analysis session
A data analysis session is a performance analysis on a specific target server. A data analysis session can include
multiple advisor packs. The data collector sets from those advisor packs are merged into a single data collector
set. All performance logs for a single data analysis session are collected during the same time period. Analyzing
reports that are generated by advisor packs running in the same data analysis session can help users understand
the overall performance situation and identify root causes for performance issues.
Event Tracing for Windows
Event Tracing for Windows (ETW) is a high-performance, low-overhead, scalable tracing system that is provided
in the Windows operating systems. It provides profiling and debugging capabilities, which can be used to
troubleshoot a variety of scenarios. SPA uses ETW events as a data source for generating the performance
reports. For general info about ETW, see Improve Debugging and Performance Tuning with ETW.
WMI query
Windows Management Instrumentation (WMI) is the infrastructure for management data and operations in
Windows operating systems. You can write WMI scripts or applications to automate administrative tasks on
remote computers. WMI also supplies management data to other parts of the operating system and to products.
SPA uses WMI class information and data points as sources for generating performance reports.
Performance counters
Performance counters are used to provide information about how well the operating system or an application,
service, or driver is performing. The performance counter data can help determine system bottlenecks, and finetune system and application performance. The operating system, network, and devices provide counter data that
an application can consume to provide users with a graphical view of how well the system is performing. SPA
uses performance counter information and data points as sources to generate performance reports.
Performance Logs and Alerts
Performance Logs and Alerts (PLA) is a built-in service in the Windows operating system. It is designed to collect
performance logs and traces, and it also raises performance alerts when certain triggers are met. PLA can be used
to collect performance counters, event tracing for Windows (ETW), WMI queries, registry keys, and configuration
files. PLA also supports remote data collection through remote procedure calls (RPC). The user defines a data
collector set, which includes information about the data to be collected, frequency of data collection, data
collection duration, filters, and a location for saving the result files. SPA uses PLA to collect all the performance
data from the target servers.
Single report
Single report is the SPA report that is generated based on one data analysis session for one advisor pack on a
single target server. It can contain notifications and various data sections.
Side-by-side report
A side-by-side report is an SPA report that compares two single reports for the same advisor pack. The two
reports can be generated from different target servers or from separate performance analysis runs on the same
target server. The side-by-side report creates the capability to compare two reports to help users identify
abnormal behaviors or settings in one of the reports. A side-by-side report contains notifications and various data
sections. In each section, data from both reports are listed side-by-side.
Trend chart
A trend chart is the SPA report that is used to investigate repetitive patterns of performance issues. Many
repetitive performance issues are caused by scheduled server load changes from the server or from client
computers, which can happen daily or weekly. SPA provides a 24-hour trend chart and a 7-day trend chart to
identify these issues.
The user can choose one or more data series at a time, which is a numeric value inside the single report, such as
Average total CPU usage. more specifically, a numeric value is a scalar value from a single server that is
generated by a single AP at a given time instance. SPA groups those values into 24 groups, one for each hour of
the day (seven for a 7-day report, one for each day of the week). SPA calculates average, minimum, maximum,
and standard deviations for each group.
Historical chart
An historical chart is the SPA report that is used to show changes in certain numeric values inside single reports
for a given server and advisor pack pair over time. The user can choose multiple data series and show them
together in the historical chart to understand the correlation between different data series.
Data series
A data series is numeric data that is collected from the same data source over a period of time. The same source
means that the data has to come from the same target server, such as the average request queue length for IIS on
one server.
Rules
Rules are combinations of logic, thresholds, and descriptions. They represent a potential performance issue. Each
advisor pack contains multiple rules. Each rule is triggered by a report generation process. A rule applies the logic
and thresholds to the data in single report. If the criteria are met, a warning notification is raised. If not, the
notification is set to the OK state. If the rule does not apply, the notification is set to the Not Applicable (NA) state.
Notifications
A notification is the information that a rule displays to users. It includes the status of the rule (OK, NA, or
Warning), the name of the rule, and possible recommendations to address the performance issues.
Server Performance Advisor Pack for Tiered Storage
Spaces
4/24/2017 • 7 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Tiered Storage Spaces, introduced in Windows Server 2012 R2, dynamically move chunks of stored data between
different classes of storage, such as fast SSDs and slower hard drives to optimize data placement with respect to
common access patterns. Provisioning decisions such as the size of the SSD tier and the ratio of SSD to HDD
heavily affect the performance of the system in response to the system s workloads. The Server Performance
Advisor (SPA) Pack for Tiered Storage Spaces collects and exposes performance data for tiered storage spaces
deployed on a system and provides you with useful statistics and recommendations for configuring the system to
maximize performance.
Goals
The SPA Pack for Tiered Storage Spaces aims to expose relevant information about the performance of the system
for a given tiered storage space. Using this SPA Advisor Pack, you can get insight into the performance (throughput,
IOPS, total data read/written) of your tiered storage system. This data further allows you to understand how the
tiered storage configuration is responding to the workload on the deployed system, and identify configuration
changes that would improve storage performance. The SPA Pack for Tiered Storage Spaces also exposes historical
(weekly) statistics from the Storage Optimizer which provides insight into the expected performance gains with
increasing the size of the SSD tier.
Setup
You can download the SPA Pack for Tiered Storage Spaces here. Once the folder is downloaded, place it into <SPA
INSTALL dir>/APs folder and it will automatically appear when SPA is restarted.
Note The computer running SPA should have administrative rights to the system under test.
Once you have the SPA Advisor Pack for Tiered Storage Spaces Pack installed, you need to run the following from
an elevated command prompt. This command modifies the routine storage tier optimization pack to pipe out to a
file that can be read by using SPA:
schtasks /change /TN \Microsoft\Windows\Storage Tiers Management\Storage Tiers Optimization /TR cmd /C
%windir%\System32\defrag.exe /c /h /g -# > %windir%\tieringOut.txt
The SPA Advisor Pack for Tiered Storage Spaces expects to find the results of the optimizer in the Windows folder.
The report will not collect this file if it is moved to another location.
The Storage Tier Optimization task is configured to run daily on all tiered volumes by default. The Windows
PowerShell command above only modifies this scheduled task to save the output. There is no artificial constraint
introduced on the system, only the latest version of the output is stored and uses a constant amount of memory.
The recommended setup for using the SPA Pack for Tiered Storage Spaces is running the analysis for 10-20 minute
durations every hour or two hours when testing the system response with a tiered storage space. This will minimize
network traffic and give a time series view of the system state over the day or week. This allows you to get a picture
of the workload running on the system and how the tiering setup performed at different points in the workload.
Caution The SPA Advisor Pack for Tiered Storage Spaces collects data about tiered spaces by reading ETW traces.
Due to the detailed nature of ETW traces, the trace file generated can grow large relatively quickly (~5GB in 30
minutes on a heavy workload). This might lead to network traffic and very minimal loss in performance.
Using the SPA Advisor Pack for Tiered Storage Spaces
Each time the SPA Advisor Pack for Tiered Storage Space runs on a server, a report is generated which can be
viewed by using SPA. This report provides analysis for all tiered volumes on the system. All the information is
presented on a per space basis, with the space being identified by their friendly names. The report is divided into 5
sections.
1. System overview
This pane shows basic configuration information about all of the Storage Spaces installed on the server. This
includes the total size and the ratio of SSD to HDD. The total sample time for the run can be seen below the
title of the report.
2. Total I/O Stats
This pane shows the total data read/written to each space over the total time the server was sampled. The
data that is read and written is split by tiers, which give us an indication of where most of our reads and
writes are happening and if it matches our expectations.
3. IOPS Stats
This pane displays the IOPS statistics for all the spaces. The first section displays the minimum, maximum,
and average IOPS over each space. The information is then split by read and write types of I/O per space,
and by I/O going to each tier on each space. The last section gives finer information about separate
Read/Write IOPS for each tier of each space.
4. Throughput Stats
This pane displays throughput data (MB/s) and is organized in the same layout as the IOPS Stats pane.
Throughput per space, split by Read/Write, split by Tier, and the finer information about read/write
throughput going to each tier for each space.
5. Tiering Engine
This pane shows collected statistics from the Storage Optimizer, which can be printed to the console during
regularly scheduled runs of the Storage Optimizer. If the previous configuration steps were performed
correctly, and the regularly scheduled storage optimizer has run since the last analysis, you should see a file
with a format similar to that shown below. If you see a <null> instead, make sure that you ran the setup
commands described earlier on the server being analyzed, and that the new scheduled task has run at least
once.
Interpreting the data
Use the following sections to interpret the data from the SPA Advisor Pack for Tiered Storage Spaces.
Performance data using historical charts
The SPA console has a historical chart viewer which can be accessed by clicking the View charts button next to the
SPA Advisor Pack for Tiered Storage Spaces.
The chart is shown in the following figure:
A good indicator of the basic performance of the Tiered Storage Space is the % read/writes on SSD, which can be
viewed on a per-space basis.
if the working set size for the workload is comparable to the size of the installed SSD tier, you should expect
the % of read/writes on SSD to be high (> 70 %).
if the read/writes on SSD are < 50 %, it could mean the following:
The Storage Optimizer hasn t run and optimized the tiers on the volume yet. To fix this, repeat the
readings after the Storage Optimizer has run. You can also run the Storage Optimizer task manually
by using Task Scheduler.
The Storage Optimizer does not have enough heat information yet about the workload or the
workload is perfectly random. Fix: Let the Storage Optimizer run for a few days. If the workload is not
mostly random, there should be improvements in the SSD read/write %.
The working set size is too large compared to the size of the SSD tier provisioned. To fix this, increase
the size of the SSD tier in accordance with the Storage Optimizer Report described in the next section.
The amount to increase and the expected gains are also described in the Storage Optimizer report.
Once the Tiered Storage Space is working as expected, the SPA Advisor Pack for Tiered Storage Spaces can be used
to analyze the performance of the system. The IOPS and throughput data is reported on a per-tier basis. The
reported performance of the tiers should be similar to that expected from the underlying hardware installed.
The threshold for detecting warnings for % of I/O going to the SSD tier can be adjusted to suit the workload. On a
perfectly uniform workload, we would expect the % of I/O going to the SSD tier to be at least the % of the SSD
installed. This is a baseline for performance, and most systems should perform significantly better.
Storage Optimizer tier analysis report
The Storage Optimizer contains useful information about the expected performance gains with differed SSD tier
provisioning options. The report has the following format for each tiered storage space on the server.
The report from the storage optimizer is based on data from the previous week of heat information and data
movements made by the storage optimizer.
The last section of the report refers to the size of all files manually pinned to a storage tier. These files do not get
moved from the assigned tier.
The main section of the report is the table of percentage I/Os serviced from SSD vs. the SSD tier size required. The
100% I/O s SSD size is a good indication of the working set size for the workload on the system. If the SSD tier was
this size (4.36 GB in the example) then given the past week s pattern of I/O s seen, you would get close to all of the
I/O s going to the SSD tier.
The distribution of this data is non-linear and the exact distribution depends on the characteristics of the workload.
The sample data was imported into Microsoft Excel, and, after normalizing to gigabytes, the data gave the following
distribution:
Looking at the distribution, you can make an informed decision about how much SSD storage to add to the Tiered
Storage Space, and what are the expected gains from the change in configuration, given that the workload remains
similar.
Performance Tuning Guidelines for Windows Server
2016
6/13/2017 • 1 min to read • Edit Online
When you run a server system in your organization, you might have business needs not met using default server
settings. For example, you might need the lowest possible energy consumption, or the lowest possible latency, or
the maximum possible throughput on your server. This guide provides a set of guidelines that you can use to tune
the server settings in Windows Server 2016 and obtain incremental performance or energy efficiency gains,
especially when the nature of the workload varies little over time.
It is important that your tuning changes consider the hardware, the workload, the power budgets, and the
performance goals of your server. This guide describes each setting and its potential effect to help you make an
informed decision about its relevance to your system, workload, performance, and energy usage goals.
WARNING
Registry settings and tuning parameters changed significantly between versions of Windows Server. Be sure to use the latest
tuning guidelines to avoid unexpected results.
In this guide
This guide organizes performance and tuning guidance for Windows Server 2016 across three tuning categories:
SERVER HARDWARE
SERVER ROLE
SERVER SUBSYSTEM
Hardware performance considerations
Active Directory Servers
Cache and memory management
Hardware power considerations
File Servers
Networking subsystem
Hyper-V Servers
Storage Spaces Direct
Remote Desktop Services
Software Defined Networking (SDN)
Web Servers
Windows Server Containers
Changes in this version
Sections added
Nano Server installation-type configuration considerations
Software Defined Networking, including HNV and SLB gateway configuration guidance
Storage Spaces Direct
HTTP1.1 and HTTP2
Windows Server Containers
Sections changed
Updates to Active Directory guidance section
Updates to File Server guidance section
Updates to Web Server guidance section
Updates to Hardware Power guidance section
Updates to PowerShell tuning guidance section
Significant updates to the Hyper-V guidance section
Performance Tuning for Workloads removed, pointers to relevant resources added to Additional Tuning
Resources article
Removal of dedicated storage sections, in favor of new Storage Spaces Direct section and canonical Technet
content
Removal of dedicated networking section, in favor of canonical Technet content
Remote Server Administration Tools
4/24/2017 • 7 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
This topic supports Remote Server Administration Tools for Windows 10.
To help ease Remote server management, you can download and install Remote Server Administration Tools.
Remote Server Administration Tools includes Server Manager, Microsoft Management Console (mmc) snap-ins,
consoles, Windows PowerShell cmdlets and providers, and some command-line tools for managing roles and
features that run on Windows Server.
Remote Server Administration Tools includes Windows PowerShell cmdlet modules that can be used to manage
roles and features that are running on Remote servers. Although Windows PowerShell remote management is
enabled by default on Windows Server 2016, it is not enabled by default on Windows 10. To run cmdlets that are
part of Remote Server Administration Tools against a Remote server, run Enable-PSremoting in a Windows
PowerShell session that has been opened with elevated user rights (that is, Run as Administrator) on your
Windows client computer after installing Remote Server Administration Tools.
Remote Server Administration Tools for Windows 10
Use Remote Server Administration Tools for Windows 10 to manage specific technologies on computers that are
running Windows Server 2016, Windows Server 2012 R2, and in limited cases, Windows Server 2012 , or Windows
Server 2008 R2 .
Remote Server Administration Tools for Windows 10 includes support for remote management of computers that
are running the Server Core installation option or the Minimal Server Interface configuration of Windows Server
2016, Windows Server 2012 R2 , and in limited cases, the Server Core installation options of Windows Server
2012. However, Remote Server Administration Tools for Windows 10 cannot be installed on any versions of the
Windows Server operating system.
Tools available in this release
for a list of the tools available in Remote Server Administration Tools for Windows 10, see the table in Remote
Server Administration Tools (RSAT) for Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows
Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.
System requirements
Remote Server Administration Tools for Windows 10 can be installed only on computers that are running Windows
10. Remote Server Administration Tools cannot be installed on computers that are running Windows RT 8.1, or
other system-on-chip devices.
Remote Server Administration Tools for Windows 10 runs on both x86-based and x64-based editions of Windows
10.
IMPORTANT
Remote Server Administration Tools for Windows 10 should not be installed on a computer that is running administration
tools packs for Windows 8.1, Windows 8, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 or
Windows 2000 Server. Remove all older versions of Administration Tools Pack or Remote Server Administration Tools,
including earlier prerelease versions, and releases of the tools for different languages or locales from the computer before you
install Remote Server Administration Tools for Windows 10.
To use this release of Server Manager to access and manage Remote servers that are running Windows Server
2012 R2 , Windows Server 2012 , or Windows Server 2008 R2 , you must install several updates to make the older
Windows Server operating systems manageable by using Server Manager. For detailed information about how to
prepare Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 for management by using
Server Manager in Remote Server Administration Tools for Windows 10, see Manage Multiple, Remote Servers
with Server Manager.
Windows PowerShell and Server Manager remote management must be enabled on remote servers to manage
them by using tools that are part of Remote Server Administration Tools for Windows 10. Remote management is
enabled by default on servers that are running Windows Server 2016, Windows Server 2012 R2, and Windows
Server 2012. For more information about how to enable remote management if it has been disabled, see Manage
multiple, remote servers with Server Manager.
Install, uninstall, or disable Remote Server Administration Tools for Windows 10
Remote Server Administration Tools for Windows 10 has the same one-step installation process as Remote Server
Administration Tools for Windows 8.1. Before the release of Remote Server Administration Tools for Windows 8,
after running the MSU installer program, users were required to turn on specific tools that they wanted to use in
the Turn Windows features on or off dialog box. This step has been eliminated; after you run the MSU
installation program, all tools are enabled by default.
To install Remote Server Administration Tools for Windows 10
1. Download the Remote Server Administration Tools for Windows 10 package from the Microsoft Download
Center. You can either run the installer from the Download Center website, or save the download package to
a local computer or share. I
IMPORTANT
You can only install Remote Server Administration Tools for Windows 10 on computers that are running Windows 10.
Remote Server Administration Tools cannot be installed on computers that are running Windows RT 8.1 or other
system-on-chip devices.
2. If you save the download package to a local computer or share, double-click the installer program,
WindowsTH-KB2693643-x64.msu or WindowsTH-KB2693643-x86.msu, depending on the architecture
of the computer on which you want to install the tools.
3. When you are prompted by the Windows Update Standalone Installer dialog box to install the update,
click Yes.
4. Read and accept the license terms. Click I accept.
5. Installation requires a few minutes to finish.
To u n i n st a l l R e m o t e Se r v e r A d m i n i st r a t i o n To o l s fo r W i n d o w s 1 0
1. On the desktop, click Start, click All Apps, click Windows System, and then click Control Panel.
2. Under Programs, click Uninstall a program.
3. Click View installed updates.
4. Right-click Update for Microsoft Windows (KB2693643), and then click Uninstall.
5. When you are asked if you are sure you want to uninstall the update, click Yes. S
To t u r n o ff sp e c i fi c t o o l s
6. On the desktop, click Start, click All Apps, click Windows System, and then click Control Panel.
7. Click Programs, and then in Programs and Features click Turn Windows features on or off.
8. In the Windows Features dialog box, expand Remote Server Administration Tools, and then expand
either Role Administration Tools or Feature Administration Tools.
9. Clear the check boxes for any tools that you want to turn off.
NOTE
If you turn off Server Manager, the computer must be restarted, and tools that were accessible from the Tools menu
of Server Manager must be opened from the Administrative Tools folder.
10. When you are finished turning off tools that you do not want to use, click OK.
Run Remote Server Administration Tools
NOTE
After installing Remote Server Administration Tools for Windows 10, the Administrative Tools folder is displayed on the
Start menu. You can access the tools from the following locations.
The Tools menu in the Server Manager console.
Control Panel\System and Security\Administrative Tools.
A shortcut saved to the desktop from the Administrative Tools folder (to do this, right click the Control Panel\System
and Security\Administrative Tools link, and then click Create Shortcut).
The tools installed as part of Remote Server Administration Tools for Windows 10 cannot be used to manage the
local client computer. Regardless of the tool you run, you must specify a remote server, or multiple remote servers,
on which to run the tool. Because most tools are integrated with Server Manager, you add remote servers that you
want to manage to the Server Manager server pool before managing the server by using the tools in the Tools
menu. For more information about how to add servers to your server pool, and create custom groups of servers,
see Add servers to Server Manager and Create and manage server groups.
In Remote Server Administration Tools for Windows 10, all GUI-based server management tools, such as mmc
snap-ins and dialog boxes, are accessed from the Tools menu of the Server Manager console. Although the
computer that runs Remote Server Administration Tools for Windows 10 runs a client-based operating system,
after installing the tools, Server Manager, included with Remote Server Administration Tools for Windows 10,
opens automatically by default on the client computer. Note that there is no Local Server page in the Server
Manager console that runs on a client computer.
To st a r t Se r v e r M a n a g e r o n a c l i e n t c o m p u t e r
1. On the Start menu, click All Apps, and then click Administrative Tools.
2. In the Administrative Tools folder, click Server Manager.
Although they are not listed in the Server Manager console Tools menu, Windows PowerShell cmdlets and
Command prompt management tools are also installed for roles and features as part of Remote Server
Administration Tools. For example, if you open a Windows PowerShell session with elevated user rights (Run as
Administrator), and run the cmdlet Get-Command -Module RDManagement , the results include a list of remote Desktop
Services cmdlets that are now available to run on the local computer after installing Remote Server Administration
Tools, as long as the cmdlets are targeted at a remote server that is running all or part of the remote Desktop
Services role.
To st a r t W i n d o w s P o w e r Sh e l l w i t h e l e v a t e d u se r r i g h t s (R u n a s a d m i n i st r a t o r )
1. On the Start menu, click All Apps, click Windows System, and then click Windows PowerShell.
2. To run Windows PowerShell as an administrator from the desktop, right-click the Windows PowerShell
shortcut, and then click Run as Administrator.
NOTE
You can also start a Windows PowerShell session that is targeted at a specific server by right-clicking a managed server in a
role or group page in Server Manager, and then clicking Windows PowerShell.
See Also
Remote Server Administration Tools for Windows 10
Remote Server Administration Tools (RSAT) for Windows Vista, Windows 7, Windows 8, Windows Server
2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2
Get started with Server Management Tools (SMT)
6/1/2017 • 5 min to read • Edit Online
Applies to: Windows Server 2016, Windows Server 2012 R2
IMPORTANT
SMT preview service is being retired on June 30, 2017. For more infomation see this blog post.
Server management tools is a set of web-based GUI and command-line tools to manage on-premises Windows
Servers from Azure.
The following video (3:46) highlights SMT features:
What is SMT?
SMT, hosted in Azure, enables management of headless Windows Servers, such as Nano Server and Server Core,
providing rapid access to your Azure and on-premises Windows Server 2016 servers.
With SMT, you can do the following:
View and change system configurations
View performance across various resources and manage processes and services
Manage devices attached to the server
View event logs
View the list of installed roles and features
Use a PowerShell console to manage and automate
How is SMT different from Remote Server Administrative Tools (RSAT)?
RSAT is a set of remote server management tools that you can download and install on Windows 10. They include
support for remote management of computers that are running the Server Core installation option or the Minimal
Server Interface configuration of Windows Server 2016, Windows Server 2012 R2, and in limited cases, the Server
Core installation options of Windows Server 2012. For more information about RSAT, see Remote Server
Administration Tools.
SMT gateway
An SMT gateway is required to enable communication between the Microsoft Azure portal and your Windows
Server 2016 machines. A gateway is typically deployed and configured on the same local network as the Windows
Server machine(s) you want to manage. The on-premises machine must have an internet connection to
communicate with the Azure portal as shown in the following illustration:
Although SMT can only manage Windows Server 2016, you can set up the SMT gateway on Windows Server 2012
R2 or Windows Server 2016. If the machine hosting the gateway is running Windows Server 2012 R2, you will
need to install WMF 5.0 on the gateway server to use PowerShell for management.
If the machine hosting the gateway is running Windows Server 2016, no additional preparation is required.
You will also need an Azure subscription to use Server Management Tools.
How to setup the gateway
Step 1: Create a new Server Management Tools connection
To begin, log in to your Azure portal account and search for Server Management Tools in Marketplace or
navigate directly to SMT.
Next, select Server Management Tools, read the description, review the terms of use, and then click Create.
This will open a form prompting you to fill out the information for the connection you are establishing, as follows:
Provide the NAME/IP/FQDN of the machine you want to connect to. If you have an existing resource group and
gateway, you may opt to select them here rather than create a new group or gateway.
If this is the first SMT connection you are creating, you will also need to create a new SMT gateway and give it a
name. You will be prompted to complete the gateway configuration after the SMT connection is created.
Once the form has been completed, click Create at the bottom of the screen and you will be taken back to the
Azure Startboard. Assuming Pin to Startboard was checked, you will see a tile appear that will indicate the
deployment is in progress. Note that you are not actually creating the connection to the machine -- just a resource
in Azure. The connection to the machine is initiated once you provide the credentials on the main SMT blade.
Once the deployment succeeds, you will be taken to the SMT blade where you can provide credentials and connect
to the machine. The User Name and Password will not be created by the connection, and must already exist on the
machine and have proper permissions. For example, you could connect with a user account that is a member of the
local Administrators group on the target server.
Step 2: Configure a new SMT gateway
If you are creating a new gateway, you will see the following status:
Click to open the Gateway Configuration page and read carefully and follow the directions to set up your onpremises machine or Azure VM as the gateway.
Unzip the zip file and run the gateway MSI installer from the folder you unzipped to. If you run the MSI from the zip
file without unzipping first, you will need to also specify the profile .json file.
After installing the gateway MSI, return to Azure and click Refresh. You will now be prompted to enter the
credentials to start managing the machine. You will see the following status:
You have established a remote connection to your resource and are now able to perform management tasks on it
through Azure.
Managing workgroup machines
To connect to workgroup machines (e.g. non-domain-joined Nano servers), run the following command in
PowerShell or at a Command Prompt as Administrator:
PowerShell:
winrm set winrm/config/client ‘@{ TrustedHosts=”TargetMachineNameOrAddress” }
Command Prompt:
winrm set winrm/config/client @{ TrustedHosts=”TargetMachineNameOrAddress” }
TargetMachineNameOrAddress should be the NetBIOS name, FQDN, or IP address (IPv4 or IPv6) that you
specified when creating the SMT connection in Azure (which is also the name displayed at the top of the blade). You
can also add multiple machines by separating them with commas.
NOTE
The commands above will replace any previous list of registered trusted hosts with the host(s) you specify in the command.
You can use the following command in PowerShell with the Concatenate parameter to add a computer name to an existing
list of trusted hosts: Set-Item wsman:\localhost\Client\TrustedHosts TargetMachineNameOrAddress –Concatenate
Additional connectivity requirements
If you want to connect using the local Administrator account, you will need to enable this policy on the target
machine by running the following command in an administrator session on the target machine:
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t
REG\_DWORD /d 1
If you will connect to a workgroup machine that is not on the same subnet as the gateway, run the following
command in an administrator session on the target machine:
NETSH advfirewall firewall add rule name=”WinRM 5985” protocol=TCP dir=in localport=5985 action=allow
Server Manager
4/24/2017 • 15 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Server Manager is a management console in Windows Server that helps IT professionals provision and manage
both local and remote Windows-based servers from their desktops, without requiring either physical access to
servers, or the need to enable remote Desktop protocol (rdP) connections to each server. Although Server
Manager is available in Windows Server 2008 R2 and Windows Server 2008, Server Manager was updated in
Windows Server 2012 to support remote, multi-server management, and help increase the number of servers an
administrator can manage.
In our tests, Server Manager in Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012 can
be used to manage up to 100 servers, depending on the workloads that the servers are running. The number of
servers that you can manage by using a single Server Manager console can vary depending on the amount of data
that you request from managed servers, and hardware and network resources available to the computer running
Server Manager. As the amount of data you want to display approaches that computer's resource capacity, you
can experience slow responses from Server Manager, and delays in the completion of refreshes. To help increase
the number of servers that you can manage by using Server Manager, we recommend limiting the event data that
Server Manager gets from your managed servers, by using settings in the Configure Event Data dialog box.
Configure Event Data can be opened from the Tasks menu in the Events tile. If you need to manage an enterpriselevel number of servers in your organization, we recommend evaluating products in the Microsoft System Center
suite.
This topic and its subtopics provide information about how to use features in the Server Manager console. This
topic contains the following sections.
Review initial considerations and system requirements
Tasks that you can perform in Server Manager
start Server Manager
Restart remote servers
Export Server Manager settings to other computers
Review initial considerations and system requirements
The following sections list some initial considerations that you need to review, as well as hardware and software
requirements for Server Manager.
Hardware requirements
Server Manager is installed by default with all editions of Windows Server 2016. No additional hardware
requirements exist for Server Manager.
Software and configuration requirements
Server Manager is installed by default with all editions of Windows Server 2016. You can use Server Manager in
Windows Server 2016 to manage Server Core installation options of Windows Server 2016, Windows Server 2012
, and Windows Server 2008 R2 that are running on remote computers. Server Manager does run on the Server
Core installation option of Windows Server 2016.
Server Manager runs in the Minimal Server Graphical Interface; that is, when the Server Graphical Shell feature is
not installed. The Server Graphical Shell feature is not installed by default on Windows Server 2016. If you are not
running Server Graphical Shell, the Server Manager console runs, but some applications or tools available from
the console are not available. Internet browsers cannot run without Server Graphical Shell, so webpages and
applications such as HTML help (The mmc F1 help, for example) cannot be opened. You cannot open dialog boxes
for configuring Windows automatic updating and feedback when Server Graphical Shell is not installed;
commands that open these dialog boxes in the Server Manager console are redirected to run sconfig.cmd.
To manage servers that are running Windows Server releases older than Windows Server 2016, install the
following software and updates to make the older releases of Windows Server manageable by using Server
Manager in Windows Server 2016.
OPERATING SYSTEM
REQUIRED SOFTWARE
Windows Server 2012 R2 or Windows Server 2012
- .NET Framework 4.6
- Windows Management Framework 5.0. The Windows
Management Framework 5.0 download package updates
Windows Management Instrumentation (WMI) providers on
Windows Server 2012 R2 and Windows Server 2012 . The
updated WMI providers let Server Manager collect
information about roles and features that are installed on the
managed servers. Until the update is applied, servers that are
running Windows Server 2012 R2 or Windows Server 2012
have a manageability status of Not accessible.
- The performance update associated with Knowledge Base
article 2682011 is no longer necessary on servers that are
running Windows Server 2012 R2 or Windows Server 2012 .
Windows Server 2008 R2
- .NET Framework 4.5
- Windows Management Framework 4.0. The Windows
Management Framework 4.0 download package updates
Windows Management Instrumentation (WMI) providers on
Windows Server 2008 R2 . The updated WMI providers let
Server Manager collect information about roles and features
that are installed on the managed servers. Until the update is
applied, servers that are running Windows Server 2008 R2
have a manageability status of Not accessible.
- The performance update associated with Knowledge Base
article 2682011 lets Server Manager collect performance data
from Windows Server 2008 R2 .
Windows Server 2008
- .NET Framework 4
- Windows Management Framework 3.0 The Windows
Management Framework 3.0 download package updates
Windows Management Instrumentation (WMI) providers on
Windows Server 2008 . The updated WMI providers let Server
Manager collect information about roles and features that are
installed on the managed servers. Until the update is applied,
servers that are running Windows Server 2008 have a
manageability status of Not accessible - verify earlier
versions run Windows Management Framework 3.0.
- The performance update associated with Knowledge Base
article 2682011 lets Server Manager collect performance data
from Windows Server 2008 .
Manage remote computers from a client computer
The Server Manager console is included with Remote Server Administration Tools for Windows 10. Note that
when Remote Server Administration Tools is installed on a client computer, you cannot manage the local
computer by using Server Manager; Server Manager cannot be used to manage computers or devices that are
running a Windows client operating system. You can only use Server Manager to manage Windows-based servers.
SERVER MANAGER
SOURCE
OPERATING
SYSTEM
TARGETED AT
WINDOWS SERVER
2008 R2 OR
WINDOWS SERVER
2008
TARGETED AT
WINDOWS SERVER
2016
TARGETED AT
WINDOWS SERVER
2012 R2
TARGETED AT
WINDOWS SERVER
2012
TARGETED AT
WINDOWS SERVER
2003
Windows 10 or
Windows Server
2016
Full support
Full support
Full support
After Software
and configuration
requirements are
satisfied, can
perform most
management
tasks, but no role
or feature
installation or
uninstallation
Not supported
Windows 8.1 or
Windows Server
2012 R2
Not supported
Full support
Full support
After Software
and configuration
requirements are
satisfied, can
perform most
management
tasks, but no role
or feature
installation or
uninstallation
Limited support;
online and offline
status only
Windows 8 or
Windows Server
2012
Not supported
Not supported
Full support
After Software
and configuration
requirements are
satisfied, can
perform most
management
tasks, but no role
or feature
installation or
uninstallation
Limited support;
online and offline
status only
To s t a rt Se rv e r M a n a g e r o n a c l i e n t c o mp u t e r
1. Follow instructions in Remote Server Administration Tools to install Remote Server Administration Tools
for Windows 10.
2. On the start screen, click Server Manager. The Server Manager tile is available after you install Remote
Server Administration Tools.
3. if neither the Administrative Tools nor the Server Manager tiles are displayed on the start screen after
installing Remote Server Administration Tools, and searching for Server Manager on the start screen does
not display results, verify that the Show administrative tools setting is turned on. To view this setting,
hover the mouse cursor over the upper right corner of the start screen, and then click Settings. If Show
administrative tools is turned off, turn the setting on to display tools that you have installed as part of
Remote Server Administration Tools.
for more information about running Remote Server Administration Tools for Windows 10 to manage remote
servers, see Remote Server Administration Tools on the TechNet Wiki.
Configure remote management on servers that you want to manage
IMPORTANT
By default, Server Manager and Windows PowerShell remote management is enabled in Windows Server 2016.
To perform management tasks on remote servers by using Server Manager, remote servers that you want to
manage must be configured to allow remote management by using Server Manager and Windows PowerShell. If
remote management has been disabled on Windows Server 2012 R2 or Windows Server 2012 , and you want to
enable it again, perform the following steps.
To c o n fi g u r e Se r v e r M a n a g e r r e m o t e m a n a g e m e n t o n W i n d o w s Se r v e r 2 0 1 2 R 2 o r W i n d o w s Se r v e r 2 0 1 2 b y u si n g t h e W i n d o w s i n t e r fa c e
1.
NOTE
The settings that are controlled by the Configure remote Management dialog box do not affect parts of Server
Manager that use DCOM for remote communications.
Do one of the following to open Server Manager if it is not already open.
On the Windows taskbar, click the Server Manager button.
On the start screen, click Server Manager.
2. In the Properties area of the Local Servers page, click the hyperlinked value for the remote
management property.
3. Do one of the following, and then click OK.
To prevent this computer from being managed remotely by using Server Manager (or Windows
PowerShell if it is installed), clear the Enable remote management of this server from other
computers check box.
To let this computer be managed remotely by using Server Manager or Windows PowerShell, select
Enable remote management of this server from other computers.
To e n a b l e Se r v e r M a n a g e r r e m o t e m a n a g e m e n t o n W i n d o w s Se r v e r 2 0 1 2 R 2 o r W i n d o w s Se r v e r 2 0 1 2 b y u si n g W i n d o w s P o w e r Sh e l l
1. Do one of the following.
To run Windows PowerShell as an administrator from the start screen, right-click the Windows
PowerShell tile, and then click Run as Administrator.
To run Windows PowerShell as an administrator from the desktop, right-click the Windows
PowerShell shortcut in the taskbar, and then click Run as Administrator.
2. type the following, and then press Enter to enable all required firewall rule exceptions.
Configure-SMremoting.exe -Enable
NOTE
This command also works in a command prompt that has been opened with elevated user rights (Run as
Administrator).
if enabling remote management fails, see about_remote_Troubleshooting on Microsoft TechNet for
troubleshooting tips and best practices.
To e n a b l e Se rv e r M a n a g e r a n d W i n d o w s P o w e r Sh e l l re mo t e ma n a g e me n t o n o l d e r o p e ra t i n g s y s t e ms
Do one of the following.
To enable remote management on servers that are running Windows Server 2008 R2 , see remote
Management with Server Manager in the Windows Server 2008 R2 help.
To enable remote management on servers that are running Windows Server 2008 , see Enable and
Use remote Commands in Windows PowerShell.
Tasks that you can perform in Server Manager
Server Manager makes server administration more efficient by allowing administrators to do tasks in the
following table by using a single tool. In Windows Server 2012 R2 and Windows Server 2012 , both standard
users of a server and members of the Administrators group can perform management tasks in Server Manager,
but by default, standard users are prevented from performing some tasks, as shown in the following table.
Administrators can use two Windows PowerShell cmdlets in the Server Manager cmdlet module, EnableServerManagerStandardUserremoting and Disable-ServerManagerStandardUserremoting, to further control
standard user access to some additional data. The Enable-ServerManagerStandardUserremoting cmdlet can
provide one or more standard, non-Administrator users access to event, service, performance counter, and role
and feature inventory data.
IMPORTANT
Server Manager cannot be used to manage a newer release of the Windows Server operating system. Server Manager
running on Windows Server 2012 or Windows 8 cannot be used to manage servers that are running Windows Server 2012
R2 .
ADMINISTRATORS (INCLUDING THE
BUILT-IN ADMINISTRATOR ACCOUNT)
STANDARD SERVER USERS
add remote servers to a pool of servers
that Server Manager can be used to
manage.
Yes
No
create and edit custom groups of
servers, such as servers that are in a
specific geographic location or serve a
specific purpose.
Yes
Yes
Install or uninstall roles, role services,
and features on the local or on remote
servers that are running Windows
Server 2012 R2 or Windows Server
2012 . For definitions of roles, role
services, and features, see Roles, Role
Services, and Features.
Yes
No
View and make changes to server roles
and features that are installed on either
local or remote servers. Note: In Server
Manager, role and feature data is
displayed in the base language of the
system, also called the system default
GUI language, or the language selected
during installation of the operating
system.
Yes
Standard users can view and manage
roles and features, and perform tasks
such as viewing role events, but cannot
add or remove role services.
TASK DESCRIPTION
ADMINISTRATORS (INCLUDING THE
BUILT-IN ADMINISTRATOR ACCOUNT)
STANDARD SERVER USERS
start management tools such as
Windows PowerShell or mmc snap-ins.
You can start a Windows PowerShell
session targeted at a remote server by
right-clicking the server in the Servers
tile, and then clicking Windows
PowerShell. You can start mmc snapins from the Tools menu of the Server
Manager console, and then point the
mmc toward a remote computer after
the snap-in is open.
Yes
Yes
Manage remote servers with different
credentials by right-clicking a server in
the Servers tile, and then clicking
Manage As. You can use Manage As
for general server and File and Storage
Services management tasks.
Yes
No
Perform management tasks associated
with the operational lifecycle of servers,
such as starting or stopping services;
and start other tools that allow you to
configure a server's network settings,
users and groups, and remote Desktop
connections.
Yes
Standard users cannot start or stop
services. They can change the local
server's name, workgroup, or domain
membership and remote Desktop
settings, but are prompted by User
Account Control to provide
Administrator credentials before they
can complete these tasks. They cannot
change remote management settings.
Perform management tasks associated
with the operational lifecycle of roles
that are installed on servers, including
scanning roles for compliance with best
practices.
Yes
Standard users cannot run Best
Practices Analyzer scans.
Determine server status, identify critical
events, and analyze and troubleshoot
configuration issues or failures.
Yes
Yes
Customize the events, performance
data, services, and Best Practices
Analyzer results about which you want
to be alerted on the Server Manager
dashboard.
Yes
Yes
Restart servers.
Yes
No
Refresh data that is displayed in the
Server Manager console about
managed servers.
Yes
No
TASK DESCRIPTION
NOTE
Server Manager cannot be used to add roles and features to servers that are running Windows Server 2008 R2 or Windows
Server 2008 .
start Server Manager
Server Manager starts automatically by default on servers that are running Windows Server 2016 when a member
of the Administrators group logs on to a server. If you close Server Manager, restart it in one of the following
ways. This section also contains steps for changing the default behavior, and preventing Server Manager from
starting automatically.
To start Server Manager from the start screen
On the Windows start screen, click the Server Manager tile.
To start Server Manager from the Windows desktop
On the Windows taskbar, click Server Manager.
To prevent Server Manager from starting automatically
1. In the Server Manager console, on the Manage menu, click Server Manager Properties.
2. In the Server Manager Properties dialog box, fill the check box for Do not start Server Manager
automatically at logon. Click OK.
3. Alternatively, you can prevent Server Manager from starting automatically by enabling the Group Policy
setting, Do not start Server Manager automatically at logon. The path to this policy setting, in the Local
Group Policy editor console, is computer Configuration\Administrative Templates\System\Server Manager.
Restart remote servers
You can restart a remote server from the Servers tile of a role or group page in Server Manager.
IMPORTANT
Restarting a remote server forces the server to restart, even if users are still logged on to the remote server, and even if
programs with unsaved data are still open. This behavior is different from shutting down or restarting the local computer, on
which you would be prompted to save unsaved program data, and verify that you wanted to force logged-on users to log
off. Be sure that you can force other users to log off of remote servers, and that you can discard unsaved data in programs
that are running on the remote servers.
if an automatic refresh occurs in Server Manager while a managed server is shutting down and restarting, refresh and
manageability status errors can occur for the managed server, because Server Manager cannot connect to the remote server
until it is finished restarting.
To restart remote servers in Server Manager
1. Open a role or server group home page in Server Manager.
2. select one or more remote servers that you have added to Server Manager. Press and hold Ctrl as you click
to select multiple servers at one time. For more information about how to add servers to the Server
Manager server pool, see add Servers to Server Manager.
3. Right-click selected servers, and then click Restart Server.
Export Server Manager settings to other computers
In Server Manager, your list of managed servers, changes to Server Manager console settings, and custom groups
that you have created are stored in the following two files. You can reuse these settings on other computers that
are running the same release of Server Manager (or Windows 10 with Remote Server Administration Tools
installed). Remote Server Administration Tools must be running on Windows client-based computers to export
Server Manager settings to those computers.
%appdata%\Microsoft\Windows\ServerManager\Serverlist.xml
%appdata%\Local\Microsoft_Corporation\ServerManager.exe_StrongName_GUID\6.2.0.0\user.config
NOTE
Manage As (or alternate) credentials for servers in your server pool are not stored in the roaming profile. Server Manager
users must add them on each computer from which they want to manage.
The network share roaming profile is not created until a user logs on to the network, and then logs off for the first time.
The Serverlist.xml file is created at this time.
You can export Server Manager settings, make Server Manager settings portable, or use them on other computers
in one of the following two ways.
To export settings to another domain-joined computer, configure the Server Manager user to have a
roaming profile in active directory Users and computers. You must be a Domain Administrator to change
user properties in active directory Users and computers.
To export settings to another computer in a workgroup, copy the preceding two files to the same location
on the computer from which you want to manage by using Server Manager.
To export Server Manager settings to other domain-joined computers
1. In active directory Users and computers, open the Properties dialog box for a Server Manager user.
2. On the Profile tab, add a path to a network share to store the user's profile.
3. Do one of the following.
On U.S. English (en-us) builds, changes to the Serverlist.xml file are automatically saved to the
profile. Go on to the next step.
On other builds, copy the following two files from the computer that is running Server Manager to
the network share that is part of the user's roaming profile.
%appdata%\Microsoft\Windows\ServerManager\Serverlist.xml
%localappdata%\Microsoft_Corporation\ServerManager.exe_StrongName_GUID\6.2.0.0\user.
config
4. Click OK to save your changes and close the Properties dialog box.
To export Server Manager settings to computers in workgroups
On a computer from which you want to manage remote servers, overwrite the following two files with the
same files from another computer that is running Server Manager, and that has the settings you want.
%appdata%\Microsoft\Windows\ServerManager\Serverlist.xml
%localappdata%\Microsoft_Corporation\ServerManager.exe_StrongName_GUID\6.2.0.0\user.config
Manage the Local Server and the Server Manager
Console
4/24/2017 • 14 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
In Windows Server, Server Manager lets you manage both the local server (if you are running Server Manager on
Windows Server, and not on a Windows-based client operating system) and remote servers that are running
Windows Server 2008 and newer releases of the Windows Server operating system.
The Local Server page in Server Manager displays server properties, events, service and performance counter data,
and Best Practices Analyzer (BPA) results for the local server. Event, service, BPA, and performance tiles function as
they do on role and server group pages. For more information about configuring the data that is displayed in these
tiles, see View and Configure Performance, Event, and Service Data and Run Best Practices Analyzer Scans and
Manage Scan Results.
Menu commands and settings in the Server Manager console heading bars apply globally to all servers in your
server pool, and let you use Server Manager to manage the entire server pool.
This topic contains the following sections.
Shut down the local server
Configure Server Manager properties
Manage the Server Manager console
Customize tools that are displayed in the Tools menu
Manage roles on role home pages
Shut down the local server
The Tasks menu in the local server Properties tile lets you start a Windows PowerShell session on the local server,
open the computer Management mmc snap-in, or open mmc snap-ins for roles or features that are installed on
the local server. You can also shut down the local server by using the Shut Down Local Server command in this
Tasks menu. The Shut Down Local Server command is also available for the local server in the Servers tile on the
All Servers page, or on any role or group page in which the local server is represented.
Shutting down the local server by using this method, unlike shutting down Windows Server 2016 from the start
screen, opens the Shut Down Windows dialog box, which lets you specify reasons for shutdown in the shutdown
Event Tracker area.
NOTE
Only members of the Administrators group can shut down or restart a server. Standard users cannot shut down or restart a
server. Clicking the Shut Down Local Server command logs standard users off server sessions. This matches the experience
of a standard user running the Alt+F4 shutdown command from the server desktop.
Configure Server Manager properties
You can view or change the following settings in the Properties tile on the Local Server page. To change a
setting's value, click the hypertext value of the setting.
NOTE
Typically, the properties displayed in the Local Server Properties tile can only be changed on the local server. You cannot
change the local server properties from a remote computer by using Server Manager because the Properties tile can only
get information about the local computer, not remote computers.
Because many properties displayed in the Properties tile are controlled by tools that are not part of Server Manager (Control
Panel, for example), changes to Properties settings are not always displayed in the Properties tile immediately. By default,
data in the Properties tile is refreshed every two minutes. To refresh Properties tile data immediately, click Refresh in the
Server Manager address bar.
SETTING
DESCRIPTION
computer name
Displays the computer friendly name, and opens the System
Properties dialog box, which lets you change the server's
name, domain membership, and other system settings such as
user profiles.
Domain (or Workgroup, if the server is not joined to a domain)
Displays the domain or workgroup of which the server is a
member. Opens the System Properties dialog box, which lets
you change the server's name, domain membership, and other
system settings such as user profiles.
Windows Firewall
Displays Windows Firewall status for the local server. Opens
Control Panel\System and Security\Windows Firewall. For
more information about configuring Windows Firewall, see
Windows Firewall with Advanced Security and IPsec.
remote management
Displays Server Manager and Windows PowerShell remote
management status. Opens the Configure remote
Management dialog box. For more information about remote
management, see Configure remote Management in Server
Manager.
remote Desktop
Shows whether users can connect to the server remotely by
using remote Desktop sessions. Opens the remote tab of the
System Properties dialog box.
NIC Teaming
Shows whether the local server is participating in NIC teaming.
Opens the NIC Teaming dialog box, and lets you join the
local server to a NIC team if desired. For more information
about NIC Teaming, see the NIC Teaming white paper.
Ethernet
Displays the networking status of the server. Opens Control
Panel\Network and Internet\Network Connections.
Operating system version
This read-only field displays the version number of the
Windows operating system that the local server is running.
Hardware information
This read-only field displays the manufacturer and model
name and number of the server hardware.
SETTING
DESCRIPTION
Last installed updates
Displays the day and time that Windows updates were last
installed. Opens Control Panel\System and
Security\Windows Update.
Windows Update
Displays Windows Update settings for the local server. Opens
Control Panel\System and Security\Windows Update.
Last checked for updates
Displays the day and time that the server last checked for
available Windows updates. Opens Control Panel\System
and Security\Windows Update.
Windows Error Reporting
Displays Windows Error Reporting opt-in status. Opens the
Windows Error Reporting Configuration dialog box. For
more information about Windows Error Reporting, its benefits,
privacy statements, and opt-in settings, see Windows Error
Reporting.
Customer Experience Improvement Program
Displays Windows Customer Experience Improvement
Program opt-in status. Opens the Customer Experience
Improvement Program Configuration dialog box. For more
information about Windows Customer Experience
Improvement Program, its benefits, and opt-in settings, see
Windows Customer Experience Improvement Program.
Internet Explorer (IE) Enhanced Security Configuration
Shows whether IE Enhanced Security Configuration (also
known as IE hardening or IE ESC) is turned on or off. Opens
the Internet Explorer Enhanced Security Configuration
dialog box. IE Enhanced Security Configuration is a security
measure for servers that prevents web pages from opening in
Internet Explorer. For more information about IE Enhanced
Security Configuration, its benefits, and settings, see Internet
Explorer: Enhanced Security Configuration.
time zone
Displays the local server's time zone. Opens the date and
time dialog box.
Product ID
Displays the Windows activation status and product ID
number (if Windows has been activated) of the Windows
Server 2016 operating system. This is not the same number as
the Windows product key. Opens the Windows Activation
dialog box.
Processors
This read-only field displays manufacturer, model name, and
speed information about the local server's processors.
Installed memory (RAM)
This read-only field displays the amount of available RAM, in
gigabytes.
Total disk space
This read-only field displays the amount of available disk
space, in gigabytes.
Manage the Server Manager console
Global settings that apply to the entire Server Manager console, and to all remote servers that have been added to
the Server Manager server pool, are found in the heading bars at the top of the Server Manager console window.
add servers to Server Manager
The command that opens the add Servers dialog box, and lets you add remote physical or virtual servers to the
Server Manager server pool, is in the Manage menu of the Server Manager console. For detailed information
about how to add servers, see add Servers to Server Manager.
Refresh data that is displayed in Server Manager
You can configure the refresh interval for data that is displayed in Server Manager on the Server Manager
Properties dialog box, which you open from the Manage menu.
To c o n fi g u r e t h e r e fr e sh i n t e r v a l i n Se r v e r M a n a g e r
1. On the Manage menu in the Server Manager console, click Server Manager Properties.
2. In the Server Manager Properties dialog box, specify a time period, in minutes, for the amount of elapsed
time you want between refreshes of the data that is displayed in Server Manager. The default is 10 minutes.
Click OK when you are finished.
Refresh limitations
Refresh applies globally to data from all servers that you have added to the Server Manager server pool. You
cannot refresh data or configure different refresh intervals for individual servers, roles, or groups.
When servers that are in a cluster are added to Server Manager, whether they are physical computers or virtual
machines, the first refresh of data can fail, or display data only for the host server for clustered objects. Subsequent
refreshes show accurate data for physical or virtual servers in a server cluster.
Data that is displayed in role home pages in Server Manager for remote Desktop Services, IP address Management,
and File and Storage Services does not refresh automatically. Refresh data that is displayed in these pages
manually, by pressing F5 or clicking Refresh in the Server Manager console heading while you are on those pages.
add or remove roles or features
The commands that open the add Roles and Features Wizard and remove Roles and Features Wizard, and let you
add or remove roles, role services, and features to servers in your server pool, are in the Manage menu of the
Server Manager console, and the Tasks menu of the Roles and Features tile on role or group pages. For detailed
information about how to add or remove roles or features, see Install or Uninstall Roles, Role Services, or Features.
In Server Manager, role and feature data is displayed in the base language of the system, also called the system
default GUI language, or the language selected during installation of the operating system.
create server groups
The command that opens the create Server Group dialog box, and lets you create custom groups of servers, is in
the Manage menu of the Server Manager console. For detailed information about how to create server groups, see
create and Manage Server Groups.
Prevent Server Manager from opening automatically at logon
The Do not start Server Manager automatically at logon check box in the Server Manager Properties dialog
box controls whether Server Manager opens automatically at logon for members of the Administrators group on a
local server. This setting does not affect Server Manager behavior when it is running on Windows 10 as part of
Remote Server Administration Tools. For more information about configuring this setting, see Server Manager.
Zoom in or out
To zoom in or out on your view of the Server Manager console, you can either use the Zoom commands on the
View menu, or press Ctrl+Plus (+) to zoom in and Ctrl+Minus (-) to zoom out.
Customize tools that are displayed in the Tools menu
The Tools menu in Server Manager includes soft links to shortcuts in the Administrative Tools folder in Control
Panel/System and Security. The Administrative Tools folder contains a list of shortcuts or LNK files to available
management tools, such as mmc snap-ins. Server Manager populates the Tools menu with links to those shortcuts,
and copies the folder structure of the Administrative Tools folder to the Tools menu. By default, tools in the
Administrative Tools folder are arranged in a flat list, sorted by type and by name. In the Server ManagerTools
menu, items are sorted only by name, not by type.
To customize the Tools menu, copy tool or script shortcuts that you want to use to the Administrative Tools
folder. You can also organize your shortcuts in folders, which create cascading menus in the Tools menu.
additionally, if you want to restrict access to the custom tools on the Tools menu, you can set user access rights on
both your custom tool folders in Administrative Tools, or directly on the original tool or script files.
We recommend against reorganizing system and administrative tools, and any management tools associated with
roles and features that are installed on the local server. Moving role and feature management tools can prevent
successful uninstallation of those management tools, when necessary. After uninstallation of a role or feature, a
nonfunctional link to a tool whose shortcut has been moved might remain in the Tools menu. If you reinstall the
role, a duplicate link to the same tool is created in the Tools menu, but one of the links will not work.
Role and feature tools that are installed as part of Remote Server Administration Tools on a Windows client-based
computer can be organized into custom folders, however. Uninstalling the parent role or feature has no effect on
the tool shortcuts that are available on a remote computer that is running Windows 10.
The following procedure describes how to create an example folder called MyTools, and move shortcuts for two
Windows PowerShell scripts into the folder that are then accessible from the Server Manager Tools menu.
To customize the Tools menu by adding shortcuts in Administrative Tools
1. create a new folder called MyTools in a convenient location.
NOTE
Because of restrictive access rights on the Administrative Tools folder, you are not allowed to create a new folder
directly in the Administrative Tools folder; you must create a new folder elsewhere (such as on the Desktop), and
then copy the new folder to the Administrative Tools folder.
2. move or copy MyTools to Control Panel/System and Security/Administrative Tools. By default, you
must be a member of the Administrators group on the computer to make changes to the Administrative
Tools folder.
3. if you do not need to restrict user access rights to your custom tool shortcuts, go on to step 6. Otherwise,
right-click either the tool file (or the MyTools folder), and then click Properties.
4. On the Security tab of the file's Properties dialog box, click edit.
5. for users for whom you want to restrict tool access, clear check boxes for Read & execute, Read, and Write
permissions. These permissions are inherited by the tool shortcut n the Administrative Tools folder.
if you edit access rights for a user while the user is using Server Manager (or while Server Manager is open),
then your changes are not shown in the Tools menu until the user restarts Server Manager.
NOTE
if you restrict access to an entire folder that you have copied to Administrative Tools, restricted users can see neither
the folder nor its contents in the Server ManagerTools menu.
edit permissions for the folder in the Administrative Tools folder. Because hidden files and folders in Administrative
Tools are always displayed in the Server ManagerTools menu, do not use the Hidden setting on a file or folder's
Properties dialog box to restrict user access to your custom tool shortcuts.
Deny permissions always overwrite Allow permissions.
6. Right-click the original tool, script, or executable file for which you want to add entries on the Tools menu,
and then click create shortcut.
7. move the shortcut to the MyTools folder in Administrative Tools.
8. Refresh or restart Server Manager, if necessary, to see your custom tool shortcut in the Tools menu.
Manage roles on role home pages
After you add servers to the Server Manager server pool, and Server Manager collects inventory data about servers
in your pool, Server Manager adds pages to the navigation pane for roles that are discovered on managed servers.
The Servers tile on role pages lists managed servers that are running the role. By default, Events, Best Practices
Analyzer, Services, and Performance tiles display data for all servers that are running the role; selecting specific
servers in the Servers tile limits the scope of events, services, performance counters, and BPA results to selected
servers only. Management tools are typically available in the Server Manager console Tools menu, after a role or
feature has been installed or discovered on a managed server. You can also right-click server entries in the Servers
tile for a role or group, and then start the management tool that you want to use.
In Windows Server 2016, the following roles and feature have management tools that are integrated into Server
Manager console as pages.
File and Storage Services. File and Storage Services pages include custom tiles and commands for
managing volumes, shares, iSCSI virtual disks, and storage pools. When you open the File and Storage
Services role home page in Server Manager, a retracting pane opens that displays custom management
pages for File and Storage Services. For more information about deploying and managing File and Storage
Services, see File and Storage Services.
remote Desktop Services. remote Desktop Services pages include custom tiles and commands for
managing sessions, licenses, gateways, and virtual desktops. For more information about deploying and
managing remote Desktop Services, see remote Desktop Services (rdS).
IP address Management (IPAM). The IPAM role page includes a custom Welcome tile containing links to
common IPAM configuration and management tasks, including a wizard for provisioning an IPAM server.
The IPAM home page also includes tiles for viewing the managed network, configuration summary, and
scheduled tasks.
There are some limitations to IPAM management in Server Manager. Unlike typical role and group pages,
IPAM has no Servers, Events, Performance, Best Practices Analyzer, or Services tiles. There is no Best
Practices Analyzer model available for IPAM; Best Practices Analyzer scans on IPAM are not supported. To
access servers in your server pool that are running IPAM, create a custom group of those servers that are
running IPAM, and access the server list from the Servers tile on the custom group page. Alternatively,
access IPAM servers from the Servers tile on the All Servers group page.
Dashboard thumbnails also display limited rows for IPAM, compared to thumbnails for other roles and
groups. By clicking the IPAM thumbnail rows, you can view events, performance data, and manageability
status alerts for servers that are running IPAM. IPAM-related services can be managed from pages for server
groups that contain IPAM servers, such as the page for the All Servers group.
for more information about deploying and managing IPAM, see IP address Management (IPAM).
See Also
Server Manager add Servers to Server Manager create and Manage Server Groups View and Configure
Performance, Event, and Service Data File and Storage Services remote Desktop Services (rdS) IP address
Management (IPAM)
Configure remote Management in Server Manager
4/24/2017 • 10 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
In Windows Server, you can use Server Manager to perform management tasks on remote servers. remote
management is enabled by default on servers that are running Windows Server 2016. To manage a server
remotely by using Server Manager, you add the server to the Server Manager server pool.
You can use Server Manager to manage remote servers that are running older releases of Windows Server, but the
following updates are required to fully manage these older operating systems.
To manage servers that are running Windows Server releases older than Windows Server 2016, install the
following software and updates to make the older releases of Windows Server manageable by using Server
Manager in Windows Server 2016.
OPERATING SYSTEM
REQUIRED SOFTWARE
Windows Server 2012 R2 or Windows
Server 2012
- .NET Framework 4.6
- Windows Management Framework
5.0. The Windows Management
Framework 5.0 download package
updates Windows Management
Instrumentation (WMI) providers on
Windows Server 2012 R2 , Windows
Server 2012 , and Windows Server
2008 R2 . The updated WMI providers
let Server Manager collect information
about roles and features that are
installed on the managed servers. Until
the update is applied, servers that are
running Windows Server 2012 R2 ,
Windows Server 2012 , or Windows
Server 2008 R2 have a manageability
status of Not accessible.
- The performance update associated
with Knowledge Base article 2682011 is
no longer necessary on servers that are
running Windows Server 2012 R2 or
Windows Server 2012 .
MANAGEABILITY
OPERATING SYSTEM
REQUIRED SOFTWARE
Windows Server 2008 R2
- .NET Framework 4.5
- Windows Management Framework
4.0. The Windows Management
Framework 4.0 download package
updates Windows Management
Instrumentation (WMI) providers on
Windows Server 2008 R2 . The updated
WMI providers let Server Manager
collect information about roles and
features that are installed on the
managed servers. Until the update is
applied, servers that are running
Windows Server 2008 R2 have a
manageability status of Not accessible.
- The performance update associated
with Knowledge Base article 2682011
lets Server Manager collect performance
data from Windows Server 2008 R2 .
Windows Server 2008
- .NET Framework 4
- Windows Management Framework
3.0 The Windows Management
Framework 3.0 download package
updates Windows Management
Instrumentation (WMI) providers on
Windows Server 2008 . The updated
WMI providers let Server Manager
collect information about roles and
features that are installed on the
managed servers. Until the update is
applied, servers that are running
Windows Server 2008 have a
manageability status of Not accessible
- verify earlier versions run
Windows Management Framework
3.0.
- The performance update associated
with Knowledge Base article 2682011
lets Server Manager collect performance
data from Windows Server 2008 .
MANAGEABILITY
for detailed information about how to add servers that are in workgroups to manage, or manage remote servers
from a workgroup computer that is running Server Manager, see add Servers to Server Manager.
Enabling or disabling remote management
In Windows Server 2016, remote management is enabled by default. Before you can connect to a computer that is
running Windows Server 2016 remotely by using Server Manager, Server Manager remote management must be
enabled on the destination computer if it has been disabled. The procedures in this section describe how to disable
remote management, and how to re-enable remote management if it has been disabled. In the Server Manager
console, the remote management status for the local server is displayed in the Properties area of the Local Server
page.
Local administrator accounts other than the built-in Administrator account may not have rights to manage a server
remotely, even if remote management is enabled. The remote User Account Control (UAC)
LocalAccountTokenFilterPolicy registry setting must be configured to allow local accounts of the Administrators
group other than the built-in administrator account to remotely manage the server.
In Windows Server 2016, Server Manager relies on Windows remote Management (WinRM) and the Distributed
component Object model (DCOM) for remote communications. The settings that are controlled by the Configure
remote Management dialog box only affect parts of Server Manager and Windows PowerShell that use WinRM
for remote communications. They do not affect parts of Server Manager that use DCOM for remote
communications. For example, Server Manager uses WinRM to communicate with remote servers that are running
Windows Server 2016, Windows Server 2012 R2, or Windows Server 2012, but uses DCOM to communicate with
servers that are running Windows Server 2008 and Windows Server 2008 R2, but do not have the Windows
Management Framework 4.0 or Windows Management Framework 3.0 updates applied. Microsoft Management
Console (mmc) and other legacy management tools use DCOM. For more information about how to change these
settings, see To configure mmc or other tool remote management over DCOM in this topic.
NOTE
Procedures in this section can be completed only on computers that are running Windows Server. You cannot enable or
disable remote management on a computer that is running Windows 10 by using these procedures, because the client
operating system cannot be managed by using Server Manager.
To enable WinRM remote management, select one of the following procedures.
To enable Server Manager remote management by using the Windows interface
To enable Server Manager remote management by using Windows PowerShell
To enable Server Manager remote management by using the command line
To enable Server Manager and Windows PowerShell remote management on earlier releases of
Windows Server
To disable WinRM and Server Manager remote management, select one of the following procedures.
To disable remote management by using Group Policy
To disable remote management by using an answer file during unattended installation
To configure DCOM remote management, see To configure DCOM remote management.
To enable Server Manager remote management by using the Windows interface
1.
NOTE
The settings that are controlled by the Configure remote Management dialog box do not affect parts of Server
Manager that use DCOM for remote communications.
On the computer that you want to manage remotely, open Server Manager, if it is not already open. On the
Windows taskbar, click Server Manager. On the start screen, click the Server Manager tile.
2. In the Properties area of the Local Servers page, click the hyperlinked value for the remote management
property.
3. Do one of the following, and then click OK.
To prevent this computer from being managed remotely by using Server Manager (or Windows
PowerShell if it is installed), clear the Enable remote management of this server from other
computers check box.
To let this computer be managed remotely by using Server Manager or Windows PowerShell, select
Enable remote management of this server from other computers.
To enable Server Manager remote management by using Windows PowerShell
1. On the computer that you want to manage remotely, do one of the following to open a Windows
PowerShell session with elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows start screen, right-click Windows PowerShell, and then on the app bar, click Run
as Administrator.
2. type the following, and then press Enter to enable all required firewall rule exceptions.
Configure-SMremoting.exe -enable
To enable Server Manager remote management by using the command line
1. On the computer that you want to manage remotely, open a command prompt session with elevated user
rights. To do this, on the start screen, type cmd, right-click the Command prompt tile when it is displayed
in the Apps results, and then on the app bar, click Run as Administrator.
2. Run the following executable file.
%windir%\system32\Configure-SMremoting.exe
3. Do one of the following:
To disable remote management, type Configure-SMremoting.exe -disable, and then press Enter.
To enable remote management, type Configure-SMremoting.exe -enable, and then press Enter.
To view the current remote management setting, type Configure-SMremoting.exe -get, and then
press ENTER.
To enable Server Manager and Windows PowerShell remote management on earlier releases of Windows
Server
Do one of the following:
To enable remote management on servers that are running Windows Server 2012 , see To enable
Server Manager remote management by using the Windows interface in this topic.
To enable remote management on servers that are running Windows Server 2008 R2 , see remote
Management with Server Manager in the Windows Server 2008 R2 help.
To enable remote management on servers that are running Windows Server 2008 , see Enable and
Use remote Commands in Windows PowerShell.
To configure mmc or other tool remote management over DCOM
1. Do one of the following to open the Windows Firewall with Advanced Security snap-in.
In the Properties area of the Local Server page in Server Manager, click the hypertext value for the
Windows Firewall property, and then click Advanced settings.
On the start screen, type WF.msc, and then click the snap-in tile when it is displayed in the Apps
results.
2. In the tree pane, select Inbound Rules.
3. verify that exceptions to the following firewall rules are enabled, and have not been disabled by Group
Policy settings. If any are not enabled, go on to the next step.
COM+ Network Access (DCOM-In)
remote Event Log Management (NP-In)
remote Event Log Management (RPC)
remote Event Log Management (RPC-EPMAP)
4. Right-click the rules that are not enabled, and then click Enable Rule on the context menu.
5. Close the Windows Firewall with Advanced Security snap-in.
To disable remote management by using Group Policy
1. Do one of the following to open Local Group Policy editor.
On a server that is running Windows Server 2016, Windows Server 2012 R2 , or Windows Server
2012 , on the start screen, type gpedit.msc, and then click the gpedit tile when it is displayed.
On a server that is running Windows Server 2008 R2 or Windows Server 2008 , in the Run dialog
box, type gpedit.msc, and then press Enter.
2. Open computer Configuration\Administrative Templates\Windows components\Windows remote
Management (WinRM)\WinRM Service.
3. In the content pane, double-click Allow remote server management through WinRM.
4. In the dialog box for the Allow remote server management through WinRM policy setting, select
Disabled to disable remote management. Click OK to save your changes and close the policy setting dialog
box.
To disable remote management by using an answer file during unattended installation
1. create an unattended installation answer file for Windows Server 2016 installations by using Windows
System Image Manager (Windows SIM). For more information about how to create an answer file and use
Windows SIM, see What is Windows System Image Manager? and Step-by-Step: Basic Windows
Deployment for IT Professionals.
2. In your answer file, locate the setting Microsoft-Windows-Web-Services-for-ManagementCore\EnableServerremoteManagement.
3. To disable Server Manager remote management by default on all servers to which you want to apply the
answer file, set Microsoft-Windows-Web-Services-for-Management-Core
\EnableServerremoteManagement to False.
NOTE
This setting disables remote management as part of the operating system setup process. Configuring this setting
does not prevent an administrator from enabling Server Manager remote management on a server after operating
system setup is complete. Administrators can enable Server Manager remote management again by using steps in To
configure Server Manager remote management by using the Windows interface or To enable Server Manager remote
management by using Windows PowerShell in this topic.
if you disable remote management by default as part of an unattended installation, and do not enable remote
management on the server again after installation, servers to which this answer file is applied cannot be fully
managed by using Server Manager. Servers that are running Windows Server 2016, Windows Server 2012 R2 , or
Windows Server 2012 (and that have remote management disabled by default) generate manageability status errors
in the Server Manager console after they are added to the Server Manager server pool.
Windows remote Management (WinRM) listener settings
Server Manager relies on default WinRM listener settings on the remote servers that you want to manage. If the
default authentication mechanism or the WinRM listener port number on a remote server has been changed from
default settings, Server Manager cannot communicate with the remote server.
The following list shows default WinRM listener settings for managing by using Server Manager.
The WinRM service is running.
A WinRM listener is created to accept HTTP requests through port number 5985.
Port number 5985 is enabled in Windows Firewall settings to allow requests through WinRM.
Both Kerberos and Negotiate authentication types are enabled.
The default port number is 5985 for WinRM to communicate with a remote computer.
for more information about how to configure WinRM listener settings, at a command prompt, type winrm help
config, and then press ENTER.
See Also
add Servers to Server Manager Windows PowerShell: about_remote_Troubleshooting on the Windows Server
TechCenter Description of User Account Control
add Servers to Server Manager
4/24/2017 • 11 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
In Windows Server you can manage multiple remote servers by using a single Server Manager console. Servers
that you want to manage by using Server Manager can be running Windows Server 2016, Windows Server 2012
R2 , Windows Server 2012 , Windows Server 2008 R2 , or Windows Server 2008 . Note that you cannot manage
a newer release of Windows Server with an older release of Server Manager.
This topic describes how to add servers to the Server Manager server pool.
NOTE
In our tests, Server Manager in Windows Server 2012 and later releases of Windows Server can be used to manage up to
100 servers that are configured with a typical workload. The number of servers that you can manage by using a single
Server Manager console can vary depending on the amount of data that you request from managed servers, and hardware
and network resources available to the computer running Server Manager. As the amount of data you want to display
approaches that computer's resource capacity, you can experience slow responses from Server Manager, and delays in the
completion of refreshes. To help increase the number of servers that you can manage by using Server Manager, we
recommend limiting the event data that Server Manager gets from your managed servers, by using settings in the
Configure Event Data dialog box. Configure Event Data can be opened from the Tasks menu in the Events tile. If you
need to manage an enterprise-level number of servers in your organization, we recommend evaluating products in the
Microsoft System Center suite.
Server Manager can receive only online or offline status from servers that are running Windows Server 2003. Although you
can use Server Manager to perform management tasks on servers that are running Windows Server 2008 R2 or Windows
Server 2008 , you cannot add roles and features to servers that are running Windows Server 2008 R2 , Windows Server
2008 or Windows Server 2003.
Server Manager cannot be used to manage a newer release of the Windows Server operating system. Server Manager
running on Windows Server 2012 R2 , Windows Server 2012 , Windows 8.1, or Windows 8 cannot be used to manage
servers that are running Windows Server 2016.
This topic contains the following sections.
add servers to manage
Provide credentials with the Manage As command
Provide credentials with the Manage As command
As you add remote servers to Server Manager, some of the servers that you add might require different user
account credentials to access or manage them. To specify credentials for a managed server that are different from
those you use to log on to the computer on which you are running Server Manager, use the Manage As
command after you add a server to Server Manager, which is accessible by right-clicking the entry for a managed
server in the Servers tile of a role or group home page. Clicking Manage As opens the Windows Security
dialog box, in which you can provide a user name that has access rights on the managed server, in one of the
following formats.
User name
User name@example.domain.com
Domain\User name
The Windows Security dialog box that is opened by the Manage As command cannot accept smart card
credentials; providing smart card credentials through Server Manager is not supported. Credentials that you
provide for a managed server by using the Manage As command are cached, and persist as long as you are
managing the server by using the same computer on which you are currently running Server Manager, or as long
as you do not overwrite them by specifying blank or different credentials for the same server. If you export your
Server Manager settings to other computers, or configure your domain profile to be roaming to allow Server
Manager settings to be used on other computers, Manage As credentials for servers in your server pool are not
stored in the roaming profile. Server Manager users must add them on each computer from which they want to
manage.
After you add servers to manage by following procedures in this topic, but before you use the Manage As
command to specify alternate credentials that might be required to manage a server that you have added, the
following manageability status errors can be displayed for the server:
Kerberos target resolution error
Kerberos authentication error
online - Access denied
NOTE
Roles and features that do not support the Manage As command include remote Desktop Services (rdS) and IP address
Management (IPAM) Server. If you cannot manage the remote rdS or IPAM server by using the same credentials you are
using on the computer on which you are running Server Manager, try adding the account you typically use to manage
these remote servers to the Administrators group on the computer that is running Server Manager. Then, log on to the
computer that is running Server Manager with the account you use to manage the remote server that is running rdS or
IPAM.
add servers to manage
You can add servers to Server Manager to manage by using any of three methods in the add Servers dialog box.
active directory Domain Services add servers to manage that active directory finds in the same domain
as the local computer.
Domain Name System (DNS) entry Search for servers to manage by computer name or IP address.
import multiple servers Specify multiple servers to import in a file that contains servers listed by
computer name or IP address.
To add servers to the server pool
1. if Server Manager is already open, go on to the next step. If Server Manager is not already open, open it by
doing one of the following.
On the Windows desktop, start Server Manager by clicking Server Manager in the Windows
taskbar.
On the Windows start screen, click the Server Manager tile.
2. On the Manage menu, click add Servers.
3. Do one of the following.
On the active directory tab, select servers that are in the current domain. Press Ctrl while selecting
to select multiple servers. Click the right-arrow button to move selected servers to the selected list.
On the DNS tab, type the first few characters of a computer name or IP address, and then press
Enter or click Search. select servers that you want to add, and then click the right-arrow button.
On the import tab, browse for a text file that contains the DNS names or IP addresses of computers
that you want to add, one name or IP address per line.
4. When you are finished adding servers, click OK.
add and manage servers in workgroups
Although adding servers that are in workgroups to Server Manager might be successful, after they are added, the
Manageability column of the Servers tile on a role or group page that includes a workgroup server can display
Credentials not valid errors that occur while trying to connect to or collect data from the remote, workgroup
server.
These or similar errors can occur in the following conditions.
The managed server is in the same workgroup as the computer that is running Server Manager.
The managed server is in a different workgroup from the computer that is running Server Manager.
One of the computers is in a workgroup, while the other is in a domain.
The computer that is running Server Manager is in a workgroup, and remote, managed servers are on a
different subnet.
Both computers are in domains, but there is no trust relationship between the two domains.
Both computers are in domains, but there is only a one-way trust relationship between the two domains.
The server you want to manage has been added by using its IP address.
To a d d r e m o t e w o r k g r o u p se r v e r s t o Se r v e r M a n a g e r
1. On the computer that is running Server Manager, add the workgroup server name to the TrustedHosts
list. This is a requirement of NTLM authentication. To add a computer name to an existing list of trusted
hosts, add the Concatenate parameter to the command. For example, to add the Server01 computer to an
existing list of trusted hosts, use the following command.
Set-Item wsman:\localhost\Client\TrustedHosts Server01 -Concatenate -force
2. Determine whether the workgroup server that you want to manage is in the same subnet as the computer
on which you are running Server Manager.
if the two computers are in the same subnet, or if the workgroup server's network profile is set to Private
in the Network and Sharing Center, go on to the next step.
if they are not in the same subnet, or if the workgroup server's network profile is not set to Private, on the
workgroup server, change the inbound Windows remote Management (HTTP-In) setting in Windows
Firewall to explicitly allow connections from remote computers by adding the computer names on the
computers tab of the setting's Properties dialog box.
3.
IMPORTANT
Running the cmdlet in this step overrides User Account Control (UAC) measures that prevent elevated processes
from running on workgroup computers unless the built-in Administrator or the System account is running the
processes. The cmdlet lets members of the Administrators group manage the workgroup server without logging on
as the built-in Administrator. Allowing additional users to manage the workgroup server can reduce its security;
however, this is more secure than providing built-in Administrator account credentials to what might be multiple
people who are managing the workgroup server.
To override UAC restrictions on running elevated processes on workgroup computers, create a registry
entry called LocalAccountTokenFilterPolicy on the workgroup server by running the following cmdlet.
New-ItemProperty -Name LocalAccountTokenFilterPolicy -path
HKLM:\SOFTWARE\Microsoft\Windows\Currentversion\Policies\System -propertytype DWord -value 1
4. On the computer on which you are running Server Manager, open the All Servers page.
5. if the computer that is running Server Manager and the target workgroup server are in the same
workgroup, skip to the last step. If the two computers are not in the same workgroup, right-click the target
workgroup server in the Servers tile, and then click Manage as.
6. Log on to the workgroup server by using the built-in Administrator account for the workgroup server.
7. verify that Server Manager is able to connect to and collect data from the workgroup server by refreshing
the All Servers page, and then viewing the manageability status for the workgroup server.
To a d d r e m o t e se r v e r s w h e n Se r v e r M a n a g e r i s r u n n i n g o n a w o r k g r o u p c o m p u t e r
1. On the computer that is running Server Manager, add remote servers to the local computer's
TrustedHosts list in a Windows PowerShell session. To add a computer name to an existing list of trusted
hosts, add the Concatenate parameter to the command. For example, to add the Server01 computer to an
existing list of trusted hosts, use the following command.
Set-Item wsman:\localhost\Client\TrustedHosts Server01 -Concatenate -force
2. Determine whether the server that you want to manage is in the same subnet as the workgroup computer
on which you are running Server Manager.
if the two computers are in the same subnet, or if the workgroup computer's network profile is set to
Private in the Network and Sharing Center, go on to the next step.
if they are not in the same subnet, or if the workgroup computer's network profile is not set to Private, on
the workgroup computer that is running Server Manager, change the inbound Windows remote
Management (HTTP-In) setting in Windows Firewall to explicitly allow connections from remote
computers by adding the computer names on the computers tab of the setting's Properties dialog box.
3. On the computer on which you are running Server Manager, open the All Servers page.
4. verify that Server Manager is able to connect to and collect data from the remote server by refreshing the
All Servers page, and then viewing the manageability status for the remote server. If the Servers tile still
displays a manageability error for the remote server, go on to the next step.
5. Log off of the computer on which you are running Server Manager, and then log on again by using the
built-in Administrator account. Repeat the preceding step, to verify that Server Manager is able to connect
to and collect data from the remote server.
if you have followed the procedures in this section, and you continue to have problems managing workgroup
computers, or managing other computers from workgroup computers, see about_remote_Troubleshooting on
the Microsoft website.
add and manage servers in clusters
You can use Server Manager to manage servers that are in failover clusters (also called server clusters or MSCS).
Servers that are in failover clusters (whether the cluster nodes are physical or virtual) have some unique
behaviors and management limitations in Server Manager.
Both physical and virtual servers in clusters are automatically added to Server Manager when one server
in the cluster is added to Server Manager. Similarly, when you remove a clustered server from Server
Manager, you are prompted to remove other servers in the cluster.
Server Manager does not display data for clustered virtual servers, because the data is dynamic, and is
identical to data for the server on which the virtual clustered node is hosted. You can select the server that
is hosting the virtual server to view its data.
if you add a server to Server Manager by using the server's virtual cluster object name, the virtual object
name is displayed in Server Manager instead of the physical server name (expected).
You cannot install roles and features on a clustered virtual server.
See Also
Server Manager create and Manage Server Groups
Install or Uninstall Roles, Role Services, or Features
4/24/2017 • 29 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
In Windows Server, the Server Manager console and Windows PowerShell cmdlets for Server Manager allow
installation of roles and features to local or remote servers, or offline virtual hard disks (VHDs). You can install
multiple roles and features on a single remote server or offline VHD in a single add Roles and Features Wizard or
Windows PowerShell session.
IMPORTANT
Server Manager cannot be used to manage a newer release of the Windows Server operating system. Server Manager
running on Windows Server 2012 R2 or Windows 8.1 cannot be used to install roles, role services, and features on servers
that are running Windows Server 2016.
You must be logged on to a server as an administrator to install or uninstall roles, role services, and features. If you
are logged on to the local computer with an account that does not have administrator rights on your target server,
right-click the target server in the Servers tile, and then click Manage As to provide an account that has
administrator rights. The server on which you want to mount an offline VHD must be added to Server Manager,
and you must have Administrator rights on that server.
For more information about what roles, role services, and features are, see Roles, Role Services, and Features.
This topic contains the following sections.
Install roles, role services, and features by using the add Roles and Features Wizard
Install roles, role services, and features by using Windows PowerShell cmdlets
Remove roles, role services, and features by using the remove Roles and Features Wizard
Remove roles, role services, and features by using Windows PowerShell cmdlets
Install roles and features on multiple servers by running a Windows PowerShell script
Install .NET Framework 3.5 and other features on-demand
Install roles, role services, and features by using the add Roles and
Features Wizard
In a single session in the add Roles and Features Wizard, you can install roles, role services, and features on the
local server, a remote server that has been added to Server Manager, or an offline VHD. For more information
about how to add a server to Server Manager to manage, see Add Servers to Server Manager.
NOTE
If you are running Server Manager on Windows Server 2016 or Windows 10, you can use the add Roles and Features Wizard
to install roles and features only on servers and offline VHDs that are running Windows Server 2016.
To install roles and features by using the add Roles and Features Wizard
1. If Server Manager is already open, go on to the next step. If Server Manager is not already open, open it by
doing one of the following.
On the Windows desktop, start Server Manager by clicking Server Manager in the Windows taskbar.
On the Windows start screen, click the Server Manager tile.
2. On the Manage menu, click add Roles and Features.
3. On the Before you begin page, verify that your destination server and network environment are prepared
for the role and feature you want to install. Click Next.
4. On the Select installation type page, select Role-based or feature-based installation to install all parts
of roles or features on a single server, or Remote Desktop Services installation to install either a virtual
machine-based desktop infrastructure or a session-based desktop infrastructure for remote Desktop
Services. The Remote Desktop Services installation option distributes logical parts of the remote
Desktop Services role across different servers as needed by administrators. Click Next.
5. On the Select destination server page, select a server from the server pool, or select an offline VHD. To
select an offline VHD as your destination server, first select the server on which to mount the VHD, and then
select the VHD file. For information about how to add servers to your server pool, see add Servers to Server
Manager. After you have selected the destination server, click Next.
NOTE
To install roles and features on offline VHDs, target VHDs must meet the following requirements.
VHDs must be running the release of Windows Server that matches the version of Server Manager you are
running. See the note at the start of Install roles, role services, and features by using the add Roles and Features
Wizard.
VHDs cannot have more than one system volume or partition.
The network shared folder in which the VHD file is stored must grant the following access rights to the
computer (or local system) account of server that you have selected to mount the VHD. User-only account
access is not sufficient. The share can grant Read and Write permissions to the Everyone group to allow
access to the VHD, but for security reasons, this is not recommended.
Read/Write access on the File Sharing dialog box.
Full Control access on the Security tab, file or folder Properties dialog box.
6. Select roles, select role services for the role if applicable, and then click Next to select features.
As you proceed, the add Roles and Features Wizard automatically informs you if conflicts were found on the
destination server that can prevent selected roles or features from installation or normal operation. You are
also prompted to add any roles, role services, or features that are required by the roles or features that you
have selected.
Additionally, if you plan to manage the role remotely, either from another server, or from a Windows clientbased computer that is running Remote Server Administration Tools, you can opt not to install management
tools and snap-ins for roles on the destination server. By default, in the add Roles and Features Wizard,
management tools are selected for installation.
7. On the Confirm installation selections page, review your role, feature, and server selections. If you are
ready to install, click Install.
You can also export your selections to an XML-based configuration file that you can use for unattended
installations with Windows PowerShell. To export the configuration you specified in this add Roles and
Features Wizard session, click Export configuration settings, and then save the XML file to a convenient
location.
The Specify an alternate source path command on the Confirm installation selections page lets you
specify an alternate source path for the files that are required to install roles and features on the selected
server. In Windows Server 2012 and later releases of Windows Server, Features on Demand lets you reduce
the amount of disk space used by the operating system, by removing role and feature files from servers that
are exclusively managed remotely. If you have removed role and feature files from a server by using the
Uninstall-WindowsFeature -remove cmdlet, you can install roles and features on the server in the future by
specifying an alternate source path, or a share on which required role and feature files are stored. The
source path or file share must grant Read permissions either to the Everyone group (not recommended for
security reasons), or to the computer account (DOMAIN\SERverNAME$) of the destination server; granting
user account access is not sufficient. For more information about Features on Demand, see Windows Server
Installation Options.
You can specify a WIM file as an alternate feature file source when you are installing roles, role services, and
features on a running, physical server. The source path for a WIM file should be in the following format, with
WIM as a prefix, and the index in which the feature files are located as a suffix:
WIM:e:\sources\install.wim:4. However, you cannot use a WIM file directly as a source for installing roles,
role services, and features to an offline VHD; you must either mount the offline VHD and point to its mount
path for source files, or you must point to a folder that contains a copy of the contents of the WIM file.
8. After you click Install, the Installation Progress page displays installation progress, results, and messages
such as warnings, failures, or post-installation configuration steps that are required for the roles or features
that you installed. In Windows Server 2012 and later releases of Windows Server, you can close the add
Roles and Features Wizard while installation is still in progress, and view installation results or other
messages in the Notifications area at the top of the Server Manager console. Click the Notifications flag
icon to see more details about installations or other tasks that you are performing in Server Manager.
Install roles, role services, and features by using Windows PowerShell
cmdlets
The Server Manager deployment cmdlets for Windows PowerShell function similarly to the GUI-based add Roles
and Features Wizard and remove Roles and Features Wizard, with an IMPORTANT difference. In Windows
PowerShell, unlike in the add Roles and Features Wizard, management tools and snap-ins for a role are not
included by default. To include management tools as part of a role installation, add the IncludeManagementTools
parameter to the cmdlet. If you are installing roles and features on a server that is running the Server Core
installation option of Windows Server 2012 or later releases, you can add a role's management tools to an
installation, but GUI-based management tools and snap-ins cannot be installed on servers that are running the
Server Core installation option of Windows Server. Only command-line and Windows PowerShell management
tools can be installed on the Server Core installation option.
To install roles and features by using the Install-WindowsFeature cmdlet
1. Do one of the following to open a Windows PowerShell session with elevated user rights.
NOTE
If you are installing roles and features on a remote server, you do not need to run Windows PowerShell with elevated
user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows Start screen, right-click the tile for Windows PowerShell, and then on the app bar,
click Run as Administrator.
2. Type Get-WindowsFeature and then press Enter to view a list of available and installed roles and features
on the local server. If the local computer is not a server, or if you want information about a remote server,
run Get-WindowsFeature -computerName <computer_name>, in which computer_name represents the
name of a remote computer that is running Windows Server 2016. The results of the cmdlet contain the
command names of roles and features that you add to your cmdlet in step 4.
NOTE
In Windows PowerShell 3.0 and later releases of Windows PowerShell, there is no need to import the Server Manager
cmdlet module into the Windows PowerShell session before running cmdlets that are part of the module. A module is
automatically imported the first time you run a cmdlet that is part of the module. Also, neither Windows PowerShell
cmdlets nor the feature names used with the cmdlets are case-sensitive.
3. type Get-help Install-WindowsFeature, and then press Enter to view the syntax and accepted parameters
for the Install-WindowsFeature cmdlet.
4. type the following, and then press Enter, where feature_name represents the command name of a role or
feature that you want to install (obtained in step 2), and computer_name represents a remote computer on
which you want to install roles and features. Separate multiple values for feature_name by using commas.
The Restart parameter automatically restarts the destination server if required by the role or feature
installation.
Install-WindowsFeature -Name <feature_name> -computerName <computer_name> -Restart
To install roles and features on an offline VHD, add both the computerName parameter and the VHD
parameter. If you do not add the computerName parameter, the cmdlet assumes that the local computer is
mounted to access the VHD. The computerName parameter contains the name of the server on which to
mount the VHD, and the VHD parameter contains the path to the VHD file on the specified server.
NOTE
You must add the computerName parameter if you are running the cmdlet from a computer that is running a
Windows client operating system.
To install roles and features on offline VHDs, target VHDs must meet the following requirements.
VHDs must be running the release of Windows Server that matches the version of Server Manager you are
running. See the note at the start of Install roles, role services, and features by using the add Roles and Features
Wizard.
VHDs cannot have more than one system volume or partition.
The network shared folder in which the VHD file is stored must grant the following access rights to the
computer (or local system) account of server that you have selected to mount the VHD. User-only account
access is not sufficient. The share can grant Read and Write permissions to the Everyone group to allow
access to the VHD, but for security reasons, this is not recommended.
Read/Write access on the File Sharing dialog box.
Full Control access on the Security tab, file or folder Properties dialog box.
Install-WindowsFeature -Name <feature_name> -VHD <path> -computerName <computer_name> -Restart
Example: The following cmdlet installs the active directory Domain Services role and the Group Policy
Management feature on a remote server, ContosoDC1. Management tools and snap-ins are added by using
the IncludeManagementTools parameter, and the destination server is to be restarted automatically, if
installation requires that the servers be restarted.
Install-WindowsFeature -Name AD-Domain-Services,GPMC -computerName ContosoDC1 -IncludeManagementTools Restart
5. When installation is finished, verify installation by opening the All Servers page in Server Manager,
selecting a server on which you installed roles and features, and viewing the Roles and Features tile on the
page for the selected server. You can also run the Get-WindowsFeature cmdlet targeted at the selected server
(Get-WindowsFeature -computerName <computer_name>) to view a list of roles and features that are
installed on the server.
remove roles, role services, and features by using the remove Roles and
Features Wizard
You must be logged on to a server as an administrator to uninstall roles, role services, and features. If you are
logged on to the local computer with an account that does not have administrator rights on your uninstallation
target server, right-click the target server in the Servers tile, and then click Manage As to provide an account that
has administrator rights. The server on which you want to mount an offline VHD must be added to Server
Manager, and you must have Administrator rights on that server.
To remove roles and features by using the remove Roles and Features Wizard
1. If Server Manager is already open, go on to the next step. If Server Manager is not already open, open it by
doing one of the following.
On the Windows desktop, start Server Manager by clicking Server Manager in the Windows taskbar.
On the Windows Start screen, click the Server Manager tile.
2. On the Manage menu, click Remove Roles and Features.
3. On the Before you begin page, verify that you have prepared for removing roles or features from a server.
Click Next.
4. On the Select Destination Server page, select a server from the server pool, or select an offline VHD. To
select an offline VHD, first select the server on which to mount the VHD, and then select the VHD file.
NOTE
The network shared folder in which the VHD file is stored must grant the following access rights to the computer (or
local system) account of server that you have selected to mount the VHD. User-only account access is not sufficient.
The share can grant Read and Write permissions to the Everyone group to allow access to the VHD, but for
security reasons, this is not recommended.
Read/Write access on the File Sharing dialog box.
Full Control access on the Security tab , file or folder Properties dialog box.
For information about how to add servers to your server pool, see add Servers to Server Manager. After you
have selected the destination server, click Next.
NOTE
You can use the remove Roles and Features Wizard to remove roles and features from servers that are running the
same release of Windows Server that supports the version of Server Manager that you are using. You cannot remove
roles, role services, or features from servers that are running Windows Server 2016, if you are running Server
Manager on Windows Server 2012 R2, Windows Server 2012, or Windows 8. You cannot use the remove Roles and
Features Wizard to remove roles and features from servers that are running Windows Server 2008 or Windows
Server 2008 R2.
5. Select roles, select role services for the role if applicable, and then click Next to select features.
As you proceed, the remove Roles and Features Wizard automatically prompts you to remove any roles, role
services, or features that cannot run without the roles or features that you are removing.
additionally, you can opt to remove management tools and snap-ins for roles on the destination server. By
default, in the remove Roles and Features Wizard, management tools are selected for removal. You can
leave management tools and snap-ins if you plan to use the selected server to manage the role on other
remote servers.
6. On the Confirm removal selections page, review your role, feature, and server selections. If you are ready
to remove the roles or features, click remove.
7. After you click remove, the removal progress page displays removal progress, results, and messages such
as warnings, failures, or post-removal configuration steps that are required, such as restarting the
destination server. In Windows Server 2012 and later releases of Windows Server, you can close the remove
Roles and Features Wizard while removal is still in progress, and view removal results or other messages in
the Notifications area at the top of the Server Manager console. Click the Notifications flag to see more
details about removals or other tasks that you are performing in Server Manager.
remove roles, role services, and features by using Windows PowerShell
cmdlets
The Server Manager deployment cmdlets for Windows PowerShell function similarly to the GUI-based remove
Roles and Features Wizard, with an IMPORTANT difference. In Windows PowerShell, unlike in the remove Roles
and Features Wizard, management tools and snap-ins for a role are not removed by default. To remove
management tools as part of a role removal, add the IncludeManagementTools parameter to the cmdlet. If you are
uninstalling roles and features from a server that is running the Server Core installation option of Windows Server
2012 or a later release of Windows Server, this parameter removes command-line and Windows PowerShell
management tools for the specified roles and features.
To remove roles and features by using the Uninstall-WindowsFeature cmdlet
1. Do one of the following to open a Windows PowerShell session with elevated user rights.
NOTE
If you are uninstalling roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
2. Type Get-WindowsFeature and then press Enter to view a list of available and installed roles and features
on the local server. If the local computer is not a server, or if you want information about a remote server,
run Get-WindowsFeature -computerName <computer_name>, in which computer_name represents the
name of a remote computer that is running Windows Server 2016. The results of the cmdlet contain the
command names of roles and features that you add to your cmdlet in step 4.
NOTE
In Windows PowerShell 3.0 and later releases of Windows PowerShell, there is no need to import the Server Manager
cmdlet module into the Windows PowerShell session before running cmdlets that are part of the module. A module is
automatically imported the first time you run a cmdlet that is part of the module. Also, neither Windows PowerShell
cmdlets nor the feature names used with the cmdlets are case-sensitive.
3. type Get-help Uninstall-WindowsFeature, and then press Enter to view the syntax and accepted
parameters for the Uninstall-WindowsFeature cmdlet.
4. Type the following, and then press Enter, where feature_name represents the command name of a role or
feature that you want to remove (obtained in step 2), and computer_name represents a remote computer
from which you want to remove roles and features. Separate multiple values for feature_name by using
commas. The Restart parameter automatically restarts destination servers if required by the role or feature
removal.
Uninstall-WindowsFeature -Name <feature_name> -computerName <computer_name> -Restart
To remove roles and features from an offline VHD, add both the computerName parameter and the VHD
parameter. If you do not add the computerName parameter, the cmdlet assumes that the local computer is
mounted to access the VHD. The computerName parameter contains the name of the server on which to
mount the VHD, and the VHD parameter contains the path to the VHD file on the specified server.
NOTE
You must add the computerName parameter if you are running the cmdlet from a computer that is running a
Windows client operating system.
The network shared folder in which the VHD file is stored must grant the following access rights to the computer (or
local system) account of server that you have selected to mount the VHD. User-only account access is not sufficient.
The share can grant Read and Write permissions to the Everyone group to allow access to the VHD, but for
security reasons, this is not recommended.
Read/Write access on the File Sharing dialog box.
Full Control access on the Security tab, file or folder Properties dialog box.
Uninstall-WindowsFeature -Name <feature_name> -VHD <path> -computerName <computer_name> -Restart
Example: The following cmdlet removes the active directory Domain Services role and the Group Policy
Management feature from a remote server, ContosoDC1. Management tools and snap-ins are also
removed, and the destination server is to be restarted automatically, if removal requires that the servers be
restarted.
Uninstall-WindowsFeature -Name AD-Domain-Services,GPMC -computerName ContosoDC1 -IncludeManagementTools
-Restart
5. When removal is finished, verify that the roles and features are removed by opening the All Servers page in
Server Manager, selecting the server from which you removed roles and features, and viewing the Roles
and Features tile on the page for the selected server. You can also run the Get-WindowsFeature cmdlet
targeted at the selected server (Get-WindowsFeature -computerName <computer_name>) to view a list of
roles and features that are installed on the server.
Install roles and features on multiple servers by running a Windows
PowerShell script
Although you cannot use the add Roles and Features Wizard to install roles, role services, and features on more
than one target server in a single wizard session, you can use a Windows PowerShell script to install roles, role
services, and features on multiple target servers that you are managing by using Server Manager. The script that
you use to perform batch deployment, as this process is called, points to an XML configuration file that you can
create easily by using the add Roles and Features Wizard, and clicking Export configuration settings after
advancing through the wizard to the Confirm installation selections page of the add Roles and Features Wizard.
IMPORTANT
All target servers that are specified in your script must be running the release of Windows Server that matches the version of
Server Manager you are running on the local computer. For example, if you are running Server Manager on Windows 10,
you can install roles, role services, and features on servers that are running Windows Server 2016. If GUI-based management
tools are added to the installation, the installation process automatically converts target servers that are running the Server
Core installation option of Windows Server to the full installation option (server with a full GUI, also known as running Server
Graphical Shell).
The script provided in this section is an example of how batch deployment can be performed by using the
Install-WindowsFeature cmdlet and a Windows PowerShell script. There are other possible scripts and methods of
performing batch deployment to multiple servers. To search for or provide other scripts for deploying roles and features,
search the Script Center Repository.
To install roles and features on multiple servers
1. If you have not already done so, create an XML configuration file that contains the roles, role services, and
features that you want installed on multiple servers. You can create this configuration file by running the
add Roles and Features Wizard, selecting roles, role services, and features that you want, and clicking
Export configuration settings after advancing through the wizard to the Confirm installation
selections page. Save the configuration file to a convenient location. You do not need to click Install or
complete the wizard if you are running it only to create a configuration file.
2. Do one of the following to open a Windows PowerShell session with elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
3. Copy and paste the following script into your Windows PowerShell session.
function Invoke-WindowsFeatureBatchDeployment {
param (
[parameter(mandatory)]
[string[]] $computerNames,
[parameter(mandatory)]
[string] $ConfigurationFilepath
)
# Deploy the features on multiple computers simultaneously.
$jobs = @()
foreach($computerName in $computerNames) {
$jobs += start-Job -Command {
Install-WindowsFeature -ConfigurationFilepath $using:ConfigurationFilepath -computerName
$using:computerName -Restart
}
}
Receive-Job -Job $jobs -Wait | select-Object Success, RestartNeeded, exitCode, FeatureResult
}
Target servers are automatically restarted if required by the roles and features that you select.
4. Run the function by doing the following.
a. Create a variable in which to store the names of your target computers, separated by commas. In the
following example, the variable $ServerNames stores the names of target servers Contoso_01 and
Contoso_02. Press Enter.
# Sample Invocation
$ServerNames = 'Contoso_01','Contoso_02'
Invoke-WindowsFeatureBatchDeployment -computerNames $ServerNames -ConfigurationFilepath
C:\Users\sampleuser\Desktop\DeploymentConfigTemplate.xml
b. To run the function, type the following, and then press Enter, where $ServerNames is an example of
the variable that you created in the preceding step, and
C:\Users\Sampleuser\Desktop\DeploymentConfigTemplate.xml is an example of a path to the
configuration file that you created in step 1.
Invoke-WindowsFeatureBatchDeployment -computerNames $ServerNames ConfigurationFilepath C:\Users\Sampleuser\Desktop\DeploymentConfigTemplate.xml
5. When installation is finished, verify installation by opening the All Servers page in Server Manager,
selecting a server on which you installed roles and features, and viewing the Roles and Features tile on the
page for the selected server. You can also run the Get-WindowsFeature cmdlet targeted at a specific server (
Get-WindowsFeature -computerName <computer_name>) to view a list of roles and features that are installed
on the server.
Install .NET Framework 3.5 and other features on-demand
starting with Windows Server 2012 and Windows 8, the feature files for .NET Framework 3.5 (which includes .NET
Framework 2.0 and .NET Framework 3.0) are not available on the local computer by default. The files have been
removed. Files for features that have been removed in a Features on Demand configuration, along with feature
files for .NET Framework 3.5, are available through Windows Update. By default, if feature files are not available on
the destination server that is running Windows Server 2012 or later releases, the installation process searches for
the missing files by connecting to Windows Update. You can override the default behavior by configuring a Group
Policy setting or specifying an alternate source path during installation, whether you are installing by using the add
Roles and Features Wizard GUI or a command line.
You can install .NET Framework 3.5 by doing one of the following.
Use To install .NET Framework 3.5 by running the Install-WindowsFeature cmdlet to add the Source
parameter, and specify a source from which to get .NET Framework 3.5 feature files. If you do not add the
Source parameter, the installation process first determines if a path to feature files has been specified by
Group Policy settings, and if no such path is found, searches for missing feature files by using Windows
Update.
Use To install .NET Framework 3.5 by using the add Roles and Features Wizard to specify an alternate
source file location on the Confirm installation options page of the add Roles and Features Wizard.
Use To install .NET Framework 3.5 by using DISM to get files from Windows Update by default, or by
specifying a source path to installation media.
Configure alternate sources for feature files in Group Policy for .NET Framework 3.5 or other features, if feature
files are not found on the local computer.
IMPORTANT
When you are installing feature files from a remote source, the source path or file share must grant Read permissions either
to the Everyone group (not recommended for security reasons), or to the computer (local system) account of the
destination server; granting user account access is not sufficient.
Servers that are in workgroups cannot access external file shares, even if the computer account for the workgroup server has
Read permissions on the external share. Alternate source locations that work for workgroup servers include installation
media, Windows Update, and VHD or WIM files that are stored on the local workgroup server.
You can specify a WIM file as an alternate feature file source when you are installing roles, role services, and features on a
running, physical server. The source path for a WIM file should be in the following format, with WIM as a prefix, and the
index in which the feature files are located as a suffix: WIM:e:\sources\install.wim:4. However, you cannot use a WIM file
directly as a source for installing roles, role services, and features to an offline VHD; you must either mount the offline VHD
and point to its mount path for source files, or you must point to a folder that contains a copy of the contents of the WIM
file.
To install .NET Framework 3.5 by running the Install-WindowsFeature cmdlet
1. Do one of the following to open a Windows PowerShell session with elevated user rights.
NOTE
if you are installing roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
On a server that is running the Server Core installation option of Windows Server 2012 R2 or
Windows Server 2012 , type PowerShell into a command prompt, and then press Enter.
2. type the following command, and then press Enter. In the following example, the source files are located in
a side-by-side store (abbreviated to as SxS) in installation media on drive D.
Install-WindowsFeature NET-Framework-Core -Source D:\Sources\SxS
If you want the command to use Windows Update as a source for missing feature files, or if a default source
has already been configured by using Group Policy, you do not need to add the Source parameter unless
you want to specify a different source.
To install .NET Framework 3.5 by using the add Roles and Features Wizard
1. On the Manage menu in Server Manager, click add Roles and Features.
2. Select a destination server that is running Windows Server 2016.
3. On the select features page of the add Roles and Features Wizard, select .NET Framework 3.5.
4. If the local computer is allowed to do so by Group Policy settings, the installation process attempts to get
missing feature files by using Windows Update. Click Install; you do not need to go on to the next step.
if Group Policy settings do not allow this, or you want to use another source for the .NET Framework 3.5
feature files, on the Confirm installation selections page of the wizard, click Specify an alternate
source path.
5. Provide a path to a side-by-side store (referred to as SxS) in installation media, or to a WIM file. In the
following example, installation media is located on drive D.
D:\Sources\SxS\
To specify a WIM file, add a WIM: prefix, and add the index of the image to use in the WIM file as a suffix, as
shown in the following example.
WIM:\\server_name\share\install.wim:3
6. Click OK, and then click Install.
To install .NET Framework 3.5 by using DISM
1. Do one of the following to open a Windows PowerShell session with elevated user rights.
NOTE
if you are installing roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows Start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
On a server that is running the Server Core installation option, type PowerShell into a command
prompt, and then press Enter.
2. Run one of the following DISM commands.
if the computer has access to Windows Update, or a default source file location has already been
configured in Group Policy, run the following command.
DISM /online /Enable-Feature /Featurename:NetFx3 /All
if the computer has access to installation media, run a command similar to the following. In the
following example, the operating system installation media is located on drive D. The LimitAccess
parameter prevents the command from attempting to contact Windows Update or a server that is
running WSUS.
DISM /online /Enable-Feature /Featurename:NetFx3 /All /LimitAccess /Source:d:\sources\sxs
NOTE
The DISM command is case-sensitive.
Configure alternate sources for feature files in Group Policy
The Group Policy setting described in this section specifies authorized source locations for .NET Framework 3.5
files, and other feature files that have been removed as part of a Features on Demand configuration. The policy
setting Specify settings for optional component installation and component repair is located in the
computer Configuration\Administrative Templates\System folder in the Group Policy Management Console
or Local Group Policy editor.
NOTE
You must be a member of the Administrators group to change Group Policy settings on the local computer. If Group Policy
settings for the computer you want to manage are controlled at the domain level, you must be a member of the Domain
Administrators group to change Group Policy settings.
To c o n fi g u r e a d e fa u l t a l t e r n a t e so u r c e p a t h i n G r o u p P o l i c y
1. In Local Group Policy editor or Group Policy Management Console, open the following policy setting.
computer Configuration\Administrative Templates\System\Specify settings for optional
component installation and component repair
2. Sselect Enabled to enable the policy setting, if it is not already enabled.
3. In the Alternate source file path text box in the Options area, specify a fully qualified path to a shared
folder or a WIM file. To specify a WIM file as an alternate source file location, add the prefix WIM: to the
path, and add the index of the image to use in the WIM file as a suffix. The following are examples of values
that you can specify.
path to a shared folder: \\server_name\share\folder_name
path to a WIM file, in which 3 represents the index of the image in which the feature files are found:
WIM:\\server_name\share\install.wim:3
4. if you do not want computers that are controlled by this policy setting to search for missing feature files in
Windows Update, select Never attempt to download payload from Windows Update.
5. If the computers that are controlled by this policy setting typically receive updates through WSUS, but you
prefer to go through Windows Update and not WSUS to find missing feature files, select Contact Windows
Update directly to download repair content instead of Windows Server Update Services (WSUS).
6. Click OK when you are finished changing this policy setting, and then close the Group Policy editor.
See Also
Windows Server Installation Options
Microsoft .NET Framework 3.5 Deployment Considerations
How to Enable or Disable Windows Features
Configure Features on Demand in Windows Server
4/24/2017 • 6 min to read • Edit Online
Applies To: Windows Server 2016
This topic describes how to remove feature files in a Features on Demand configuration by using the UninstallWindowsFeature cmdlet.
Features on Demand is a feature, introduced in Windows 8 and Windows Server 2012 , that allows you to remove
role and feature files (sometimes called feature payload) from the operating system to conserve disk space, and
install roles and features from remote locations or installation media instead of from local computers. You can
remove feature files from running physical or virtual computers. You can also add feature files to or remove feature
files from Windows image (WIM) files or offline virtual hard disks (VHDs) to create a reproducible copy of Features
on Demand configurations.
In a Features on Demand configuration, when feature files are not available on a computer, if an installation
requires those feature files, Windows Server 2012 R2 or Windows Server 2012 can be directed to get the files from
a side-by-side feature store (a shared folder that contains feature files, and is available to the computer on the
network), from Windows Update, or from installation media. By default, when feature files are not available on the
target server, Features on Demand searches for missing feature files by performing the following tasks, in the order
shown.
1. Searching in a location that has been specified by users of the add Roles and Features Wizard or DISM
installation commands
2. Evaluating the configuration of the Group Policy setting, computer Configuration\Administrative
Templates\System\Specify settings for optional component installation and component repair
3. Searching Windows Update
You can override default Features on Demand behavior by doing any of the following.
Specifying an alternate source path as part of the
parameter
Install-WindowsFeature
cmdlet, by adding the
Source
Specifying an alternate source path on the Confirm installation options page while you are installing
features by using the add Roles and Features Wizard
Configuring the Group Policy setting, Specify settings for optional component installation and
component repair
This topic contains the following sections.
create a feature file or side-by-side store
Methods of removing feature files
remove feature files by using Uninstall-WindowsFeature
create a feature file or side-by-side store
This section describes how to set up a remote feature file shared folder (also called a side-by-side store) that stores
the files required to install roles, role services, and features on servers that run Windows Server 2012 R2 or
Windows Server 2012 . After you have set up a feature store, you can install roles, role services, and features on
servers that are running those operating systems, and specify the feature store as the location of installation source
files.
To create a feature file store
1. create a shared folder on a server on your network. For example, \\network\share\sxs.
2. verify that you have the correct permissions assigned to the feature store. The source path or file share must
grant Read permissions either to the Everyone group (not recommended for security reasons), or to the
computer accounts (DOMAIN\SERverNAME$) of servers on which you plan to install features by using this
feature store; granting user account access is not sufficient.
You can access file sharing and permissions settings by doing either of the following on the Windows
desktop.
Right-click the shared folder, click Properties, and then change allowed users and their access rights
to the folder on the Security tab.
Right-click the shared folder, point to Share with, and then click Specific people.
NOTE
Servers that are in workgroups cannot access external file shares, even if the computer account for the workgroup
server has Read permissions on the external share. Alternate source locations that work for workgroup servers
include installation media, Windows Update, and VHD or WIM files that are stored on the local workgroup server.
3. copy the Sources\SxS folder from your Windows Server installation media to the shared folder that you
created in step 1.
Methods of removing feature files
Two methods are available for removing feature files from Windows Server in a Features on Demand configuration.
The remove parameter of the Uninstall-WindowsFeature cmdlet lets you delete feature files from a server or
offline virtual hard disk (VHD) that is running Windows Server 2012 R2 or Windows Server 2012 . Valid
values for the remove parameter are the names of roles, role services, and features.
Deployment Image Servicing and Management (DISM) commands let you create custom WIM files that
conserve disk space by omitting feature files that are either not needed, or can be obtained from other,
remote sources. For more information about using DISM to prepare custom images, see How to Enable or
Disable Windows Features.
remove feature files by using Uninstall-WindowsFeature
You can use the Uninstall-WindowsFeature cmdlet both to uninstall roles, role services, and features from servers
and offline VHDs that are running Windows Server 2012 R2 or Windows Server 2012 , and to delete feature files.
You can both uninstall and delete the same roles, role services, and features in the same command if desired.
IMPORTANT
When you delete feature files for a role, role service, or feature, roles, role services, and features that depend upon the files
you are removing are also deleted. If you are deleting feature files for a role service or subfeature, and no other role services
or subfeatures for the parent role or feature remain installed, then files for the entire parent role or feature are deleted. To
view all feature files that would be deleted by the Uninstall-WindowsFeature -remove command, add the whatif
parameter to the command to run it and view results without actually deleting feature files.
To remove role and feature files by using Uninstall-WindowsFeature
1. Do one of the following to open a Windows PowerShell session with elevated user rights.
NOTE
if you are uninstalling roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
On a server that is running the Server Core installation option, type PowerShell into a command
prompt, and then press Enter.
2. type the following, and then press Enter.
Uninstall-WindowsFeature -Name <feature_name> -computerName <computer_name> -remove
Example: remote Desktop Licensing is the last remaining role service of remote Desktop Services that is
installed. The command uninstalls remote Desktop Licensing, and then deletes feature files for the entire
remote Desktop Services role from the specified server, contoso_1.
Uninstall-WindowsFeature -Name rdS-Licensing -computerName contoso_1 -remove
Example: In the following example, the command removes active directory Domain Services and Group
Policy Management from an offline VHD. The role and feature are first uninstalled, then their feature files
removed entirely from the offline VHD, Contoso.vhd.
NOTE
You must add the
8.1 or Windows 8.
computerName
parameter if you are running the cmdlet from a computer that is running Windows
if you enter the name of a VHD file from a network share, that share must grant Read and Write permissions to the
computer account of the server that you selected to mount the VHD. User-only account access is not sufficient. The
share can grant Read and Write permissions to the Everyone group to allow access to the VHD, but for security
reasons, this is not recommended.
Uninstall-WindowsFeature -Name AD-Domain-Services,GPMC -VHD C:\WS2012VHDs\Contoso.vhd -computerName
ContosoDC1
See Also
Install or Uninstall Roles, Role Services, or Features Windows Server Installation Options How to Enable or Disable
Windows Features Deployment Image Servicing and Management (DISM) Overview
View and Configure Performance, Event, and Service
Data
4/24/2017 • 15 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
This topic describes how to view and configure the event log entries, performance counters, and service alerts that
are displayed for local and remote servers in Server Manager.
Event, service, and performance log data is displayed in two places in the Server Manager console in Windows
Server.
On the dashboard, you can click the Events, Performance, and Services rows of thumbnails to configure
event, performance, and service log data that you want to see for roles, the entire Server Manager server
pool, user-created groups of servers, and the local server. Clicking the hypertext rows opens detail View
dialog boxes that let you specify the data about which you want to be alerted in the dashboard. After you
configure event, service, and performance log data that you want to be highlighted in the dashboard
thumbnails, log entries that match the criteria you have specified are listed at the bottom of the detail View
dialog boxes.
Events, Services, and Performance tiles are part of role and group home pages. Commands on the Tasks
menu of these tiles let you specify the data that you want collected from managed servers. The tiles include
filters and queries to further limit the log entries that are displayed in the tile, if desired.
This topic contains the following sections.
What are thumbnails?
View and configure events
View and configure performance counters
Manage services and configure service alerts
View and copy event or performance entries
What are thumbnails?
Thumbnails are displayed on the Server Manager dashboard for each role (a role's thumbnail reflects data
collected about all of the servers in the Server Manager pool that are running the role), for each server group, for
the All Servers group (all of the servers in the Server Manager pool), and for the local server. After Server
Manager gets data from managed servers, thumbnails are automatically created for roles that are running on
servers in the server pool.
if the Server Manager console is running on a client computer as part of Remote Server Administration Tools,
there is no Local Server thumbnail.
The thumbnail displays a quick view of the status and manageability of roles, servers, and server groups. The
thumbnail heading row changes color (and highlighted numbers are displayed in the left margin) when events,
performance counters, Best Practices Analyzer results, services, or general manageability issues meet criteria that
you configure in the detail View dialog boxes opened by clicking thumbnail rows. The following table describes
the data displayed in thumbnails.
THUMBNAIL ROW
DESCRIPTION
Manageability
The manageability of a server includes several measures:
whether the server is online or offline, whether it is accessible
and reporting data to Server Manager, whether the user who
is logged on to the local computer has adequate user rights
to access or manage the remote server, whether the remote
server is running all of the software that is required to
manage it remotely, or whether the server is configured in a
way that allows it to be queried and managed by using Server
Manager. The only manageability data that Server Manager
can collect from a server that is running Windows Server 2003
is whether the server is online or offline. For detailed
information about manageability status errors and how to
resolve them, see the Server Manager Troubleshooting Guide.
Events
You can configure the Events row of a thumbnail to display
alerts when events are logged that match severity levels,
sources, time periods, servers, or event IDs that you specify.
View details about events, and change the alerts you want to
see by clicking the Events row, and opening the Events detail
View dialog box for the role or server group.
Services
You can configure the Services row to display alerts when
services are found in a role or server group that match startup
types, service status, service names, and servers that you
specify in the Services detail View dialog box.
After a server has been added to the Server Manager server
pool, service alerts about the Shell Hardware Detection service
can be displayed if there are no users logged on to the
managed server. This occurs because the Shell Hardware
Detection service runs only when users are logged on to the
managed server, or connected to a remote Desktop session
on the managed server. To avoid seeing Shell Hardware
Detection service alerts for this case, click Services in the
thumbnails for server groups, including the All Servers
group. In the Services detail View dialog box, on the
Services drop-down list, clear the check box for Shell
Hardware Detection, and then click OK.
Performance
You can configure the Performance row to display alerts for
a role or server group when performance alerts occur that
match resource types, servers, or time periods that you
specify in the Performance detail View dialog box.
By default, performance counters are turned off. Managed
servers that are running operating systems newer than
Windows Server 2003, and for which performance counters
have not been started, typically show manageability status
errors of online - Performance counters not started in the
Servers tile of role or group pages. To turn performance
counters on for managed servers, on the All Servers page,
right-click entries in the Performance tile that show a
Counter Status value of Off, and then click start
Performance Counters. You can also start performance
counters by right-clicking entries for servers in the Servers
tile of role or group pages, and then clicking start
Performance Counters.
THUMBNAIL ROW
DESCRIPTION
BPA results
You can configure the BPA results row to display alerts for a
role or server group when BPA scan results are found that
match severity levels, servers, or BPA categories that you
specify in the BPA Results detail View dialog box.
View and configure events
In this section, learn how to configure what event log data is collected from servers in the Server Manager server
pool, and which events you want highlighted in thumbnails.
NOTE
The events about which you are alerted in thumbnails are a subset of the total events that you instruct Server Manager to
collect from managed servers. Although changing event criteria in the Configure Event Data dialog box in Events tiles can
change the numbers of alerts you see on the Server Manager dashboard, changing the event alert criteria in thumbnails has
no effect on the event log data that is collected from managed servers.
To configure the events collected from managed servers
1. In the Server Manager console, open any page except the dashboard. You can configure the events that you
want collected from managed servers in the Events tile on role, server group, or local server pages.
2. On the Tasks menu of the Events tile, click Configure Event Data.
3. select the event severity levels that you want to be collected from the servers in the selected group. By
default, Critical, Error, and Warning severity levels are selected.
4. Specify a time period during which the events occur. The default age for events is 24 hours.
5. select the event log files from which you want events to be collected. The defaults are Application, Setup,
and System.
6. To save your changes, click OK to close the Configure Event Data dialog box. Event data automatically
refreshes when your changes are saved.
To configure the events highlighted in thumbnails
1. if Server Manager is already open, go on to the next step. If Server Manager is not already open, open it by
doing one of the following.
On the Windows desktop, start Server Manager by clicking Server Manager in the Windows
taskbar.
On the Windows start screen, click the Server Manager tile.
2. On the dashboard page, in a thumbnail in the Roles and Server Groups tile, click the Events row.
3. In the Events detail View dialog box, add a severity level to the events that you want displayed. By default,
thumbnails only display alert highlighting for critical events. Note that the number of events displayed in
the detail View dialog box increases when you add a severity level about which you want to be alerted.
4. In the Event sources field, select the event sources about which you want to be alerted. The default is All.
5. if this thumbnail is for a role that is installed on multiple servers, or a group of multiple servers, you can
select the servers for which you want event alerts in the Servers drop-down list.
6. In the time period field, specify a time period up to 1440 minutes, 24 hours, or 1 day.
7. In the Event IDs field, type the event ID numbers of specific events about which you want to be alerted. You
can type a range of event IDs separated by a dash (-), and exclude event IDs from the range by typing the
dash before the event ID or range of event IDs that you want to exclude. For example, the value 1,3,5-99,-76
means that alerts are raised for event IDs 1 and 3, and all events with IDs between 5 and 99 except for event
ID 76.
8. As you change the criteria for which alerts are displayed, the number of event alerts that are displayed in
the results pane at the bottom of the dialog box might change. select entries in the list and click Hide Alerts
to prevent them from affecting the alert count that is displayed in the source thumbnail. Press and hold Ctrl
as you select alerts to select multiple alerts at one time. You can do this for alerts that match your event
alerting criteria, but that you do not need to see.
9. Click Show All to return hidden alerts to the list.
10. Click OK to save your changes, close the detail View dialog box, and view the event alert changes in the
source thumbnail.
View and configure performance log data
In this section, learn how to configure what performance log data is collected from servers in the Server Manager
server pool, and which performance counter alerts you want highlighted in thumbnails.
By default, performance counters are turned off. Managed servers that are running operating systems newer than
Windows Server 2003, and for which performance counters have not been started, typically show manageability
status errors of online - Performance counters not started in the Servers tile of role or group pages. To turn
performance counters on for managed servers, on the All Servers page, right-click entries in the Performance tile
that show a Counter Status value of Off, and then click start Performance Counters. You can also start
performance counters by right-clicking entries for servers in the Servers tile of role or group pages, and then
clicking start Performance Counters.
NOTE
The performance alerts you view in thumbnails are a subset of the total performance counter data that you instruct Server
Manager to collect from managed servers. Although changing performance alert criteria in the Configure Performance
Alerts dialog box in Performance tiles can change the numbers of alerts you see on the Server Manager dashboard,
changing the performance alert criteria in thumbnails has no effect on the performance log data that is collected from
managed servers.
Because of this, the maximum age of performance data that you can display in thumbnails cannot be greater than the
maximum graph display period that is configured in the Configure Performance Alerts dialog box. For example, if the
Graph display period value in Configure Performance Alerts is 1 day, the maximum value for the time period field in a
Performance detail View dialog box that you have opened from the Server Manager dashboard can be 1 day, 24 hours,
or 1,440 minutes.
To configure the performance log data collected from managed servers
1. In the Server Manager console, open any page except the dashboard. You can configure the performance
data that you want collected from managed servers in the Performance tile on role, server group, or local
server pages.
2. To collect performance log data from managed servers, performance counters must be turned on. If
performance counters are turned off, right-click an entry in the Performance tile list, and then click start
Performance Counters. Performance counter data collection can require some time, depending on the
number of servers from which data is collected, and available network bandwidth. View the status in the
Counter Status column.
3. On the Tasks menu of the Performance tile, click Configure Performance Alerts.
4. for the servers in the selected group, or that are running the selected role, specify at what percent of CPU
usage you want performance counter alerts collected by Server Manager. The default is 85%.
5. Specify the remaining available memory, in megabytes, that servers must have before you want
performance counter alerts collected. The default is 2 MB.
6. Specify a time period that is displayed by the graphs for the resources CPU Usage and Available Memory
in the Performance tile on the selected page. The default period is one day. Click Save.
Note that the number of performance alerts in the Performance tile, and the mapping of the alerts over
time as displayed by the graph, can change after you click Save.
NOTE
for virtual machines that have Dynamic Memory turned on, increasing the performance alerts threshold can result in
false positive alerts.
7. To refresh the list of performance alerts that are collected from your servers, on the Tasks menu, click
Refresh.
To configure the performance alerts highlighted in thumbnails
1. On the dashboard page, in a thumbnail in the Roles and Server Groups tile, click the Performance row.
2. In the Performance detail View dialog box, select or clear check boxes for resource performance
thresholds about which you want to be alerted in the Resource type field. Note that the number of
performance alerts displayed in the detail View dialog box can increase when you add a resource
performance threshold about which you want to be alerted.
3. if this thumbnail is for a role that is installed on multiple servers, or a group of multiple servers, you can
select the servers for which you want performance alerts in the Servers drop-down list.
4. In the time period field, specify a time period up to 1440 minutes, 24 hours, or 1 day.
5. As you change the criteria for which alerts are displayed, the number of alerts that are displayed in the
results pane at the bottom of the dialog box might change. Click Hide Alerts to hide all alerts older than the
current time, and prevent them from affecting the alert count that is displayed in the source thumbnail.
6. Click Show All to return hidden alerts to the list.
7. Click OK to save your changes, close the detail View dialog box, and view the performance alert changes in
the source thumbnail.
To view the properties of performance alerts
1. Do one of the following.
On the dashboard page, in a thumbnail in the Roles and Server Groups tile, click the Performance
row.
Open a role or group home page, and locate the Performance tile for the role or group.
2. Double-click a performance alert in the list to view its properties. Alternatively, you can right-click a
performance alert, and then click View Properties.
3. In the Performance Alert Properties dialog box, select log entries to view information about the processes
that are associated with the entry in the Processes area.
4. When you are finished viewing performance alert properties, close the dialog box.
Analyze performance data and solve problems
for more information about analyzing performance counter data that you view in Server Manager, and solving
performance problems on managed servers, see the following resources.
Analyzing performance data
Solving performance problems
for more information about advanced performance monitoring and analysis tools that are available for Windows
Server 2012 and later releases of Windows Server, including Server Performance Advisor 3.0, see Performance on
MSDN.
Manage services and configure service alerts
In this section, learn how to start, stop, restart, pause, or resume services that are displayed in the Services tile on
role and server group pages in Server Manager. You can also configure the services about which you are alerted in
thumbnails on the Server Manager dashboard.
NOTE
You cannot change the start type for services, service dependencies, recovery options, or other service properties in the
Services tile in Server Manager. To change service properties other than the service status, open the Services snap-in. A
shortcut to open the Services snap-in is available on the Tools menu in Server Manager.
To start, stop, restart, pause, or resume a service
1. In the Server Manager console, open any page except the dashboard (in other words, any role or group
home page).
2. In the Services tile for the role or group, right-click a service.
3. In the context menu, click the action that you want to perform on the service. If the service is stopped, the
only action you can perform is to start the service. Similarly, if the service is paused, the only action you can
perform is to resume the service.
4. Note that when you start, stop, restart, pause, or resume a service, the value of the Status column changes
for the service in the Services tile.
To configure service alerts highlighted in thumbnails
1. On the dashboard page, in a thumbnail in the Roles and Server Groups tile, click the Services row.
2. In the Services detail View dialog box, select the startup types for services about which you want to be
alerted. By default, Automatic (delayed start) and Automatic are selected.
3. select the service statuses about which you want to be alerted. By default, All is selected.
4. select services about which you want to be alerted. By default, All is selected.
5. select the servers associated with the role or group for which you want to receive alerts about services. By
default, All is selected.
6. As you change the criteria for which alerts are displayed, the number of alerts that are displayed in the
results pane at the bottom of the dialog box might change. Click Hide Alerts to hide all alerts older than the
current time, and prevent them from affecting the alert count that is displayed in the source thumbnail.
7. Click Show All to return hidden alerts to the list.
8. Click OK to save your changes, close the detail View dialog box, and view the service alert changes in the
source thumbnail.
View and copy event, service, or performance entries
You can copy event, service, or performance entry properties in both the detail View dialog boxes and the Events
and Performance tiles for a role or group. Right-click an event or performance entry, and then click copy.
The Events tile also lets you preview event properties in the bottom half of the tile by selecting an event in the list.
To copy the properties shown in the preview, right click the preview pane, and then click copy.
See Also
Server Manager
Filter, sort, and query Data in Server Manager Tiles
View Task details and Notifications
4/24/2017 • 3 min to read • Edit Online
Applies To: Windows Server 2016
In Server Manager in Windows Server 2012 R2 or Windows Server 2012, when you perform management tasks
such as adding roles and features, starting services, refreshing data that is displayed in the Server Manager console,
or creating a custom group of servers, a notification is displayed in the Notifications area of the Server Manager
console header. Notifications, and the Task details dialog box that you can open from the Notifications menu by
clicking the flag icon, display the status of user tasks or requests, show you if a task failed, and help you
troubleshoot problems by pointing to detailed error messages about task failures.
The Notifications area
The Notifications area in the Server Manager menu bar, marked by a flag icon, displays the results of tasks that
you start in Server Manager. Notifications inform you whether tasks that you started in Server Manager were
successful or failed. When notifications are available for you to view, the number of available notifications is
displayed next to the flag icon. If a task failed, could only be partially completed (for example, if it could not be
completed on all of the remote servers on which you wanted to perform the task), or completed with warnings, the
Notifications flag becomes red. Tasks for which notifications are displayed include the following.
Manually refreshing the data displayed in Server Manager (notifications are displayed for automatic
refreshes only if the refreshes fail)
starting or stopping services
Installing or uninstalling roles, role services, and features
starting a Best Practices Analyzer (BPA) scan
adding remote servers to manage (notifications are displayed for failures to contact or refresh the data
displayed for remote servers)
Items in the Notifications menu show a progress bar, a brief description of the task, the name of the target server
for the task (or one of the target servers, if multiple target servers were selected), a link to a related control or
dialog box if applicable, and a Tasks menu. The Tasks menu shows commands that apply to the active notification
(the notification over which your mouse cursor is hovered). For example, if you stop a service, you can click Restart
on the Tasks menu in the notification to restart the service.
Notifications are particularly useful for installing or uninstalling roles, role services, and features. For example, if
you start a feature installation on a remote server, you can close the add Roles and Features Wizard while the
installation is still in progress, but the active task remains in the Notifications list. The Notifications item shows a
progress bar for the installation, and lets you reopen the add Roles and Features Wizard, if needed, by clicking add
Roles and Features Wizard. The items in this list notify you if an installation failed, or if additional configuration
steps are required to finish deploying the feature.
Notifications also play an IMPORTANT part in troubleshooting problems with tasks or processes in Server
Manager. For more information about how to use messages in the Notifications area and Task details dialog box
to troubleshoot unsuccessful tasks or processes, see the Server Manager Troubleshooting Guide.
To delete a notification that you no longer want to see from the Notifications list, hover your mouse cursor over
the notification, and then click remove Task (X).
Viewing and troubleshooting tasks by using Task details
The Task details command at the bottom of the Notifications menu opens the Task details dialog box, which
provides full descriptions of task events (starting, stopping, warnings, successes, or failures). Like other list controls
in Server Manager, such as Events, Services, and Best Practices Analyzer tiles, you can filter and create queries
to run on the tasks that are displayed in the Task details dialog box. (for more information about filtering and
creating queries on list controls, see Filter, sort, and query Data in Server Manager Tiles.) In the top pane, you can
review notifications as they have been displayed in the Notifications menu, and see how many notifications have
been generated about the same task. selecting a notification in the top pane displays full details about the
notification in the bottom pane.
The bottom pane is particularly useful for troubleshooting failed tasks. If Server Manager cannot connect to or get
data for a server that is a member of the server pool, entries in this pane often contain detailed messages, including
the full text of underlying Windows remote Management (WinRM), networking, or security problems that prevent
Server Manager from communicating with a target server.
See Also
Filter, sort, and query Data in Server Manager Tiles Server Manager Troubleshooting Guide
Run Best Practices Analyzer Scans and Manage Scan
Results
4/24/2017 • 14 min to read • Edit Online
Applies To: Windows Server 2016
In Windows management, best practices are guidelines that are considered the ideal way, under typical
circumstances, to configure a server as defined by experts. For example, it is considered a best practice for most
server applications to keep open only those ports required for the applications to communicate with other
networked computers, and block unused ports. Although best practice violations, even crucial ones, are not
necessarily problematic, they indicate server configurations that can result in poor performance, poor reliability,
unexpected conflicts, increased security risks, or other potential problems.
Best Practices Analyzer (BPA) is a server management tool that is available in Windows Server 2012 R2, Windows
Server 2012, and Windows Server 2008 R2. BPA can help administrators reduce best practice violations by
scanning roles that are installed on managed servers that are running Windows Server 2012 or Windows Server
2008 R2, and reporting best practice violations to the administrator.
You can run Best Practices Analyzer (BPA) scans either from Server Manager, by using the BPA GUI, or by using
cmdlets in Windows PowerShell. starting with Windows Server 2012, you can scan one role or multiple roles at
one time, on multiple servers, whether you use the Best Practices Analyzer tile in the Server Manager console or
Windows PowerShell cmdlets to run scans. You can also instruct BPA to exclude or ignore scan results that you do
not want to see.
This topic contains the following sections.
find BPA
How BPA works
Performing Best Practices Analyzer scans on roles
Manage scan results
find BPA
You can find the Best Practices Analyzer tile on role and server group pages of Server Manager in Windows Server
2012 R2 and Windows Server 2012, or you can open a Windows PowerShell session with elevated user rights to
run Best Practices Analyzer cmdlets.
How BPA works
BPA works by measuring a role's compliance with best practice rules in eight different categories of effectiveness,
trustworthiness, and reliability. Results of measurements can be any of the three severity levels described in the
following table.
SEVERITY LEVEL
DESCRIPTION
Error
Error results are returned when a role does not satisfy the
conditions of a best practice rule, and functionality problems
can be expected.
SEVERITY LEVEL
DESCRIPTION
Information
Information results are returned when a role satisfies the
conditions of a best practice rule.
Warning
Warning results are returned if the results of noncompliance
can cause problems if changes are not made. The application
might be compliant as operating currently, but may not satisfy
the conditions of a rule if changes are not made to its
configuration or policy settings. For example, a scan of remote
Desktop Services might show a warning result if a license
server is unavailable to the role, because even if no remote
connections are active at the time of the scan, not having the
license server prevents new remote connections from
obtaining valid client access licenses.
Rule categories
The following table describes the best practice rules categories against which roles are measured during a Best
Practices Analyzer scan.
CATEGORY NAME
DESCRIPTION
Security
Security rules are applied to measure a role's relative risk for
exposure to threats such as unauthorized or malicious users,
or loss or theft of confidential or proprietary data.
Performance
Performance rules are applied to measure a role's ability to
process requests and perform its prescribed duties in the
enterprise within expected periods of time given the role's
workload.
Configuration
Configuration rules are applied to identify role settings that
might require modification for the role to perform optimally.
Configuration rules can help prevent conflicts in settings that
can result in error messages or prevent the role from
performing its prescribed duties in an enterprise.
Policy
Policy rules are applied to identify Group Policy or Windows
registry settings that might require modification for a role to
operate optimally and securely.
Operation
Operation rules are applied to identify possible failures of a
role to perform prescribed tasks in the enterprise.
Predeployment
Predeployment rules are applied before an installed role is
deployed in the enterprise. They let administrators evaluate,
before the role is used in production, whether best practices
were satisfied.
Postdeployment
Postdeployment rules are applied after all required services
have started for a role, and after the role is running in the
enterprise.
CATEGORY NAME
DESCRIPTION
Prerequisites
Prerequisite rules explain configuration settings, policy
settings, and features that are required for a role before BPA
can apply specific rules from other categories. A prerequisite in
scan results indicates that an incorrect setting, a missing
program, an incorrectly enabled or disabled policy, a registry
key setting, or other configuration has prevented BPA from
applying one or more rules during a scan. A prerequisite result
does not imply compliance or noncompliance. It means that a
rule could not be applied, and is not therefore part of the scan
results.
Performing Best Practices Analyzer scans on roles
You can perform BPA scans on roles by using either the BPA GUI in Server Manager, or by using Windows
PowerShell cmdlets.
In Windows Server 2012 R2 and Windows Server 2012 , some roles prompt you to specify additional parameters,
such as the names of specific servers or shares that are running parts of the role, or the IDs of submodels, before
starting a BPA scan. For BPA scans on models that require you to specify additional parameters, use the BPA
cmdlets; the BPA GUI cannot accept additional parameters such as submodel IDs. For example, the submodel ID
FSRM represents the File Services BPA submodel for File Server Resource Manager, a role service of File and
Storage Services. To run a scan only on the File Server Resource Manager role service, run a BPA scan by using
Windows PowerShell cmdlets, and add the parameter SubmodelId to your cmdlet.
Although you cannot pass additional parameters to a scan that you start in the BPA GUI, the BPA tile in Server
Manager displays results for the most recent BPA scan, regardless of how the scan was started.
Scanning roles by using the BPA GUI
Scanning roles by using Windows PowerShell cmdlets
Scanning roles by using the BPA GUI
Follow these steps to scan one or more roles in the BPA GUI.
To sc a n r o l e s b y u si n g t h e B P A G U I
1. Do one of the following to open Server Manager if it is not already open.
On the Windows taskbar, click the Server Manager button.
On the start screen, click the Server Manager tile.
2. In the navigation pane, open a role or group page.
Running BPA scans from a role or group page scans all roles that are installed on servers in that group.
3. On the Tasks menu of the Best Practices Analyzer tile, click start BPA Scan.
4. Depending on the number of rules that are evaluated for the role or group you selected, the BPA scan can
require a few minutes to finish.
Scanning roles by using Windows PowerShell cmdlets
Use the following procedures to scan one or more roles by using Windows PowerShell cmdlets.
NOTE
The procedures in this section do not show all BPA cmdlets and parameters. For more information about BPA operations in
Windows PowerShell, in your Windows PowerShell session, enter Get-helpBPACmdlet-full, where BPACmdlet can be one of
the following values. You can also find BPA cmdlet help topics on the Windows Server TechCenter.
Get-BPAmodel
Invoke-BPAmodel
Get-BPAResult
Set-BPAResult
To scan a single role by using Windows PowerShell cmdlets
1. Do one of the following to run Windows PowerShell with elevated user rights.
To run Windows PowerShell as an administrator from the start screen, right-click the Windows
PowerShell tile in the Apps results, and then on the app bar, click Run as administrator.
To run Windows PowerShell as an administrator from the desktop, right-click the Windows
PowerShell shortcut in the taskbar, and then click Run as Administrator.
2. starting in Windows PowerShell 3.0, cmdlet modules are automatically imported into your Windows
PowerShell session the first time a cmdlet from the module is used. There is no need to import or load the
BPA cmdlet module.
3. find the model IDs of all roles for which BPA scans can be performed by entering the Get-Bpamodel
cmdlet, as shown in the following example.
Get-Bpamodel
4. In the results of step 3, locate the model IDs of the roles on which you want to run a BPA scan.
5. Enter one of the following commands to start the BPA scan for a specific role. For multiple roles, separate
model IDs with commas.
Invoke-BPAmodel -modelId <modelID_from_Step3>
Invoke-BPAmodel <modelID_from_Step3>
Example: Invoke-BPAmodel
-modelId Microsoft/Windows/DNSServer,Microsoft/Windows/FileServices
NOTE
The model ID includes the entire path that is shown in the Id column; for example, Microsoft/Windows/Hyper-V.
You can also start a scan on a specific role from the results of step 3 by piping the results of the
Get-BPAmodel cmdlet into the Invoke-BPAmodel cmdlet as shown in the following example.
Get-BPAmodel <model_ID> | Invoke-BPAmodel
Running this cmdlet without specifying a model ID pipes all models that are returned by the Get-BPAmodel
cmdlet into the Invoke-BPAmodel cmdlet, starting scans on all models that are available on servers that have
been added to the Server Manager server pool.
To scan all roles by using Windows PowerShell cmdlets
1. Open a Windows PowerShell session with elevated user rights, if one is not already open. See the preceding
procedure for instructions.
2. Pipe all roles for which BPA scans can be performed into the
Invoke-BPAmodel
cmdlet to start scans.
Get-BPAmodel | Invoke-BPAmodel
3. When the scan is complete, Windows PowerShell returns results similar to the following, for each role that
was scanned.
modelId
SubmodelId
Success
Scantime
ScantimeUtcOffset
detail
:
:
:
:
:
:
Microsoft/Windows/FileServices
True
1/01/2012 12:18:40 PM
-08:00:00
{server_name1, server_name2}
Manage scan results
After a BPA scan is completed in the GUI, you can view scan results in the BPA tile. When you select a result in the
tile, a preview pane in the tile displays result properties, including an indication of whether the role is compliant
with the associated best practice. If a result is not compliant, and you want to know how to resolve the problems
described in the result properties, hyperlinks in error and warning result properties open detailed resolution help
topics on the Windows Server TechCenter.
NOTE
BPA scan results are not automatically saved or archived. Running a new scan on a model or submodel overwrites the results
of the last scan. To save BPA scan results for archiving, printing, or sending to others, see To view BPA results from Windows
PowerShell sessions in different formats in this section.
Exclude and include BPA results
if you do not need to see some BPA results, such as results that occur frequently in your BPA scans but require no
resolution, you can exclude the results, by using either the BPA GUI or BPA cmdlets in Windows PowerShell. Results
can be included again at any time.
NOTE
When you exclude results, they are also excluded from view on managed servers. Other administrators cannot see excluded
results on managed servers. To exclude results from view in a local Server Manager console only, create a custom query
instead of using the Exclude Result command.
Exclude scan results
The Exclude setting is persistent; results that you exclude remain excluded in future scans of the same model on
the same computer, unless they are included again.
You can exclude scan results by using the Set-BPAResult cmdlet with the Exclude parameter. As in the Best
Practices Analyzer tile in Server Manager, you can exclude individual result objects, or you can also exclude a set of
results whose fields (category, title, and severity, for example) are equal to or contain specified values. For example,
you can exclude all Performance results from a set of scan results for a model.
NOTE
You must run at least one BPA scan on a model before you can use procedures in this section.
To e x c l u d e s c a n re s u l t s b y u s i n g t h e G U I
1. Open a role or server group page in Server Manager.
2. In the Best Practices Analyzer tile for the role or server group, right-click a result in the list, and then click
Exclude Result.
The result is no longer displayed in the list of results.
3. To view excluded results in the GUI, run the built-in Excluded results query. Click Saved Search Queries,
and then click Excluded results.
After running the Excluded results query, note that the tile subheading text, a description of the results that
are displayed in the list, changes to Excluded results. Only excluded results are displayed in the list.
To e x c l u d e s c a n re s u l t s b y u s i n g W i n d o w s P o w e r Sh e l l c md l e t s
1. Open a Windows PowerShell session with elevated user rights.
2. Exclude specific results from a model scan by running the following command.
Get-BPAResult -modelId <model ID> | Where { $_.<Field Name> -eq "Value"} | Set-BPAResult -Exclude $true
The preceding command retrieves BPA scan result items for the model ID that is represented by model ID.
The second section of the command filters the results of the Get-BPAResult cmdlet to retrieve only those
scan results for which the value for a result field, represented by Field Name, matches the text in quotation
marks.
The final section of the command, following the second pipe character, excludes the results that are filtered
by the previous section of the cmdlet.
Example:
Get-BPAResult -Microsoft/Windows/FileServices | Where { $_.Severity -eq "Information"} | Set-BPAResult Exclude $true
Include scan results
When you want to view scan results that were excluded, you can include those scan results. The Include setting is
persistent; included results remain included in future scans of the same model on the same computer.
To i n c l u d e sc a n r e su l t s b y u si n g t h e G U I
1. Open a role or server group page in Server Manager.
2. In the Best Practices Analyzer tile for the role or server group, right-click an excluded result in the Excluded
results query list, and then click Include Result.
The result is no longer displayed in the list of excluded results. Clear the query by clicking Clear All to view
the included result in the list of all included results.
To i n c l u d e sc a n r e su l t s b y u si n g W i n d o w s P o w e r Sh e l l c m d l e t s
1. Open a Windows PowerShell session with elevated user rights.
2. Include specific results from a model scan by typing the following command, and then pressing Enter.
Get-BPAResult -modelId <model Id> | Where { $_.<Field Name> -eq "Value" } | Set-BPAResult -Exclude $false
The preceding command retrieves BPA scan result items for the model represented by model Id.
The second part of the command, after the first pipe character ( | ) filters the results of the Get-BPAResult
cmdlet to retrieve only those scan results for which the value of the result field, represented by Field Name,
matches the text in quotation marks.
The final part of the command, after the second pipe character, includes results that are filtered by the
second part of the cmdlet, by setting the value of the -Exclude parameter to false.
Example:
Get-BPAResult -Microsoft/Windows/FileServices | Where { $_.Severity -eq "Information"} | Set-BPAResult Exclude $false
View and export BPA scan results in Windows PowerShell
To view and manage scan results by using Windows PowerShell cmdlets, see the following procedures. Before you
can use any of the following procedures, run at least one BPA scan on at least one model or submodel.
To view results of the most recent scan of a role by using Windows PowerShell
1. Open a Windows PowerShell session with elevated user rights.
2. Get the results of the most recent scan for a specified model ID. type the following, in which the model is
represented by model ID, and then press Enter. You can get results for multiple model IDs by separating the
model IDs with commas.
Get-BPAResult <model ID>
Example:
Get-BPAResult Microsoft/Windows/DNSServer,Microsoft/Windows/FileServices
if you scanned a submodel of a model, such as a role service, get the results for only that submodel by
including the submodel ID in the cmdlet.
Example:
Get-BPAResult Microsoft/Windows/FileServices -SubmodelID FSRM
To view or save BPA results from Windows PowerShell sessions in different formats
In Windows PowerShell, each BPA result resembles the following.
ResultNumber
ResultId
modelId
SubmodelId
RuleId
computerName
Context
Source
Severity
Category
Title
Problem
Impact
Resolution
compliance
compliance with
help
Excluded
: 14
: 1557706192
: Microsoft/Windows/FileServices
: FSRM
: 16
: server_name1, server_name2
: FileServices
: server_name1
: Information
: Configuration
: Access Denied remediation requires remote management be enabled on this server
:
:
:
: The File Server Best Practices Analyzer scan has determined that you are in
this best practice.
:
: False
Do one of the following.
To format BPA results in a table, run the following cmdlet, adding the result properties that you want
to see from the preceding example.
Get-BPAResult model ID | format-Table -Property <property1,property2,property3...>
Example:
Get-BPAResult Microsoft/Windows/FileServices | format-Table -Property
modelId,SubmodelId,computerName,Source,Severity,Category,Title,Problem,Impact,Resolution,compliance,help
To format BPA results in a GUI-based grid viewer, with a text-string filter, and column headings that
can be clicked to sort results, run the following cmdlet.
Get-BPAResult <model ID> | OGV
To export BPA results to an HTML file that can be archived or sent to email recipients, run the
following cmdlet, where path represents the path and file name to which you want to save the HTML
results.
Get-BPAResult <model ID> | convertTo-Html | Set-Content <path>
Example:
Get-BPAResult Microsoft/Windows/FileServices | convertTo-Html | Set-Content
C:\BPAResults\FileServices.htm
To export BPA results to a comma-separated values (CSV) text file, run the following cmdlet, where
path represents the path and text file name to which you want to save the CSV results. CSV results
can be imported into Microsoft Excel, or other programs that display data in spreadsheets or grids.
Get-BPAResult <model ID> | Export-CSV <path>
Example: Get-BPAResult
Microsoft/Windows/FileServices | Export-CSV C:\BPAResults\FileServices.txt
See Also
Best Practices Analyzer resolution content on the Windows Server TechCenter Filter, sort, and query Data in Server
Manager Tiles Manage Multiple, remote Servers with Server Manager
create and Manage Server Groups
4/24/2017 • 2 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
This topic describes how to create custom, user-defined groups of servers in Server Manager in Windows Server.
Server groups
Servers that you add to the server pool are displayed on the All Servers page in Server Manager. You can create
custom groups of servers that you have added. Server groups allow you to view and manage a smaller subset of
your server pool as a logical unit; for example, you can create a group called Accounting Servers for all servers in
your organization's Accounting department, or a group called Chicago for all servers that are geographically
located in Chicago. After you create a server group, the group's home page in Server Manager displays
information about events, services, performance counters, Best Practices Analyzer results, and installed roles and
features for the group as a whole.
Servers can be a member of more than one group.
To create a new server group
1. On the Manage menu, click create Server Group.
2. In the Server group name text box, type a friendly name for your server group, such as Accounting
Servers.
3. add servers to the selected list from the server pool, or add other servers to the group by using the active
directory, DNS, or import tabs. For more information about how to use these tabs, see add Servers to
Server Manager in this guide.
4. When you have finished adding servers to the group, click OK. The new group is displayed in the Server
Manager navigation pane under the All Servers group.
To edit an existing server group
1. Do one of the following.
In the Server Manager navigation pane, right-click a server group, and then click edit Server Group.
On the home page for the server group, open the Tasks menu on the Servers tile, and then click edit
Server Group.
2. change the group name, or add or remove servers from the group.
NOTE
removing servers from a server group does not remove servers from Server Manager. Servers that you remove from
a group remain in the All Servers group, in the server pool.
3. When you are finished with changes to the group, click OK.
To delete an existing server group
1. Do one of the following.
In the Server Manager navigation pane, right-click a server group, and then click delete Server
Group.
On the home page for the server group, open the Tasks menu on the Servers tile, and then click
delete Server Group.
2. When you are prompted to make sure you want to delete the server group, click Yes.
NOTE
deleting a server group does not remove servers from Server Manager. Servers that were in a deleted group remain
in the All Servers group, in the server pool.
3. When you are finished with changes to the group, click OK.
See Also
add Servers to Server Manager Server Manager
Filter, sort, and query Data in Server Manager Tiles
4/24/2017 • 3 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
In Windows Server, tiles in Server Manager let you filter and sort data, and create and save custom queries. You
can sort, use keyword filters, and run queries on list entries in the Events, Performance, Best Practices Analyzer,
Services, and Roles and Features tiles on server role or group pages in Server Manager.
This topic contains the following sections.
Filter list entries in tiles
sort list entries in tiles
create and run custom queries on tile data
Filter list entries in tiles
The Filter text box is a quick way of reducing the list of entries that are displayed in a tile to only those entries that
contain a specified text string.
To apply a filter to the list of entries in a tile
1. Open a role or server group page in Server Manager.
2. In the Filter text box of an Events, Performance, Best Practices Analyzer, Services, or Roles and Features tile,
type a string on which you want to filter.
for example, if you want to see only events with an event ID of 1014, type 1014 in the Filter text box. All
collected events that contain the string 1014 in at least one field are returned as results.
3. Note that the filter changes the description text under the tile title. Instead of All results, it says Filtered
results.
4. To clear the filter, delete the string in the filter box, or click X.
sort list entries in tiles
sort list entries in Server Manager tiles by clicking column headings. Clicking a column heading the first time sorts
column values in ascending alphanumeric order (arrow pointing up); clicking again sorts column values in
descending alphanumeric order (arrow pointing down).
create and run custom queries on tile data
You can create custom queries in the Events, Performance, Best Practices Analyzer, Services, or Roles and Features
tiles in Server Manager. By default, the area of the tile toolbar in which you select criteria to build a custom query
is hidden; click expand (chevron button at right edge of tile toolbar) to display query criteria.
To create a custom query for tile data
1. Open a role or server group page in Server Manager.
2. In an Events, Performance, Best Practices Analyzer, Services, or Roles and Features tile, expand the querybuilding area by clicking expand.
3. Click add criteria to open a list of attributes (or fields) that apply to the entries in the tile.
4. select criteria to add. When you are finished, click add. Criteria that you selected are added to the querybuilding area.
5. Click the hypertext operator to select an operator. For numerical or date and time criteria, for example, the
default is less than or equal to.
6. Specify acceptable values for the criteria. For example, if you selected date and time, provide a date in the
format m/d/yyyy.
7. Repeat these steps from step 3 forward to add more criteria to your query.
You can add duplicates of criteria that are already in your query, but the duplicates are added to the query
with the or operator.
for example, to query for event IDs 1003 or 1014, you would first add the ID criteria to your query, make
the value of ID equal to 1003, and then add a second ID criteria to your query, making the value of the
second ID equal to 1014. The resulting query is and ID equals 1003 or ID equals 1014.
8. When you are finished adding criteria and specifying operators and values, click Save to save the query.
9. Enter a friendly name for the query. For example, the query created in the preceding step can be named
Licensing events.
10. When you are finished viewing query results, click Clear All to clear all filters and queries, and display all
entries in the list.
11. To run a saved query, click Saved Search Queries, and click the name of the saved query that you want to
run.
12. To delete a saved query, click Saved Search Queries, and then click X by the name of the saved query that
you want to delete.
See Also
Server Manager
View and Configure Performance, Event, and Service Data
Keyboard Shortcuts for Server Manager
4/24/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Because Server Manager was fully redesigned starting in Windows Server 2012, keyboard shortcuts that worked in
the Server Manager console in Windows Server 2008 R2 or Windows Server 2008 are not necessarily the same
commands. This topic describes the new keyboard shortcuts and access keys for Server Manager in Windows
Server 2012 and newer releases of Windows Server.
Commands that do not have their own keyboard shortcuts or access keys are accessible by pressing the Tab key,
and tabbing through their control group when it is in focus.
Access keys
active Control Area in Server Manager
Welcome Tile
CONTROL GROUP
ACCESS KEY
Welcome tile - Quick start tab
Alt+Q
Welcome tile - What's New tab
Alt+W
Welcome tile - Learn more tab
Alt+L
Welcome tile Hide command
Alt+D
Role and Group Thumbnails
CONTROL GROUP
ACCESS KEY
Roles and Server Groups tile
Alt+R
Console Header Controls
CONTROL GROUP
ACCESS KEY
Back button in the address bar
Alt+Left arrow or Backspace
forward button in the address bar
Alt+right arrow
Refresh
F5
Notifications area, open Task details dialog box
Alt+N
Manage menu
Alt+M
View menu
Alt+V
CONTROL GROUP
ACCESS KEY
help menu
Alt+H
Open Server Manager help
F1
Zoom in
Ctrl+Plus (+)
Zoom out
Ctrl+Minus (-)
Display console at 100%
Ctrl+0
Tiles on Role, Group or Local Server Pages
CONTROL GROUP
ACCESS KEY
Local Server page Properties tile
Alt+P
Role, group, or local server page page Events tile
Alt+E
Role, group, or local server page Services tile
Alt+R
Role, group, or local server page Best Practices Analyzer (BPA)
tile
Alt+B
Role, group, or local server page Performance tile
Alt+O
Role, group, or local server page Roles and Features tile
Alt+A
All Servers page Servers tile
Alt+A
Navigating within Local Server Properties tile
CONTROL GROUP
ACCESS KEY
computer name
Alt+C
Last installed updates
Alt+L
Domain or Workgroup
Alt+D
Windows Update
Alt+W
Last checked for updates
Alt+S
remote management
Alt+R
Windows Firewall
Alt+F
remote Desktop
Alt+K
Windows Error Reporting
Alt+G
CONTROL GROUP
ACCESS KEY
NIC Teaming
Alt+T
Customer Experience Improvement Program
Alt+X
Wired Ethernet connection
Alt+O
IE Enhanced Security Configuration
Alt+Y
time zone
Alt+Z
Navigating within Events, Services, BPA, Performance, and Roles and Features tiles
CONTROL GROUP
ACCESS KEY
Tasks menu
Alt+T
Filter control
Alt+F
query control
Alt+Q
Save queries
Alt+S
Get Started with Software Inventory Logging
4/24/2017 • 2 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Software Inventory Logging collects Microsoft software inventory data on a per server basis. Before using Software
Inventory Logging with Windows Server 2012 R2, make sure that Windows Update KB 3000850 and KB 3060681
are installed on each system that will be inventoried. No Windows Update is required for Windows Server 2016.
Also, if you want to use SIL’s capability to forward data to an aggregation server, be sure you have SSL certificates
valid for your network.
Feature description
Software Inventory Logging in Windows Server is a feature with a simple set of PowerShell cmdlets that help
server administrators retrieve a list of the Microsoft software that is installed on their servers. It also provides the
capability to collect and forward this data periodically over the network to a target web server, using the HTTPS
protocol, for aggregation. Managing the feature, primarily for hourly collection and forwarding, is also done with
PowerShell commands.
NOTE
An aggregation server running a web service can be separately configured. Learn more about Software Inventory Logging
Aggregator.
IMPORTANT
None of the data collected by Software Inventory Logging is sent to Microsoft as part of the feature’s functionality.
Practical applications
Software Inventory Logging is intended to reduce the operational costs of retrieving accurate information
regarding the Microsoft software deployed locally on a server, but especially across many servers in an IT
environment (assuming it is deployed and enabled across the IT environment). The ability to forward this data to an
aggregation server (if set up separately by an IT administrator), allows the data to be collected in one place by a
uniform, automatic process. While this can also be achieved by querying the interfaces directly, Software Inventory
Logging, by employing a forwarding (over the network) architecture initiated by each server, can overcome
machine discovery challenges typical for many software inventory and asset management scenarios. SSL is used to
secure data forwarded over HTTPS to an administrator’s aggregation server. Having the data in one place (on one
server) makes the data easier to analyze, manipulate and report on. It is important to note that none of this data is
sent to Microsoft as part of the feature functionality. Software Inventory Logging data and functionality is meant for
the sole use of the server software’s licensed owner and administrators.
Software Inventory Logging can assist server administrators in performing the following tasks:
Retrieving software and server inventory information from Windows Servers, remotely and on-demand.
Aggregating software and server inventory information for a wide variety of software asset management
scenarios by enabling each server’s Software Inventory Logging feature and choosing a web server target
URI, and certificate thumbprint for authentication.
See Also
Software Inventory Logging Aggregator
Manage Software Inventory Logging
Software Inventory Logging Cmdlets in Windows PowerShell
Microsoft Assessment and Planning Toolkit Volume Activation Management Tool
Manage Software Inventory Logging
4/24/2017 • 12 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2
This document describes how to manage Software Inventory Logging, a feature that helps datacenter
administrators easily log Microsoft software asset management data for their deployments over time. This
document describes how to manage Software Inventory Logging. Before using Software Inventory Logging with
Windows Server 2012 R2, make sure that Windows Update KB 3000850 and KB 3060681 are installed on each
system needing to be inventoried. No Wndows Updates are required for Windows Server 2016. This feature runs
locally on each server to be inventoried. It does not collect data from remote servers.
The Software Inventory Logging feature can also be added to two versions of Windows Server prior to Windows
Server 2012 R2. You can install the following updates to add Software Inventory Logging functionality to Windows
Server 2012 and Windows Server 2008 R2 SP1:
Windows Server 2012 (Standard or Datacenter Edition)
NOTE
Make sure you have WMF 4.0 installed before applying the update package below.
WMF 4.0 Update package for Windows Server 2012: KB 3119938
Windows Server 2008 R2 SP1
NOTE
Make sure you have WMF 4.0 installed before applying the update package below.
Requires .NET Framework 4.5
WMF 4.0 Update package for Windows Server 2008 R2: KB 3109118
There are two primary methods for inventorying using this feature:
1. Starting the SIL logging functionality to collect from SIL data sources and forward the payload over the
network to a specified target (URI) on an hourly basis.
2. Manually querying the SIL data using PowerShell or WMI at any interval.
Starting SIL logging involves some planning and foresight, but has significant advantages compared to manually
querying the data. Using SIL logging has the following three primary advantages for data center administrators:
An ongoing history (log) can be collected over time, allowing flexible and comprehensive reports from a
single source.
Computer discovery challenges typical of many inventory tools can be overcome.
Trust boundary challenges and the need for elevated user privileges typical of many inventory tools can be
overcome while maintaining a level of security, since the data is encrypted over HTTPS with SSL.
Software Inventory Logging is installed by default, but logging is not started by default. All configuration of
Software Inventory Logging is done with PowerShell cmdlets. There are only a few configuration options for
Software Inventory Logging. This document describes these options and their intended purpose, as well as the
cmdlets used for data collection (if using the second method above).
In this document
The configuration options covered in this document include:
Starting and Stopping Software Inventory Logging
Software Inventory Logging over time
Displaying Software Inventory Logging data
Deleting data logged by Software Inventory Logging
[Backing up and restoring data logged by Software Inventory Logging]manage-software-inventorylogging.md#BKMK_Step5)
Reading data logged and published by Software Inventory Logging
Software Inventory Logging Security
Working with date and time settings in Windows Server Software Inventory Logging
Enabling and Configuring Software Inventory Logging in a Mounted Virtual Hard Disk
Overview of Using Software Inventory Logging in Windows Server 2012 R2 without KB 3000850
Using Software Inventory Logging in a Windows Server 2012 R2 Hyper-V environment without KB 3000850
NOTE
This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. For
more information, see Using Cmdlets.
Starting and Stopping Software Inventory Logging
Software Inventory Logging daily collection and forward over the network must be enabled on a computer running
Windows Server 2012 R2 to log software inventory.
NOTE
You can use the Get-SilLogging PowerShell cmdlet to retrieve information about the Software Inventory Logging Service,
including whether it is running or stopped.
To Start Software Inventory Logging
1. Sign in to the server with an account that has local administrator privileges.
2. Open PowerShell as an Administrator.
3. At the PowerShell prompt, type Start-SilLogging
NOTE
It is possible to set the target without setting a certificate thumbprint, but if you do, the forwards will fail and data will be
stored locally for up to a default value of 30 days (after which it will be deleted). Once a valid certificate hash is set for the
target (and corresponding valid certificate installed in the LocalMachine/Personal store), data stored locally will be forwarded
to the target as long as the target is configured to accept this data with this certificate (see Software Inventory Logging
Aggregator for more information).
To Stop Software Inventory Logging
1. Sign in to the server with an account that has local administrator privileges.
2. Open PowerShell as an Administrator.
3. At the PowerShell prompt, type Stop-SilLogging
Configuring Software Inventory Logging
There are three steps to configuring Software Inventory Logging to forward data to an aggregation server over
time:
1. Use Set-SilLogging –TargetUri to specify the web address of your aggregation server (must start with
“https://”).
2. Use Set-SilLogging –CertificateThumbprint to specify the thumbprint hash of your valid SSL certificate
to be used to authenticate the data transmissions to your aggregation server (your aggregation server will
need to be configured to accept hash).
3. Install a valid SSL certificate (for your network) in the Local Machine/Personal Store (or
/LocalMachine/MY) of the local server to forward data from.
It is best to complete these steps before using Start-SilLogging. If you want to use them after using StartSilLogging, you simply need to stop and start SIL again. Or, you can use the Publish-SilData Cmdlet to ensure the
aggregation server has a full complement of the data for this server.
For a comprehensive guide to setting up the SIL framework as a whole, see Software Inventory Logging
Aggregator. In particular, if Publish-SilData produces an error, or SIL Logging fails otherwise, see the
troubleshooting section .
Software Inventory Logging over time
If Software Inventory Logging was started by an administrator, hourly collection and forwarding of the data to the
aggregation server (target URI) commences. The first forward will be a complete data set of the same data that GetSilData retrieves and displays on the console at a point in time. Thereafter, at each interval, SIL will make a check of
the data and only forward a small identifying acknowledgment to the target aggregation server if there is no
change in the data since the last collection. If any value has changed, SIL will again send a complete data set.
IMPORTANT
If at any interval the target URI is unreachable or the data transfer over the network is unsuccessful for any reason, data
collected will be stored locally for up to a default value of 30 days (after which time it will be deleted). On the next successful
forward of data to the target aggregation server, all data stored locally will be forwarded and local cached data will be
deleted.
Displaying Software Inventory Logging data
In addition to the PowerShell cmdlets described in the previous section, six additional cmdlets can be used to
collect Software Inventory Logging data:
Get-SilComputer: Displays the point in time values for specific server and operating system-related data, as
well as the FQDN or hostname of the physical host, if available.
Get-SilComputerIdentity (KB 3000850): Displays identifiers used by SIL for individual servers.
Get-SilData: Displays a point in time collection of all Software Inventory Logging data.
Get-SilSoftware: Displays the point in time identity of all software installed on the computer.
Get-SilUalAccess: Displays the total number of unique client device requests and client user requests of the
server from two days prior.
Get-SilWindowsUpdate: Displays the point in time list of all Windows updates installed on the computer.
A typical use case scenario for Software Inventory Logging cmdlets would be for an administrator to query
Software Inventory Logging for a point in time collection of all Software Inventory Logging data using GetSilSoftware.
Output Example
PS C:\> Get-SilData
ID
UUID
VMGUID
Name
HypervisorHostName
:
:
:
:
:
961FF8A1-8549-4BEC-8DF6-3B3E32C26FFA
B49ACB4C-7D9C-4806-9917-AE750BB3DA84
E84CCCBD-0D0F-486B-A424-9780C7CF92E4
Server01Guest.Test.Contoso.com
Server01.Test.Contoso.com
ID
Name
InstallDate
Publisher
Version
:
:
:
:
:
{F0C3E5D1-1ADE-321E-8167-68EF0DE699A5}
Microsoft Visual C++ 2010 x86 Redistributable - 10.0.40219
12/5/2013
Microsoft Corporation
10.0.40219
ID
Name
InstallDate
Publisher
Version
:
:
:
:
:
{89F4137D-6C26-4A84-BDB8-2E5A4BB71E00}
Microsoft Silverlight
3/20/2014
Microsoft Corporation
5.1.30214.0
ChassisSerialNumber
CollectedDateTime
Model
Name
NumberOfCores
NumberOfLogicalProcessors
NumberOfProcessors
OSName
OSSku
OSSuite
OSSuiteMask
OSVersion
ProcessorFamily
ProcessorManufacturer
ProcessorName
SystemManufacturer
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
4452-0564-0284-2290-0113-6804-05
10/27/2014 4:01:33 PM
Virtual Machine
Server01Guest.Test.Contoso.com
1
1
1
Microsoft Windows Server 2012 R2 Datacenter
8
400
400
6.3.9600
179
GenuineIntel
Intel(R) Xeon(R) CPU
E5440 @ 2.83GHz
Microsoft Corporation
NOTE
Output from this cmdlet is the same as all other Get-Sil cmdlets for this feature combined, but is provided to the console
asynchronously so the order of the objects may not always be the same.
It is not necessary to have Software Inventory Logging started to use the Get-Sil cmdlets.
Deleting data logged by Software Inventory Logging
Software Inventory Logging is not intended to be a mission critical component. Its design is intended to impact
local system operations as little as possible while maintaining a high level of reliability. This also allows the
administrator to manually delete Software Inventory Logging database and supporting files (every file in
\Windows\System32\LogFiles\SIL directory) to meet operational needs.
To delete data logged by Software Inventory Logging
1. In PowerShell, stop Software Inventory Logging with the Stop-SilLogging command.
2. Open Windows Explorer.
3. Go to \Windows\System32\Logfiles\SIL\
4. Delete all files in the folder.
Backing up and restoring data logged by Software Inventory Logging
Software Inventory Logging will temporarily store hourly collections of data if forwards over the network are
failing. The log files are stored in the \Windows\System32\LogFiles\SIL\ directory. Backups of this Software
Inventory Logging data can be made with your regularly scheduled server backups.
IMPORTANT
If for any reason a repair installation or upgrade of the operating system is necessary, any log files stored locally will be lost. If
this data is critical for operations, it is recommended to be backed up prior to new operating system installation. After repair
or upgrade, simply restore to the same location.
NOTE
If for any reason managing the retention duration of data logged locally by SIL becomes important, this can be configured by
changing the registry value here: \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\SoftwareInventoryLogging. The
default is ‘30’ for 30 days.
Reading data logged and published by Software Inventory Logging
Data logged by SIL, but stored locally (if the forward to the target URI fails), or data that is successfully forwarded
to the target aggregation server, is stored in a binary file (for each day’s data). To display this data in PowerShell,
use the Import-BinaryMiLog cmdlet.
Software Inventory Logging Security
Administrative privileges on the local server are required to successfully retrieve data from Software Inventory
Logging WMI and PowerShell APIs.
To successfully leverage the full capability of the Software Inventory Logging feature to forward data to an
aggregation point continually over time (at hourly intervals), an administrator needs to employ client certificates to
ensure secure SSL sessions for transfer of data over HTTPS. A basic overview of HTTPS authentication can be found
here: HTTPS authentication.
Any data stored locally on a Windows Server (only occurs if the feature is started but the target is unreachable for
any reason) is only accessible with administrative privileges on the local server.
Working with date and time settings in Windows Server 2012 R2
Software Inventory Logging
When using Set-SilLogging -TimeOfDay to set the time SIL logging runs, you must specify a date and time.
The calendar date will be set and logging will not occur until the date is reached, in local system time.
When using Get-SilSoftware, or Get-SilWindowsUpdate, “InstallDate” will always show 12:00:00AM, a
meaningless value.
When using Get-SilUalAccess, “SampleDate” will always show 11:59:00PM, a meaningless value. Date is the
pertinent data for these cmdlet queries.
Enabling and Configuring Software Inventory Logging in a Mounted
Virtual Hard Disk
Software Inventory Logging also supports configuration and enablement on offline virtual machines. The practical
uses for this are intended to cover both ‘gold image’ setup for wide deployment across data centers, as well as
configuring end user images going from a premises to a cloud deployment.
To support these uses, Software Inventory Logging has registry entries associated with each configurable option.
These registry values can be found under
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\SoftwareInventoryLogging.
Function
Value Name
Data
Corresponding Cmdlet
(available only in the
running OS)
Start/Stop Feature
CollectionState
1 or 0
Start-SilLogging, StopSilLogging
Specifies target aggregation
point on the network
TargetUri
string
Set-SilLogging -TargetURI
Specifies Certificate
Thumbprint or Hash of the
certificate used for SSL
authentication for the target
web server
CertificateThumbprint
string
Set-SilLogging CertificateThumbprint
Specifies the date and time
that the feature should start
(if value set is in the future
according to local system
time)
CollectionTime
Default: 2000-0101T03:00:00
Set-SilLogging -TimeOfDay
To modify these values on an offline VHD (VM OS not running), a VHD must be first mounted and then the
following commands can be used to make changes:
Reg load
Reg delete
Reg add
Reg unload
Software Inventory Logging will check these values when the OS starts, and execute accordingly.
Overview of Using Software Inventory Logging in Windows Server
2012 R2 without KB 3000850
The following changes to Software Inventory Logging capability and default settings were made with KB 3000850:
The default interval for collection and forward over the network when SIL logging is started changed from
daily to hourly (at random within each hour).
The default data payload was reduced to only include objects from Get-SilComputer, GetSilComputerIdentity, and Get-SilSoftware.
Guest to host channel communication in Hyper-V environments was removed.
Using Software Inventory Logging in a Windows Server 2012 R2
Hyper-V environment without KB 3000850
NOTE
This functionality is removed with the installation of the KB 3000850 update.
When using Software Inventory Logging on a Windows Server 2012 R2 Hyper-V host, it is possible to retrieve SIL
data from Windows Server 2012 R2 guests that are running locally, if SIL logging has been started in the guest(s).
However, this is only possible when using the Get-SilData and Publish-SilData Powershell cmdlets, and only
possible with WIndows Server 2012 R2 in both host and guest. The purpose of this capability is to allow data
center administrators that provide guest VMs to tenants, or other entities of a large corporation, to capture
software inventory data at the hypervisor host and subsequently forward all of this data to an aggregator (or target
URI).
Below are two examples of what the output on the PowerShell console would look like (much abbreviated) on a
Windows Server 2012 R2 Hyper-V host running one Windows Server 2012 R2 guest VM with SIL logging started.
You will notice the first example, which uses Get-SilData alone, will output all data from the host as expected. Also
included is all SIL data from the guest, but in a collapsed format. To expand and view this data from the guest,
simply cut and paste the snippet used in the second example below. SIL data objects from the guest will always
have the VM GUID associated within the object.
NOTE
Since SIL data is output on the console, when using the Get-SilData cmdlet, in data streams, objects will not always be output
in a predictive order. In the two examples below, the text has been color coded (blue for physical host data and green for
virtual guest data) only as an illustrative tool for this document.
Output Example 1
Output Example 2 (w/ Expand-SilData function)
See Also
Get Started with Software Inventory Logging
Software Inventory Logging Aggregator
Software Inventory Logging Cmdlets in Windows PowerShell
Import-BinaryMiLog
Export-BinaryMiLog
Software Inventory Logging Aggregator
4/24/2017 • 32 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2
What is Software Inventory Logging Aggregator?
Software Inventory Logging Aggregator (SILA) receives, aggregates, and produces basic reports of the number
and types of Microsoft enterprise software installed on Windows Servers in a data center.
SILA is software that you install on Windows Server, but is not included in the Windows Server installation. To
install the software, first download it for free from the Windows Download Center: Software Inventory Logging
Aggregator 1.0 for Windows Server
The Software Inventory Logging framework is intended to reduce the operational costs of inventorying Microsoft
software deployed across many servers in an IT environment. This framework consists of two components, this SIL
Aggregator, and the Windows Server feature, introduced in Windows Server 2012 R2, Software Inventory Logging
(SIL). This Software Inventory Logging Aggregator 1.0 will install on one server and receive inventory data from
any Windows Server configured to forward data to it via SIL. The design allows data center administrators to
enable SIL in master Windows Server images intended for wide distribution across their environment. This
software package is the target point and intended for customers to install on their premises for easy logging of
inventory data over time. This software also allows for periodic creation of basic inventory reports in Microsoft
Excel. Software Inventory Logging Aggregator 1.0 reports include counts of installations of Windows Server,
System Center, and SQL Server.
IMPORTANT
No Data is sent to Microsoft with the use of this software.
Data SIL Collects Over Time
Once deployed correctly, the following data can be viewed at the SIL Aggregator:
Unique Windows Server installs in your data center
FQDN
Identifying GUIDs
Number of physical processors and cores
Number of virtual processors (if a VM)
Model and Type of physical processors
If hyper threading is enabled on physical processors or not
Chassis serial number
High-water mark count, and identity, of simultaneously running Windows Server VMs (if a host running a
hypervisor) on each host, over time
High-water mark count, and host name, of simultaneously running managed (System Center agent present)
Windows Server VMs on each host, over time
Name of System Center agents installed on VMs counted in managed high-water mark
Count and location of SQL Server installations over time (only SKUs and editions that require a license)
Lists of software installed in Add\/Remove Programs
Who will use SIL?
IT Pros, or data center administrators, looking for a low cost method of collecting valuable software
inventory data, automatically, over time.
CIOs and Finance Controllers, who need to report usage of Microsoft enterprise software in their
organizations’ IT deployments.
Getting Started
Prerequisites
Software Inventory Logging Aggregator (SIL Aggregator) on a minimum of one server for aggregation and
reports, either in a VM or on physical hardware):
Windows Server 2016
Windows Server 2012 R2 (Standard or Datacenter Edition)
The IIS server role, with .Net Framework 4.5, WCF Services, and HTTP Activation, all in the same selection
tree in Add Roles and Features Wizard.
SQL Server 2012 Sp2 Standard Edition or SQL Server 2014 Standard Edition
64 bit Microsoft Excel 2013 (optional for installation but needed for creating reports)
Optional: VMware PowerCLI 5.5.0.5836 (needed in VMware environments)
Software Inventory Logging (SIL) exists in Windows Server versions with the following updates installed:
Windows Server 2012 R2 (Standard or Datacenter Edition)
Windows Server 2012 R2 update KB3000850 (November, 2014)
Windows Server 2012 R2 update KB3060681 (June, 2015)(May appear as an optional update on
Windows Update)
Security and Account Types
Certificate requirement
SIL and the SIL Aggregator rely on SSL certificates for authenticated communication. The common
implementation of this will be to install SIL Aggregator with one certificate (server name and certificate name
match) for hosting the web service that receives inventory data. Then, Windows Servers to be inventoried using
the SIL feature will use a different client certificate, to push data to the SIL Aggregator. A PowerShell cmdlet (SetSilAggregator, more details below) needs to be used to add certificate thumbprints to the SIL Aggregator’s list of
approved certificates from which the Aggregator will accept associated data. The SIL Aggregator proceeds with
processing and insertion into its database after authentication of each payload of data with a certificate. See the
SIL Aggregator Cmdlets Detail section for more specific details on how this works.
Polling Account Setup
When adding credentials to the SIL Aggregator to enable polling operations, you should use a least privileged
account approach. Also, as a security best practice, you shouldn’t use the same credentials for all, or many, hosts in
a data center or other IT deployment.
On a Windows Server host that you want to set up for polling by the SIL Aggregator, and to avoid using a user in
the administrators group, follow these steps to give just enough access to a user account:
To se t u p a p o l l i n g a c c o u n t
1. On the Windows Server Hyper-V host you want to poll from your SIL Aggregator, create a local user
account using Computer Management in Windows (be sure to uncheck the box that forces a password
change at first logon).
2. Add this user to the Remote Management Users group.
3. Add this user to the Hyper-V Administrators group.
4. Open WMIMgmt.msc with Start->Run.
5. Click More Actions in the Actions section and select Properties.
6. Click Security.
7. Select cimv2 namespace in the Namespace treeview.
8. Click Security (button) .
9. Add the Remote Management Users group in the format machinename\group name
10. Click OK.
11. Back in the Security for root\cimv2 window, select the Remote Management Users.
12. In the permissions section at the bottom, ensure that the Remote Enable is checked.
13. Click Apply and then click OK.
14. Click OK in the Properties window.
Installing SIL Aggregator
There are some things you need to make sure of before installing SIL Aggregator on a Windows Server:
You have a valid SSL certificate that you want to use to host this software’s web service.
Certificate should be in .pfx format
The Windows Server name and the certificate name should match.
SQL Server Standard Edition is installed, or is installed on a remote server you intend to be used with
this software.
SIL Aggregator works with both SQL Server 2012 sp2 and SQL Server 2014. There is nothing out of
the ordinary needed when making selections during SQL Server installation.
The account used to install SIL Aggregator must be a sysadmin role on SQL in order to be able to
create the database during install.
The account used to install SIL Aggregator should be added as an administrator on SQL Analysis
Services before SIL Aggregator is installed.
Once installed, the SQL Server Agent should be configured to run automatically.
The IIS server role is added with .Net Framework 4.5, WCF Services, and HTTP Activation, all in the same
selection tree in Add Roles and Features Wizard.
You are logged on to the server with an account that has administrative privileges on the server.
You are logged on to the server with an account that has sysadmin privileges on the SQL Server, if
Windows Authentication is desired
OR
If SQL Authentication is desired, you have the password for an account that has SQL administrative
privileges.
To i n st a l l So ft w a r e I n v e n t o r y L o g g i n g A g g r e g a t o r
1. Double-click Setup.exe to start the installation.
2. Click Next on the welcome window.
3. If you accept the EULA, check the box accepting the agreement and then click Next.
4. In Choose Features, select Install Software Inventory Logging Aggregator and Reporting Module,
and then click Next.
For more information on installing the reporting module only, see
Aggregator Cmdlet Details section.
Publish-SilReport
under the SIL
5. After all prerequisites are verified, click Next.
6. In Choose an Account Type, select either local user or gMSA, depending on your preference.
Choosing the local user account option will create a local user with an auto generated strong password.
This account will be used for all SIL Aggregator services and task operations on the local server. Using
Group Managed Service Accounts (gMSA) is recommended if the Aggregator is part of an Active Directory
domain (Windows Server 2012 and above). For more information on gMSA, see: Group Managed Service
Accounts Overview
The gMSA account option must be used if you plan to run the SQL Server database on a separate
server from the SIL Aggregator.
Don’t forget to reboot the server after adding the computer account to the gMSA enabled security
group in Active Directory.
7. In Choose a SQL Server, enter the SQL Server where your SQL instance is installed, or localhost, if it is
installed on the local server.
Only one SIL Aggregator per SQL instance is supported.
8. Select the authentication type and click Verify SQL.
9. Click Next, and then in Internet Information Services Server Details, select a port number or keep the
default.
10. Browse for the .pfx file location, type the password for the .pfx file, and then click Next.
11. The final screen will show installation progress. Once completed successfully, click Finish.
Uninstalling SIL Aggregator
To u n i n st a l l So ft w a r e I n v e n t o r y L o g g i n g A g g r e g a t o r
1. Open PowerShell as an administrator and then type
Aggregator has stopped.
Stop-SilAggregator
. When the prompt returns, SIL
By design, SIL Aggregator will process files after 20 minutes or 100 files are received. In high scale
environments this scenario will never occur, but at low scale, some files may remain to be processed before
the aggregator can be stopped. Use the –Force parameter if keeping these files and data is unnecessary.
2. Go to Control Panel, click Programs and Features, click Uninstall Programs, click Software Inventory
Logging Aggregator, and then click Uninstall.
Software Inventory Logging Aggregator will open a window to prompt you to choose between deleting all
data in the database, or keeping all data in the database. The default selection is to keep (if a reinstall is
desired, you can attach to the existing database to pick up where the Aggregator left off).
3. Select either Keep or Delete, and then click Next.
4. After the progress bar completes, click Finish.
Start using SIL and the SIL Aggregator
Introduction to SIL Aggregator PowerShell cmdlets
The following commands can be run from the Windows PowerShell console as an administrator.
WINDOWS POWERSHELL CMDLET
FUNCTION
Start-SilAggregator
Starts all Software Inventory Logging Aggregator services and
tasks. This is required for the Aggregator to receive data over
HTTPS from servers with SIL Logging started.
Stop-SilAggregator
Stops all Software Inventory Logging Aggregator services and
tasks. If tasks or services are in the middle of operations, there
could be a delay to the completion of this command.
Set-SilAggregator
Allows the administrator to make configuration changes to
Software Inventory Logging Aggregator.
Add-SilVmHost
Used to add specific host names, or an array of host names,
to be polled on a regular interval (default is one hour
intervals).
Remove-SilVmHost
Used to remove specific host names, or an array of host
names, to be polled on a regular interval.
Get-SilVMHost
Used to retrieve the list of physical hosts Software Inventory
Logging Aggregator is configured to poll for ongoing VM
running state data.
Get-SILAggregatorData
Used to retrieve data from the database to the PowerShell
console.
Publish-SilReport
Use to create reports from the database of Software
Inventory Logging data. Note: Cube processing on the
Aggregator occurs once a day. So data captured at the
Aggregator will not appear in reports until the following day.
Suggested Order to Start
Once you have Software Inventory Logging Aggregator installed on your server, open PowerShell as an
administrator.
On your SIL Aggregator:
Run
Start-SilAggregator
This is required for your Aggregator to actively receive data being forwarded to it over HTTPS from
your servers you have (or will) set up to be inventoried. Note that even if you have enabled your
servers to forward to this Aggregator first, it is ok, as they will cache their data payloads locally for
up to 30 days. Once the Aggregator, their “targeturi” is up and running, all cached data will be
forwarded at once to the Aggregator and all data will be processed.
Run
Add-SilVMHost
Example:
add-silvmhost –vmhostname contoso1 –hostcredential get-credential
In this example, contoso1 is the network name (or IP address) of the physical host server that
you want your Aggregator to poll for regular updates as to which VMs are running on it in
order to track this data over time. Get-Credential will prompt the logged on user to enter an
account to be used to poll this host from that point forward. Running the same command, on
the same host, will allow you to update the account used at any time. Beware of account
password changes and expirations over time. If credentials change or expire, polling on the
host will fail.
By default, polling will commence hourly, starting one hour after Start-SilAggregator is run,
or one hour after a host is newly added to the polling list. The polling interval can be changed
by using the Set-SilAggregator cmdlet .
This cmdlet will auto detect from a preset list of options (see SIL Aggregator Cmdlets Detail
section), which HostType and HyperVisorType is correct for the host you are adding. If it is
unable to recognize these or the credentials provided are incorrect, a prompt will be
displayed. If you accept with a Y entry, the host will be added, listed as Unknown, but it will
not be polled.
Run
Set-SilAggregator –AddCertificateThumbprint
“your client certificate’s thumbprint”
This is required to receive data over HTTPS from Windows Servers with SIL Logging enabled. The
thumbprint will be added to the list of thumbprints that the SIL Aggregator will accept data from. The
SIL Aggregator is designed to accept valid enterprise client authentication certificates. The certificate
used will need to be installed in the \localmachine\MY (Local Computer -> Personal) store on
the server forwarding the data.
On your Windows Servers to be inventoried, open PowerShell as an administrator and run these
commands:
Run
Set-SilLogging –TargetUri “https://contososilaggregator” –CertificateThumbprint “your client
certificate’s thumbprint”
This will tell SIL in Windows Server where to send inventory data and which certificate to use
for authentication.
IMPORTANT
Make sure “https://’ is in the TargetUri value.
The enterprise client certificate with this thumbprint needs to be installed in
\localmachine\MY or use certmgr.msc to install the certificate in Local Computer ->
Personal store.
IMPORTANT
If these values are not correct, or if the certificate is not installed in the correct store (or is invalid),
forwards to the target will fail when SIL Logging is started. Data will be cached locally for up to 30
days.
Run
Start-SilLogging
This starts SIL Logging. Each hour, at random intervals within the hour, SIL will forward its inventory
data to the Aggregator specified with the –targeturi parameter. The first forward will be a complete
set of data. Each subsequent forward will be more of a “heartbeat” with just identifying data that
nothing has changed. If there is any change to the data set, another complete set of data will be
forwarded.
Run
Publish-SilData
The first time SIL is enabled for logging, this step is optional.
This is a manual, one-time forward of a complete set of data.
If SIL Logging has been started for some time and a new SIL Aggregator is designated with
Set-SilLogging , then it is required to run this cmdlet, one time only, to send a complete set of
data to the new Aggregator.
Once you have followed these steps to add physical hosts running virtual Windows Server machines, AND you
have enabled Software Inventory Logging (or SIL Logging) inside those Windows Servers, you can run
Publish-SilReport –OpenReport at any time on the SIL Aggregator (requires Excel 2013). Note however, that the
SQL Server Analysis Services cube processes once a day, so data is not available in reports on the same day.
Architectural Overview
SIL works in both push and pull modes and consists of two components working in parallel: The Software
Inventory Logging (SIL) feature in Windows Server, and the Software Inventory Logging Aggregator (SILA)
downloadable MSI. The servers to be inventoried push software inventory data over HTTPS, using SIL, to the SIL
Aggregator (every hour at random points within each hour). The Aggregator in turn, polls, or queries, the physical
hypervisor hosts to pull hardware inventory data each hour. Both push and pull need to be configured properly to
enable full functionality of SIL. These can be configured in any order. However, cube processing on the Aggregator
occurs once a day, so data captured at the aggregator, via either push or pull, will not appear in reports until the
following day.
IMPORTANT
No data is sent to Microsoft with the use of this software.
Enable SIL on multiple servers
There are several ways to enable SIL in a distributed server infrastructure, such as in a private cloud of virtual
machines. Following is an example of one way to set up Windows Server images to automatically send inventory
data to a SIL Aggregator when they start up on the network for the first time.
Run the following cmdlets in the PowerShell console as an administrator on each running VM or physical
computer/device that has Windows Server installed (see the Prerequisites section), :
You will need a valid client SSL certificate in .pfx format to use these steps. The thumbprint of this certificate will
need to be added to your SIL Aggregator using the Set-SILAggregator –AddCertificateThumbprint cmdlet. This
client certificate does not need to match the name of your SIL Aggregator.
$secpasswd = ConvertTo-SecureString " " -AsPlainText –Force
$mycreds = New-Object System.Management.Automation.PSCredential (" ", $secpasswd)
$driveLetters = ([int][char]'C')..([int][char]'Z') | % {[char]$_}
$occupiedDriveLetters = Get-Volume | % DriveLetter
$availableDriveLetters = $driveLetters | ? {$occupiedDriveLetters -notcontains $_}
$firstAvailableDriveLetter = $availableDriveLetters[0]
New-PSDrive -Name $firstAvailableDriveLetter -PSProvider filesystem -root
which holds your pfx certificate file>
Copy-Item ${firstAvailableDriveLetter}:\
<\server\path to share
-credential $mycreds
c:<location of your choice>
Remove-PSDrive –Name $firstAvailableDriveLetter
$mypwd = ConvertTo-SecureString -String " " -Force –AsPlainText
Import-PfxCertificate -FilePath c:\
cert:\localMachine\my -Password $mypwd
Set-sillogging –targeturi “https://
–certificatethumbprint
NOTE
Use the Certificate thumbprint from your client pfx file and added to your SIL Aggregator using the Set-SilAggregator `AddCertificateThumbprint cmdlet.
Start-sillogging
Whenever a SIL Aggregator cannot be reached, SIL inventory data will cache locally on Windows Servers for up to
30 days. Once a successful push is made to the Aggregator, all cached data is forwarded.
Add Publish-SilData to the above list if pushing SIL data to a new SIL Aggregator after successful pushes to an
old aggregator (this will send a complete complement of SIL data, which the new aggregator will need for this
machine).
Software Inventory Logging Aggregator Reports
Cube Processing
On a Software Inventory Logging Aggregator, the SQL Server Analysis Services cube will be processed once a day
at 3:00:00 AM local system time. Reports will reflect all data up until that time, but nothing after that time on the
same day.
High-Water Mark
A fundamental aspect of Software Inventory Logging Aggregator reports is the capture of what is commonly
referred to as a “high-water mark” of simultaneously running Windows Servers. This applies to Windows Server
and System Center counts in these reports. For Windows Server, each physical host has a point in time (regardless
of the OS type on the host), over the course of a month, when the most Windows Server VMs are running
simultaneously. This is the high-water mark for the month. Additionally, for System Center, there is a point in time
in the month when the most managed Windows Servers are simultaneously running per physical host (a
managed server is identified when one or more System Center agents are present). Only the most recent highwater mark for any physical host will be shown in the report. No data after the high-water mark will be shown.
and it can be assumed that the number of Windows Server VMs (WS tabs), or managed Windows Server VMs (SC
tabs), has fallen below the high-water mark after that point. This manner of tracking and representing usage is
intended to help with capacity planning as well as aligning with license models for these products.
On SQL related tabs in the report, SQL Server installs are counted cumulatively; not by hig-water mark. Totals are
a running count of SQL Server installs.
NOTE
Use of Software Inventory Logging does not replace the obligation to accurately report usage of Microsoft software under
applicable license terms.
Poll Date Time
When using Software Inventory Logging Aggregator, it is important to understand that aggregation for highwater mark counts is poll driven. In other words, a high-water mark can only be captured by a poll of the
underlying physical host. Thus high-water mark counts are directly associated with a corresponding “Poll Date
Time.” While poll interval is adjustable, the fidelity of high-water marks captured will be impacted if a higher
interval value is used. The higher the interval, the less representative the data will be of actual usage.
Reports Are Month by Month
All reports, even yearly reports, are represented as month by month reports. High-water marks, totals, as well as
machine data, are reset at the beginning of each calendar month.
Report data impacted by the switch to a new month includes:
All high-water marks for all hosts are reset at the start of a new month.
If the Aggregator receives at least one full payload from a VM (over HTTPS), but stops receiving heartbeats,
all polls of the underlying host within that month will assume the association between host, VM, and VM
data as that VM is running or stopped throughout the month. At the start of the new month, this association
is cleared until either a full payload or heartbeat is received from that VM.
Additional Notes on Report Behavior
Summary tabs are meant to be quick reference lists of inventory. Hosts and their VMs are listed in the same
column.
Ignore all values that are grey or dim. These are artifacts of the report creation from the SSAS cube.
If a VM is listed with “Unknown OS,” it means that the Aggregator has not received a full data payload from
that VM via SIL over HTTPS.
VMs listed under “Unknown Host” are Windows Server VMs successfully forwarding inventory data over
HTTPS to the Aggregator, but the Aggregator is not actively or successfully polling the underlying host for
that VM. Counts will always be zero for these entries since the underlying host is unknown. Use the
Add-SilVMHost cmdlet, with correct credentials, to add the host (or all hosts) to SIL Aggregator for polling.
Once polled successfully, the VM data and the host data will be associated on reports moving forward.
All dates and times are local to the SIL Aggregator system time and locale. This includes inventory data
received over HTTPS from SIL enabled systems. When these files are processed (no more than 20 minutes
after receiving) the data is inserted into the database with the local system time.
“SIL Aggregator” will be denoted on any server machine that has Software Inventory Logging Aggregator
installed.
If a physical host changes either number of processors or amount of physical memory, a new row will
appear in the report along with the old row. Polling updates will cease on the old row and proceed on the
new row as if it is a newly added host.
On Summary and Detail tabs, the total listed in columns for Simultaneously Running Windows Servers or
managed Windows Servers indicate a total of all the high-water marks for all hosts below. These include
Windows Servers that are not hypervisor hosts and have no VMs running, as well as servers that may have
VMs running but they are “Unknown,” as no data is being received from within the VM from SIL via HTTPS.
These are totaled for convenience.
In the SQL Server section of the Dashboard tab, total SQL Server installation count is a summary of all the
edition totals on the Dashboard. This can lead to a discrepancy between the total seen on the SQL Detail
tab in cases where multiple editions of SQL are installed on a single server. The Dashboard would count
these separately on each server, the Detail tab does not. Multiple SQL editions installed on one Windows
Server is always counted as a count of one, per licensing terms.
In the Windows Server section of the Dashboard tab, rows for Other Hypervisor Hosts and Total
Hypervisor Hosts include physical Windows Server hosts that may or may NOT be running Hyper-V.
Column Descriptions
Following are descriptions of each column on the Windows Server Detail tab of the Excel based report SIL
Aggregator creates. Other data tabs are either the same or a subset of these columns. The one exception would be
the “Install Count” on the SQL Server tabs (see High-Water Mark section).
COLUMN HEADER
DESCRIPTION
Calendar Month
Data in reports is grouped by month, most recent first. Data
within the month is not listed in a specific order.
COLUMN HEADER
DESCRIPTION
Host Name
Network name, or FQDN, of the physical host the SIL
Aggregator is successfully polling.
Use the Get-SilVMHost cmdlet to find hosts that have been
added but are not, or no longer, being polled successfully. The
last successful poll will be displayed.
Host Type
Operating System manufacturer on the physical host.
Hypervisor Type
Hypervisor manufacturer on the physical host.
Processor Manufacturer
Processor manufacturer of the processors on the physical
host.
Processor Model
Processor model of the processors on the physical host.
Is Hyper Threading Enabled?
Displays as either True or False depending on if hyper
threading is enabled on the processors of the physical host.
VM Name
The network name, or FQDN, of the Windows Server virtual
machine. If the Aggregator has not received data from this
machine over HTTPS, the friendly name of the VM in the
hypervisor is listed.
Simultaneously Running Windows Server VMs by host
Count of simultaneously running Windows Server VMs on the
host. The highest number in the month for that host is the
high-water mark count listed and captured at that point in
time.
See High-Water Mark section of this documentation.
Physical hosts with Windows Server installed, or with
Windows Server installed and no known Windows Server VMs
running, will always have a count of one. If at least one known
Windows Server VM is running on the host, and Windows
Server is running on the host itself, the host OS is not part of
the count.
Physical Processor Count
Number of physical processors installed on the physical host.
Physical Core Count
Number of physical processor cores installed on the physical
host.
Virtual Processor Count
Number of virtual processors that Windows recognizes within
the VM. This value only comes from data forwarded over
HTTPS using SIL in a Windows Server.
Poll Date Time
Date and time of the latest high-water mark point of
Windows Server VMs simultaneously running on that physical
host.
See Poll Date Time section of this documentation.
VM Last Seen Date Time
Date and time when the Aggregator last received data
inventory over HTTPS from this Windows Server VM.
COLUMN HEADER
DESCRIPTION
Host Last Seen Date Time
Date and time when the Aggregator last received data
inventory over HTTPS from this Windows Server physical host.
It is supported to have physical hosts, running Windows
Server and HyperV, to enable SIL and forward inventory data
over HTTPS to a SIL Aggregator.
SIL Aggregator Cmdlets Detail
Following are details of the SIL Aggregator cmdlets. For the full cmdlet documentation, see: SIL Aggregator
PowerShell cmdlets
Publish-SilReport
This cmdlet, used as is, will create a Software Inventory Logging Report and place it in the logged in user’s
Documents directory (Excel 2013 is required on the machine where the cmdlet is run).
Used with the
–OpenReport
parameter, it will create the report and open it in Excel for viewing.
You will notice when installing SIL Aggregator that there is an option to install the reporting module only. It
is possible to install the reporting module on a Windows client operating system, such as Windows 8.1 or
Windows 10. This allows a thin client, like a laptop or tablet, to connect to an SIL Aggregator database
server to publish SIL reports directly.
The following example will prompt for credentials to use, connect to a SIL Aggregator database
server named SILContoso, and create and open an SIL report on the local computer.
Publish-SilReport -DBServerName "SILContoso" -DBServerCredential Get-Credential –OpenReport
Before connecting for the first time, in most cases you will need to open a port in the firewall on the
SIL Aggregator database server to allow connections. IT Pros will want to set this up beforehand to
allow their finance controllers or other inventory managers access to create their own reports. For
steps to do this, see the link below. A typical default port for SQL Server Analysis Services is 2383.
Add-SilVMHost
The following host types and hypervisor versions are supported when using the Add-SilVMHost cmdlet. Note that
it is not required to specify these. The Add-SilVMHost cmdlet will automatically detect a supported combination. If
it is unable to detect, or the credentials provided are incorrect, a prompt will be displayed. If the user accepts with a
“Y” entry, the host will be added but it will not be polled. It will be added as “Unknown”.
HYPERVISOR VERSION
SIL AGGREGATOR HOSTTYPE VALUE
SIL AGGREGATOR HYPERVISORTYPE VALUE
Windows Server, 2012 R2
Windows
HyperV
VMware 5.5
VMware
Esxi
Xen 4.x
Ubuntu, OpenSuse, or CentOS
Xen
XenServer 6.2
Citrix
XenServer
KVM
Ubuntu, OpenSuse, or CentOS
KVM
Other versions of these hypervisor platforms and types may work as well. SIL Aggregator ships with the sshnet
version below. This is used to communicate with Linux based virtualization platforms.
sshnet 2014.4.6-beta1
https://sshnet.codeplex.com/releases/view/120504
Copyright (c) 2010, RENCI
Get-SilAggregator
Get-SilAggregator provides configuration information for your Software Inventory Logging Aggregator
application. The following example output shows:
Application is running
Polling interval is every hour (can be changed in hour increments)
Polling start time
Target URI that other machines should set to forward data to this aggregator
Certificate thumbprints this Aggregator accepts SIL data from
Account type specified at install
PS C:\Windows\system32> Get-SilAggregator
``
State : Running HostPollIntervalInHours : Every 1 Hour(s)
PollStartTime : 8/24/2015 5:07:33 AM
TargetURI : https://SilContoso
CertificateThumbprint : 3efc6b8ce7d5eefba5107ede9d1caca550417452,
2dc4ea8bfb64b1246a8c1ffa1b701cd1042a3412
UserProfile : Local
Set-SilAggregator
With the Set-SilAggregator cmdlet you can:
Change the hourly interval for which polling will occur.
Change the start date and time for polling to start at the interval specified.
Add or remove certificate thumbprints which the SIL Aggregator will accept data from, or associated with.
Get-AggregatorData
Used alone, this cmdlet displays the contents of the Windows Server Detail tab of a SIL Aggregator Excel
report.
Used with parameters, this cmdlet will retrieve data directly from the database intended to assist with
customized uses of the SIL overall solution.
Note that the –StartTime and –Endtime parameters will show report data from the first of the month of
start date and the last of the month of the end date.
Get-SilVMHost
This cmdlet outputs the list of physical hosts the SIL Aggregator is configured to poll, the most recent
successful poll date and time, and the HostType (or OS manufacturer), and the HypervisorType (hypervisor
manufacturer). See the Add-SilVMHost details for more information on HostType and HypervisorType.
If a host has no poll date and time, but has a supported HostType and HypervisorType, this means polling
has not yet commenced or has not yet been successful.
This cmdlet will also list any host names that have been added via the data coming from VMs themselves, if
available from the VM. These will appear in the list but will not have any HostType or HypervisorType. This
data can help match up VMs and hosts that may not be setup for polling.
Use the –StartTime and –EndTime parameters to assist with understanding when hosts were first added or
last polled.
Remove -SilVMHost
This cmdlet will remove any host from the list of hosts to be polled. If a host is removed, it is possible that a
VM on the host will re-add the host to the list, but the host will not be polled with correct credentials being
specified using the Add-SilVMHost cmdlet.
If a host is removed, it will be removed from polling but it will not be removed from reports. Since polling
will cease, the host will not be present in reports on the following month(s).
Use the –StartTime and –EndTime parameters individually to assist with removing groups of hosts
successfully polled up to a date, or successfully polled from a date.
Avoid these errors and issues with SIL and SIL Aggregator
(Troubleshooting Guide)
Things to check if
SilLogging
or
Publish-Sildata
cmdlet fail or error:
Be sure the targeturi has https:// in the entry.
Be sure all required updates for Windows Server are installed (see Prerequisites for SIL). A quick way
to check is to look for these using the following cmdlet: Get-SilWindowsUpdate *3060*, *3000*
Be sure the certificate being used to authenticate with the aggregator is installed in the correct store
on the local server to be inventoried with SilLogging (see Getting Started section).
On the SIL Aggregator, be sure the certificate thumbprint of the certificate being used to authenticate
with the aggregator is added to list using the Set-SilAggregator –AddCertificateThumbprint cmdlet
(see Getting Started section).
If using enterprise certificates, check that the server with SIL enabled is joined to the domain for
which the cert was created, or is otherwise verifiable with a root authority. If a certificate is not
trusted on the local machine attempting to forward/push data to an Aggregator, this action will fail
with an error.
If all of the above has been checked, you can check that the certificate used to install the SIL
Aggregator is healthy and matches the name of the SIL Aggregator server itself (this step is
unnecessary if other machines are successfully forwarding to the same SIL Aggregator).
You can check the following location for cached SIL files on the server attempting to forward/push,
\Windows\System32\Logfiles\SIL. If SilLogging has started and has been running for more than an
hour, or Publish-SilData has been run recently, and there are no files in this directory, than logging
to the aggregator has been successful.
Confirm that the logged in user has SQL database and Analysis Services access.
This is required when installing SIL Aggregator.
This is required when using PowerShell remotely to manage SIL Aggregator.
To publish SIL Aggregator reports from a client desktop OS.
Use the option to install the Reporting Module only on your Windows client (8.1/10).
If you encounter issues when trying to create a report using powershell remotely, you likely need to
have a firewall port opened on the SIL Aggregator you are trying to connect to (see
Publish-SilReport Cmdlet under SIL Aggregator Cmdlets Detail section).
When using gMSA option:
Don’t forget to reboot the server after joining it to the gMSA enabled machine group in Active
Directory.
In the installation process, don’t use fully qualified domain when entering domain\user. For example,
use mydomain\gmsaaccount$. Don’t enter mydomain.com\gmsaaccount$.
Managing SIL Over Time
Uninstall/Reinstall SIL Aggregator
If it becomes necessary to uninstall and then reinstall SIL Aggregator, you can do so without losing existing and
historical inventory data. Simply uninstall (following steps provided in this documentation) and select the option
to keep the Software Inventory Logging database. Then reinstall SIL Aggregator (following the steps provided in
this documentation) and select the option to attach to an existing database.
After performing this operation, it is necessary to update the credentials using the
Add-SilVMHost
cmdlet on any
hosts that were previously being polled by SIL Aggregator (assuming that continuing to collect data from these
hosts is desired). In addition, to avoid duplicate entries for the same host on reports, it is necessary to re-add hosts
for polling using the same network address as was originally added. Here are the three supported vmhostname
types that can be used to add a host using the Add-SilVMHost cmdlet:
IP Address
Fully Qualified Domain Name (FQDN)
Netbios Name
Changing SIL Aggregators
When you want to start inventorying servers in your environment with a different SIL Aggregator, simply use the
SIL cmdlet on these servers to change the targeturi (and certificate thumbprint if necessary),
Set-SilLogging –TargetUri . Note that after doing this it is necessary to use the Publish-SilData cmdlet at least
once to forward a full inventory to the newly specified SIL Aggregator.
Changing or Updating Certificates
IMPORTANT STEPS TO AVOID DATA LOSS: If it is necessary to change the certificate that servers are using to
forward data to an SIL Aggregator, but the target Aggregator will remain the same, use these steps to avoid
potential data loss in transit to the Aggregator:
On the SIL Aggregator use the Set-SilAggregator
thumbprint the SIL Aggregator.
–AddCertificateThumbprint
cmdlet to add the new
On ALL servers forwarding data, install the new certificate to be used in \LOCALMACHINE\MY using your
preferred method.
On ALL servers forwarding data, use the
thumbprint of the new certificate.
Set-SilLogging –CertificateThumbprint
cmdlet to update to the
CRITICAL: Only after all servers forwarding data have been updated, remove the old thumbprint
from the SIL Aggregator using Set-SilAggregator –RemoveCertificateThumbprint cmdlet. If a server
forwarding data continues to forward using an old certificate that has been removed from the SIL
Aggregator data will be lost and not inserted in the database on the Aggregator. This only impacts
scenarios where a server has previously successfully forwarded data to a SIL Aggregator and the certificate
is then removed from the SIL Aggregator’s list of thumbprints to accept data from.
Release Notes
There is a known issue that SIL Aggregator will not process and report on the presence of SQL Server
Standard Edition installs. Here are the steps to correct this:
1. Open SQL Server Management Studio on your SIL Aggregator.
2. Connect to the Database Engine.
3. Expand the SoftwareInventoryLogging database, and then Tables, in the selection tree.
4. Right click dbo.SqlServerEdition, and then select ‘Edit Top 200 Rows’.
5. Change the PropertyNumValue next to “Standard Edition” to 2760240536 (from -1534726760).
6. Close the query to save the change.
7. For any server running SIL that has already logged data to this Aggregator, it may be necessary to
run the Publish-SilData Cmdlet one time for the Aggregator to correctly process the presence of
SQL Server Standard Edition.
In SIL generated reports, all processor core counts include the count of threads if hyper-threading is
enabled on the physical server. To get actual physical core counts on servers with hyperthreading enabled,
it is necessary to reduce these counts by half.
Totals in the rows (on Dashboard tab) and columns (on Summary and Detail tabs) labeled
“Simultaneously Running…”, for both Windows Server and System Center don’t exactly match between
the two locations. On the Dashboard tab, it is necessary to add “Windows Server Devices (with no
known VMs)” value to the “Simultaneously Running…” value to equal this number on the Summary
and Detail tabs.
See IMPORTANT STEPS TO AVOID DATA LOSS when changing or updating certificates under the
Managing SIL Over Time section of this documentation.
While it is possible to add Windows Server 2008 R2 and Windows Server 2012 hosts to the polling host
list, this version (1.0) of SIL Aggregator only supports polling Windows Server 2012 R2, for
Windows/Hyper-V based hosts, to have success with all features and functionality. In particular, it is known
that when polling Windows Server 2008 R2 hosts, virtual machines and hosts may not match up in the SIL
Aggregator reports.
See Also
Software Inventory Logging Aggregator 1.0 for Windows Server
SIL Aggregator PowerShell cmdlets
SIL PowerShell cmdlets
An Overview of SIL
Managing SIL
Get Started with User Access Logging
4/24/2017 • 4 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
User Access Logging (UAL) is feature in Windows Server that aggregates client usage data by role and products on
a local server. It helps Windows server administrators quantify requests from client computers for roles and
services on a local server.
UAL is installed and enabled by default, and collects data in nearly real-time. No administrator configuration is
required, although UAL can be disabled or enabled. For more information, see Manage User Access Logging. The
User Access Logging service aggregates client usage data by roles and products into local database files. IT
administrators can later use Windows Management Instrumentation (WMI) or Windows PowerShell cmdlets to
retrieve quantities and instances by server role (or software product), by user, by device, by the local server, and by
date.
NOTE
UAL supports the Microsoft Assessment and Planning Toolkit.
Practical applications
UAL aggregates unique client device and user request events that are logged into a local database. These records
are then made available (through a query by a server administrator) to retrieve quantities and instances by server
role, by user, by device, by the local server, and by date. In addition, UAL has been extended to enable nonMicrosoft software developers to instrument their UAL events to be aggregated by Windows Server.
UAL can perform the following tasks:
Quantify client user requests for local physical or virtual servers.
Quantify client user requests for installed software products on a local physical or virtual server.
Retrieve data on a local server running Hyper-V to identify periods of high and low demand on a Hyper-V
virtual computer.
Retrieve UAL data from multiple remote servers.
In addition, software developers can instrument UAL events that can then be aggregated and retrieved by using
WMI and Windows PowerShell interfaces.
The following server roles and services can be supported by UAL:
Active Directory Certificate Services (AD CS)
Active Directory Rights Management Services (AD RMS)
BranchCache
Domain Name System (DNS)
NOTE
UAL collects DNS data every 24 hours, and there is a separate UAL cmdlet for this scenario.
Dynamic Host Configuration Protocol (DHCP)
Fax Server
File Services
File Transfer Protocol (FTP) Server
Hyper-V
NOTE
UAL collects Hyper-V data every 24 hours, and there is a separate UAL cmdlet for this scenario.
Web Server (IIS)
WARNING
To use UAL with IIS, you must use iisual.exe. For more information, see Analyzing Client Usage Data with IIS User
Access Logging.
Microsoft Message Queue (MSMQ) Services
Network Policy and Access Services
Print and Document Services
Routing and Remote Access Service (RRAS)
Windows Deployment Services (WDS)
Windows Server Update Services (WSUS)
IMPORTANT
UAL is not recommended for use on servers that are connected directly to the Internet, such as web servers on an Internetaccessible address space, or in scenarios where extremely high performance is the primary function of the server (such as in
HPC workload environments). UAL is primarily intended for small, medium, and enterprise intranet scenarios where high
volume is expected, but not as high as deployments that serve Internet-facing traffic volume on a regular basis.
Important functionality
The following table describes key functions of UAL and their potential value.
FUNCTIONALITY
VALUE
Collect and aggregate client request event data in near realtime.
Up to three years of data can be saved. Important:
Administrators need to enforce compliance of the data
collected and data retention periods with the organization’s
privacy policy and local regulations.
FUNCTIONALITY
VALUE
Query UAL by using WMI or Windows PowerShell interfaces
to retrieve client request data on a local or remote server.
UAL enables a single view of ongoing usage data. Server and
enterprise administrators can retrieve this data and coordinate
with business administrators to optimize use of their volume
software licenses.
Enabled by default.
Server administrators do not need to configure or otherwise
set up this feature for all core functionality to be available and
working.
Data logged with UAL
The following user-related data is logged with UAL.
DATA
DESCRIPTION
UserName
The user name on the client that accompanies the UAL entries
from installed roles and products, if applicable.
ActivityCount
The number of times a particular user accessed a role or
service.
FirstSeen
The date and time when a user first accesses a role or service.
LastSeen
The date and time when a user last accessed a role or service.
ProductName
The name of the software parent product, such as Windows,
that is providing UAL data.
RoleGUID
The UAL assigned or registered GUID that represents the
server role or installed product.
RoleName
The name of the role, component, or subproduct that is
providing UAL data. This is also associated with a
ProductName and a RoleGUID.
TenantIdentifier
A unique GUID for a tenant client of an installed role or
product that accompanies the UAL data, if applicable.
The following device-related data is logged with UAL.
DATA
DESCRIPTION
IPAddress
The IP address of a client device that is used to access a role
or service.
ActivityCount
The number of times a particular device accessed the role or
service.
FirstSeen
The date and time when an IP address was first used to access
a role or service.
LastSeen
The date and time when an IP address was last used to access
a role or service.
DATA
DESCRIPTION
ProductName
The name of the software parent product, such as Windows,
that is providing UAL data.
RoleGUID
The UAL-assigned or registered GUID that represents the
server role or installed product.
RoleName
The name of the role, component, or subproduct that is
providing UAL data. This is also associated with a
ProductName and a RoleGUID.
TenantIdentifier
A unique GUID for a tenant client of an installed role or
product that accompanies the UAL data, if applicable.
Software requirements
UAL can be used on any computer running versions of Windows Server after Windows Server 2012.
See also
User Access Logging on MSDN.
Manage User Access Logging
Manage User Access Logging
4/24/2017 • 10 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
This document describes how to manage User Access Logging (UAL).
UAL is a feature that can help server administrators quantify the number of unique client requests of roles and
services on a local server.
UAL is installed and enabled by default and collects data on a nearly real-time basis. There are only a few
configuration options for UAL. This document describes these options and their intended purpose.
To learn more about the benefits of UAL, see the Get Started with User Access Logging.
In this document
The configuration options covered in this document include:
Disabling and enabling the UAL service
Collecting and removing data
Deleting data logged by UAL
Managing UAL in high volume environments
Recovering from a corrupt state
Enable Work Folders usage license tracking
Disabling and enabling the UAL service
UAL is enabled and runs by default when a computer running Windows Server 2012, or later, is installed and
started for the first time. Administrators may want to turn off and disable UAL to comply with privacy
requirements or other operational needs. You can turn off UAL using the Services console, from the command line,
or by using PowerShell cmdlets. However, to ensure that UAL does not run again the next time the computer is
started, you also need to disable the service. The following procedures describes how to turn off and disable UAL.
NOTE
You can use the Get-Service UALSVC PowerShell cmdlet to retrieve information about the UAL Service including whether it
is running or stopped and whether it is enabled or disabled.
To stop and disable the UAL service by using the Services console
1. Sign in to the server with an account that has local administrator privileges.
2. In Server Manager, point to Tools, and then click Services.
3. Scroll down and select User Access Logging Service.Click Stop the service.
4. Right-click the service name and select Properties. On the General tab, change the Startup type to
Disabled, and then click OK.
To stop and disable UAL from the command line
1. Sign in to the server with an account that has local administrator privileges.
2. Press the Windows logo + R, then type cmd to open a Command Prompt window.
IMPORTANT
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click
Yes.
3. Type net stop ualsvc, and then press ENTER.
4. Type netsh ualsvc set opmode mode=disable, and then press ENTER.
The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure.
Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because
of formatting constraints.
You can also stop and disable UAL by using the Stop-service and Disable-Ual Windows PowerShell commands.
Stop-service ualsvc
Disable-ual
If at a later date you want to restart and re-enable UAL you can do so with the following procedures.
To start and enable the UAL service by using the Services console
1. Sign in to the server an account that has local administrator privileges.
2. In Server Manager, point to Tools, and then click Services.
3. Scroll down and select User Access Logging Service.Click Start the service.
4. Right-click the service name and select Properties. On the General tab, change the Startup type to
Automatic, and then click OK.
To start and enable UAL from the command line
1. Sign in to the server with local administrator credentials.
2. Press the Windows logo + R, then type cmd to open a Command Prompt window.
IMPORTANT
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click
Yes.
3. Type net start ualsvc, and then press ENTER.
4. Type netsh ualsvc set opmode mode=enable, and then press ENTER.
The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure.
Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because
of formatting constraints.
You can also start and reenable UAL by using the Start-service and Enable-Ual Windows PowerShell commands.
Enable-ual
Start-service ualsvc
Collecting UAL data
In addition to the PowerShell cmdlets described in the previous section, 12 additional cmdlets can be used to
collect UAL data:
Get-UalOverview: Provides UAL related details and history of installed products and roles.
Get-UalServerUser: Provides client user access data for the local or targeted server.
Get-UalServerDevice: Provides client device access data for the local or targeted server.
Get-UalUserAccess: Provides client user access data for each role or product installed on the local or
targeted server.
Get-UalDeviceAccess: Provides client device access data for each role or product installed on the local or
targeted server.
Get-UalDailyUserAccess: Provides client user access data for each day of the year.
Get-UalDailyDeviceAccess: Provides client device access data for each day of the year.
Get-UalDailyAccess: Provides both client device and user access data for each day of the year.
Get-UalHyperV: Provides virtual machine data relevant to the local or targeted server.
Get-UalDns: Provides DNS client specific data of the local or targeted DNS server.
Get-UalSystemId: Provides system specific data to uniquely identify the local or targeted server.
is meant to provide a unique profile of a server for all other data from that server to be correlated
with. If a server experiences any change in the in one of the parameters of Get-UalSystemId a new profile is
created. Get-UalOverview is meant to provide the administrator with a list of roles installed and being used on the
server.
Get-UalSystemId
NOTE
Basic features of Print and Document Services and File Services are installed by default. Therefore administrators can expect
to always see information on these displayed as if the full roles are installed. Separate UAL cmdlets are included for Hyper-V
and DNS because of the unique data that UAL collects for these server roles.
A typical use case scenario for UAL cmdlets would be for an administrator to query UAL for unique client accesses
over the course of a date range. This can be done in a variety of ways. The following is a recommended method to
query unique device accesses over a date range.
PS C:\Windows\system32>Gwmi -Namespace "root\AccessLogging" -query "SELECT * FROM MsftUal_DeviceAccess WHERE
LastSeen >='1/01/2013' and LastSeen <='3/31/2013'"
This will return a verbose listing of all unique client devices, by IP address, that have made requests of the server in
that date range.
‘ActivityCount’ for each unique client is limited to 65,535 per day. Also, calling into WMI from PowerShell is only
required when you query by date. All other UAL cmdlet parameters can be used within PS queries as expected, as
in the following example:
PS C:\Windows\system32> Get-UalDeviceAccess -IPAddress "10.36.206.112"
ActivityCount
FirstSeen
IPAddress
LastSeen
ProductName
RoleGuid
RoleName
TenantIdentifier
PSComputerName
:
:
:
:
:
:
:
:
1
6/23/2012 5:06:50 AM
10.36.206.112
6/23/2012 5:06:50 AM
Windows Server 2012 Datacenter
10a9226f-50ee-49d8-a393-9a501d47ce04
File Server
00000000-0000-0000-0000-000000000000
UAL retains up to two years’ worth of history. To allow retrieval of UAL data by an administrator when the service
is running, UAL makes a copy of the active database file, current.mdb, to a file named GUID.mdb every 24 hours for
the WMI provider’s use.
On the first day of the year, UAL will create a new GUID.mdb. The old GUID.mdb is retained as an archive for the
provider’s use. After two years, the original GUID.mdb will be overwritten.
IMPORTANT
The following procedure should be performed only by an advanced user and would commonly be used by a developer
testing their own instrumentation of UAL application programming interfaces...
To adjust the default 24-hour interval to make data visible to the WMI provider
1. Sign in to the server with an account that has local administrator privileges.
2. Press the Windows logo + R, then type cmd to open a Command Prompt window.
3. Add the registry value:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WMI\AutoLogger\Sum\PollingInterv
al (REG_DWORD).
WARNING
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should
back up any valued data on your computer.
The following example shows how to add a two-minute interval (not recommended as a long term running
state): REG ADD HKLM\System\CurrentControlSet\Control\WMI\AutoLogger\Sum /v
PollingInterval /t REG_DWORD /d 120000 /F
Time values are in milliseconds. The minimum value is 60 seconds, the maximum is seven days, and the
default is 24 hours.
4. Use the Services console to stop and restart the User Access Logging Service.
Deleting data logged by UAL
UAL is not intended to be a mission critical component. Its design is intended to impact local system operations as
little as possible while maintaining a high level of reliability. This also allows the administrator to manually delete
UAL database and supporting files (every file in \Windows\System32\LogFilesSUM\ directory) to meet operational
needs.
To delete data logged by UAL
1. Stop the User Access Logging Service.
2. Open Windows Explorer.
3. Go to \Windows\System32\Logfiles\SUM\.
4. Delete all files in the folder.
Managing UAL in high volume environments
This section describes what an administrator can expect when UAL is used on a server with high client volume:
The maximum number of accesses that can be recorded with UAL is 65,535 per day. UAL is not recommended for
use on servers that are connected directly to the Internet, such as web servers that are connected directly to the
Internet, or in scenarios where extremely high performance is the primary function of the server (such as in HPC
workload environments). UAL is primarily intended for small, medium, and enterprise intranet scenarios where
high volume is expected, but not as high as many deployment that serve Internet-facing traffic volume on a regular
basis.
UAL in Memory: Because UAL uses the Extensible Storage Engine (ESE), UAL’s memory requirements will increase
over time (or by quantity of client requests). But memory will be relinquished as the system requires it to minimize
impact on system performance.
UAL on Disk: UAL’s hard disk requirements are approximately as shown below:
0 unique client records: 22M
50,000 unique client records: 80 M
500,000 unique client records: 384M
1,000,000 unique client records: 729M
Recovering from a corrupt state
This section discusses UAL’s use of the Extensible Storage Engine (ESE) at a high level and what an administrator
can do if UAL data is corrupted or unrecoverable.
UAL uses ESE to optimize use of system resources and for its resistance to corruption. For more information about
the benefits of ESE, see Extensible Storage Engine on MSDN.
Each time the UAL service starts ESE performs a soft recovery. For more information, see Extensible Storage Engine
Files on MSDN.
If there is a problem with the soft recovery, ESE will perform a crash recovery. For more information, see JetInit
Function on MSDN.
If UAL is still unable to start with the existing set of ESE files, it will delete all files in the
\Windows\System32\LogFiles\SUM\ directory. After these files are deleted, the User Access Logging Service will
restart and new files are created. The UAL service will then resume as if on a freshly installed computer.
IMPORTANT
The files in UAL database directory should never be moved or modified. Doing so will initiate the recovery steps, including
the cleanup routine described in this section. If backups of the\Windows\System32\LogFiles\SUM\ directory are needed, then
every file in this directory must be backed up together in order for a restore operation to function as expected.
Enable Work Folders usage license tracking
Work Folders server can use UAL to report client usage. Unlike UAL, Work Folder logging is not turned on by
default. You can enable it with the following regkey change:
Reg add HKLM\Software\Microsoft\Windows\CurrentVersion\SyncShareSrv /v EnableWorkFoldersUAL /t REG_DWORD /d 1
After the regkey is added, you must restart the SyncShareSvc service on the server, to enable logging.
After logging is enabled, 2 informational events get logged to the Windows Logs\Application channel each time a
client connects to the server. For Work Folders, each user may have one or more client devices that connect to the
server and check for data updates every 10 minutes. If the server is experiencing 1000 users, each with 2 devices
the application logs will overwrite every 70 minutes, making troubleshooting unrelated issues difficult. To avoid
this, you can disable the User Access Logging service temporarily, or increase the size of the server’s Windows
Logs\Application channel.
See also
Get Started with User Access Logging
Windows Server Update Services (WSUS)
5/23/2017 • 3 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Windows Server Update Services (WSUS) enables information technology administrators to deploy the latest
Microsoft product updates. You can use WSUS to fully manage the distribution of updates that are released
through Microsoft Update to computers on your network. This topic provides an overview of this server role and
more information about how to deploy and maintain WSUS.
WSUS Server role description
A WSUS server provides features that you can use to manage and distribute updates through a management
console. A WSUS server can also be the update source for other WSUS servers within the organization. The WSUS
server that acts as an update source is called an upstream server. In a WSUS implementation, at least one WSUS
server on your network must be able to connect to Microsoft Update to get available update information. As an
administrator, you can determine - based on network security and configuration - how many other WSUS servers
connect directly to Microsoft Update.
Practical applications
Update management is the process of controlling the deployment and maintenance of interim software releases
into production environments. It helps you maintain operational efficiency, overcome security vulnerabilities, and
maintain the stability of your production environment. If your organization cannot determine and maintain a
known level of trust within its operating systems and application software, it might have a number of security
vulnerabilities that, if exploited, could lead to a loss of revenue and intellectual property. Minimizing this threat
requires you to have properly configured systems, use the latest software, and install the recommended software
updates.
The core scenarios where WSUS adds value to your business are:
Centralized update management
Update management automation
New and changed functionality
NOTE
Upgrade from any version of Windows Server that supports WSUS 3.2 to Windows Server 2012 R2 requires that you first
uninstall WSUS 3.2.
In Windows Server 2012, upgrading from any version of Windows Server with WSUS 3.2 installed is blocked during the
installation process if WSUS 3.2 is detected. In that case, you will be prompted to first uninstall Windows Server Update
Services prior to upgrading your server.
However, because of changes in this release of Windows Server and Windows Server 2012 R2, when upgrading from any
version of Windows Server and WSUS 3.2, the installation is not blocked. Failure to uninstall WSUS 3.2 prior to performing a
Windows Server 2012 R2 upgrade will cause the post installation tasks for WSUS in Windows Server 2012 R2 to fail. In this
case, the only known corrective measure is to format the hard drive and reinstall Windows Server.
Windows Server Update Services is a built-in server role that includes the following enhancements:
Can be added and removed by using the Server Manager
Includes Windows PowerShell cmdlets to manage the most important administrative tasks in WSUS
Adds SHA256 hash capability for additional security
Provides client and server separation: versions of the Windows Update Agent (WUA) can ship independently
of WSUS
Using Windows PowerShell to manage WSUS
for system administrators to automate their operations, they need coverage through command-line automation.
The main goal is to facilitate WSUS administration by allowing system administrators to automate their day-to-day
operations.
What value does this change add?
By exposing core WSUS operations through Windows PowerShell, system administrators can increase productivity,
reduce the learning curve for new tools, and reduce errors due to failed expectations resulting from a lack of
consistency across similar operations.
What works differently?
In earlier versions of the Windows Server operating system, there were no Windows PowerShell cmdlets, and
update management automation was challenging. The Windows PowerShell cmdlets for WSUS operations add
flexibility and agility for the system administrator.
In this collection
The following guides for planning, deploying, and managing WSUS are in this collection:
Deploy Windows Server Update Services
Manage Updates using Windows Server Update Services
Deploy
4/24/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Windows Server Update Services (WSUS) enables information technology administrators to deploy the latest
Microsoft product updates. WSUS is a Windows Server server role that can be installed to manage and distribute
updates. A WSUS server can be the update source for other WSUS servers within the organization. The WSUS
server that acts as an update source is called an upstream server.
In a WSUS implementation, at least one WSUS server in the network must connect to Microsoft Update to get
available update information. You can determine, based on network security and configuration, how many other
servers connect directly to Microsoft Update.
This guide provides conceptual information for planning and deploying Windows Server Update Service.
Plan your WSUS deployment
Step 1: Install the WSUS Server Role
Step 2: Configure WSUS
Step 3: Approve and Deploy Updates in WSUS
Step 4: Configure Group Policy Settings for Automatic Updates
Plan your WSUS deployment
4/24/2017 • 28 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The first step in the deployment of Windows Server Update Services (WSUS) is to make important decisions, such
as deciding the WSUS deployment scenario, choosing a network topology, and understanding the system
requirements. The following checklist summarizes the steps that are involved in preparing for your deployment.
TASK
DESCRIPTION
1.1. Review considerations and system requirements
Review the list of considerations and system requirements to
ensure that you have all the necessary hardware and software
to deploy WSUS.
1.2. Choose a WSUS deployment scenario
Decide which WSUS deployment scenario will be used.
1.3. Choose a WSUS storage strategy
Decide which WSUS storage strategy best fits your
deployment.
1.4. Choose WSUS update languages
Decide which WSUS update languages will be installed.
1.5. Plan WSUS computer groups
Plan the WSUS computer group approach that you will use for
your deployment.
1.6. Plan WSUS Performance Considerations: Background
Intelligent Transfer Service
Plan a WSUS design for optimized performance.
1.7. Plan Automatic Updates settings
Plan how you will configure the automatic updates settings for
your scenario.
1.1. Review considerations and system requirements
System Requirements:
Before you enable the WSUS server role, confirm that the server meets the system requirements and confirm that
you have the necessary permissions to complete the installation by adhering with the following guidelines:
Server hardware requirements to enable WSUS role are bound to hardware requirements. The minimum
hardware requirements for WSUS are:
Processor: 1.4 gigahertz (GHz) x64 processor (2 Ghz or faster is recommended)
Memory: WSUS requires an additional 2 GB of RAM more than what is required by the server and all
other services or software.
Available disk space: 10 GB (40 GB or greater is recommended)
Network adapter: 100 megabits per second (Mbps) or greater
Software Requirements:
For viewing reports, WSUS requires the Microsoft Report Viewer Redistributable 2008
If you install roles or software updates that require you to restart the server when installation is complete,
restart the server before you enable the WSUS server role.
Microsoft .NET Framework 4.0 must be installed on the server where the WSUS server role will be installed.
The NT Authority\Network Service account must have Full Control permissions for the following folders so
that the WSUS Administration snap-in displays correctly:
%windir%\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
NOTE
This path might not exist prior to install Web Server Role that contains Internet Information Services (IIS).
%windir%\Temp
Confirm that the account you plan to use to install WSUS is a member of the Local Administrators group.
Installation Considerations:
During the installation process, WSUS will install the following by default:
.NET API and Windows PowerShell cmdlets
Windows Internal Database (WID), which is used by WSUS
Services used by WSUS, which are:
Update Service
Reporting Web Service
Client Web Service
Simple Web Authentication Web Service
Server Synchronization Service
DSS Authentication Web Service
Features on Demand Considerations
Be aware that configuring client computers (including servers) to update by using WSUS will result in the following
limitations:
1. Server roles that have had their payloads removed using Features on Demand cannot be installed on
demand from Microsoft Update. You will must either provide an installation source at the time you try to
install such server roles, or configure a source for Features on Demand in Group Policy.
2. Windows client editions will not be able to install .NET 3.5 on demand from the web. The same
considerations as server roles apply to .NET 3.5.
NOTE
Configuring a Features on Demand installation source does not involve WSUS. For information on how to configure Features,
see Configure Features on Demand in Windows Server.
WSUS database requirements
WSUS requires one of the following databases:
Windows Internal Database (WID)
Microsoft SQL Server 2012 with SP1
Microsoft SQL Server 2012
Microsoft SQL Server 2008 R2 SP2
Microsoft SQL Server 2008 R2 SP1
The following editions of SQL Server are supported by WSUS:
Standard
Enterprise
Express
NOTE
SQL Server Express 2008 R2 has a database size limitation of 10 GB. This database size is likely to be sufficient for WSUS,
although there is no appreciable benefit to using this database instead of WID. WID database has a minimum RAM memory
requirement of 2 GB beyond the standard Windows Server system requirements.
You can install the WSUS role on a computer that is separate from the database server computer. In this case, the
following additional criteria apply:
1. The database server cannot be configured as a domain controller.
2. The WSUS server cannot run remote Desktop Services.
3. The database server must be in the same active directory domain as the WSUS server, or it must have a trust
relationship with the active directory domain of the WSUS server.
4. The WSUS server and the database server must be in the same time zone or be synchronized to the same
Coordinated Universal time (Greenwich Mean time) source.
1.2. Choose a WSUS deployment scenario
This section describes the basic features of all WSUS deployments. Use this section to familiarize yourself with a
simple deployment with a single WSUS server, in addition to more complex scenarios, such as a WSUS server
hierarchy or a WSUS server on an isolated network segment.
Simple WSUS deployment
The most basic WSUS deployment consists of a server inside the corporate firewall that serves client computers on
a private intranet. The WSUS server connects to Microsoft Update to download updates. This is known as
synchronization. During synchronization, WSUS determines if any new updates have been made available since the
last time you synchronized. If it is your first time synchronizing WSUS, all updates are made available for download.
NOTE
Initial synchronization can take over an hour. All synchronizations after that should be significantly quicker.
By default, the WSUS server uses port 80 for HTTP protocol and port 443 for HTTPS protocol to obtain updates
from Microsoft. If there is a corporate firewall between your network and the Internet, you will have to open these
ports on the server that communicates directly to Microsoft Update. If you are planning to use custom ports for this
communication, you must open those ports instead. You can configure multiple WSUS servers to synchronize with
a parent WSUS server. By default, the WSUS server uses port 8530 for HTTP protocol and port 8531 for HTTPS
protocol to provide updates to client workstations.
Multiple WSUS servers
Administrators can deploy multiple servers running WSUS that synchronize all content within their organization's
intranet. You might expose only one server to the Internet, which would be the only server that downloads updates
from Microsoft Update. This server is set up as the upstream server the source to which the downstream servers
synchronize. When applicable, servers can be located throughout a geographically dispersed network to provide
the best connectivity to all client computers.
Disconnected WSUS server
If corporate policy or other conditions limit computer access to the Internet, administrators can set up an internal
server to run WSUS. An example of this is a server that is connected to the intranet but is isolated from the Internet.
After downloading, testing, and approving the updates on this server, an administrator would export the update
metadata and content to a DVD. The update metadata and content is imported from the DVD to servers running
WSUS within the intranet.
WSUS server hierarchies
You can create complex hierarchies of WSUS servers. Because you can synchronize one WSUS server with another
WSUS server instead of with Microsoft Update, you need to have only a single WSUS server that is connected to
Microsoft Update. When you link WSUS servers together, there is an upstream WSUS server and a downstream
WSUS server. A WSUS server hierarchy deployment offers the following benefits:
You can download updates one time from the Internet and then distribute the updates to client computers
by using downstream servers. This method saves bandwidth on the corporate Internet connection.
You can download updates to a WSUS server that is physically closer to the client computers, for example, in
branch offices.
You can set up separate WSUS servers to serve client computers that use different languages of Microsoft
products.
You can scale WSUS for a large organization that has more client computers than one WSUS server can
effectively manage.
NOTE
We recommend that you do not create a WSUS server hierarchy that is more than three levels deep. Each level adds time to
propagate updates throughout the connected servers. Although there is no theoretical limit to a hierarchy, only deployments
with a hierarchy of five levels deep have been tested by Microsoft Corporation.
You can connect WSUS servers in Autonomous mode (to achieve distributed administration) or in Replica mode (to
achieve centralized administration). You do not have to deploy a server hierarchy that uses only one mode: you can
deploy a WSUS solution that uses both autonomous and replica WSUS servers.
Autonomous mode
The Autonomous mode, also called distributed administration, is the default installation option for WSUS. In
Autonomous mode, an upstream WSUS server shares updates with downstream servers during synchronization.
Downstream WSUS servers are administered separately, and they do not receive update approval status or
computer group information from the upstream server. By using the distributed management model, each WSUS
server administrator selects update languages, creates computer groups, assigns computers to groups, tests and
approves updates, and makes sure that the correct updates are installed to the appropriate computer groups. The
following image shows how you might deploy autonomous WSUS servers in a branch office environment:
Replica mode
The Replica mode, also called centralized administration, works by having an upstream WSUS server that shares
updates, approval status, and computer groups with downstream servers. Replica servers inherit update approvals
and are not administered separately from the upstream WSUS server. The following image shows how you might
deploy replica WSUS servers in a branch office environment.
NOTE
If you set up several replica servers to connect to a single upstream WSUS server, do not schedule synchronization to run at
the same time on each replica server. This practice will avoid sudden surges in bandwidth usage.
Branch offices
You can leverage the Branch Office feature in Windows to optimize WSUS deployment. This type of deployment
offers the following advantages:
1. helps reduce WAN link utilization and improves application responsiveness. To enable BranchCache
acceleration of content that is served by the WSUS server, install the BranchCache feature on the server and
the clients, and ensure that the BranchCache service has started. No other steps are necessary.
2. In branch offices that have low-bandwidth connections to the central office but high-bandwidth connections
to the Internet, the Branch Office feature can also be used. In this case you may want to configure
downstream WSUS servers to get information about which updates to install from the central WSUS server,
but download the updates from Microsoft Update.
Network Load Balancing
Network Load Balancing (NLB) increases the reliability and performance of your WSUS network. You can set up
multiple WSUS servers that share a single failover cluster running QL Server such as SQL Server 2008 R2 SP1. In
this configuration you must use a full SQL Server installation, not the Windows Internal Database installation that is
provided by WSUS, and the database role must be installed on all WSUS front-end servers. You can also have all
the WSUS servers use a distributed file system (DFS) to store their content.
WSUS setup for NLB: compared to WSUS 3.2 setup for NLB, a special setup call and parameters are no longer
required to configure WSUS for NLB. You need only setup each WSUS server, keeping the following considerations
in mind.
WSUS must be setup using the SQL database option instead of WID.
If storing updates locally, the same Content folder must be shared between the WSUS servers that are
sharing the same SQL database.
WSUS setup must be done in serial. Postinstall tasks cannot be run on more than one server at the same
time when sharing the same SQL database.
WSUS deployment with roaming client computers
If the network includes mobile users who log on to the network from different locations, you can configure WSUS
to let roaming users update their client computers from the WSUS server that is closest to them geographically. For
example, you might deploy one WSUS server each region and use a different DNS subnet for each region. All client
computers could be directed to the same WSUS server, which resolves in each subnet to the nearest physical
WSUS server.
1.3. Choose a WSUS storage strategy
Windows Server Update Services (WSUS) uses two types of storage systems: a database to store WSUS
configuration and update metadata, and an optional local file system to store update files. Before you install WSUS,
you should decide how you want to implement storage.
Updates are composed of two parts: metadata that describes the update, and the files that are required to install the
update. Update metadata is typically much smaller than the actual update, and it is stored in the WSUS database.
Update files are stored on a local WSUS server or on a Microsoft Update Web server.
WSUS database
WSUS requires a database for each WSUS server. WSUS supports the use of a database that resides on a different
computer than the WSUS server, with some restrictions. For a list of supported databases and remote database
limitations, see section "1.1 Review initial considerations and system requirements," in this guide.
The WSUS database stores the following information:
WSUS server configuration information
Metadata that describes each update
Information about client computers, updates, and interactions
If you install multiple WSUS servers, you must maintain a separate database for each WSUS server, whether it is an
autonomous or a replica server. You cannot store multiple WSUS databases on a single instance of SQL Server,
except in Network Load Balancing (NLB) clusters that use SQL Server failover.
SQL Server, SQL Server Express, and Windows Internal Database provide the same performance characteristics for
a single-server configuration, where the database and the WSUS service are located on the same computer. A
single-server configuration can support several thousand WSUS client computers.
NOTE
Do not attempt to manage WSUS by accessing the database directly. directly manipulating the database can cause database
corruption. The corruption might not be immediately obvious, but it can prevent upgrades to the next version of the product.
You can manage WSUS by using the WSUS console or WSUS application programming interfaces (APIs).
WSUS with Windows Internal Database
By default, the installation wizard creates and uses a Windows Internal Database that is named SUSDB.mdf. This
database is located in the %windir%\wid\data\ folder, where %windir% is the local drive on which the WSUS server
software is installed.
NOTE
Windows Internal Database (WID) was introduced in Windows Server 2012 .
WSUS supports Windows authentication only for the database. You cannot use SQL Server authentication with
WSUS. If you use Windows Internal Database for the WSUS database, WSUS Setup creates an instance of SQL
Server that is named server\Microsoft##WID, where server is the name of the computer. With either database
option, WSUS Setup creates a database named SUSDB. The name of this database is not configurable.
We recommend that you use Windows Internal Database in the following cases:
The organization has not already purchased and does not require a SQL Server product for any other
application.
The organization does not require an NLB WSUS solution.
You intend to deploy multiple WSUS servers (for example, in branch offices). In this case, you should
consider using Windows Internal Database on the secondary servers, even if you will use SQL Server for the
root WSUS server. Because each WSUS server requires a separate instance of SQL Server, you will quickly
experience database performance issues if only one instance of SQL Server handles multiple WSUS servers.
Windows Internal Database does not provide a user interface or any database management tools. If you select this
database for WSUS, you must use external tools to manage the database. For more information, see:
Backup and Restore WSUS Data and Backing Up Your Server
Reindex the WSUS database
WSUS with SQL Server
We recommend that you use SQL Server with WSUS in the following cases:
1. You require an NLB WSUS solution.
2. You already have at least one instance of SQL Server installed.
3. You cannot run the SQL Server service under a local non-system account or by using SQL Server
authentication. WSUS supports Windows authentication only.
WSUS update storage
When updates are synchronized to your WSUS server, the metadata and update files are stored in two separate
locations. Metadata is stored in the WSUS database. Update files can be stored on your WSUS server or on
Microsoft Update servers, depending on how you have configured your synchronization options. If you choose to
store update files on your WSUS server, client computers will download approved updates from the local WSUS
server. If not, client computers will download approved updates directly from Microsoft Update. The option that
makes the most sense for your organization will depend on network bandwidth to the Internet, network bandwidth
on the intranet, and local storage availability.
You can select a different update storage solution for each WSUS server that you deploy.
Local WSUS server storage
Local storage of update files is the default option when you install and configure WSUS. This option can save
bandwidth on the corporate connection to the Internet because client computers download updates directly from
the local WSUS server.
This option requires that the server have sufficient disk space to store all needed updates. at a minimum, WSUS
requires 20 GB to store updates locally; however, we recommend 30 GB based on tested variables.
remote storage on Microsoft Update servers
You can store updates remotely on Microsoft Update servers. This option is useful if most client computers connect
to the WSUS server over a slow WAN connection, but they connect to the Internet over a high-bandwidth
connection.
In this case, the root WSUS server synchronizes with Microsoft Update and receives the update metadata. After you
approve the updates, the client computers download the approved updates from Microsoft Update servers.
1.4. Choose WSUS update languages
When you deploy a WSUS server hierarchy, you should determine which language updates are required
throughout the organization. You should configure the root WSUS server to download updates in all languages
that are used throughout the entire organization.
For example, the main office might require English and French language updates, but one branch office requires
English, French, and German language updates, and another branch office requires English and Spanish language
updates. In this situation, you would configure the root WSUS server to download updates in English, French,
German, and Spanish. You would then configure the first branch office WSUS server to download updates in
English, French, and German only, and configure the second branch office to download updates in English and
Spanish only.
The Choose Languages page of the WSUS Configuration Wizard allows you to get updates from all languages or
from a subset of languages. selecting a subset of languages saves disk space, but it is IMPORTANT to choose all the
languages that are needed by all the downstream servers and client computers of a WSUS server.
Following are some IMPORTANT notes about the update language that you should keep in mind before configure
this option:
Always include English in addition to any other languages that are required throughout your organization.
All updates are based on English language packs.
Downstream servers and client computers will not receive all the updates they need if you have not selected
all the necessary languages for the upstream server. Make sure you select all the languages that will be
needed by all the client computers that are associated with all the downstream servers.
You should generally download updates in all languages on the root WSUS server that synchronizes to
Microsoft Update. This selection guarantees that all downstream servers and client computers will receive
updates in the languages that they require.
If you are storing updates locally, and you have set up a WSUS server to download updates in a limited number of
languages, you may notice that there are updates in languages other than the ones you specified. Many update files
are bundles of several different languages, which include at least one of the languages specified on the server.
Upstream servers
NOTE
Configure upstream servers to synchronize updates in all languages that are required by downstream replica servers. You will
not be notified of needed updates in the unsynchronized languages.
Updates will appear as Not Applicable on client computers that require the language. To avoid this, make sure all
operating system languages are included in your WSUS server's synchronization options. You can see all the
operating system languages by going to the computers view of the WSUS Administration Console and sorting the
computers by operating system language. However, you may want to include more languages if there are
Microsoft applications in more than one language (for example, if the French version of Microsoft Word is installed
on some computers that use the English version of Windows 8.
Choosing languages for an upstream server is not the same as choosing languages for a downstream server. The
following procedures explain the differences.
To choose update languages for a server synchronizing from Microsoft Update
1. In the WSUS Configuration Wizard:
To get updates in all languages, click Download updates in all languages, including new
languages.
To get updates only for specific languages, click Download updates only in these languages, and
then select the languages for which you want updates.
To choose update languages for a downstream server
1. If the upstream server has been configured to download update files in a subset of languages: In the WSUS
Configuration Wizard, click Download updates only in these languages (only languages marked with
an asterisk are supported by the upstream server), and then select the languages for which you want
updates.
> [!NOTE]
> You should do this even though you want the downstream server to download the same languages as the
upstream server.
a. If the upstream server has been configured to download update files in all languages: In the WSUS
Configuration Wizard, click Download updates in all languages supported by the upstream
server.
NOTE
You should do this even though you want the downstream server to download the same languages as the
upstream server. This setting causes the upstream server to download updates in all languages, including
languages that were not originally configured for the upstream server. If you add languages to the upstream
server, you should copy the new updates to its replica servers.
Changing language options on the upstream server alone might cause a mismatch between the number of
updates that are approved on the central server and the number of updates approved on the replica servers.
1.5. Plan WSUS computer groups
WSUS allows you to target updates to groups of client computers, so you can ensure that specific computers
always get the right updates at the most convenient times. For example, if all the computers in one department
(such as the Accounting team) have a specific configuration, you can set up a group for that team, decide which
updates their computers need and what time they should be installed, and then use WSUS reports to evaluate the
updates for the team.
NOTE
If a WSUS server is running in replica mode, computer groups cannot be created on that server. All the computer groups that
are needed for client computers of the replica server must be created on the WSUS server that is the root of the WSUS server
hierarchy. For more information about replica mode, see Manage WSUS Replica Servers Manage WSUS Replica Servers in the
WSUS 3.0 SP2 Operations Guide.
Computers are always assigned to the All computers group, and they remain assigned to the Unassigned
computers group until you assign them to another group. Computers can belong to more than one group.
Computer groups can be set up in hierarchies (for example, the Payroll group and the Accounts Payable group
below the Accounting group). Updates that are approved for a higher group will automatically be deployed to
lower groups, in addition to the higher group. In this example, if you approve Update1 for the Accounting group,
the update will be deployed to all the computers in the Accounting group, all the computers in the Payroll group,
and all the computers in the Accounts Payable group.
Because computers can be assigned to multiple groups, it is possible for a single update to be approved more than
once for the same computer. However, the update will be deployed only once, and any conflicts will be resolved by
the WSUS server. To continue with the previous example, if computerA is assigned to the Payroll group and the
Accounts Payable group, and Update1 is approved for both groups, it will be deployed only once.
You can assign computers to computer groups by using one of two methods, server-side targeting or client-side
targeting. Following are the definitions for each method:
Server-side targeting: You manually assign one or more client computers to multiple groups
simultaneously.
Client-side targeting: You use Group Policy or edit the registry settings on client computers to enable
those computers to automatically add themselves into the previously created computer groups.
Conflict Resolution
The server applies the following rules to resolve conflicts and determine the resultant action on clients:
1. Priority
2. Install/Uninstall
3. Deadline
Priority
The actions associated with the group of the highest priority override the actions of other groups. The deeper a
group appears within the hierarchy of groups, the higher its priority. Priority is assigned only based on depth; all
branches have equal priority. For example, a group two levels beneath the Desktops branch has a higher priority
than a group one level beneath the Server branch.
In the following text example of the Update Services console hierarchy pane, for a WSUS server named WSUS-01,
computer groups named Desktop computers and Server have been added to the default All computers group.
Both the Desktop computers and Server groups are at the same hierarchical level.
Update Services
WSUS-01
Updates
computers
All computers
Unassigned computers
Desktop computers
Desktops-L1
Desktops-L2
Servers
Servers-L1
Downstream Servers
Synchronizations
Reports
Options
In this example, the group two levels beneath the Desktop computers branch (Desktops L2) has a higher priority
than the group one level beneath the Server branch (Servers L1). Accordingly, for a computer that has membership
in both the Desktops-L2 and the Servers-L1 groups, all actions for the Desktops-L2 group take priority over actions
specified for the Servers-L1 group.
Priority of Install and Uninstall
Install actions override uninstall actions. Required installs override optional installs (optional installs are only
available through the API and changing an approval for an update using the WSUS Administration Console will
clear all optional approval.)
Priority of Deadlines
Actions that have a deadline override those with no deadline. Actions with earlier deadlines override those with
later deadlines.
1.6. Plan WSUS performance considerations
There are some areas that you should carefully plan before deploy WSUS so that you can have optimized
performance. The key areas are:
Network setup
Deferred download
Filters
Installation
Large update deployments
Background Intelligent Transfer Service (BITS)
Network setup
To optimize performance in WSUS networks, consider the following suggestions:
1. Set up WSUS networks in a hub-and-spoke topology rather than in a hierarchical topology.
2. Use DNS netmask ordering for roaming client computers, and configure roaming client computers to obtain
updates from the local WSUS server.
Deferred download
You can approve updates, and download the update metadata before you download the update files, this method is
called deferred downloads. When you defer downloads, an update is downloaded only after it is approved. We
recommend that you defer downloads because it optimizes network bandwidth and disk space.
In a hierarchy of WSUS servers, WSUS automatically sets all downstream servers to use the deferred download
setting of the root WSUS server. You can change this default setting. For example, you can configure an upstream
server to perform full, immediate synchronizations, and then configure a downstream server to defer the
downloads.
If you deploy a hierarchy of connected WSUS servers, we recommend that you do not deeply nest the servers. If
you enable deferred downloads and a downstream server requests an update that is not approved on the upstream
server, the downstream server's request forces a download on the upstream server. The downstream server then
downloads the update on a subsequent synchronization. In a deep hierarchy of WSUS servers, delays can occur as
updates are requested, downloaded, and then passed through the server hierarchy. By default, deferred downloads
are enabled when you store updates locally. You can change this option manually.
Filters
WSUS lets you filter update synchronizations by language, product, and classification. In a hierarchy of WSUS
servers, WSUS automatically sets all downstream servers to use the update filtering options that are selected on
the root WSUS server. You can reconfigure download servers to receive only a subset of the languages.
By default, the products to be updated are Windows and Office, and the default classifications are Critical updates,
Security updates, and Definition updates. To conserve bandwidth and disk space, we recommend that you limit
languages to those that you actually use.
Installation
Updates typically consist of new versions of files that already exist on the computer that is being updated. On a
binary level, these existing files might not differ very much from updated versions. The express installation files
feature identifies the exact bytes between versions, creates and distributes updates of only those differences, and
then merges the existing file together with the updated bytes.
Sometimes this feature is called "delta delivery" because it downloads only the delta (difference) between two
versions of a file. Express installation files are larger than the updates that are distributed to client computers
because the express installation file contains all possible versions of each file that is to be updated.
You can use express installation files to limit the bandwidth that is consumed on the local network, because WSUS
transmits only the delta applicable to a particular version of an updated component. However, this comes at the
cost of additional bandwidth between your WSUS server, any upstream WSUS servers, and Microsoft Update, and
requires additional local disk space. By default, WSUS does not use express installation files.
Not all updates are good candidates for distribution by using express installation files. If you select this option, you
obtain express installation files for all updates. If you do not store updates locally, the Windows Update Agent will
decide whether to download the express installation files or the full-file update distributions.
Large update deployment
When you deploy large updates (such as service packs), you can avoid saturating the network by using the
following practices:
1. Use Background Intelligent Transfer Service (BITS) throttling. BITS bandwidth limitations can be controlled
by time-of-day, but they apply to all applications that are using BITS. To learn how to control BITS throttling,
please see Group Policies
2. Use Internet Information Services (IIS) throttling to limit throttling to one or more web services.
3. Use computer groups to control the rollout. A client computer identifies itself as a member of a particular
computer group when it sends information to the WSUS server. The WSUS server uses this information to
determine which updates should be deployed to this computer. You can set up multiple computer groups
and sequentially approve large service pack downloads for a subset of these groups.
Background Intelligent Transfer Service
WSUS uses the Background Intelligent Transfer Service (BITS) protocol for all its file transfer tasks. This includes
downloads to client computers and server synchronizations. BITS enables programs to download files by using
spare bandwidth. BITS maintains file transfers through network disconnections and computer restarts. For more
information, see: Background Intelligent Transfer Service.
1.7. Plan Automatic Updates settings
You can specify a deadline to approve updates on the WSUS server. The deadline causes client computers to install
the update at a specific time, but there are a number of different situations, depending on whether the deadline has
expired, whether there are other updates in the queue for the computer to install, and whether the update (or
another update in the queue) requires a restart.
By default, Automatic Updates polls the WSUS server for approved updates every 22 hours minus a random offset.
If new updates need to be installed, they are downloaded. The time between each detection cycle can be
manipulated from 1 to 22 hours.
You can manipulate the notification options as follows:
1. If Automatic Updates is configured to notify the user of updates that are ready to be installed, the
notification is sent to the System log and to the notification area of the client computer.
2. When a user with appropriate credentials clicks the notification area icon, Automatic Updates displays the
available updates to install. The user must click Install to start the installation. A message appears if the
update requires the computer to be restarted to complete the update. If a restart is requested, Automatic
Updates cannot detect additional updates until the computer is restarted.
If Automatic Updates is configured to install updates on a set schedule, applicable updates are downloaded and
marked as ready to install. Automatic Updates notifies users who have appropriate credentials by using a
notification area icon, and an event is logged in the System log.
At the scheduled day and time, Automatic Updates installs the update and restarts the computer (if necessary), even
if no local administrator is logged on. If a local administrator is logged on and the computer requires a restart,
Automatic Updates displays a warning and a countdown for the restart. Otherwise, the installation occurs in the
background.
If the computer must be restarted, and any user is logged on, a similar countdown dialog box is displayed, which
warns the user about the impending restart. You can manipulate computer restarts with Group Policy.
After the new updates are downloaded, Automatic Updates polls the WSUS server for the list of approved packages
to confirm that the packages it downloaded are still valid and approved. This means that, if a WSUS administrator
removes updates from the list of approved updates while Automatic Updates is downloading updates, only the
updates that are still approved are actually installed.
Step 1: Install the WSUS Server Role
4/24/2017 • 2 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The next step in the deployment of your WSUS server is to install the WSUS server role. The following procedure
describes how to install the WSUS server role by using Server Manager.
IMPORTANT
This installation procedure only covers how to install WSUS using Windows Internal Database (WID). The procedures to install
WSUS using Microsoft SQL Server are documented in this article.
To install the WSUS server role
1. Log on to the server on which you plan to install the WSUS server role by using an account that is a member
of the Local Administrators group.
2. In Server Manager, click Manage, and then click add Roles and Features.
3. On the Before you begin page, click Next.
4. In the select installation type page, confirm that Role-based or feature-based installation option is
selected and click Next.
5. On the select destination server page, choose where the server is located (from a server pool or from a
virtual hard disk). After you select the location, choose the server on which you want to install the WSUS
server role, and then click Next.
6. On the select server roles page, select Windows Server Update Services. Add features that are
required for Windows Server Update Services opens. Click Add Features, and then click Next.
7. On the select featurespage. retain the default selections, and then click Next.
IMPORTANT
WSUS only requires the default Web Server role configuration. If you are prompted for additional Web Server role
configuration while setting up WSUS you can safely accept the default values and continue setting up WSUS.
8. On the Windows Server Update Services page, click Next.
9. On the Select Role Services page, leave the default selections, and then click Next.
TIP
You must select one Database type. If the database options are all cleared (not selected), post installation tasks will
fail.
10. On the Content location selection page, type a valid location to store the updates. For example, you can
create a folder named WSUS_database at the root of drive K specifically for this purpose, and type
k:\WSUS_database as the valid location.
11. Click Next. The Web Server Role (IIS) page opens. Review the information, and then click Next. In select
the role services to install for Web Server (IIS), retain the defaults, and then click Next.
12. On the Confirm installation selections page, review the selected options, and then click Install. The WSUS
installation wizard runs. This might take several minutes to complete.
13. Once WSUS installation is complete, in the summary window on the Installation progress page, click
Launch Post-Installation tasks. The text changes, requesting: Please wait while your server is
configured. When the task has finished, the text changes to: Configuration successfully completed. Click
Close.
14. In Server Manager, verify if a notification appears to inform you that a restart is required. This can vary
according to the installed server role. If it requires a restart make sure to restart the server to complete the
installation.
IMPORTANT
At this point the installation process is finished, however for WSUS to be functional you need to proceed to Step 2: Configure
WSUS.
Step 2: Configure WSUS
4/24/2017 • 22 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
After installing the WSUS server role on your server, you need to properly configure it. The following checklist
summarises the steps involved in performing the initial configuration for your WSUS server.
TASK
DESCRIPTION
2.1. Configure network connections
Configure the cluster network by using the Network
Configuration Wizard.
2.2. Configure WSUS by using the WSUS Configuration
Wizard
Use the WSUS Configuration wizard to perform the base
WSUS configuration.
2.3. Configure WSUS computer groups
Create computer groups in the WSUS administration console
to manage updates in your organization.
2.4. Configure client updates
Specify how and when automatic updates are applied to client
computers.
2.5. Secure WSUS with the Secure Sockets Layer Protocol
Configure Secure Sockets Layer (SSL) protocol to help protect
Windows Server Update Services (WSUS).
2.1. Configure network connections
Before you start the configuration process, be sure that you know the answers to the following questions:
1. Is the server's firewall configured to allow clients to access the server?
2. Can this computer connect to the upstream server (such as the server that is designated to download
updates from Microsoft Update)?
3. Do you have the name of the proxy server and the user credentials for the proxy server, if you need them?
By default, WSUS is configured to use Microsoft Update as the location from which to obtain updates. if you have a
proxy server on the network, you can configure WSUS to use the proxy server. if there is a corporate firewall
between WSUS and the Internet, you might have to configure the firewall to ensure that WSUS can obtain updates.
TIP
Although Internet connectivity is required to download updates from Microsoft Update, WSUS offers you the ability to
import updates onto networks that are not connected to the Internet.
When you have the answers for these questions, you can start configuring the following WSUS network settings:
Updates Specify the way this server will obtain updates (from Microsoft Update or from another WSUS
server).
Proxy if you identified that WSUS needs to use a proxy server to have Internet access, you need to
configure proxy settings in the WSUS server.
Firewall if you identified that WSUS is behind a corporate firewall, there are some additional steps that
must be done at the edge device to properly allow WSUS traffic.
2.1.1. Connection from the WSUS server to the Internet
if there is a corporate firewall between WSUS and the Internet, you might have to configure that firewall to ensure
WSUS can obtain updates. To obtain updates from Microsoft Update, the WSUS server uses port 443 for HTTPS
protocol. Although most of corporate firewalls allow this type of traffic, there are some companies that restrict
Internet access from the servers due the company's security policies. if your company restricts access, you need to
obtain authorization to allow Internet access from WSUS to the following list of URLs:
http://windowsupdate.microsoft.com
http://*.windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://*.update.microsoft.com
https://*.update.microsoft.com
http://*.windowsupdate.com
http://download.windowsupdate.com
http://download.microsoft.com
http://*.download.windowsupdate.com
http://wustat.windows.com
http://ntservicepack.microsoft.com
http://go.microsoft.com
IMPORTANT
For a scenario in which WSUS is failing to obtain updates due firewall configurations, see article 885819 in the Microsoft
Knowledge Base.
The following section describes how to configure a corporate firewall that is positioned between WSUS and the
Internet. Because WSUS initiates all the network traffic, you it is not necessary to configure Windows Firewall on
the WSUS server. Although the connection between Microsoft Update and WSUS requires ports 80 and 443 to be
open, you can configure multiple WSUS servers to synchronize with a custom port.
2.1.2. Connection between WSUS servers
WSUS upstream and downstream servers will synchronize on the port configured by the WSUS Administrator. By
default, these ports are configured as follows:
On WSUS 3.2 and earlier, port 80 for HTTP and 443 for HTTPS
On WSUS 6.2 and later (at least Windows Server 2012 ), port 8530 for HTTP and 8531 for HTTPS are used
The firewall on the WSUS server must be configured to allow inbound traffic on these ports.
2.1.3. Connection between clients (Windows Update Agent) and WSUS servers
The listening interfaces and ports are configured in the IIS site(s) for WSUS and in any Group Policy settings used
to configure client PCs. The default ports are the same as those specified in the preceding section Connection
between WSUS servers, and the firewall on the WSUS server must also be configured to allow inbound traffic on
these ports.
Configure the proxy server
If the corporate network uses proxy servers, the proxy servers must support HTTP and SSL protocols and use basic
authentication or Windows authentication. These requirements can be met by using one of the following
configurations:
1. A single proxy server that supports two protocol channels. In this case, set one channel to use HTTP and the
other channel to use HTTPS.
NOTE
You can set up one proxy server that handles both protocols for WSUS during the WSUS server software installation.
2. Two proxy servers, each of which supports a single protocol. In this case, one proxy server is configured to
use HTTP, and the other proxy server is configured to use HTTPS.
To set up two proxy servers, each of which will handle one protocol for WSUS, use the following procedure:
To set up WSUS to use two proxy servers
1. Log on to the computer that is to be the WSUS server by using an account that is a member of the local
Administrators group.
2. Install the WSUS server role. During the WSUS Configuration Wizard (discussed in the next section) do not
specify a proxy server.
3. Open a command prompt (Cmd.exe) as an administrator. To open a command prompt as an administrator,
go to Start. In Start Search, type Command prompt. at the top of the start menu, right-click Command
prompt, and then click Run as administrator. if the User Account Control dialog box appears, enter the
appropriate credentials (if requested), confirm that the action it displays is what you want, and then click
Continue.
4. In the Command prompt window, go to the C:\Program Files\Update Services\Tools folder. type the
following command:
wsusutil ConfigureSSlproxy [< proxy_server proxy_port>] -enable, where:
a. proxy_server is the name of the proxy server that supports HTTPS.
b. proxy_port is the proxy server port number.
5. Close the Command prompt window.
To add the proxy server that uses the HTTP protocol to the WSUS configuration, use the following procedure:
To add a proxy server that uses the HTTP protocol
1. Open the WSUS Administration Console.
2. In the left pane, expand the server name, and then click Options.
3. In the Options pane, click Update Source and Update Server, and then click the Proxy Server tab.
4. Use the following options to modify the existing proxy server configuration:
To c h a n g e o r a d d a p ro x y s e rv e r t o t h e W SU S c o n f i g u ra t i o n
a. Select the check box for Use a proxy server when synchronizing.
b. In the Proxy server name text box, type the name of the proxy server.
c. In the Proxy port number text box, type the port number of the proxy server. The default port
number is 80.
d. Ff the proxy server requires that you use a specific user account, select the Use user credentials to
connect to the proxy server check box. type the required user name, domain, and password into
the corresponding text boxes.
e. If the proxy server supports basic authentication, select the Allow basic authentication (password
is sent in cleartext) check box.
f. Click OK.
To re mo v e a p ro x y s e rv e r f ro m t h e W SU S c o n f i g u ra t i o n
a. To remove a proxy server from the WSUS configuration, clear the check box for Use a proxy server
when synchronizing.
b. Click OK.
2.2. Configure WSUS by using the WSUS Configuration Wizard
This procedure assumes that you are using the WSUS Configuration Wizard, which appears the first time you
launch the WSUS Management Console. Later in this topic, you will learn how to perform these configurations by
using the Options page:
To configure WSUS
1. In the Server Manager navigation pane, click Dashboard, click Tools, and then click Windows Server
Update Services.
NOTE
If the complete WSUS Installation dialog box appears, click Run. In the complete WSUS Installation dialog box,
click Close when the installation successfully finishes.
2. The Windows Server Update Services Wizard opens. On the Before you Begin page, review the
information, and then click Next.
3. Read the instructions on the Join the Microsoft Update Improvement Program page and evaluate if
you want to participate. If you want to participate in the program. retain the default selection, or clear the
check box, and then click Next.
4. On the Choose Upstream Server page, there are two options:
a. Synchronize the updates with Microsoft Update
b. Synchronize from another Windows Server Update Services server
if you choose to synchronize from another WSUS server, specify the server name and the port
on which this server will communicate with the upstream server.
To use SSL, select the Use SSL when synchronizing update information check box. The
servers will use port 443 for synchronization. (Make sure that this server and the upstream
server support SSL).
if this is a replica server, select the This is a replica of the upstream server check box.
5. After selecting the proper options for your deployment, click Next to proceed.
6. On the Specify Proxy Server page, select the Use a proxy server when synchronizing check box, and
then type the proxy server name and port number (port 80 by default) in the corresponding boxes.
IMPORTANT
You must complete this step if you identified that WSUS needs a proxy server to have Internet access.
7. if you want to connect to the proxy server by using specific user credentials, select the Use user credentials
to connect to the proxy server check box, and then type the user name, domain, and password of the
user in the corresponding boxes. if you want to enable basic authentication for the user who is connecting
to the proxy server, select the Allow basic authentication (password is sent in cleartext) check box.
8. Click Next. On the Connect to Upstream Server page, click start Connecting.
9. When it connects, click Next to proceed.
10. On the Choose Languages page, you have the option to select the languages from which WSUS will
receive updates - all languages or a subset of languages. selecting a subset of languages will save disk
space, but it is IMPORTANT to choose all of the languages that are needed by all the clients of this WSUS
server. if you choose to get updates only for specific languages, select Download updates only in these
languages, and then select the languages for which you want updates; otherwise, leave the default
selection.
WARNING
if you select the option Download updates only in these languages, and this server has a downstream WSUS
server connected to it, this option will force the downstream server to also use only the selected languages.
11. After selecting the appropriate language options for your deployment, click Next to continue.
12. The Choose Products page allows you specify the products for which you want updates. select product
categories, such as Windows, or specific products, such as Windows Server 2008. selecting a product
category selects all the products in that category.
13. select the appropriate product options for your deployment, and then click Next.
14. On the Choose Classifications page, select the update classifications that you want to obtain. Choose all
the classifications or a subset of them, and then click Next.
15. The Set Sync Schedule page enables you to select whether to perform synchronization manually or
automatically.
if you choose Synchronize manually, you must start the synchronization process from the WSUS
Administration Console.
if you choose Synchronize automatically, the WSUS server will synchronize at set intervals.
Set the time for the First synchronization, and then specify the number of Synchronizations per day
that you want this server to perform. For example, if you specify that there should be four synchronizations
per day, starting at 3:00 A.M., synchronizations will occur at 3:00 A.M., 9:00 A.M., 3:00 P.M., and 9:00 P.M.
16. After selecting the appropriate synchronization options for your deployment, click Next to continue.
17. On the Finished page, you have the option to start the synchronization now by selecting the Begin initial
synchronization check box. if you do not select this option, you need to use WSUS Management Console
to perform the initial synchronization. Click Next if you want to read more about additional settings, or you
can click Finish to conclude this wizard and finish the initial WSUS setup.
18. After you click Finish, the WSUS Management Console appears.
Now that you have performed the basic WSUS configuration, read the next sections for more details about
changing the settings by using WSUS Management Console.
2.3. Configure WSUS computer groups
computer groups are an IMPORTANT part of Windows Server Update Services (WSUS) deployments. Computer
groups permit you to test and target updates to specific computers. There are two default computer groups: All
computers and Unassigned computers. By default, when each client computer first contacts the WSUS server, the
server adds that client computer to both of these groups.
You can create as many custom computer groups as you need to manage updates in your organization. As a best
practice, create at least one computer group to test updates before you deploy them to other computers in your
organization.
Use the following procedure to create a new group and assign a computer to this group:
To create a computer group
1. In the WSUS Administration Console, under Update Services, expand the WSUS server, expand
computers, right-click All computers, and then click add computer Group.
2. In the add computer Group dialog box, in Name, specify the name of the new group, and click then add.
3. Click computers, and then select the computers that you want to assign to this new group.
4. Right-click the computer names that you selected in the previous step, and then click change Membership.
5. In the Set computer Group Membership dialog box, select the test group that you created, and then click
OK.
2.4. Configure client updates
WSUS Setup automatically configures IIS to distribute the latest version of Automatic Updates to each client
computer that contacts the WSUS server. The best way to configure Automatic Updates depends on the network
environment.
In an environment that uses active directory directory service, you can use an existing domain-based Group
Policy Object (GPO) or create a new GPO.
In an environment without active directory, use the Local Group Policy editor to configure Automatic
Updates, and then point the client computers to the WSUS server.
IMPORTANT
The following procedures assume that your network runs active directory. These procedures also assume that you are
familiar with Group Policy and you use it to manage the network.
Use the following procedures to configure Automatic Updates for client computers:
Step 4: Configure Group Policy Settings for Automatic Updates
2.3. Configure computer groups in this topic
Configure Automatic Updates in Group Policy
if you have set up active directory in your network, you can configure one or multiple computers simultaneously
by including them in a Group Policy Object (GPO), and then configuring that GPO with WSUS settings. We
recommend that you create a new GPO that contains only WSUS settings.
Link this WSUS GPO to an active directory container that is appropriate for your environment. In a simple
environment, you might link a single WSUS GPO to the domain. In a more complex environment, you might link
multiple WSUS GPOs to several organizational units (OUs), which will enable you to apply different WSUS policy
settings to different types of computers.
To e n a b l e W SU S t h r o u g h a d o m a i n G P O
1. In the Group Policy Management Console (GPMC), browse to the GPO on which you want to configure
WSUS, and then click edit.
2. In the GPMC, expand computer Configuration, expand Policies, expand Administrative Templates,
expand Windows components, and then click Windows Update.
3. In the details pane, double-click Configure Automatic Updates. The Configure Automatic Updates
policy opens.
4. Click Enabled, and then select one of the following options under the Configure automatic updating
setting:
Notify for download and notify for install. This option notifies a logged-on administrative user
before you download and install the updates.
Auto download and notify for install. This option automatically begins downloading updates and
then notifies a logged-on administrative user before installing the updates. By default, this option is
selected.
Auto download and schedule the install. This option automatically begins downloading updates
and then installs the updates on the day and time that you specify.
Allow local admin to choose setting. This option lets local administrators to use Automatic
Updates in Control Panel to select a configuration option. For example, they can choose a scheduled
installation time. Local administrators cannot disable Automatic Updates.
5. select Enable client-side targeting, select Enabled, and then type the name of the WSUS computer group
to which you want to add this computer in the Target group name for this computer box.
NOTE
Enable client-side targeting enables client computers to add themselves to target computer groups on the WSUS
server, when Automatic Updates is redirected to a WSUS server. if the status is set to Enabled, this computer will
identify itself as a member of a particular computer group when it sends information to the WSUS server, which uses
it to determine which updates are deployed to this computer. This setting indicates to the WSUS server which group
the client computer will use. You must create the group on the WSUS server, and add domain-member computers to
that group.
6. Click OK to close the Enable client-side targeting policy and return to the Windows Update details pane.
7. Click OK to close the Configure Automatic Updates policy and return to the Windows Update details
pane.
8. In the Windows Update details pane, double-click Specify intranet Microsoft update service location.
9. Click Enabled, and then, server in the Set the intranet update service for detecting updates and Set
the intranet statistics server text boxes, type the same URL of the WSUS server. For example, type
http://servername in both boxes (where servername is the name of the WSUS server).
WARNING
When you type the intranet address of your WSUS server make sure to specify which port is going to be used. By
default WSUS will use port 8530 for HTTP and 8531 for HTTPS. For example, if you are using HTTP, you should type
http://servername:8530.
10. Click OK.
After you set up a client computer, it will take several minutes before the computer appears on the computers
page in the WSUS Administration Console. For client computers that are configured with a domain-based Group
Policy Object, it can take about 20 minutes for Group Policy to apply the new policy settings to the client computer.
By default, Group Policy updates in the background every 90 minutes, with a random offset of 0-30 minutes. if you
want to update Group Policy sooner, you can open a Command prompt window on the client computer and type
gpupdate /force.
for client computers that are configured by using the Local Group Policy editor, the GPO is applied immediately,
and the update takes about 20 minutes. if you begin detection manually, you do not have to wait 20 minutes for
the client computer to contact WSUS.
Because waiting for detection to start can be a time-consuming process, you can use the following procedure to
initiate detection immediately.
To i n i t i a t e W SU S d e t e c t i o n
1. On the client computer, open a Command prompt window with elevated privileges.
2. type wuauclt.exe /detectnow, and then press ENTER.
2.5. Secure WSUS with the Secure Sockets Layer Protocol
You can use the Secure Sockets Layer (SSL) protocol to help secure the WSUS deployment. WSUS uses SSL to
authenticate client computers and downstream WSUS servers to the WSUS server. WSUS also uses SSL to encrypt
update metadata.
IMPORTANT
Clients and downstream servers that are configured to use Transport Layer Security (TLS) or HTTPS must also be configured
to use a fully qualified domain name (FQDN) for their upstream WSUS server.
WSUS uses SSL for metadata only, not for update files. This is the same way that Microsoft Update distributes
updates. Microsoft reduces the risk of sending update files over an unencrypted channel by signing each update. In
addition, a hash is computed and sent together with the metadata for each update. When an update is
downloaded, WSUS checks the digital signature and hash. if the update has been changed, it is not installed.
Limitations of WSUS SSL deployments
You must consider the following limitations when you use SSL to secure a WSUS deployment:
1. Using SSL increases the server workload. You should expect a 10 percent loss of performance because of
the cost of encrypting all the metadata that is sent over the network.
2. if you use WSUS with a remote SQL Server database, the connection between the WSUS server and the
database server is not secured by SSL. if the database connection must be secured, consider the following
recommendations:
move the WSUS database to the WSUS server.
move the remote database server and the WSUS server to a private network.
Deploy Internet Protocol security (IPsec) to help secure network traffic. For more information about IPsec,
see Creating and Using IPsec Policies.
Configure SSL on the WSUS server
WSUS requires two ports for SSL: one port that uses HTTPS to send encrypted metadata, and one port that uses
HTTP to send updates. When you configure WSUS to use SSL, consider the following:
You cannot configure the whole WSUS website to require SSL because all traffic to the WSUS site would
have to be encrypted. WSUS encrypts update metadata only. if a computer attempts to retrieve update files
on the HTTPS port, the transfer will fail.
You should require SSL for the following virtual roots only:
SimpleAuthWebService
DSSAuthWebService
ServerSyncWebService
APIremoting30
ClientWebService
You should not require SSL for the following virtual roots:
Content
Inventory
ReportingWebService
SelfUpdate
The certificate of the certification authority (CA) must be imported into the local computer Trusted Root CA
store, or the Windows Server Update Service Trusted Root CA store on downstream WSUS servers. if the
certificate is only imported to the Local User Trusted Root CA store, the downstream WSUS server will not
be authenticated on the upstream server.
for more information about how to use SSL certificates in IIS, see Require Secure Sockets Layer (IIS 7).
You must import the certificate to all computers that will communicate with the WSUS server. This includes
all client computers, downstream servers, and computers that run the WSUS Administration Console. The
certificate should be imported into the local computer Trusted Root CA store or into the Windows Server
Update Service Trusted Root CA store.
You can use any port for SSL. However, the port that you set up for SSL also determines the port that WSUS
uses to send clear HTTP traffic. Consider the following examples:
if you use the industry standard port of 443 for HTTPS traffic, WSUS uses the industry standard port
80 for clear HTTP traffic.
if you use any port other than 443 for HTTPS traffic, WSUS will send clear HTTP traffic over the port
that numerically comes before the port for HTTPS. For example, if you use port 8531 for HTTPS,
WSUS will use port 8530 for HTTP.
You must re-initialize ClientServicingProxy if the server name, SSL configuration, or port number are
changed.
To c o n fi g u r e SSL o n t h e W SU S r o o t se r v e r
1. Log on to the WSUS server by using an account that is a member of the WSUS Administrators group or the
local Administrators group.
2. Go to start, type CMD, right-click Command prompt, and then click Run as administrator.
3. Navigate to the %ProgramFiles%\Update Services\Tools\ folder.
4. In the Command prompt window, type the following command:
Wsusutil configuresslcertificateName
where:
certificateName is the DNS name of the WSUS server.
Configure SSL on client computers
When you configure SSL on client computers, you should consider the following issues:
You must include a URL for a secure port on the WSUS server. Because you cannot require SSL on the
server, the only way to make sure that client computers can use a security channel is by using a URL that
specifies HTTPS. if you use any port other than 443 for SSL, you must include that port in the URL also.
The certificate on a client computer must be imported into the Local computer Trusted Root CA store or
Automatic Update Service Trusted Root CA store. if the certificate is imported to the Local User's Trusted
Root CA store only, Automatic Updates will fail server authentication.
The client computers must trust the certificate that you bind to the WSUS server. Depending on the type of
certificate that is used, you might have to set up a service to enable the client computers to trust the
certificate that is bound to the WSUS server.
Configure SSL for downstream WSUS servers
The following instructions configure a downstream server to synchronize to an upstream server that uses SSL.
To sy n c h r o n i z e a d o w n st r e a m se r v e r t o a n u p st r e a m se r v e r t h a t u se s SSL
1. Log on to the computer by using a user account that is a member of the local Administrators group or the
WSUS Administrators group.
2. Click start, click All Programs, click Administrative Tools, and then click Windows Server Update
Service.
3. In the right pane, expand the server name.
4. Click Options, and then click Update Source and Proxy Server.
5. On the Update Source page, select Synchronize from another Windows Server Update Services
server.
6. type the name of the upstream server into the Server name text box. type the port number that the server
uses for SSL connections into the Port number text box.
7. select the Use SSL when synchronizing update information check box, and then click OK.
additional SSL resources
The steps that are required to set up a certification authority, bind the certificate to the WSUS website, and
establish a trust between the client computers and the certificate are beyond the scope of this guide. For more
information and for instructions about how to install certificates and set up this environment, see the following
topics:
Suite B PKI Step-by-Step Guide
Implementing and Administering Certificate Templates
active directory Certificate Services Upgrade and Migration Guide
Configure Certificate Autoenrollment
2.6. Complete IIS Configuration
By default, anonymous read access is enabled for the default and all new IIS websites. Some applications, notably
Windows SharePoint Services, may remove anonymous access. if this has occurred, you must re-enable the
anonymous read access before you can successfully install and operate WSUS.
To enable anonymous read access, follow the steps for the applicable version of IIS:
1. Enable Anonymous Authentication (IIS 7), as documented in the IIS 7 Operations Guide.
2. Enabling Anonymous Authentication (IIS 6.0), as documented in the IIS 6.0 Operations Guide.
2.7. Configure a Signing Certificate
WSUS has the ability to publish custom update packages to update Microsoft and non-Microsoft products. WSUS
can automatically sign these custom update packages for you with an Authenticode certificate. To enable custom
update signing, you must install a package signing certificate on your WSUS server. There are several
considerations associated with custom update signing.
1. Certificate Distribution. The private key must be installed on the WSUS server, and the public key must be
explicitly installed in the trusted certificate store on all client PCs and servers which are to receive customsigned updates.
2. Expiration. When the self-signed certificate expires or nears expiration, WSUS will log events in the event
log.
3. Certificate Updates/Revocation. if you wanted to update or revoke a certificate (i.e. after discovering that
it expired), WSUS offered no functionality to enable this. Accomplishing this turned into a manual task that
was very hard to either do by hand or automate successfully.
Step 3: Approve and Deploy Updates in WSUS
4/24/2017 • 3 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Computers in a computer group automatically contact the WSUS server over the next 24 hours to obtain updates.
You can use the WSUS reporting feature to determine whether those updates were deployed to the test computers.
When the tests are successfully completed, you can approve the updates for the applicable computer groups in
your organization. The following checklist describes the steps to approve and deploy updates by using WSUS
management console.
TASK
DESCRIPTION
3.1. Approve and deploy WSUS updates
Approve and deploy WSUS updates by using the WSUS
Management Console.
3.2. Configure auto-approval rules
Configure WSUS to automatically approve installation of
updates for selected groups, and how to approve revisions to
existing updates.
3.3. Review installed updates with WSUS Reports
Review the updates that were installed, the computers that
received those updates and other details by using the WSUS
Reporting feature.
3.1. Approve and deploy WSUS updates
Use the following procedure to approve and deploy updates.
To approve and deploy WSUS updates
1. On the WSUS Administration Console, click Updates. In the right pane, an update status summary is
displayed for All Updates, Critical Updates, Security Updates, and WSUS Updates.
2. In the All Updates section, click Updates needed by computers.
3. In the list of updates, select the updates that you want to approve for installation in your test computer
group. Information about a selected update is available in the bottom pane of the Updates panel. To select
multiple contiguous updates, hold down the shift key while clicking the update names. To select multiple
noncontiguous updates, press down the CTRL key while clicking the update names.
4. Right-click the selection, and then click Approve.
5. In the Approve Updates dialog box, select your test group, and then click the down arrow.
6. Click Approved for Install, and then click OK.
7. The Approval Progress window appears, which shows the progress of the tasks that affect update approval.
When the approval process is complete, click Close.
3.2. Configure auto-approval rules
Automatic Approvals enables you to specify how to automatically approve installation of updates for selected
groups, and how to approve revisions to existing updates.
To configure Automatic Approvals
1. In the WSUS Administration Console, under Update Services, expand the WSUS server, and then click
Options. The Options window opens.
2. In Options, click Automatic Approvals. The Automatic Approvals dialog opens.
3. In Update Rules, click New Rule. The add Rule dialog opens.
4. In add Rule, in Step 1: select Properties, select any single option, or combination of options from the
following:
When an update is in a specific classification
When an update is in a specific product
Set a deadline for the approval
5. In Step 2: edit the properties, click each of the options listed, and then select the appropriate options for
each.
6. In Step 3: Specify a name, type a name for your rule, and then click OK.
7. Click OK to close the Automatic Approvals dialog.
3.3. Review installed updates with WSUS Reports
24 hours after you approve the updates, you can use the WSUS Reports feature to determine whether the updates
were deployed to the test group computers. To check the status of an update, you can use the WSUS Reports
feature as follows.
To review updates
1. In the navigation pane of the WSUS Administration Console, click Reports.
2. On the Reports page, click the Update Status Summary report. The Updates Report window appears.
3. If you want to filter the list of updates, select the criteria that you want to use, for example, Include updates
in these classifications, and then click Run Report.
4. You will see the Updates Report pane. You can check the status of individual updates by selecting the
update in the left section of the pane. The last section of the report pane shows the status summary of the
update.
5. You can save or print this report by clicking the applicable icon on the toolbar.
6. After you test the updates, you can approve the updates for installation on the applicable computer groups
in your organization.
Step 4: Configure Group Policy Settings for
Automatic Updates
4/24/2017 • 38 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
In an active directory environment, you can use Group Policy to define how computers and users (referred to in
this document as WSUS clients) can interact with Windows Updates to obtain automatic updates from Windows
Server Update Services (WSUS).
This topic contains two main sections:
Group Policy settings for WSUS client updates, which provides prescriptive guidance and behavioral details about
the Windows Update and Maintenance Scheduler settings of Group Policy that control how WSUS clients can
interact with Windows Update to obtain automatic updates.
Supplemental information has the following sections:
Accessing the Windows Update settings in Group Policy, which provides general guidance about using
Group Policy Management editor, and information about accessing the Update Services policy extensions
and Maintenance Scheduler settings in Group Policy.
Changes to WSUS relevant to this guide: for administrators familiar with WSUS 3.2 and previous versions,
this section gives a brief summary of key differences between the current and past version of WSUS
relevant to this guide.
Terms and Definitions: definitions for various terms pertaining to WSUS and update services that are used
in this guide.
Group Policy settings for WSUS client updates
This section provides information about three extensions of Group Policy. In these extensions you will find the
settings that you can use to configure how WSUS clients can interact with Windows Update to receive automatic
updates.
computer Configuration > Windows Update policy settings
computer Configuration > Maintenance Scheduler policy settings
User Configuration > Windows Update policy settings
NOTE
This topic assumes that you already use and are familiar with Group Policy. If you are not familiar with Group Policy, it is
advised that you review the information in the Supplemental information section of this document before attempting to
configure policy settings for WSUS.
Computer Configuration > Windows Update policy settings
This section provides details about the following computer-based policy settings:
Allow Automatic Updates immediate installation
Allow non-administrators to receive update notifications
Allow signed updates from an intranet Microsoft update service location
Automatic Updates detection frequency
Configure Automatic Updates
delay Restart for scheduled installations
Do not adjust default option to "Install Updates and Shut Down" in Shut Down Windows dialog
Do not display "Install updates and Shut Down" option in Shut Down Windows dialog
Enable client-side targeting
Enabling Windows Update Power Management to automatically wake up the computer to install scheduled
updates
No auto-restart with logged on users for scheduled automatic updates installations
Re-prompt for restart with scheduled installations
Reschedule Automatic Updates scheduled installations
Specify intranet Microsoft update service location
Turn on recommended updates via Automatic Updates
Turn on Software Notifications
In the GPME, Windows Update policies for computer-based configuration are located in the path: PolicyName >
Computer Configuration > Policies > Administrative Templates > Windows components > Windows
Update.
NOTE
By default, these settings are not configured.
Allow Automatic Updates immediate installation
Specifies whether Automatic Updates will automatically install updates that do not interrupt Windows services or
restart Windows.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
if the "Configure Automatic Updates" policy setting is set to Disabled, this policy has no effect.
Policy setting state
Behavior
Not Configured
Specifies that updates are not immediately installed. Local
administrators can change this setting by using the Local
Group Policy editor.
Enabled
Specifies that Automatic Updates immediately installs updates
after they are downloaded and ready to install.
Disabled
Specifies that updates are not immediately installed.
Options: There are no options for this setting.
Allow non-administrators to receive update notifications
Specifies whether non-administrative users will receive update notifications based on the Configure Automatic
Updates policy setting.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
See details in the table below.
NOTE
if the "Configure Automatic Updates" policy setting is disabled or is not configured, this policy setting has no effect.
IMPORTANT
starting in Windows 8 and Windows RT, this policy setting is enabled by default. In all prior versions of Windows, it is
disabled by default.
Policy setting state
Behavior
Not Configured
Specifies that users will always see an Account Control window
and require elevated permissions to do these tasks. A local
administrator can change this setting by using the Local
Group Policy editor.
Enabled
Specifies that Windows Automatic Update and Microsoft
Update will include non-administrators when determining
which signed-in user will receive update notifications. Nonadministrative users will be able to install all optional,
recommended, and IMPORTANT update content for which
they received a notification. Users will not see a User Account
Control window, and they do not need elevated permissions
to install these updates, except in the case of updates that
contain User Interface, End User License Agreement, or
Windows Update setting changes.
There are two situations where the effect of this setting
depends on the operating computer:
1. Hide or Restore updates
2. Cancel an update installation
In Windows Vista or Windows XP, if this policy setting is
enabled, users will not see a User Account Control window,
and they do not need elevated permissions to hide, restore, or
cancel updates.
In Windows Vista, if this policy setting is enabled, users will
not see a User Account Control window, and they do not
need elevated permissions to hide, restore, or cancel updates.
If this policy setting is not enabled, users will always see an
Account Control window, and they require elevated
permissions to hide, restore, or cancel updates.
In Windows 7 , this policy setting has no effect. Users will
always see an Account Control window, and they require
elevated permissions to do these tasks.
In Windows 8 and Windows RT, this policy setting has no
effect.
Disabled
Specifies that only logged-on administrators receive update
notifications. Note: In Windows 8 and Windows RT, this policy
setting is enabled by default. In all prior versions of Windows,
it is disabled by default.
Options: There are no options for this setting.
Allow signed updates from an intranet Microsoft update service location
Specifies whether Automatic Updates accepts updates that are signed by entities other than Microsoft when the
update is found on an intranet Microsoft update service location.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
Windows RT
NOTE
Updates from a service other than an intranet Microsoft update service must always be signed by Microsoft, and they are
not affected by this policy setting.
NOTE
This policy is not supported on Windows RT. Enabling this policy will not have any effect on computers running Windows RT.
Options: There are no options for this setting.
Policy setting state
Behavior
Not Configured
Specifies that updates from an intranet Microsoft update
service location must be signed by Microsoft.
Enabled
Specifies that Automatic Updates accepts updates received
through an intranet Microsoft update service location if they
are signed by a certificate found in the local computer's
"Trusted Publishers" certificate store.
Disabled
Specifies that updates from an intranet Microsoft update
service location must be signed by Microsoft.
Options: There are no options for this setting.
Always automatically restart at the scheduled time
Specifies whether a restart timer will always begin immediately after Windows Update installs IMPORTANT
updates, instead of first notifying users on the sign-in screen for at least two days.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
if the "No auto-restart with logged on users for scheduled automatic updates installations" policy setting is enabled, this
policy has no effect.
Policy setting state
Behavior
Not Configured
Specifies that Windows Update will not alter the computer's
restart behavior.
Enabled
Specifies that a restart timer will always begin immediately
after Windows Update installs IMPORTANT updates, instead
of first notifying users on the sign-in screen for at least two
days.
The restart timer can be configured to start with any value
from 15 to 180 minutes. When the timer runs out, the restart
will proceed even if the computer has signed-in users.
Disabled
Specifies that Windows Update will not alter the computer's
restart behavior.
Options: if this setting is enabled, you can specify the amount of time that will elapse after updates are installed
before a forced computer restart occurs.
Automatic Updates detection frequency
Specifies the hours that Windows will use to determine how long to wait before checking for available updates. The
exact wait time is determined by using the hours specified here minus zero to twenty percent of the hours
specified. For example, if this policy is used to specify a 20 hour detection frequency, all clients to which this policy
is applied will check for updates anywhere between 16 and 20 hours.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
Windows RT
NOTE
The "Specify intranet Microsoft update service location" setting must be enabled for this policy to have effect.
if "Configure Automatic Updates" policy setting is disabled, this policy has no effect.
NOTE
This policy is not supported on Windows RT. Enabling this policy will not have any effect on computers running Windows RT.
Policy setting state
Behavior
Not Configured
Specifies that Windows will check for available updates at the
default interval of 22 hours.
Enabled
Specifies that Windows will check for available updates at the
specified interval.
Disabled
Specifies that Windows will check for available updates at the
default interval of 22 hours.
Options: if this setting is enabled, you can specify the time interval (in hours) that Windows Update waits before
checking for updates.
Configure Automatic Updates
Specifies specify whether automatic updates are enabled on this computer.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
Windows RT
if enabled, you must select one of the four options provided in this Group Policy setting.
To use this setting, select Enabled, and then in Options under Configure automatic updating, select one of the
options (2, 3, 4, or 5).
Policy setting state
Behavior
Not Configured
Specifies that the use of automatic updates is not specified at
the Group Policy level. However, a computer administrator can
still configure automatic updates in the Control Panel.
Enabled
Specifies that Windows recognizes when the computer is
online and uses its Internet connection to search Windows
Update for available updates.
When enabled, local administrators will be allowed to use the
Windows Update control panel to select a configuration
option of their choice. However, local administrators will not
be allowed to disable the configuration for Automatic
Updates.
- 2 - Notify for download and notify for install
When Windows Update finds updates that apply to the
computer, users will be notified that updates are ready for
download. Users can then run Windows Update to download
and install any available updates.
- 3 - Auto download and notify for install (default setting)
Windows Update finds applicable updates and downloads
them in the background; the user is not notified or
interrupted during the process. When the downloads are
complete, users are notified that there are updates ready to
install. Users can then run Windows Update to install the
downloaded updates.
- 4 - Auto download and schedule the install
You can specify the schedule by using the options in this
Group Policy setting. If no schedule is specified, the default
schedule for all installations will be every day at 3:00 A.M. If
any updates require a restart to complete the installation,
Windows will restart the computer automatically. (if a user is
signed in to the computer when Windows is ready to restart,
the user will be notified and given the option to delay the
restart.) Note: starting Windows 8, you can set updates to
install during automatic maintenance instead of using a
specific schedule tied to Windows Update. Automatic
maintenance will install updates when the computer is not in
use, and avoid installing updates when the computer is
running on battery power. If automatic maintenance is unable
to install updates within days, Windows Update will install
updates right away. Users will then be notified about a
pending restart. A pending restart will only take place if there
is no potential for accidental data loss. You can specify
schedule options in the GPME Maintenance Scheduler
settings, which are located in the path, PolicyName >
computer Configuration > Policies > Administrative
Templates > Windows components > Maintenance
Scheduler > Automatic Maintenance Activation
Boundary. See the section of this reference titled:
Maintenance Scheduler settings, for setting details. 5 - Allow
local admin to choose setting
- Specifies whether local administrators are allowed to use the
Automatic Updates control panel to select a configuration
option of their choice for example, whether local
administrators can choose a scheduled installation time.
Local administrators will not be allowed to disable the
configuration for Automatic Updates.
Disabled
Specifies that any client updates that are available from the
public Windows Update service must be manually downloaded
from the Internet and installed.
delay Restart for scheduled installations
Specifies the amount of time Automatic Updates will wait before proceeding with a scheduled restart.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the
"Configure Automatic Updates" policy setting is disabled, this policy has no effect.
Policy setting state
Behavior
Not Configured
Specifies that after updates are installed, the default wait time
of fifteen minutes will elapse before any scheduled restart
occurs.
Enabled
Specifies that when the installation is finished, a scheduled
restart will occur after the specified number of minutes has
expired.
Disabled
Specifies that after updates are installed, the default wait time
of fifteen minutes will elapse before any scheduled restart
occurs.
Options: if this setting is enabled, you can use this option to specify the amount of time (in minutes) Automatic
Updates waits before proceeding with a scheduled restart.
Do not adjust default option to "Install Updates and Shut Down" in Shut Down Windows dialog
This policy setting enables you to specify whether the Install Updates and Shut Down option is permitted as the
default choice in the Shut Down Windows dialog box.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
This policy setting has no impact if the PolicyName > computer Configuration > Policies > Administrative Templates >
Windows components > Windows Update > Do not display "Install Updates and Shut Down" option in Shut Down
Windows dialog policy setting is enabled.
Policy setting state
Behavior
Not Configured
Specifies that Install Updates and Shut Down will be the
default option in the Shut Down Windows dialog box if
updates are available for installation at the time the user
selects the Shut Down option to shut down the computer.
Enabled
if you enable this policy setting, the user's last shut down
choice (for example, Hibernate or Restart), is the default option
in the Shut Down Windows dialog box, regardless of whether
the Install Updates and Shut Down option is available in the
What do you want the computer to do? menu.
Disabled
Specifies that Install Updates and Shut Down will be the
default option in the Shut Down Windows dialog box if
updates are available for installation at the time the user
selects the Shut Down option to shut down the computer.
Options: There are no options for this setting.
Do not connect to any Windows Update Internet locations
Even when Windows Update is configured to receive updates from an intranet update service, it will periodically
retrieve information from the public Windows Update service to enable future connections to Windows Update
and other services, such as Microsoft Update or the Windows Store.
Enabling this policy will disable the functionality to periodically retrieve information from the public Windows
Server Update Service, and it may cause connection to public services such as the Windows Store to stop working.
SUPPORTED ON:
EXCLUDING:
starting with Windows Server 2012 R2 , Windows 8.1 or
Windows RT 8.1, Windows operating systems that are still
within their Microsoft Products Support Lifecycle.
null
NOTE
This policy applies only when the computer is configured to connect to an intranet update service by using the "Specify
intranet Microsoft update service location" policy setting.
Policy setting state
Behavior
Not Configured
The default behavior to retrieve information from the public
Windows Server Update Service persists.
Enabled
Specifies that computers will not retrieve information from the
public Windows Server Update Service.
Disabled
The default behavior to retrieve information from the public
Windows Server Update Service persists.
Options: There are no options for this setting.
Do not display "Install updates and Shut Down" option in Shut Down Windows dialog
Specifies whether the Install Updates and Shut Down option is displayed in the Shut Down Windows dialog
box.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
Policy setting state
Behavior
Not Configured
Specifies that the Install Updates and Shut Down option is
available in the Shut Down Windows dialog box if updates
are available when the user selects the Shut Down option to
shut down the computer. A local administrator can change
this setting by using local policy.
Enabled
Specifies that Install Updates and Shut Down will not appear
as a choice in the Shut Down Windows dialog box, even if
updates are available for installation when the user selects the
Shut Down option to shut down the computer.
Disabled
Specifies that the Install Updates and Shut Down option will
be the default option in the Shut Down Windows dialog box
if updates are available for installation at the time the user
selects the Shut Down option to shut down the computer.
Options: There are no options for this setting.
Enable client-side targeting
Specifies the target group name or names that are configured in the WSUS console that are to receive updates
from WSUS.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
Windows RT
NOTE
This policy applies only when this computer is configured to support the specified target group names in WSUS. If the target
group name doesn't exist in WSUS, it will be ignored until it is created. If the "Specify intranet Microsoft update service
location" policy setting is disabled or not configured, this policy has no effect.
NOTE
This policy is not supported on Windows RT. Enabling this policy will not have any effect on computers running Windows RT.
Policy setting state
Behavior
Not Configured
Specifies that no target group information is sent to WSUS. A
local administrator can change this setting by using a local
policy.
Enabled
Specifies that the specified target group information is sent to
WSUS, which uses it to determine which updates should be
deployed to this computer. If WSUS supports multiple target
groups, you can use this policy to specify multiple group
names, separated by semicolons, if you have added the target
group names in the computer group list in WSUS. Otherwise,
a single group must be specified.
Disabled
Specifies that no target group information is sent to WSUS.
Options: Use this space to specify one or more target group names.
Enabling Windows Update Power Management to automatically wake up the computer to install scheduled updates
Specifies whether Windows Update will use the Windows Power Management or Power Options features to
automatically wake up the computer from hibernation if there are updates scheduled for installation.
The computer will automatically wake only if Windows Update is configured to install updates automatically. If the
computer is in hibernation when the scheduled installation time occurs and there are updates to be applied,
Windows Update will use the Windows Power Management or Power Options features to automatically wake the
computer to install the updates. Windows Update will also wake the computer and install an update if an
installation deadline occurs.
The computer will not wake unless there are updates to be installed. If the computer is on battery power, when
Windows Update wakes it, it will not install updates and the computer will automatically return to hibernation in
two minutes.
SUPPORTED ON:
EXCLUDING:
starting with Windows Vista and Windows Server 2008 (
Windows 7 ), Windows operating systems that are still within
their Microsoft Products Support Lifecycle.
null
Policy setting state
Behavior
Not Configured
Windows Update does not wake the computer from
hibernation to install updates. A local administrator can
change this setting by using a local policy.
Enabled
Windows Update wakes the computer from hibernation to
install updates under the previously listed conditions.
Disabled
Windows Update does not wake the computer from
hibernation to install updates.
Options: There are no options for this setting.
No auto-restart with logged on users for scheduled automatic updates installations
Specifies that to complete a scheduled installation, Automatic Updates will wait for the computer to be restarted by
any user who is signed in, instead of causing the computer to restart automatically.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the
"Configure Automatic Updates" policy setting is disabled, this policy has no effect.
Policy setting state
Behavior
Not Configured
Specifies that Automatic Updates will notify the user that the
computer will automatically restart in five minutes to complete
the installation.
Enabled
Some updates require the computer to be restarted before
the updates will take effect. If the status is set to Enabled,
Automatic Updates will not restart a computer automatically
during a scheduled installation if a user is signed in to the
computer. Instead, Automatic Updates will notify the user to
restart the computer.
Disabled
Specifies that Automatic Updates will notify the user that the
computer will automatically restart in five minutes to complete
the installation.
Options: There are no options for this setting.
Re-prompt for restart with scheduled installations
Specifies the amount of time for Automatic Updates to wait before prompting again with a scheduled restart.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
Windows RT
IMPORTANT
This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the
"Configure Automatic Updates" policy setting is disabled, this policy has no effect.
NOTE
This policy has no effect on computers running Windows RT.
Policy setting state
Behavior
Not Configured
A scheduled restart occurs ten minutes after the prompt for
restart message is dismissed. A local administrator can change
this setting by using a local policy.
Enabled
Specifies that after the previous prompt for restart was
postponed, a scheduled restart will occur after the specified
number of minutes elapses.
Disabled
A scheduled restart occurs ten minutes after the prompt for
restart message is dismissed.
Options: When enabled, you can use this setting option to specify (in minutes) the duration of time that will elapse
before users are prompted again about a scheduled restart.
Reschedule Automatic Updates scheduled installations
Specifies the amount of time for Automatic Updates to wait following a computer startup, before proceeding with a
scheduled installation that was previously missed.
if the status is set to Not Configured, a missed scheduled installation will occur one minute after the computer is
next started.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the
"Configure Automatic Updates" policy setting is disabled, this policy has no effect.
Policy setting state
Behavior
Not Configured
Specifies that a missed scheduled installation will occur one
minute after the computer is next started.
Enabled
Specifies that a scheduled installation that did not take place
earlier will occur the specified number of minutes after the
computer is next started.
Disabled
Specifies that a missed scheduled installation will occur with
the next scheduled installation.
Options: When this policy setting is enabled, you can use it to specify a number of minutes after the computer is
next started, that a scheduled installation that did not take place earlier will occur.
Specify intranet Microsoft update service location
Specifies an intranet server to host updates from Microsoft Update. You can then use WSUS to automatically
update computers on your network.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
Windows RT.
This setting enables you to specify a WSUS server on your network that will function as an internal update service.
Instead of using Microsoft Updates on the Internet, WSUS clients will search this service for updates that apply.
To use this setting, you must set two server name values: the server from which the client detects and downloads
updates, and the server to which updated workstations upload statistics. The values need not be different if both
services are configured on the same server.
NOTE
if the "Configure Automatic Updates" policy setting is disabled, this policy has no effect.
NOTE
This policy is not supported on Windows RT. Enabling this policy will not have any effect on computers running Windows RT.
Policy setting state
Behavior
Not Configured
if Automatic Updates is not disabled by policy or user
preference, this policy specifies that clients connect directly to
the Windows Update site on the Internet.
Enabled
Specifies that the client connects to the specified WSUS server,
instead of Windows Update, to search for and download
updates. Enabling this setting means that end users in your
organization do not have to go through a firewall to get
updates, and it gives you the opportunity to test updates
before deploying them.
Disabled
if Automatic Updates is not disabled by policy or user
preference, this policy specifies that clients connect directly to
the Windows Update site on the Internet.
Options: When this policy setting is enabled, you must specify the intranet update service that WSUS clients will
use when detecting updates, and the Internet statistics server to which updated WSUS clients will upload statistics.
Example values:
SETTING OPTION:
EXAMPLE VALUE:
Set the intranet update service for detecting updates
http://wsus01:8530
Set the intranet statistics server
http://IntranetUpd01
Turn on recommended updates via Automatic Updates
Specifies whether Automatic Updates will deliver IMPORTANT and recommended updates from WSUS.
SUPPORTED ON:
EXCLUDING:
starting with Windows Vista, Windows operating systems that
are still within their Microsoft Products Support Lifecycle.
null
Policy setting state
Behavior
Not Configured
Specifies that Automatic Updates will continue to deliver
IMPORTANT updates if it is already configured to do so.
Enabled
Specifies that Automatic Updates will install recommended
updates and IMPORTANT updates from WSUS.
Disabled
Specifies that Automatic Updates will continue to deliver
IMPORTANT updates if it is already configured to do so.
Options: There are no options for this setting.
Turn on Software Notifications
This policy setting enables you to control whether users see detailed enhanced notification messages about
featured software from the Microsoft Update service. Enhanced notification messages convey the value and
promote the installation and use of optional software. This policy setting is intended for use in loosely managed
environments in which you allow the end user access to the Microsoft Update service.
if you are not using the Microsoft Update service, the "Software Notifications" policy setting has no effect.
if the "Configure Automatic Updates" policy setting is disabled or is not configured, the "Software Notifications"
policy setting has no effect.
SUPPORTED ON:
EXCLUDING:
starting with Windows Server 2008 (Windows Vista) and
Windows 7 , Windows operating systems that are still within
their Microsoft Products Support Lifecycle.
null
NOTE
By default, this policy setting is disabled.
Policy setting state
Behavior
Not Configured
Users on computers that are running Windows 7 are not
offered messages for optional applications. Users on
computers that are running Windows Vista are not offered
messages for optional applications or updates. A local
administrator can change this setting by using Control Panel
or a local policy.
Enabled
if you enable this policy setting, a notification message will
appear on the user's computer when featured software is
available. The user can click the notification to open Windows
Update and get more information about the software or
install it. The user can also click Close this message or Show
me later to defer the notification as appropriate.
In Windows 7 , this policy setting will only control detailed
notifications for optional applications. In Windows Vista, this
policy setting controls detailed notifications for optional
applications and updates.
Disabled
Specifies that users running Windows 7 will not be offered
detailed notification messages for optional applications, and
users running Windows Vista will not be offered detailed
notification messages for optional applications or optional
updates.
Options: There are no options for this setting.
computer Configuration > Maintenance Scheduler policy settings
In the Configure Automatic Updates setting, you selected the option 4 - Auto download and schedule the
install, you can specify schedule Maintenance Scheduler settings in the GPMC for computers running Windows 8
and Windows RT. If you did not select option 4 in the "Configure Automatic Updates" setting, you do not need to
configure these settings for the purpose of automatic updates. Maintenance Scheduler settings are located in the
path: PolicyName > computer Configuration > Policies > Administrative Templates > Windows
components > Maintenance Scheduler. The Maintenance Scheduler extension of Group Policy contains the
following settings:
Automatic Maintenance Activation Boundary
Automatic Maintenance Random delay
Automatic WakeUp Policy
Automatic Maintenance Activation Boundary
This policy enables you to configure the "Automatic Maintenance activation boundary" setting.
The maintenance activation boundary is the daily scheduled time at which Automatic Maintenance starts.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
This setting is related to option 4 in Configure Automatic Updates. If you did not select option 4 in Configure Automatic
Updates, it is not necessary to configure this setting.
Policy setting state
Behavior
Not Configured
if this policy setting is not configured, the daily scheduled time
as specified on client computers in the Action Center >
Automatic Maintenance Control Panel will apply.
Enabled
Enabling this policy setting overrides any default or modified
settings configured on client computers in Control Panel >
Action Center > Automatic Maintenance (or in some client
versions, Maintenance).
Disabled
if you set this policy setting to Disabled, the daily scheduled
time as specified in the Action Center > Automatic
Maintenance, in the Control Panel will apply.
Automatic Maintenance Random delay
This policy setting allows you to configure the Automatic Maintenance activation random delay.
The maintenance random delay is the amount of time up to which Automatic Maintenance will delay starting from
its activation boundary. This setting is useful for virtual machines where random maintenance might be a
performance requirement.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
This setting is related to option 4 in Configure Automatic Updates. If you did not select option 4 in Configure Automatic
Updates, it is not necessary to configure this setting.
By default, when enabled, the regular maintenance random delay is set to PT4H.
Policy setting state
Behavior
Not Configured
A four-hour random delay is applied to Automatic.
Enabled
Automatic Maintenance will delay starting from its activation
boundary by up to the specified amount of time.
Disabled
No random delay is applied to Automatic Maintenance.
Automatic WakeUp Policy
This policy setting allows you to configure the Automatic Maintenance wake-up policy.
The maintenance wake-up policy specifies whether Automatic Maintenance should make a wake-up request to the
operating computer for daily scheduled maintenance.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
if the operating computer's power-wake policy is explicitly disabled, this setting has no effect.
NOTE
This setting is related to option 4 in Configure Automatic Updates. If you did not select option 4 in Configure Automatic
Updates, it is not necessary to configure this setting.
Policy setting state
Behavior
Not Configured
if you do not configure this policy setting, the wake-up setting
as specified in the Action Center > Automatic Maintenance
Control Panel will apply.
Enabled
if you enable this policy setting, Automatic Maintenance will
attempt to set an operating system wake-up policy and make
a wake-up request for the daily scheduled time, if required.
Disabled
if you disable this policy setting, the wake-up setting as
specified in the Action Center > Automatic Maintenance
Control Panel will apply.
User Configuration > Windows Update policy settings
This section provides details about the following user-based policy settings:
Do not display "Install Updates and Shut Down" option in Shut Down Windows dialog box
Do not adjust default option to "Install Updates and Shut Down" in Shut Down Windows dialog box
remove access to use all Windows Update features
In the GPMC, the user settings for automatic computer updates are located in the path: PolicyName > User
Configuration > Policies > Administrative Templates > Windows components > Windows Update. The
settings are listed in the same order as they appear in the computer Configuration and User Configuration
extensions in Group Policy, when the Settings tab of the Windows Update policy is selected to sort the settings
alphabetically.
NOTE
By default, unless otherwise noted, these settings are not configured.
TIP
for each of these settings, you can use the following steps to enable, disable, or navigate between settings:
Do not display 'Install Updates and Shut Down' option in Shut Down Windows dialog box
Specifies whether the Install Updates and Shut Down option is displayed in the Shut Down Windows dialog
box.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
Policy setting state
Behavior
Not Configured
Specifies that the Install Updates and Shut Down option will
appear in the Shut Down Windows dialog box if updates are
available when the user selects the Shut Down option to shut
down the computer.
Enabled
if you enable this policy setting, Install Updates and Shut
Down will not appear as a choice in the Shut Down Windows
dialog box, even if updates are available for installation when
the user selects the Shut Down option to shut down the
computer.
Disabled
Specifies that the Install Updates and Shut Down option will
appear in the Shut Down Windows dialog box if updates are
available when the user selects the Shut Down option to shut
down the computer.
Options: There are no options for this setting.
Do not adjust default option to "Install Updates and Shut Down" in Shut Down Windows dialog box
Specifies whether the Install Updates and Shut Down option is allowed as the default choice in the Shut Down
Windows dialog box.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
NOTE
This policy setting has no impact if the PolicyName > User Configuration > Policies > Administrative Templates >
Windows components > Windows Update > Do not display "Install Updates and Shut Down" option in Shut Down
Windows dialog box is enabled.
Policy setting state
Behavior
Not Configured
Specifies whether the Install Updates and Shut Down option
will be the default option in the Shut Down Windows dialog
box if updates are available for installation at the time the user
selects the Shut Down option to shut down the computer.
Enabled
Specifies whether the user's last shut down choice (for
example, Hibernate or Restart) is the default option in the
Shut Down Windows dialog box, regardless of whether the
Install Updates and Shut Down option is available in the
What do you want the computer to do? menu.
Disabled
Specifies whether the Install Updates and Shut Down option
will be the default option in the Shut Down Windows dialog
box if updates are available for installation at the time the user
selects the Shut Down option to shut down the computer.
Options: There are no options for this setting.
remove access to use all Windows Update features
This setting enables you to remove WSUS client access to Windows Update.
SUPPORTED ON:
EXCLUDING:
Windows operating systems that are still within their
Microsoft Products Support Lifecycle.
null
Policy setting state
Behavior
Not Configured
Users are able to connect to the Windows Update website.
Enabled
IMPORTANT: if enable, all Windows Update features are
removed. This includes blocking access to the Windows
Update website at http://windowsupdate.microsoft.com, from
the Windows Update hyperlink on the start menu or start
screen, and also on the Tools menu in Internet Explorer.
Windows automatic updating is also disabled; the user will
neither be notified about nor receive critical updates from
Windows Update. This setting also prevents Device Manager
from automatically installing driver updates from the Windows
Update website.
When enabled, you can configure one of the following
notification options:
- 0 - Do not show any notifications
This setting will remove all access to Windows Update features
and no notifications will be shown.
- 1 - Show restart required notifications
This setting will show notifications about restarts that are
required to complete an installation. Note: On computers
running Windows 8 and Windows RT, if this policy is enabled,
only notifications related to restarts and the inability to detect
updates will be shown. The notification options are not
supported. Notifications on the sign-in screen are always
displayed.
Disabled
Users are able to connect to the Windows Update website.
Options: See Enabled in the table for this setting.
Supplemental information
This section provides addition information about using opening, and saving WSUS settings in Group Policies, and
definitions for terms used in this guide. For administrators familiar with past versions of WSUS (WSUS 3.2 and
previous versions), there is a table that briefly summarizes differences between WSUS versions.
Accessing the Windows Update settings in Group Policy
The procedure that follows describes how to open the GPMC on your domain controller. The procedure then
describes how to either open an existing domain-level Group Policy Object (GPO) for editing, or create a new
domain-level GPO and open it for editing.
NOTE
You must be a member of the Domain Admins group or equivalent, to perform this procedure.
To o p e n o r a d d a n d o p e n a G r o u p P o l i c y O b j e c t
1. On your domain controller, go to Server Manager, > Tools, > Group Policy Management. The Group
Policy Management Console opens.
2. In the left pane, expand your forest. For example, double-click forest: example.com.
3. In the left pane, double-click Domains, and then double-click the domain for which you want to manage a
Group Policy object. For example, double-click example.com.
4. Do one of the following:
5. To open an existing domain-level GPO for editing, double click the domain that contains the Group
Policy object that you want to manage, right-click the domain policy you want to manage, and then click
edit. Group Policy Management editor (GPME) opens.
6.
7. a. a. Right-click the domain for which you want to create a new Group Policy object, and then click
create a GPO in this domain, and Link it here.
To c re a t e a n e w Gro u p P o l i c y o b j e c t a n d o p e n f o r e d i t i :n g
b. In New GPO, in Name, type a name for the new Group Policy object, and then click OK.
c. Right-click your new Group Policy object, and then click edit. GPME opens.
To o p e n t h e W i n d o w s U p d a t e o r M a i n t e n a n c e Sc h e d u l e r e x t e n si o n s o f G r o u p P o l i c y
1. In Group Policy Management editor, do one of the following:
Open the computer Configuration > Windows Update extension of Group Policy. Navigate to:
PolicyName > computer Configuration > Policies / Administrative Templates > Windows
components > Windows Update.
Open the User Configuration > Windows Update extension of Group Policy. Navigate to:
PolicyName > User Configuration > Policies > Administrative Templates > Windows
components > Windows Update.
Open the computer Configuration > Maintenance Scheduler extension of Group Policy. In
GPOE, navigate to PolicyName > computer Configuration > Policies > Administrative
Templates > Windows components > Maintenance Scheduler.
for more information about the Group Policy, see Group Policy Overview.
TIP
After you have opened the extension of Group Policy you want, you can use the following steps to enable, disable, or
navigate between settings:
To c o n fi g u r e G r o u p P o l i c y se t t i n g s
1. In ExtensionOfGroupPolicy, double-click the setting you want to view or modify.
2. To configure the setting, do one of the following:
To retain the default unspecified state of the setting, select Not Configured
To enable the setting, select Enabled
To disable the setting, select Disabled.
3. In Options, if any options are listed, retain the default values or modify them as needed.
4. Do one of the following:
To save your changes and proceed to the next setting, click Apply, and then click Next Setting.
To save your changes and close the dialog box, click OK.
To discard all unsaved changes and close the dialog box, click Cancel.
changes to WSUS relevant to this guide
The following table summarizes key differences between the current and past versions of WSUS that are relevant
to this guide.
WINDOWS SERVER AND WSUS VERSIONS
DESCRIPTION
Windows Server 2012 R2 with WSUS 6.0, and subsequent
versions
starting in Windows Server 2012 , the WSUS server role is
integrated with the operating system, and the associated
Group Policy settings for WSUS clients are, by default,
included in Group Policy.
Windows Server 2008 (and earlier versions of Windows
Server) with WSUS 3.2 and earlier
In Windows Server 2008 (and earlier versions of Windows
Server) using WSUS versions 3.2 (and earlier), the Group Policy
settings that govern WSUS clients are not included in these
Windows Server operating systems. The policy settings are in
the WSUS Administrative template, wuau.adm. In these
server versions, the WSUS Administrative template must first
be added into the Group Policy Management Console (GPMC)
before the WSUS client settings can be configured.
Terms and Definitions
Following is a list of terms used in this guide.
TERM
DEFINITION
Automatic Updates
A service that runs on Windows computers (Automatic
Updates): Refers to the client computer component built into
the Microsoft Windows Vista, Windows Server 2003, Windows
XP, and Windows 2000 with SP3 operating systems to get
updates from Microsoft Update or Windows Update.
Casual reference (automatic updates): The term used to
describe when the Windows Update Agent automatically
schedules and downloads updates.
autonomous server
Use to refer to a downstream Windows Server Update
Services (WSUS) server on which administrators can manage
WSUS components.
downstream server
Use to refer to a Windows Server Update Services (WSUS)
server that gets updates from another WSUS server rather
than from Microsoft Update or Windows Update.
TERM
DEFINITION
Group Policy extension (and: extension of Group Policy
A collection of settings in Group Policy that are used to
control how users and computers (to whom the policies apply)
can configure and use various Windows services and features.
Administrators can use WSUS with Group Policy for client-side
configuration of the Automatic Updates client, to help ensure
that end-users can't disable or circumvent corporate update
policies.
WSUS does not require the use of active directory or Group
Policy. Client configuration can also be applied by using local
group policy or by modifying the Windows registry.
internal update service
A casual reference to a network infrastructure that uses one or
more WSUS servers to distribute updates.
replica server
Use to refer to a downstream Windows Server Update
Services (WSUS) server that mirrors the approvals and settings
on the upstream server to which it is connected. You cannot
manage WSUS on a replica server.
Microsoft Update
An Internet-based Microsoft download site: A Microsoft
Internet site that stores and distributes updates for Windows
computers (device drivers), Windows operating systems and
other Microsoft software products.
Software Update Services (SUS)
SUS was the predecessor product for Windows Server Update
Services (WSUS).
updates
Any of a collection of software revisions, hotfixes, service
packs, feature packs and device drivers that can be installed
on a computer to extend functionality, or improve
performance and security.
update files
The files required to install an update on a computer.
update information (also known as update metadata)
The information about an update, as opposed to the update
binary files in an update package. For example, metadata
supplies information for the properties of an update, thus
enabling you to find out for what the update is useful.
Metadata also includes Microsoft Software License Terms. The
metadata package downloaded for an update is typically much
smaller than the actual update file package.
update source
The location to which a Windows Server Update Services
(WSUS) server synchronizes to get update files. This location
can be either Microsoft Update or an upstream WSUS server.
upstream server
A Windows Server Update Services (WSUS) server that
provides update files to another WSUS server, which in turn is
referred to as a downstream server.
TERM
DEFINITION
Windows Server Update Services (WSUS)
A Server Role program that runs on one or more Windows
Server computers on a corporate network. A WSUS
infrastructure enables you to manage updates for computers
on your network to install.
You can use WSUS to approve or decline updates before
release, to force updates to install by a given date, and to
obtain extensive reports on what updates each computer on
your network requires. You can configure WSUS to approve
certain classes of updates automatically (critical updates,
security updates, service packs, drivers, etc.). WSUS also
enables you to approve updates for "detection" only, so that
you can see what computers will require a given update
without having to install the updates.
In a WSUS implementation, at least one WSUS server in the
network must be able to connect to Microsoft Update to get
available updates. Based on network security and
configuration, the administrator can determine how many
other servers connect directly to Microsoft Update.
You can configure a WSUS server to get updates over the
Internet from such places as:
- the public Microsoft Update
- the public Windows Update
- the Windows Store
Windows Update
An Internet-based Microsoft download site: A Microsoft
Internet site that stores and distributes updates for Windows
computers (device drivers), and Windows operating systems.
computer service: The name of the Windows Update service
that runs on computers. Windows Update detects, downloads,
and installs updates on Windows computers.
Depending on computer and policy configurations, the
Windows Update Agent can download updates from:
- Microsoft Update
- Windows Update
- Windows Store
- An Internet (network) update service (WSUS)
computers that are not managed in a WSUS-based
environment will typically use Windows Update to connect
directly - over the Internet - to Windows Update, Microsoft
Update, or the Windows Store to obtain updates.
WSUS Client
A computer that receives updates from a WSUS intranet
update service.
In the case of Group Policy settings that control end-user
interaction with Automatic Updates: a user of a computer in a
WSUS environment.
Update Management with Windows Server Update
Services
5/23/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
You should check the WSUS administration console home page regularly to view overall update compliance and
network health. Check application logs frequently, if you suspect problems such as download failures or client
computers that are failing to report to the WSUS server. This guide provides information to help you manage
Windows Server Update Services.
In this guide
In this guide, you will find information about:
Setting up Update Synchronizations
Managing WSUS Client computers and WSUS computer Groups
Viewing and Managing Updates
WSUS and the Catalog Site
Updates Operations
The Server cleanup Wizard
Running WSUS Replica mode
WSUS Messages and Troubleshooting Tips
Setting up Update Synchronizations
4/24/2017 • 7 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
During synchronization, a WSUS server downloads updates (update metadata and files) from an update source. It
also downloads new product classifications and categories, if any. When your WSUS server synchronizes for the
first time, it will download all of the updates that you specified when you configured synchronization options. After
the first synchronization, your WSUS server downloads only updates from the update source, as well as revisions in
metadata for existing updates, and expirations to updates.
The first time a WSUS server downloads updates may take a long time. If you are setting up multiple WSUS servers,
you can speed up the process to a certain extent by downloading all the updates on one WSUS server and then
copying the updates to the content directories of the other WSUS servers.
You can copy content from one WSUS server's content directory to another. The location of the content directory is
specified when you run the WSUS post installation procedure. You can use the wsusutil.exe tool to export update
metadata from one WSUS server to a file. You can then import that file into other WSUS servers.
Setting up Update Synchronizations
The Options page is the central access point in the WSUS Administration Console for customizing how your WSUS
server synchronizes updates. You can specify which updates are synchronized automatically, where your server
gets updates, connection settings, and the synchronization schedule. You can also use the Configuration Wizard
from the Options page to configure or reconfigure your WSUS server at any time.
Synchronizing Update by Product and Classification
A WSUS server downloads updates based on the products or product families (for example, Windows, or Windows
Server 2008, Datacenter edition) and classifications (for example, critical updates or security updates) that you
specify. at the first synchronization, the WSUS server downloads all of the updates available in the categories that
you have specified. In subsequent synchronizations, your WSUS server downloads only the newest updates (or
changes to the updates already available on your WSUS server) for the categories you have specified.
You can specify update products and classifications on the Options page under Products and Classifications.
Products are listed in a hierarchy, grouped by product family. If you select Windows, you automatically select every
product that falls under that product hierarchy. By selecting the parent check box you select all items under it, as
well as all future versions. selecting the child check boxes will not select the parent check boxes. The default setting
for products is all Windows products, and the default setting for classifications is critical and security updates.
If a WSUS server is running in replica mode, you will not be able to perform this task. For more information about
replica mode, see Running WSUS Replica mode, and Step 1: Prepare for Your WSUS Deployment.
To sp e c i fy u p d a t e p r o d u c t s a n d c l a ssi fi c a t i o n s fo r sy n c h r o n i z a t i o n
1. In the WSUS Administration Console, click the Options node.
2. Click Products and Classifications, and then click the Products tab.
3. Select the check boxes of the products or product families you want to update with WSUS, and then click OK.
4. On the Classifications tab, select the check boxes of the update classifications you want your WSUS server
to synchronize, and then click OK.
NOTE
You can remove products or classifications in the same way. Your WSUS server will stop synchronizing new updates for the
products you have cleared. However, updates that were synchronized for those products before you cleared them will remain
on your WSUS server and will be listed as available.
To remove those products, Decline the update, as documented in Updates Operations, and then use the The Server cleanup
Wizard to remove them.
Synchronizing Updates by Language
Your WSUS server downloads updates based on the languages that you specify. You can synchronize updates in all
of the languages in which they are available, or you can specify a subset of languages. If you have a hierarchy of
WSUS servers, and you need to download updates in different languages, make sure that you have specified all the
necessary languages on the upstream server. On a downstream server you can specify a subset of the languages
you specified on the upstream server.
Synchronizing Updates from the Microsoft Update Catalog
for details about synchronizing updates from the Microsoft Update Catalog site, see: WSUS and the Catalog Site.
Synchronizing Device Updates by Inventory (Inventory-based Synchronization)
Certain product categories and classifications (e.g. Drivers) contain a very large number of updates and it is not
advised to synchronize these entire categories to your WSUS server. Doing so can lead to performance issues and
ongoing maintenance challenges. The WSUS inventory system collects non-identifying information from client
devices and uses that inventory information to retrieve just enough update metadata from Microsoft Update. This
mechanism is roughly equivalent to having WSUS search the Microsoft Update Catalog automatically, importing
only the updates for devices that are detected on managed devices.
Enabling this inventory feature is the only supported way to obtain certain device firmware and model-based
servicing sets which are not published to the Microsoft Update Catalog.
Updates synchronized in this manner are reviewed and approved just like any other update, and are also subject to
the same auto-approval rules, supersedence and expiration, and any other behavior associated with traditional
updates.
WSUS performs server-side filtering when clients request certain Driver and Firmware updates, including updates
which have been imported by Inventory. Thus, a client computer or device will receive metadata and detectoids for
drivers and driver updates only for devices actually attached to that device. This behavior minimizes client scan
time and reduces the data transferred between the client and the WSUS server.
NOTE
When Inventory-based Synchronization is enabled, WSUS maintains the device inventory on a per-device basis; only a
summary roll-up (de-duplicated list of IDs) is ever sent to the upstream WSUS server. Upstream WSUS servers do not receive
information about which devices are associated with which computers, nor how many instances of a given device exist within
your WSUS hierarchy. In general, this summary roll-up cannot be used to identify or count devices on a WSUS-managed
network.
Configuring Proxy Server Settings
You can configure your WSUS server to use a proxy server during synchronization with an upstream server or
Microsoft Update. This setting will apply only when your WSUS server runs synchronizations. By default your
WSUS server will try to connect directly to the upstream server or Microsoft Update.
To specify a proxy server for synchronization
1. In the WSUS Administration Console, click Options, and then click Update Source and Proxy Server.
2. On the Proxy Server tab, select the Use a proxy server when synchronizing check box, and then type the
server name and port number of the proxy server.
NOTE
Configure WSUS with the same port number that the proxy server is configured to use.
if you want to connect to the proxy server with specific user credentials, select the Use user
credentials to connect to the proxy server check box, and then enter the user name, domain, and
password of the user in the corresponding boxes.
if you want to enable basic authentication for the user connecting to the proxy server, select the
Allow basic authentication (password is sent in cleartext) check box.
3. Click OK.
NOTE
Because WSUS initiates all of its network traffic, there is no need to configure Windows Firewall on a WSUS server
connected directly to Microsoft update.
Configuring the Update Source
The update source is the location from which your WSUS server gets its updates and update metadata. You can
specify that the update source should be either Microsoft Update or another WSUS server (the WSUS server that
acts as the update source is the upstream server, and your server is the downstream server).
Options for customizing how your WSUS server synchronizes with the update source include the following:
You can specify a custom port for synchronization. For information about configuring ports, see Step 3:
Configure WSUS in the WSUS deployment guide.
You can use Secure Socket Layers (SSL) to secure synchronization of update information between WSUS
servers. For more information about using SSL, see section "3.5. Secure WSUS with the Secure Sockets Layer
Protocol" of Step 3: Configure WSUS in the WSUS deployment guide.
Synchronizing Manually or Automatically
You can either synchronize your WSUS server manually or specify a time for it to synchronize automatically.
To manually synchronize the WSUS server
1. In the WSUS Administration Console, click Options, and then click Synchronization Schedule.
2. Click Synchronize manually, and then click OK.
To set up an automatic synchronization schedule
1. In the WSUS Administration Console, click Options, then click Synchronization Schedule.
2. Click Synchronize automatically.
3. For First synchronization, select the time you want synchronization to start each day.
4. for Synchronizations per day, select the number of synchronizations you want to do each day. For
example, if you want four synchronizations a day starting at 3:00 A.M., then synchronizations will occur at
3:00 A.M., 9:00 A.M., 3:00 P.M., and 9:00 P.M. each day. (Note that a random time offset will be added to the
scheduled synchronization time in order to space out the server connections to Microsoft Update.)
5. Click OK.
To synchronize your WSUS server immediately
1. On the WSUS Administration Console, select the top server node.
2. In the Overview pane, under Synchronization Status, click Synchronize now.
Managing WSUS Client computers and WSUS
computer Groups
4/24/2017 • 4 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The computers node is central access point in the WSUS administrative console for managing WSUS client
computers and devices. Under this node you can find the different groups you have set up (plus the default group,
Unassigned computers).
Managing Client computers
Selecting one of the computer groups in the computers node under Options causes the computers in that group
to be displayed in the details pane. If a computer is assigned to multiple groups, it will appear in the listings of both
groups. If you select a computer in the list, you can see its properties, which include general details about the
computer and the status of updates for it, such as the installation or detection status of an update for a particular
computer. You can filter the list of computers under a given computer group by status. The default shows only
computers for which updates are needed or which have had installation failures; however, you can filter the display
by any status. Click Refresh after changing the status filter.
You can also manage computer groups on the computers page, which includes creating the groups and assigning
computers to them. For more information about managing computer groups, see Managing computer Groups in
the next section of this guide, and section 1.5. Plan WSUS computer groups in Step 1: Prepare for Your WSUS
Deployment of the WSUS deployment guide.
NOTE
You must first configure client computers to contact the WSUS server before you can manage them from that server. Until
you perform this task, your WSUS server will not recognize your client computers and they will not be displayed in the list on
the computers page. For more information about setting up client computers, see 1.5. Plan WSUS computer groups of Step
1: Prepare for Your WSUS Deployment, and Step 3: Configure WSUS, in the WSUS deployment guide.
Controlling when WSUS client computers install updates
There are two methods to control when WSUS client computers install updates:
Approval with deadlines: Deadlines strictly enforce when an update is installed
WSUS Group Policies: Group Policies control when the Windows Update Agent scans and installs updates
for more information, see: Step 5: Configure Group Policy Settings for Automatic Updates, in the WSUS
Deployment Guide.
Managing computer Groups
WSUS allows you to target updates to groups of client computers, so you can ensure that specific computers
always get the right updates at the most convenient times. For example, if all the computers in one department
(such as the Accounting team) have a specific configuration, you can set up a group for that team, decide which
updates their computers need and what time they should be installed, and then use WSUS reports to evaluate the
updates for the team.
Computers are always assigned to the All computers group, and remain assigned to the Unassigned computers
group until you assign them to another group. Computers can belong to more than one group.
Computer groups can be set up in hierarchies (for example, the Payroll group and the Accounts Payable group
below the Accounting group). Updates that are approved for a higher group will automatically be deployed to
lower groups, as well as to the higher group itself. Thus, if you approve Update1 for the Accounting group, the
update will be deployed to all the computers in the Accounting group, all the computers in the Payroll group, and
all the computers in the Accounts Payable group.
Because computers can be assigned to multiple groups, it is possible for a single update to be approved more than
once for the same computer. However, the update will be deployed only once, and any conflicts will be resolved by
the WSUS server. To continue with the example above, if computerA is assigned to both the Payroll and the
Accounts Payable groups, and Update1 is approved for both groups, it will be deployed only once.
You can assign computers to computer groups by using one of two methods, server-side targeting or client-side
targeting. With server-side targeting, you manually move one or more client computers to one computer group at
a time. With client-side targeting, you use Group Policy or edit the registry settings on client computers to enable
those computers to automatically add themselves into the previously created computer groups. This process can be
scripted and deployed to many computers at once. You must specify the targeting method you will use on the
WSUS server by selecting one of the two options on the computers section of the Options page.
NOTE
If a WSUS server is running in replica mode, computer groups cannot be created on that server. All the computer groups
needed for clients of the replica server must be created on the WSUS server that is the root of the WSUS server hierarchy. For
more information about replica mode, see Running WSUS Replica mode and for more information about server-side and
client-side targeting, see section 1.5. Plan WSUS computer groups of Step 1: Prepare for Your WSUS Deployment in the
WSUS deployment guide.
Viewing and Managing Updates
4/24/2017 • 7 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
You can use the WSUS console to view and manage updates.
Viewing Updates
On the Updates page, you can do the following:
View updates. The update overview displays updates that have been synchronized from the update source to
your WSUS server and are available for approval.
Filter updates. In the default view you can filter updates by approval status and installation status. The
default setting is for unapproved updates that are needed by some clients or that have had installation
failures on some clients. You can change this view by changing the approval status and installation status
filters, and then clicking Refresh.
Create new update views. In the Actions pane, click New Update View. You can filter updates by
classification, product, the group for which they have been approved, and synchronization date. You can sort
the list by clicking the appropriate column heading in the title bar.
Search for updates. You can search for an individual update or set of updates by title, description, Knowledge
Base article, or the Microsoft Security Response Center number for the update.
View details, status, and revision history for each update.
Approve and Decline updates.
To view updates
1. In the WSUS administration console, expand the Updates node, and then click All Updates.
2. By default, updates are displayed with their title, classification, installed/not applicable percentage, and
approval status. If you wish to display more or different update properties, right-click the column heading
bar and select the appropriate columns.
3. To sort by different criteria, such as download status, title, classification, release date, or approval status, click
the appropriate column heading.
To filter the list of updates displayed on the Updates page
1. In the WSUS administration console, expand Updates, and then click All Updates.
2. In the center pane next to Approval, select the desired approval status, and next to Status select the desired
installation status. Click Refresh.
To create a new update view on WSUS
1. In the WSUS administration console, expand Updates, and then click All Updates.
2. In the Actions pane, click New Update View.
3. In the Add Update View window, under Step 1: select properties, select the properties you need to filter
the update view:
Select Updates are in a specific classification to filter on updates belonging to one or more update
classifications.
Select Updates are for a specific product to filter on updates for one or more products or product
families.
Select Updates are approved for a specific group to filter on updates approved for one or more
computer groups.
Select Updates were synchronized within a specific time period to filter on updates synchronized at a
specific time.
Select Updates are WSUS updates to filter on WSUS updates.
4. Under Step 2: edit the properties, click the underlined words to pick the values you want.
5. Under Step 3: Specify a name, give your new view a name.
6. Click OK.
Your new view will appear in the tree view pane under Updates. It will be displayed, like the standard views, in the
center pane when you select it.
To search for an update
1. Select the Updates node (or any node under it).
2. In the Actions pane, click Search.
3. In the Search window, on the Updates tab, enter your search criteria. You can use text from the Title,
Description, and Microsoft Knowledge Base (KB) article number fields. Each of these items is a
property listed on the details tab in the update properties.
To view the properties for an update
1. In the WSUS administration console, expand Updates, and then click All Updates.
2. In the list of updates, click the update you want to view.
3. In the lower pane, you will see the different property sections:
The title bar displays the title of the update; for example, Security Update for Windows Media Player 9
(KB911565).
The Status section displays the installation status of the update (the computers on which it needs to
be installed, computers on which it was installed with errors, computers on which it has been installed
or is not applicable, and computers that have not reported status for the update), as well as general
information (KB and MSRC numbers release date, etc.).
The Description section displays a brief description of the update.
The additional details section displays the following information:
The installation behavior of the update (whether or not it is removable, requests a restart,
requires user input, or must be installed exclusively).
Whether or not the update has Microsoft Software License Terms
The products to which the update applies
The updates that supersede this update
The updates that are superseded by this update
The languages supported by the update
The update ID
Note that you can perform this procedure on only one update at a time. If you select multiple updates, only the first
update in the list will be displayed in the Properties pane.
Managing Updates with WSUS
Updates are used for updating or providing a full file replacement for software that is installed on a computer.
Every update that is available on Microsoft Update is made up of two components:
Metadata: Provides information about the update. For example, metadata supplies information for the
properties of an update, thus enabling you to find out for what the update is useful. Metadata also includes
Microsoft Software License Terms. The metadata package downloaded for an update is typically much
smaller than the actual update file package.
Update files: The actual files required to install an update on a computer.
When updates are synchronized to your WSUS server, the metadata and update files are stored in two separate
locations. Metadata is stored in the WSUS database. Update files can be stored either on your WSUS server or on
Microsoft Update servers, depending on how you have configured your synchronization options. If you choose to
store update files on Microsoft Update servers, only metadata is downloaded at the time of synchronization; you
approve the updates through the WSUS console, and then client computers get the update files directly from
Microsoft Update at the time of installation. For more information about options for storing updates, see section
1.3. Choose a WSUS storage strategy of Step 1: Prepare for Your WSUS Deployment, in the WSUS deployment
guide.
You will be setting up and running synchronizations, adding computers and computer groups, and deploying
updates on a regular basis. The following list gives examples of general tasks you might undertake in updating
computers with WSUS.
Determine an overall update management plan based on your network topology and bandwidth, company
needs, and organizational structure.
Whether to set up a hierarchy of WSUS servers and how the hierarchy should be structured.
What computer groups to create, and how to assign computers to them (server-side or client-side
targeting).
Which database to use for update metadata (for example, Windows Internal Database, SQL Server).
Whether updates should be synchronized automatically, and at what time.
Set synchronization options, such as update source, product and update classification, language, connection
settings, storage location, and synchronization schedule.
Get the updates and associated metadata on your WSUS server through synchronization from either
Microsoft Update or an upstream WSUS server.
Approve or decline updates. You have the option of allowing users to install the updates themselves (if they
are local administrators on their client computers).
Configure automatic approvals. You can also configure whether you want to enable automatic approval of
revisions to existing updates or approve revisions manually. If you choose to approve revisions manually,
then your WSUS server will continue using the older version until you manually approve the new revision.
Check the status of updates. You can view update status, print a status report, or configure e-mail for regular
status reports.
Update Products and Classifications
Updates available on Microsoft Update are differentiated by product (or product family) and classification.
A product is a specific edition of an operating system or application, for example, Windows Server 2012. A product
family is the base operating system or application from which the individual products are derived. An example of a
product family is Microsoft Windows, of which Windows Server 2012 is a member. You can select the products or
product families for which you want your server to synchronize updates. You can specify a product family or
individual products within the family. Selecting any product or product family will get updates for current and
future versions of the product.
Update classifications represent the type of update. For any given product or product family, updates could be
available among multiple update classifications (for example, Windows 7 family Critical Updates and Security
Updates). The following table lists update classifications.
UPDATE CLASSIFICATIONS
DESCRIPTION
Critical Updates
Broadly released fixes for specific problems addressing critical,
non-security related bugs.
Definition Updates
Updates to virus or other definition files.
Drivers
Software components designed to support new hardware.
Feature packs
New feature releases, usually rolled into products at the next
release.
Security updates
Broadly released fixes for specific products, addressing security
issues.
Service packs
Cumulative sets of all hotfixes, security updates, critical
updates, and updates created since the release of the product.
Service packs might also contain a limited number of
customer-requested design changes or features.
Tools
Utilities or features that aid in accomplishing a task or set of
tasks.
Update rollups
A cumulative set of hotfixes, security updates, critical updates,
and other updates that are packaged together for easy
deployment. A rollup generally targets a specific area, such as
security, or a specific component, such as Internet Information
Services (IIS).
Updates
Broadly released fixes for specific problems addressing noncritical, non-security related bugs.
WSUS and the Catalog Site
4/24/2017 • 3 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The Catalog Site is the Microsoft location from which you can import hotfixes and hardware drivers.
The Microsoft Update Catalog Site
In order to import hotfixes into WSUS, you must access the Microsoft Update Catalog Site from a WSUS computer.
Any computer that has the WSUS administrative console installed, whether or not it is a WSUS server, can be used
to import hotfixes from the Catalog Site. You must be logged on to the computer as an administrator to import the
hotfixes.
To access the Microsoft Update Catalog Site
1. In the WSUS administrative console, select either the top server node or Updates, and in the Actions pane
click import Updates. A browser window will open at the Microsoft Update Catalog Web site.
2. In order to access the updates at this site, you must install the Microsoft Update Catalog activeX control.
3. You can browse this site for Windows hotfixes and hardware drivers. When you have found the ones you
want, add them to your basket.
4. When you have finished browsing, go to the basket and click import to import your updates. To download
the updates without importing them, clear the import directly into Windows Server Update Services
checkbox.
Approved updates imported from the Microsoft Update Catalog Site are downloaded the next time the WSUS
server synchronizes. They are not downloaded at the time of import from the Microsoft Update Catalog Site.
Note that you must access the Microsoft Update Catalog Site though the WSUS console to ensure that the updates
are imported in a WSUS-compatible format. If you access the Microsoft Update Catalog website manually, any
updates that you download are not imported into the WSUS server, but instead are downloaded as individual .MSU
files. WSUS does not currently have a supported mechanism for importing files in the \.MSU format.
if you run The Server cleanup Wizard, updates imported from the Microsoft Update Catalog that are set as Not
Approved or as Declined may be removed from the WSUS server. If they are removed, they can be re-imported
from the Microsoft Update Catalog.
NOTE
You can remove updates that are imported from the Microsoft Update Catalog that are set as either Not Approved or
Declined, by running the WSUS Server cleanup Wizard. You can re-imported updates that have been previously removed
from your WSUS systems through the Microsoft Update Catalog.
Restricting access to hotfixes
WSUS administrators might consider restricting access to the hotfixes they have downloaded from the Microsoft
Update Catalog Site. In order to make this restriction follow the steps below:
To restrict access to hotfixes
1. Enable Windows authentication on the IIS Content vroot.
Start IIS Manager.
Navigate to the content node under WSUS Administration web site.
On the Content Home pane, double click in the Authentication option.
Select Anonymous Authentication and click Disable in the Actions pane on the right.
Select Windows Authentication and click Enable in the Actions pane on the right.
2. Create a WSUS target group for the computers that need the hotfix, and add them to the group. For more
information about computers and groups, see Managing WSUS Client computers and WSUS computer
Groups in this guide, and section 3.3. Configure WSUS computer groups of Step 3: Configure WSUS, in the
WSUS deployment guide.
3. Download the files for the hotfix.
4. Set the permissions of these files so that only machine accounts of those machines can read them. You will
also need to allow the Network Service account full access to the files.
5. Approve the hotfix for the WSUS target group created in Step 2.
importing updates in different languages
The Microsoft Update Catalog Web site includes updates that support multiple languages. It is very IMPORTANT to
match the languages supported by the WSUS server with the languages supported by these updates. If the WSUS
server does not support all the languages included in the update, the update will not be deployed to client
computers. Likewise, if an update supporting multiple languages has been downloaded to the WSUS server but not
yet deployed to client computers, and an administrator deselects one of the languages included the update, the
update will not be deployed to the clients.
Updates Operations
4/24/2017 • 13 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
After updates have been synchronized to your WSUS server, they will be scanned automatically for relevance to the
server's client computers. However, you must approve the updates before they are deployed to the computers on
your network. When you approve an update, you are essentially telling WSUS what to do with it (your choices are
Install or Decline for a new update). You can approve updates for the All computers group or for subgroups. If
you do not approve an update, its approval status remains Not approved, and your WSUS server allows clients to
evaluate whether or not they need the update.
If your WSUS server is running in replica mode, you will not be able to approve updates on your WSUS server. For
more information about replica mode, see Running WSUS Replica mode.
Approving Updates
You can approve the installation of updates for all the computers in your WSUS network or for different computer
groups. After approving an update, you can do one (or more) of the following:
Apply this approval to child groups, if any.
Set a deadline for automatic installation. When you select this option, you set specific times and dates to
install updates, overriding any settings on the client computers. In addition, you can specify a past date for
the deadline if you want to approve an update immediately (to be installed the next time client computers
contact the WSUS server).
Remove an installed update if that update supports removal.
There are two IMPORTANT considerations that you should keep in mind:
First, you cannot set a deadline for automatic installation for an update if user input is required (for example,
specifying a setting relevant to the update). To determine whether an update will require user input, look at
the May request user input field in the update properties for an update displayed on the Updates page.
Also check for a message in the Approve Updates box that says, "The selected update requires user
input and does not support an installation deadline."
If there are updates to the WSUS server component, you cannot approve other updates to client systems
until the WSUS update is approved. You will see this warning message in the Approve Updates dialog:
"There are WSUS updates that have not been approved. You should approve the WSUS updates before
approving this update." In this case, you should click the WSUS Updates node and make sure that all of the
updates in that view have been approved before returning to the general updates.
To approve updates
1. In the WSUS administrative console, click Updates and then click All Updates.
2. In the list of updates, select the update that you want to approve and right-click (or go to the Actions pane),
and in the Approve Updates dialog, select the computer group for which you want to approve the update,
and click the arrow next to it.
3. Select Approved for Install, and then click Approve.
4. The Approval Progress window will display the progress toward completing the approval. When the
process is complete, the Close button appears. Click Close.
5. You can select a deadline by right-clicking the update, selecting the appropriate computer group, clicking the
arrow next to it, and then clicking Deadline.
You can select one of the standard deadlines (one week, two weeks, one month), or you can click
Custom to specify a date and time.
If you want an update to be installed as soon as the client computers contact the server, click Custom,
and then set a date and time to the current date and time or to one in the past.
To approve multiple updates
1. In the WSUS administrative console, click Updates and then click All Updates.
2. To select multiple contiguous updates, press shift while selecting updates. To select multiple noncontiguous
updates, press and hold down CTRL while selecting updates.
3. Right-click the selection and click Approve. The Approve Updates dialog opens with the Approval status
set to Keep existing approvals and the OK button disabled.
4. You can change the approvals for the individual groups, but doing so will not affect child approvals. select
the group for which you want to change the approval, and click the arrow to its left. In the shortcut menu,
click Approved for Install.
5. The approval for the selected group changes to Install. If there are any child groups, their approval remains
Keep existing approval. To change the approval for the child groups, click the group and click the arrow to
its left. In the shortcut menu, click Apply to Children.
6. To set a specific child to inherit all its approval from the parent, click the child and click the arrow to its left.
In the shortcut menu, click Same as Parent. If you set a child to inherit approvals, but are not changing the
parent approvals, the child will inherit the existing approvals of the parent.
7. If you want the approval behavior to change for all children, approve All computers, and then choose
Apply to Children.
8. Click OK after setting all your approvals. The Approval Progress window will display the progress toward
completing the approval. When the process is complete, the Close button will be available. Click Close.
Declining updates
if you select this option, the update is removed from the default list of available updates and the WSUS server will
not offer the update to clients, either for evaluation or installation. You can reach this option by selecting an update
or group of updates and right-clicking or going to the Actions pane. Declined updates will appear in the updates list
only if you select Declined in the Approval list when specifying the filter for the update list under View.
To decline updates
1. In the WSUS administrative console, click Updates, and then click All Updates.
2. In the list of updates, select one or more updates that you want to decline.
3. select Decline, and then click Yes on the confirmation message.
cleaning up declined updates
Declined updates continue to consume some WSUS server resources. You should run The Server cleanup Wizard
to remove declined updates from the WSUS database. See: The Server cleanup Wizard, for additional details.
Reinstating declined updates
After an update has been declined, you can still reinstate it.
To reinstate declined updates
1. In the WSUS administrative console, click Updates and then click All Updates.
2. change Approval to Declined and click Refresh. The list of declined updates loads.
3. In the list of updates, select one or more declined updates that you want to reinstate.
4. To reinstate a particular update, right click on the update and select Approve. In the Approve Updates
dialog, click OK to re-apply the default "Not Approved" approval status. The update will show in the list as
Not approved instead of Declined.
After a declined update has been cleaned up by using the WSUS Server cleanup Wizard, it will be deleted from the
WSUS server and will no longer appear in the All Updates view. You can re-import Declined, cleaned-up updates
from the Microsoft Update Catalog. For additional information, see WSUS and the Catalog Site.
change an Approved Update to Not Approved
If an update has been approved and you decide not to install it at this time, and instead want to save it for a future
time, you can change the update to a status of Not Approved. This means that the update will remain in the default
list of available updates and will report client compliance, but will not be installed on clients.
To change an update from approved to not approved
1. In the WSUS administrative console, click Updates, and then click All Updates.
2. In the list of updates, select one or more approved updates that you want to change to Not Approved.
3. In the shortcut menu or the Actions pane, select Not Approved, and then click Yes on the confirmation
message.
Approving Updates for removal
You can approve an update for removal (that is, to uninstall an already-installed update). This option is available
only if the update is already installed and supports removal. You can specify a deadline for the update to be
uninstalled, or specify a past date for the deadline if you want to remove the update immediately (the next time
client computers contact the WSUS server).
It is IMPORTANT to mention that not all updates support removal. You can see whether an update supports
removal by selecting an individual update and looking at the details pane. Under additional details, you will see
the removable category. If the update cannot be removed through WSUS, in some cases it can be removed with
add or remove Programs from Control Panel.
To approve updates for removal
1. In the WSUS administrative console, click Updates and then click All Updates.
2. In the list of updates, select one or more updates that you want to approve for removal and right-click them
(or go to the Actions pane).
3. In the Approve Updates dialog, select the computer group from which you want to remove the update, and
click the arrow next to it.
4. select Approved for removal, and then click the remove button.
5. After the remove approval has completed, you can select a deadline by right-clicking the update once more,
selecting the appropriate computer group, and then clicking the arrow next to it. Then select Deadline. You
may select one of the standard deadlines (one week, two weeks, one month), or you can click Custom to
select a specific date and time.
6. If you want an update to be removed as soon as the client computers contact the server, click Custom, and
set a date in the past.
Approving Updates Automatically
You can configure your WSUS server for automatic approval of certain updates. You can also specify automatic
approval of revisions to existing updates as they become available. This option is selected by default. A revision is a
version of an update that has had changes made to it (for example, it might have expired, or its applicability rules
might have changed). If you do not choose to approve the revised version of an update automatically, WSUS will
use the older version, and you must manually approve the update revision.
You can create rules that your WSUS server will automatically apply during synchronization. You specify what
updates you want to automatically approve for installation, by update classification, by product, and by computer
group. This applies only to new updates, as opposed to revised updates. You can also specify an update approval
deadline, which sets a number of days and a specific time of offering before the approved update is deadlineinstalled. These settings are available in the Options pane, under Automatic Approvals.
To automatically approve updates
1. In the WSUS administration console, click Options, and then click Automatic Approvals.
2. In Update Rules, click New Rule.
3. In the add Rule dialog, under Step 1: select properties, select whether to use When an update is in a
specific classification or When an update is in a specific product (or both) as criteria. Optionally, select
whether to Set a deadline for the approval.
4. In Step 2: edit the properties click the underlined properties to select the Classifications, Products, and
computer groups for which you want automatic approvals, as applicable. Optionally, choose the update
approval deadline Day and time.
5. In Step 3: Specify a name box, type a unique name for the rule.
6. Click OK.
Automatic approval rules will not apply to updates requiring an End User License Agreement (EULA) that has not
yet been accepted on the server. If you find that applying an automatic approval rule does not cause all the relevant
updates to be approved, you should approve these updates manually.
Automatically Approving Revisions to Updates and Declining Expired
Updates
The Automatic Approvals section of the Options pane contains a default option to automatically approve revisions
to approved updates. You can also set your WSUS server to automatically decline expired updates. If you choose
not to approve the revised version of an update automatically, your WSUS server will use the older revision, and
you must manually approve the update revision.
NOTE
A revision is a version of an update that has changed (for example, it might have expired or have updated applicability rules).
To automatically approve revisions to updates and decline expired updates
1. In the WSUS administration console, click Options, and then click Automatic Approvals.
2. On the Advanced tab, make sure that both Automatically approve new revisions of approved updates
and Automatically decline updates when a new revision causes them to expire are selected.
3. Click OK.
NOTE
Keeping the default values for these options allows you maintain good performance on your WSUS network. If you
do not want expired updates to be declined automatically, you should make sure to decline them manually on a
periodic basis.
Automatically Declining Superseded Updates
When you approve a new update that supersedes an existing update which is automatically approved, the
superseded update becomes "Not Applicable" to a computer or device once the newer update has been installed.
You can verify in the WSUS console that an update is Not Applicable for all computers. When that is the case, the
update can be safely Declined. additionally, the update may be automatically declined when you run the WSUS
Server cleanup Wizard.
To search for superseded updates, you can select the "Superseded" flag column in the All Updates view, and sort on
that column. There will be four groups:
Updates which have never been superseded (a blank icon).
Updates which have been superseded, but have never superseded another update (an icon with a blue
square at the bottom).
Updates which have been superseded and have superseded another update (an icon with a blue square in
the middle).
Updates which have superseded another update (an icon with a blue square at the top).
There is no feature in Windows Server Update Services that automatically declines superseded updates upon
approval of a newer update. It is recommended to first set the approval to "Not Approved," and then use the Server
cleanup Wizard to automatically decline the update when all relevant conditions have been satisfied. For more
information, see: The Server cleanup Wizard.
Approving Superseding or Superseded Updates
Typically, an update that supersedes other updates does one or more of the following:
Enhances, improves, or adds to the fix provided by one or more previously released updates.
Improves the efficiency of its update file package, which is installed on client computers if the update is
approved for installation. For example, the superseded update might contain files that are no longer relevant
to the fix or to the operating systems now supported by the new update, so those files are not included in
the superseding update's file package.
Updates newer versions of operating systems. It is also IMPORTANT to note that the superseding update
might not support earlier versions of operating systems.
Conversely, an update that is superseded by another update does the following:
Fixes a problem similar to that of the update that supersedes it. However, the update that supersedes it
might enhance the fix that the superseded update provides.
Updates earlier versions of operating systems. In some cases, these versions of operating systems are no
longer updated by the superseding update.
In an individual update's detail pane, an informational icon and a message at the top indicates that it either
supersedes or is superseded by another update. In addition, you can determine which updates supersede or are
superseded by the update by looking at the Updates superseding this update and Updates superseded by
this update entries in the additional details section of the Properties. An update's detail pane is displayed
below the list of updates.
WSUS does not automatically decline superseded updates, and it is recommended that you do not assume that
superseded updates should be declined in favor of the new, superseding update. Before declining a superseded
update, make sure that it is no longer needed by any of your client computers. The following are examples of
scenarios in which you might need to install a superseded update:
If a superseding update supports only newer versions of an operating system, and some of your client
computers run earlier versions of the operating system.
If a superseding update has more restricted applicability than the update it supersedes, which would make it
inappropriate for some client computers.
If an update no longer supersedes a previously released update because of new changes. It is possible that
through changes at each release, an update no longer supersedes an update it previously superseded in an
earlier version. In this scenario, you will still see a message about the superseded update, even though the
update that supersedes it has been replaced by an update that does not.
The Server cleanup Wizard
4/24/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The Server cleanup Wizard is integrated into the user interface and can be used to help you manage your disk
space. This wizard can do the following operations:
Remove unused updates and update revisions remove all older updates and update revisions that have not
been approved.
Delete computers not contacting the server delete all client computers that have not contacted the server in
thirty days or more.
Delete unneeded update files delete all update files that are not needed by updates or by downstream
servers.
Decline expired updates decline all updates that have been expired by Microsoft.
Decline superseded updates decline all updates that meet all the following criteria:
The superseded update is not mandatory
The superseded update has been on the server for thirty days or more
The superseded update is not currently reported as needed by any client
The superseded update has not been explicitly deployed to a computer group for ninety days or
more
The superseding update must be approved for install to a computer group
It is important to mention that if you choose to remove unneeded content with the Server cleanup Wizard, all the
private update files that you have downloaded from the Catalog Site will be removed as well. You will need to reimport these files after running the Server cleanup Wizard.
If updates are approved using an auto-approval rule, they might still be in the "Approved" state, and will not be
removed by The Server cleanup Wizard. To remove auto-approved updates that are in an "approved" state , the
WSUS Admin must - at minimum - manually set the approval status of superseded updates to "Not Approved" so
they will be eligible for declination by the Server cleanup Wizard. The Server cleanup Wizard will ensure a newer
update is approved and that no client system is still reporting that update as needed before marking the update as
"Declined."
Running WSUS Replica mode
4/24/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
A WSUS server running in replica mode inherits the update approvals and computer groups created on an
administration server. In a scenario that uses replica mode, you typically have a single administration server, and
one or more subordinate replica WSUS servers spread out throughout the organization, based on site or
organizational topography. You approve updates and create computer groups on the administration server, which
the replica mode servers will then mirror. Replica mode servers can be set up only during WSUS Setup, and if you
implemented this scenario, it is likely because it is important in your organization that update approvals and
computer groups are managed centrally.
If your WSUS server is running in replica mode, you will be able to perform only limited administration capabilities
on the server, which will primarily consist of:
Adding and removing computers from computer groups. Computer group membership is not distributed
to replica servers, only the computer groups themselves. Therefore, on a replica mode server, you will
inherit the computer groups that you created on the administration server. However, the computer groups
will be empty. You must then assign the client computers that connect to the replica server to the computer
groups.
Setting a synchronization schedule
Specifying proxy-server settings
Specifying the update source. This can be a server other than the administration server
Viewing available updates
Monitoring update, synchronization, computer status, and WSUS settings on the server
Running all standard WSUS reports available on replica mode servers
WSUS Messages and Troubleshooting Tips
4/24/2017 • 3 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
This topic provides information about some common WSUS messages.
WSUS Messages
This section contains information about the following WSUS messages:
Computer has not reported status:
Message ID 6703 - WSUS Synchronization Failed
Error 0x80070643: Fatal error during installation
Some services are not running. Check the following services
computer has not reported status:
Troubleshooting computer connection issues
This message is generated in the WSUS console when a WSUS client computer does not send information to the
WSUS server to indicate it's current update state. This issue is typically caused by the WSUS client computer, not
the WSUS server.
The most common reasons are:
The computer is turned off
The computer has lost connectivity to the network:
The network cable is unplugged
The computer has a faulty network adapter
The network port to which the computer connects has been disabled
The wireless adapter is unable to associate with and connect to the corporate wireless access point
The computer is in hibernation mode
The computer has been physically removed from the network
Message ID 6703 - WSUS Synchronization Failed
Message: The request failed with HTTP status 503: Service Unavailable.
Source: Microsoft.UpdateServices.Administration.AdminProxy.createUpdateServer.
When you attempt to open Update Services on the WSUS server you receive the following error:
Error: Connection Error
An error occurred trying to connect to the WSUS server. This error can happen for a number of reasons.
Please contact your network administrator if the problem persists. Click the reset Server Node to connect
to the server again.
In addition to the above, attempts to access the URL for the WSUS Administration website (i.e.,
http://CM12CAS:8530) fails with the error:
HTTP Error 503. The service is unavailable
In this situation, the most likely cause is that the WsusPool Application Pool in IIS is in a stopped state.
Also, the Private Memory Limit (KB) for the Application Pool is probably set to the default value of 1843200 KB.
if you encounter this problem, increase the Private Memory Limit to 4GB (4000000 KB) and restart the Application
Pool. To increase the Private Memory Limit, select the WsusPool Application Pool and click Advanced Settings
under edit Application Pool. Then set the Private Memory Limit to 4GB (4000000 KB).
After the Application Pool has been restarted, monitor the SMS_WSUS_SYNC_MANAGER component status,
wcm.log and wsyncmgr.log for failures. Please note that it may be necessary to increase the Private Memory Limit
to 8GB (8000000 KB) or higher depending on the environment.
For additional details, see: WSUS sync in ConfigMgr 2012 fails with HTTP 503 errors
Error 0x80070643: Fatal error during installation
Cause: WSUS Setup uses Microsoft SQL Server to perform the installation. This problem occurs because the user
who is running WSUS Setup does not have System Administrator permissions in SQL Server.
Resolution: To resolve this problem, grant System Administrator permissions to a user account or to a group
account in SQL Server, and then run WSUS Setup again.
Some services are not running. Check the following services:
Selfupdate See Automatic Updates Must Be Updated for information about troubleshooting the Selfupdate
service.
WSSUService.exe This service facilitates synchronization. If you have problems with synchronization, access
WSUSService.exe by clicking start, pointing to Administrative Tools, clicking Services, and then finding
Windows Server Update Service in the list of services. Do the following:
Verify that this service is running. Click Start if it is stopped or Restart to refresh the service.
Use Event Viewer to check the Application, Security, and System event logs to see if there are any events
that might indicate a problem.
You can also check the SoftwareDistribution.log to see if there are events that might indicate a problem.
Web servicesSQL Service Web services are hosted in IIS. If they are not running, ensure that IIS is running (or
started). You can also try resetting the Web service by typing iisreset at a command prompt.
SQL Service Every service except for the selfupdate service requires that the SQL service is running. If any of the
log files indicate SQL connection problems, check the SQL service first. To access the SQL service, click Start, point
to Administrative Tools, click Services, and then look for one of the following:
MSSQLSERver (if you are using WMSDE or MSDE, or if you are using SQL Server and are using the default
instance name for the instance name)
MSSQL$WSUS (if you are using a SQL Server database and have named your database instance "WSUS")
Right-click the service, and then click Start if the service is not running, or Restart to refresh the service if it
is running.
4/24/2017 • 6 min to read • Edit Online
Applies To: Windows 10 1607, Windows Server 2016
Express update delivery ISV support
Windows 10 Update downloads can be large because every package contains all previously released fixes to
ensure consistency and simplicity.
Since version 7, Windows has been able to reduce the size of Windows Update downloads with a feature called
Express, and although consumer devices support it by default, Windows 10 enterprise devices require Windows
Server Update Services (WSUS) to take advantage of Express.
How Microsoft supports Express
Express on WSUS Standalone
Express update delivery is already available on all supported versions of WSUS.
Express on Devices Directly Connected to Windows Update
Consumer devices support Express download: they use the Windows Update (WU) client to scan, download
and install updates. During the download phase, the WU client requests Express packages and downloads
the appropriate byte ranges.
Enterprise devices managed using Windows Update for Business also get the benefit of Express
update delivery support without any change in configuration.
How ISVs can take advantage of Express
ISVs can use WSUS and the WU client to support Express update delivery. Microsoft recommends the following
three steps, each discussed in more detail in the sections below:
1. Configure WSUS
WSUS server is required for scan & update synchronizations (additional information can be found here)
2. Specify and populate an ISV file cache
An ISV file cache is recommended to host the update content, which includes the update cabinet files (.cab
files) and the Express packages (.psf files).
3. Set up an ISV client agent to direct WU client operations
NOTE
Requires Cumulative Update for Windows 10 Version 1607 release in (or after) January 2017 (KB3213986 (OS Build
14393.693) to be installed.
The ISV client agent determines which updates to approve, and when do download and install updates
The WU client determines byte ranges to download and initiates the download request
Step 1: Configure WSUS
WSUS serves as the interface to Windows Update and manages all metadata describing Express packages that
need to be downloaded. If you need to deploy, see Overview of Windows Server Update Services 3.0 SP2.
Once WSUS has been deployed, the primary consideration is whether or not to store update content locally on the
WSUS server. When configuring WSUS, we recommend not storing updates locally. This assumes that you already
have software directing deployment of these packages in your environment. For more about how to configure
WSUS local storage, see Determine Where to Store Updates.
Step 2: Specify and Populate the ISV File Cache
Specify the ISV File Cache
New client-side Group Policy and Mobile Device Management (MDM) settings detailed in the Configuration
service provider reference define the location of the ISV file cache.
NAME
DESCRIPTION
Configure an alternate download location for updates.
Specifies an alternate intranet server to host updates from
Microsoft Update. You can then use this update service to
automatically update computers on your network
There are two options when setting up the alternate download location for the ISV file cache:
1. Specify an ISV HTTP server hostname, which is the ISV file cache
This approach configures the WU client to make download requests to the HTTP server specified in the
policy
2. Specify localhost
This approach configures the WU client to make download requests to localhost. This allows the ISV client
agent to handle these requests and route as appropriate to fulfill the download request.
IMPORTANT
The ISV file cache requires the following:
The server must be HTTP 1.1 compliant per the RFC: http://www.w3.org/Protocols/rfc2616/rfc2616.html
Specifically, the web server needs to support HEAD and GET requests
- Partial Range requests
- Keep-alive
- Do not use “Transfer-Encoding:chunked”
Populate the ISV File Cache
The ISV file cache must be populated with files associated with the updates to be installed on managed clients.
To populate the ISV file cache:
1. Use WSUS APIs to access the update’s file path and file name for the MU service.
The metadata for each update on WSUS server contains the update’s file path and file name on Microsoft
Update as follows (Microsoft Update hostname in bold, followed by file path and filename):
http://download.windowsupdate.com/c/msdownload/update/software/updt/2016/09/windows10.0kb3195781-x64_0c06079bccc35cba35a48bd2b1ec46f818bd2e74.msu
2. Download files from Microsoft Update and store them in the ISV file cache using one of these two methods:
Store files using the same folder path as on the MU service
Store files using an ISV-defined folder path
Have HTTP server (or localhost) redirect HTTP GET requests, which reference the MU folder path and
file name, to the ISV file location.
Step 3: Set up an ISV client agent to direct WU client operations
The ISV client agent orchestrates the download and installation of approved updates using the following
recommended workflow:
1. The ISV client agent calls the WU client to scan against the WSUS server
2. The scan returns the set of applicable updates to the WU client
3. The ISV client determines which updates to approve, download and install
4. The ISV client agent calls WU client to download the approved updates
5. Once the updates have been downloaded, the ISV client agent calls the WU client to install the approved
updates
See Searching, Downloading, and Installing Updates for additional information about using the WU client to scan,
download and install updates.
Download workflow options
Following are two illustrations of download workflow options from an ISV file cache:
How Express download works
For OS updates that support Express, there are two versions of the file payload stored on the service:
Full-file version -- essentially replacing the local versions of the update binaries
Express version -- containing the deltas needed to patch the existing binaries on the device.
Both the full-file version and the Express version are referenced in the update’s metadata, which has
been downloaded to the client as part of the Scan phase.
Express download works as follows:
The WU client will try to download Express first, and under certain situations fall back to full-file if
needed (for example, if going through a proxy that doesn’t support byte range requests).
1. When the WU client initiates an Express download, the WU client first downloads a stub, which is
part of the Express package.
2. The WU client passes this stub to the Windows installer, which uses the stub to do a local
inventory, comparing the deltas of the file on the device with what is needed to get to the latest
version of the file being offered.
3. The Windows installer then requests the WU client to download the ranges which have been
determined to be required.
4. The WU client downloads these ranges and passes them to the Windows installer, which
applies the ranges and then determines if additional ranges are needed. This repeats until the
Windows installer tells the WU client that all necessary ranges have been downloaded.
At this point, the download is complete and the update is ready to be installed.
How Delivery Optimization reduces bandwidth consumption
Delivery Optimization (DO) is a self-organizing distributed cache solution for businesses looking to reduce
bandwidth consumption for operating system updates, operating system upgrades, and applications. DO allows
clients to download those elements from alternate sources (such as other peers on the network) in conjunction
with the specified download location (the ISV file cache in this scenario).
By default in Windows 10 Enterprise and Education, DO allows peer-to-peer sharing on the organization's own
network only, but you can configure it differently using Group Policy and mobile device management (MDM)
settings.
Refer to Configure Delivery Optimization for Windows 10 updates for more information about DO.
5/2/2017 • 3 min to read • Edit Online
Applies To: Windows 10 1607, Windows Server 2016
Monthly Delta update ISV support without WSUS
Windows 10 Update downloads can be large because every package contains all previously released fixes to ensure
consistency and simplicity.
Since version 7, Windows has been able to reduce the size of Windows Update downloads with a feature called
Express, and although consumer devices support it by default, Windows 10 enterprise devices require Windows
Server Update Services (WSUS) to take advantage of Express. If you have WSUS available, see Express update
delivery ISV support. We recommend using it to to enable Express update delivery.
If you do not currently have WSUS installed, but you need smaller update package sizes in the interim, you can use
Monthly Delta update. Delta update reduces package sizes substantially, but not as much as with WSUS Express
update delivery. We recommend that you deploy WSUS Express update whenever possible for the greatest
reduction in package sizes. Following is a chart comparing Delta, Cumulative and Express download sizes for
Windows 10 version 1607:
What is Monthly Delta update?
There are two variants of the monthly security update: Delta and Cumulative.
Monthly Delta update is new, and an interim solution for ISVs who do not have WSUS available to help reduce
update package sizes.
IMPORTANT
Delta update will only be available for servicing of Windows 10 1607 (Anniversary Update) and 1703 (Creators
Update) releases. For releases after 1703, you will need to implement a deployment infrastructure that supports Express
update delivery to continue taking advantage of incremental updates.
By using Monthly Delta update, packages will only contain one month’s updates. Monthly Cumulative contains all
the updates up to that update release, resulting in a large file that grows each month. Both Delta and Monthly
updates are released on the second Tuesday of each month, also known as "Update Tuesday." The following table
compares Delta and Cumulative updates:
MONTHLY DELTA UPDATE
MONTHLY CUMULATIVE UPDATE
Scope
Single update with only new fixes for
that month
Single update with all new fixes for that
month and all previous months
Application
Can only be applied if the previous
month’s update was applied
(Cumulative or Delta)
Can be applied at any time
Delivery
Published only to Windows Update
Catalog where it can be downloaded
for use with other tools or processes.
Not offered to PCs that are connected
to Windows Update
Published to Windows Update (where all
consumer PCs will install it), WSUS, and
the Windows Update Catalog
Delta and Cumulative have the same KB number, with the same classification, and release at the same time. Updates
can be distinguished by either the update title in the catalog, or by the name of the msu:
2017-02 \Delta Update** for Windows 10 Version 1607 for x64-based Systems (KB1234567)
2017-02 \Cumulative Update** for Windows 10 Version 1607 for x86-based Systems (KB1234567)
When to use Monthly Delta Update
If size of the update to the client device is a concern, we recommend using Delta update on the devices that have
the previous month’s update, and Cumulative update on the devices that are falling behind. This way, all devices
only require a single update to bring them up to date. This requires a small adjustment in the overall update
management process, as you will have to deploy different updates based on how up-to-date the devices are in the
organization:
Prevent deployment of Delta and Cumulative updates in the same month
Since Delta update and Cumulative update are available at the same time, it’s important to understand what
happens if you deploy both updates in the same month.
If you approve and deploy the same version of the Delta and Cumulative update, you will not only generate
additional network traffic since both will be downloaded to the PC, but you may not be able to reboot your
computer to Windows after restart.
If both Delta and Cumulative updates are inadvertently installed and your computer is no longer booting, you can
recover with the following steps:
1. Boot into WinRE command prompt
2. List the packages in a pending state:
x:\windows\system32\dism.exe /image:<drive letter for windows directory> /Get-Packages >> <path to text
file>
Example:
x:\windows\system32\dism.exe /image:c:\ /Get-Packages >> c:\temp\packages.txt
3. Open the text file where you piped get-packages. If you see any install pending patches, run removepackage for each package name:
dism.exe /image:<drive letter for windows directory> /remove-package /packagename:<package name>
Example:
x:\windows\system32\dism.exe /image:c:\ /remove-package
/packagename:Package_for_KB4014329~31bf3856ad364e35~amd64~~10.0.1.0
NOTE
Do not remove uninstall pending patches.
IMPORTANT
Delta update will only be available for servicing of Windows 10 1607 (Anniversary Update) and 1703 (Creators
Update) releases. For releases after 1704, you will need to implement a deployment infrastructure that supports Express
update delivery to continue taking advantage of incremental updates.
4/24/2017 • 4 min to read • Edit Online
Applies to: Windows Server 2012, Windows Server 2012 R2, Windows Server 2016
Migrating the WSUS Database from WID to SQL
Use the following steps to migrate the WSUS database (SUSDB) from a Windows Internal Database instance to a
Local or Remote instance of SQL Server.
Prerequisites:
SQL Instance. This can be the default MSSQLServer or a custom Instance.
SQL Server Management Studio
WSUS with WID role installed
IIS (This is normally included when you install WSUS through Server Manager). It is not already installed, it
will need to be.
To migrate the WSUS database
1. Stop the IISAdmin and WSUS Services on the WSUS Server
From PowerShell (elevated), run:
a. Stop-Service IISADMIN
b. Stop-Service WsusService
2. Detach the SUSDB from the Windows Internal Database. This can be done from SQL Management Studio or
from a command prompt (elevated):
Using SQL Management Studio:
a. Right-click SUSDB -> Tasks -> click Detach:
Check Drop Existing Connections and click OK (optional, if active connections exist).
b. From a command prompt (Administrator mode):
Run the following SQL command to detach the WSUS database (SUSDB) from the Windows Internal
Database instance by using the sqlcmd utility. For more information about the sqlcmd utility, see
sqlcmd Utility.
cmd -S \\.\pipe\Microsoft\#\#WID\tsql\query use master
alter database SUSDB set single_user with rollback immediate
GO
sp_detach_db SUSDB
GO
3. Copy SUSDB.mdf and SUSDB_log.ldf from the WID Data Folder (%SystemDrive%*Windows\WID\Data*)
to the SQL Instance Data Folder.
For example, if your SQL Instance Folder is C:\Program Files\Microsoft SQL
Server\MSSQL12.MSSQLSERVER\MSSQL, and the WID Data folder is C:\Windows\WID\Data, copy the
SUSDB files from C:\Windows\WID\Data to C:\Program Files\Microsoft SQL
Server\MSSQL12.MSSQLSERVER\MSSQL\Data
4. Attach SUSDB to the SQL Instance
a. In SQL Server Management Studio, under the Instance node, right-click Databases, and then click
Attach.
b. In the Attach Databases box, under Databases to attach, click the Add button and locate the
SUSDB.mdf file (copied from the WID Folder), and then click OK.
5. After attaching the SUSDB, verify that NT AUTHORITY\NETWORK SERVICE has login permissions to the
instance of SQL Server:
In SQL Server Management Studio, open the instance, click Security, and then click Logins. The NT
AUTHORITY\NETWORK SERVICE account should be listed. If it is not, you need to add it by adding New
Login Name:
a. Right Click Logins and click New Login…
b. On the General page, fill out the Login name (NT AUTHORITY\NETWORK SERVICE), and set the
Default database to SUSDB.
c. On the Server Roles page, ensure public and sysadmin are selected.
d. On the User Mapping page:
Under Users mapped to this login: select **SUSDB
Under Database role membership for: SUSDB, ensure public and webService are checked.
e. Click OK. You should now see NT AUTHORITY\NETWORK SERVICE under Logins.
6. Verify permissions on the database:
Right-click the SUSDB, select Properties, and then click Permissions. The NT AUTHORITY\NETWORK
SERVICE account should be listed. If it is not, you need to add it.
If both WSUS and SQL Instance are on the same machine skip to step 8. Otherwise proceed to step 7.
7. For remote SQL instances, you will also need to grant the WSUS server rights to connect to the remote SQL
Server Instance. In SQL Server Management Studio, connect to the SQL instance, click Security, and then
click Logins. The WSUS Server account should be listed. If it is not, you need to add it.
a. On the Login name textbox, enter the WSUS machine in the following format: [FQDN]
[WSUSComputerName]$. Verify that the Default database is set to SUSDB.
In the following example, the FQDN is Contosto.com and the WSUS machine name is
WsusMachine:
b. On the User Mapping page, select the SUSDB Database under "Users mapped to this login", and
check webservice under the "Database role membership for: SUSDB":
c. Click OK to save settings. You may need to restart the SQL Service for the changes to take effect.
8. Edit the registry to point WSUS to the instance of SQL Server that now holds the WSUS database and to
recognize the new database for future WSUS updates. If you have not already done so, export the keys in the
registry that you plan to edit or back up the whole registry.
a. Click Start, click Run, type regedit, and then click OK.
b. Locate the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\UpdateServices\Server\Setup\SqlServerNam
e
In the Value text box, type [ServerName] \ [InstanceName], and then click OK. If the instance name
is the default instance, type [ServerName].
c. Locate the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update
Services\Server\Setup\Installed Role Services\UpdateServices-WidDatabase
d. Rename the Key to UpdateServices-Database
NOTE
If you do not update this key, then WsusUtil will attempt to service the WID rather than the SQL Instance to
which you have migrated.
9. Start IISAdmin and WSUS Services:
From Task Manager:
a. Ctrl + Shift + Esc, click More details, and then click Services
b. Right-click IISAdmin, and then click Start
c. Right-click WsusService, and then click Start
From PowerShell, run:
a. Start-Service IISADMIN
b. Start-Service WsusService
10. If you are using the WSUS Console, close and restart it.
11. Uninstalling the WID Role (Not Recommended):
Removing the WID Role also removes a Database Folder (%SystemDrive%\Program Files\Update
Services\Database) which contains scripts required by WSUSUtil.exe for post-installation tasks. If you
choose to uninstall the WID role, make sure you back up the %SystemDrive%\Program Files\Update
Services\Database folder beforehand.
After the WID role is removed, verify that the following registry key is present:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\Installed Role
Services\UpdateServices-Database
Windows Commands
5/1/2017 • 5 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Use this topic to find the documentation resources and other technical information that you need to learn about the
command shell, and to automate command-line tasks by using scripts or scripting tools.
To read introductory information about the command shell and command-line tools, see Feature description.
To find information about a specific command, in the following A-Z menu, click the letter that the command starts
with, and then click the command name.
A | B | C | D | E | F | G | H | I | J| K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
Prerequisites
The information that is contained in this overview applies to:
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003 R2
Windows Server 2003
Windows 8
Windows 7
Windows Vista
Windows XP
Feature description
Command shell overview
The command shell is a software program that provides direct communication between the user and the operating
system. The non-graphical, command shell user interface provides the environment in which you run characterbased applications and utilities. The command shell executes programs and displays their output on the screen by
using individual characters similar to the MS-DOS command interpreter, Command.com. The command shell in the
Windows Server operating system uses the command interpreter, Cmd.exe. Cmd.exe loads applications, directs the
flow of information between applications, and translates user input into a form that the operating system
understands.
You can use the command shell to create and edit scripts to automate routine tasks. For example, you can create
simple scripts in batch (.bat) files to automate the management of user accounts or nightly backups. You can also
use the command-line version of Windows Script Host to run more sophisticated scripts in the command shell. For
more information, see cscript or wscript. You can perform operations more efficiently by using scripts than you can
by using the user interface. Scripts accept all commands that are available at the command line.
Customize the Command prompt window
You can change the properties for the Command prompt window.
To c o n fi g u r e t h e C o m m a n d p r o m p t w i n d o w
1. Open a Command prompt window, click the upper-left corner of the Command prompt window, and then click
2.
3.
4.
5.
6.
7.
8.
Properties. (Or to open Command prompt Properties from the keyboard, press ALT+SPACEBAR+P.)
Click the Options tab.
In Command History, type or select 999 in Buffer Size, and then type or select 5 in Number of Buffers. By
increasing the screen buffer size to 999, you enable scrolling through the Command prompt window. By
increasing the number of buffers to five, you increase the number of lines in the Command prompt window to
5000.
In edit Options, select the Quick edit mode and Insert mode check boxes.
Click the Layout tab.
In Screen Buffer Size, type or select 2500 in Height.
To further customize your Command prompt window settings, perform any of the following optional tasks:
In Screen Buffer Size, increase Width.
In Window Size, increase Height.
In Window Size, increase Width.
Clear the Let system position window check box, and then, in Window Position, change the values in
Left and Top.
In the Apply Properties dialog box, click Save properties for future windows with same title.
NOTE
To enable or disable file and directory name completion on a computer or user logon session, run regedit.exe and set the
following reg_DWOrd value:
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\completionChar\reg_DWOrd
To set the reg_DWOrd value, use the hexadecimal value of a control character for a particular function (for example, 0 9 is
Tab and 0 08 is Backspace). User-specified settings take precedence over computer settings, and command-line options take
precedence over registry settings.
Cau t i on
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you
should back up any valued data on the computer.
Command-line reference A-Z
To find information about a specific command, in the following A-Z menu, click the letter that the command starts
with, and then click the command name. A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X
|Y|Z
NOTE
Each command-line tool topic displays the version of Windows that is supported by the command-line tool.
A
append
arp
assoc
at
atmadm
attrib
auditpol
autochk
autoconv
autofmt
Command-line reference A-Z
B
bcdboot
bcdedit
bdehdcfg
bitsadmin
bootcfg
break_1
Command-line reference A-Z
C
cacls_1
call
cd
certreq_old
certutil
change
chcp
chdir_1
chglogon
chgport
chgusr
chkdsk
chkntfs
choice
cipher
clip
cls
Cmd
cmdkey
cmstp
color
comp
compact
convert
copy
cprofile
cscript
Command-line reference A-Z
D
date
dcgpofix
defrag
del
dfsrmig
diantz
dir
diskcomp
diskcopy
diskperf
diskraid
diskshadow
dispdiag
Dnscmd
doskey
driverquery
Command-line reference A-Z
E
echo
edit
endlocal
erase
eventcreate
eventquery
eventtriggers
Evntcmd
exit_2
expand
extract
Command-line reference A-Z
F
fc
find
findstr
finger
flattemp
fondue
for
forfiles
format
freedisk
fsutil
ftp
ftype
fveupdate
Command-line reference A-Z
G
getmac
gettype
goto
gpfixup
gpresult
gpupdate
graftabl
Command-line reference A-Z
H
help
helpctr
hostname
Command-line reference A-Z
I
icacls
if
inuse
ipconfig
ipxroute
irftp
Command-line reference A-Z
J
jetpack
Command-line reference A-Z
K
klist
ksetup
ktmutil
ktpass
Command-line reference A-Z
L
label
lodctr
logman
logoff
lpq
lpr
Command-line reference A-Z
M
macfile
makecab
manage-bde
mapadmin
Md
mkdir
mklink
mmc
mode
more
mount
mountvol
move
mqbkup
mqsvc
mqtgsvc
msdt
msg
msiexec
msinfo32
mstsc
Command-line reference A-Z
N
nbtstat
netcfg
netsh
netstat
Net print
nfsadmin
nfsshare
nfsstat
nlbmgr
nslookup
ntbackup
ntcmdprompt
ntfrsutl
Command-line reference A-Z
O
openfiles
Command-line reference A-Z
P
pagefileconfig
path
pathping
pause
pbadmin
pentnt
perfmon
ping
pnpunattend
pnputil
popd
PowerShell
PowerShell_ise
print
prncnfg
prndrvr
prnjobs
prnmngr
prnport
prnqctl
prompt
pubprn
pushd
pushprinterconnections
Command-line reference A-Z
Q
qappsrv
qprocess
query
quser
qwinsta
Command-line reference A-Z
R
rcp
rd
rdpsign
recover
reg
regini
regsvr32
relog
rem
ren
rename
repair-bde
replace
reset session
rexec
risetup
rmdir
robocopy
route_ws2008
rpcinfo
rpcping
rsh
rundll32
rwinsta
Command-line reference A-Z
S
schtasks
Scwcmd
secedit
serverceipoptin
Servermanagercmd
serverweroptin
set_1
setlocal
setx
sfc
shadow
shift
showmount
shutdown
sort
start
subst
sxstrace
sysocmgr
systeminfo
Command-line reference A-Z
T
takeown
tapicfg
taskkill
tasklist
tcmsetup
telnet
tftp
time
timeout_1
title_1
tlntadmn
tpmvscmgr
tracerpt_1
tracert
tree
tscon
tsdiscon
tsecimp_1
tskill
tsprof
type
typeperf
tzutil
Command-line reference A-Z
U
unlodctr_1
Command-line reference A-Z
V
ver
verifier
verify_1
vol
Command-line reference A-Z
W
waitfor
wbadmin
wdsutil
wecutil
wevtutil
where_1
whoami
winnt
winnt32
winpop
winrs
wlbs_1
wmic
wscript
Command-line reference A-Z
X
xcopy
Command-line reference A-Z
Y
Command-line reference A-Z
Z
Command-line reference A-Z
A-Z list
4/24/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Alphabetical listing of commands:
append
arp
assoc
at
atmadm
attrib
auditpol
autochk
autoconv
autofmt
bcdboot
bcdedit
bdehdcfg
bitsadmin
bootcfg
break_1
cacls_1
call
cd
certreq_old
certutil
change
chcp
chdir_1
chglogon
chgport
chgusr
chkdsk
chkntfs
choice
cipher
clip
cls
Cmd
cmdkey
cmstp
color
comp
compact
convert
copy
cprofile
cscript
date
dcgpofix
defrag
del
dfsrmig
diantz
dir
diskcomp
diskcopy
diskperf
diskraid
diskshadow
dispdiag
Dnscmd
doskey
driverquery
echo
edit
endlocal
erase
Evntcmd
eventcreate
eventquery
eventtriggers
exit_2
expand
extract
fc
find
findstr
finger
flattemp
for
forfiles
format
freedisk
fsutil
ftp
ftype
fveupdate
getmac
gettype
goto
gpfixup
gpresult
gpupdate
graftabl
help
helpctr
hostname
icacls
if
inuse
ipconfig
ipxroute
irftp
jetpack
klist
ksetup
ktmutil
ktpass
label
lodctr
logman
logoff
lpq
lpr
macfile
makecab
manage-bde
mapadmin
Md
mkdir
mklink
mode
more
mount
mountvol
move
mqbkup
mqsvc
mqtgsvc
msdt
msg
msiexec
msinfo32
mstsc
nbtstat
netcfg
netsh
netstat
Net print
nfsadmin
nfsshare
nfsstat
nslookup
ntbackup
ntcmdprompt
openfiles
pagefileconfig
path
pathping
pause
pbadmin
pentnt
perfmon
ping
pnpunattend
pnputil
popd
PowerShell
print
prncnfg
prndrvr
prnjobs
prnmngr
prnport
prnqctl
prompt
pubprn
pushd
qappsrv
qprocess
query
quser
qwinsta
rcp
rd
rdpsign
recover
reg
regsvr32
relog
rem
ren
rename
repair-bde
replace
reset session
rexec
risetup
rmdir
robocopy
route_ws2008
rpcinfo
rpcping
rsh
rundll32
rwinsta
schtasks
serverceipoptin
Servermanagercmd
serverweroptin
set_1
setlocal
setx
sfc
shadow
shift
showmount
shutdown
sort
start
subst
sysocmgr
systeminfo
sxstrace
tapicfg
takeown
taskkill
tasklist
tcmsetup
telnet
tftp
time
timeout_1
title_1
tlntadmn
tracerpt_1
tracert
tree
tscon
tsdiscon
tsecimp_1
tskill
tsprof
type
typeperf
tzutil
unlodctr_1
ver
verifier
verify_1
vol
waitfor
wbadmin
wdsutil
wecutil
wevtutil
where_1
whoami
winnt
winnt32
winpop
winrs
wmic
xcopy
Command-Line Syntax Key
6/7/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The following table describes the notation used to indicate command-line syntax.
NOTATION
DESCRIPTION
Text without brackets or braces
Items you must type as shown
<Text inside angle brackets>
Placeholder for which you must supply a value
[Text inside square brackets]
Optional items
{Text inside braces}
Set of required items; choose one
Vertical bar (
)
Ellipsis (…)
Items that can be repeated
Commands by Server Role
4/24/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
A server role describes the primary function of the server. Administrators can choose to dedicate an entire server to
one role, or install multiple server roles and sub roles on a single computer. Each role may include additional
command-line tools, installed as part of the role. The following topics provide a list of commands associated with
each server role.
print Command Reference
Services for Network File System Command Reference
remote Desktop Services (Terminal Services) Command Reference
Windows Server Backup Command Reference
print Command Reference
4/24/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The following is a list of print command-line tools.
COMMAND
DESCRIPTION
[lpq]lpq.md)
Displays the status of a print queue on a computer running
Line printer Daemon (LPD).
lpr
Sends a file to a computer or printer sharing device running
the Line printer Daemon (LPD) service in preparation for
printing.
Net print
Displays information about a specified printer queue, displays
information about a specified print job, or controls a specified
print job.
print
Sends a text file to a printer.
prncnfg
Configures or displays configuration information about a
printer.
prndrvr
adds, deletes, and lists printer drivers.
prnjobs
pauses, resumes, cancels, and lists print jobs.
prnmngr
adds, deletes, and lists printers or printer connections, in
addition to setting and displaying the default printer.
prnport
creates, deletes, and lists standard TCP/IP printer ports, in
addition to displaying and changing port configuration.
prnqctl
prints a test page, pauses or resumes a printer, and clears a
printer queue.
pubprn
Publishes a printer to the active directory directory service.
rundll32 printui.dll,printUIEntry
Enables you to automate the installation and configuration of
printers using scripts or the command prompt.
Services for Network File System Command
Reference
6/7/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Services for Network File System (NFS) provides a file sharing solution that enables you to transfer files between
computers running Windows Server 2008 and UNIX operating systems using the NFS protocol.
The following is a list of NFS command-line tools.
COMMAND
DESCRIPTION
mapadmin
Manage User Name Mapping for Microsoft Services for
Network File System.
Mount
Mount Network File System (NFS) network shares.
Nfsadmin
Manage Server for NFS and Client for NFS.
Nfsshare
Control Network File System (NFS) shares.
Nfsstat
Display or reset counts of calls made to Server for NFS.
Rpcinfo
List programs on remote computers.
Showmount
Display mounted directories.
remote Desktop Services (Terminal Services)
Command Reference
4/24/2017 • 2 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The following is a list of remote Desktop Services command-line tools.
NOTE
In Windows Server 2008 R2, Terminal Services was renamed remote Desktop Services. To find out what's new in the latest
version, see What s New in remote Desktop Services in Windows Server 2012 in the Windows Server TechNet Library.
CO M M AND
DESCRIPTIO N
change
changes remote Desktop Session Host (rd Session Host) server
settings for logons, COM port mappings, and install mode.
change logon
Enables or disables logons from client sessions on an rd
Session Host server, or displays current logon status.
change port
lists or changes the COM port mappings to be compatible with
MS-DOS applications.
change user
changes the install mode for the rd Session Host server.
chglogon
Enables or disables logons from client sessions on an rd
Session Host server, or displays current logon status.
chgport
lists or changes the COM port mappings to be compatible with
MS-DOS applications.
chgusr
changes the install mode for the rd Session Host server.
flattemp
Enables or disables flat temporary folders.
logoff
Logs off a user from a session on an rd Session Host server
and deletes the session from the server.
msg
Sends a message to a user on an rd Session Host server.
mstsc
creates connections to rd Session Host servers or other remote
computers.
qappsrv
Displays a list of all rd Session Host servers on the network.
qprocess
Displays information about processes that are running on an rd
Session Host server.
query
Displays information about processes, sessions, and rd Session
Host servers.
query process
Displays information about processes that are running on an rd
Session Host server.
CO M M AND
DESCRIPTIO N
query session
Displays information about sessions on an rd Session Host
server.
query termserver
Displays a list of all rd Session Host servers on the network.
query user
Displays information about user sessions on an rd Session Host
server.
quser
Displays information about user sessions on an rd Session Host
server.
qwinsta
Displays information about sessions on an rd Session Host
server.
rdpsign
Enables you to digitally sign a remote Desktop Protocol (.rdp)
file.
reset session
Enables you to reset (delete) a session on an rd Session Host
server.
rwinsta
Enables you to reset (delete) a session on an rd Session Host
server.
shadow
Enables you to remotely control an active session of another
user on an rd Session Host server.
tscon
Connects to another session on an rd Session Host server.
tsdiscon
Disconnects a session from an rd Session Host server.
tskill
Ends a process running in a session on an rd Session Host
server.
tsprof
Copies the remote Desktop Services user configuration
information from one user to another.
Windows Server Backup Command Reference
6/7/2017 • 1 min to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
The following subcommands for wbadmin provide backup and recovery functionality from a command prompt.
To configure a backup schedule, you must be a member of the Administrators group. To perform all other tasks
with this command, you must be a member of the Backup Operators or the Administrators group, or you must
have been delegated the appropriate permissions.
You must run wbadmin from an elevated command prompt. (To open an elevated command prompt, click Start,
right-click Command Prompt, and then click Run as administrator.)
SUBCOMMAND
DESCRIPTION
Wbadmin enable backup
Configures and enables a daily backup schedule.
Wbadmin disable backup
Disables your daily backups.
Wbadmin start backup
Runs a one-time backup. If used with no parameters, uses the
settings from the daily backup schedule.
Wbadmin stop job
Stops the currently running backup or recovery operation.
Wbadmin get versions
Lists details of backups recoverable from the local computer
or, if another location is specified, from another computer.
Wbadmin get items
Lists the items included in a specific backup.
Wbadmin start recovery
Runs a recovery of the volumes, applications, files, or folders
specified.
Wbadmin get status
Shows the status of the currently running backup or recovery
operation.
Wbadmin get disks
Lists disks that are currently online.
Wbadmin start systemstaterecovery
Runs a system state recovery.
Wbadmin start systemstatebackup
Runs a system state backup.
Wbadmin delete systemstatebackup
Deletes one or more system state backups.
Wbadmin start sysrecovery
Runs a recovery of the full system (at least all the volumes that
contain the operating system's state). This subcommand is
only available if you are using the Windows Recovery
Environment.
SUBCOMMAND
DESCRIPTION
Wbadmin restore catalog
Recovers a backup catalog from a specified storage location in
the case where the backup catalog on the local computer has
been corrupted.
Wbadmin delete catalog
Deletes the backup catalog on the local computer. Use this
command only if the backup catalog on this computer is
corrupted and you have no backups stored at another
location that you can use to restore the catalog.