Windows Admin Center

Contents
Management
Use Windows Admin Center to manage your environment (New!)
Manage Windows Server systems and environments
Manage Windows Server Hybrid Cloud Print
Deploy Windows Server Hybrid Cloud Print with Pre-Authentication
Deploy Windows Server Hybrid Cloud Print with Passthrough Auth
What is the Server Core installation option?
What's included in the Server Core installation option?
Basic administration tasks in Server Core
Manage Server Core
Configure memory dump files
Patch your Server Core installation
Manage on-premises systems with 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
Configure Features on Demand in Windows Server
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
Manage Server Core and remote systems Remote Server Administration Tools
Manage Windows with OpenSSH
Getting started with OpenSSH
Configuring Windows for OpenSSH
Managing OpenSSH Keys
Windows Server Update Services (WSUS)
Deploy Windows Server Update Services
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
Update Management with Windows Server Update Services
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
Express update delivery ISV support
Monthly Delta-update ISV support without WSUS
Migrating the WSUS database from Windows Internal Database (WID) to SQL
Collect information about your environment and systems
System Insights
Understanding capabilities
Managing capabilities
Adding and developing capabilities
Adding, removing, and updating capabilities
Choosing capability data sources
FAQ
Collect events with Setup and Boot Event Collection
Collect information about software Software Inventory Logging (SIL)
Manage Software Inventory Logging
Software Inventory Logging Aggregator
Collect user information with User Access Logging (UAL)
Manage User Access Logging
Tune your Windows Server performance
Performance Tuning Guidelines
Microsoft Server Performance Advisor
Server Performance Advisor User's Guide
Server Performance Advisor Pack Development Guide
Automate Windows Server management
Windows PowerShell scripting
Windows Commands
 T IP
Looking for information about older versions of Windows Server? Check out our other Windows Server libraries on
docs.microsoft.com. You can also search this site for specific information.
Once you have deployed Windows Server into your environment, including the specific roles for the features and functions you
need, the next step is managing those servers. Windows Server includes a number of tools to help you understand your Windows
Server environment, manage specific servers, fine-tune performance, and eventually automate many management tasks.
The tools you use to manage Windows Server instances depend, in large amount, on the types of systems you have deployed
(Windows Server with Desktop Experience vs Server Core), physical versus virtual machines, and where your servers are located.
Use the following information to perform basic management tasks on Windows Server.
Use the following table to determine which tools to use when.
INS TALL & R U N W IND O W S R U N S ER V ER MANAG ER O N R U N S ER V ER MANAG ER IN

I AM AD MIN CENTER W IND O W S S ER V ER R S AT O N W IND O W S 1 0
Sitting at a Windows 10 PC X X
Sitting at a Windows Server X X X

system running the desktop
experience
Sitting at a Windows Server X (install on Windows 10, use to X

system running Server Core manage Server Core)
Sitting far away from my X X

Windows Server system
Sitting far away from my X Use RDS to remote into the X

Windows Server system but it server, then use Server Manager
DOES have desktop experience
In addition to the tools mentioned below, you can also use Remote Desktop Services to access on-premises, remote, and virtual
servers. Then you can use Server Manager to perform management tasks.
Manage Windows Server systems and environments
Manage on-premises systems, remote systems, and systems without UI with Windows Admin Center
A browser-based management app that enables on-premises administration of Windows Servers with no Azure or cloud
dependency. Windows Admin Center (formerly called "Project Honolulu") gives you full control over all aspects of your server
infrastructure and is particularly useful for management on private networks that are not connected to the Internet. You can
install Windows Admin Center on Windows 10, on a gateway server, or directly on the Windows Server system that you want
to manage.
Manage on-premises systems with Server Manager

A management console included in the full installation of Windows Server. (It is not available for installs that don't have UI -
Server Core doesn't include Server Manager.) Use Server Manager to install and remove server roles, add and remove remote
servers, start and stop services, and view data gathered about your environment.
Manage remote systems and systems without UI with Remote Server Administration Tools (RSAT)
If your environment includes installations of Server Core or remote servers (either on-premises or virtual machines), you can
use RSAT to manage those systems. RSAT includes Server Manager, so you can use it to manage all of your servers. Note that
RSAT runs on Windows 10. You can't install RSAT on Windows Server Core. You can also manage Server Core installations
from the command line. See Basic administration tasks in Server Core
Manage updates to Windows Server systems

Use Windows Server Update Services (WSUS ) to manage and deploy updates to the systems in your Windows Server
environment.
Gather information about your environment
Setup and Boot Event Collection

Setup and Boot Event Collection lets you 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.
Software Inventory 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 2016, Windows Server 2012 R2, or Windows Server 2012 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.
Tune your Windows Server environment for performance
Performance tuning guidelines

Review a set of guidelines that you can use to tune the server settings in Windows Server and obtain incremental performance
or energy efficiency gains, especially when the nature of the workload varies little over time.

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.
Windows PowerShell
Windows PowerShell is a command-line shell and scripting language designed to let you rapidly automate administrative tasks.
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.
System Insights
Native predictive analytics locally analyze Windows Server system data, such as performance counters and ETW events,
helping IT administrators proactively detect and address problematic behavior in deployments.
Windows Admin Center
5/23/2019 • 2 minutes to read • Edit Online
Applies To: Windows Admin Center, Windows Admin Center Preview
Windows Admin Center (codenamed Project Honolulu) is an evolution of Windows Server in-box
management tools; it’s a single pane of glass that consolidates all aspects of local and remote server management.
As a locally deployed, browser-based management experience, an Internet connection and Azure aren’t required.
Windows Admin Center gives you full control of all aspects of your deployment, including private networks that
aren’t Internet-connected.
Introduction
Download the PDF
Quick start
You can get Windows Admin Center up and running in your environment in minutes:
1. Download
2. Install
3. Get started
Contents at a glance
Understand Plan
What is Windows Admin Center? What type of installation is right for you?
FAQ User access options
Case studies
Related management products
Videos
Deploy Configure
Prepare your environment Windows Admin Center settings
Install Windows Admin Center User access control and permissions
Enable high availability Extensions
Use Connect to Azure

Launch & add connections Azure hybrid services
Manage servers Connect Windows Admin Center to Azure
Manage hyper-converged infrastructure Deploy Windows Admin Center in Azure
Manage failover clusters Manage Azure VMs with Windows Admin Center
Manage virtual machines
Logging
Support Extend
Support policy Overview of extensions
Common troubleshooting steps Understanding extensions
Known issues Develop an extension
Guides
Publishing extensions
Release history
Learn about our latest released features:
Version 1904 is the most recent GA release that introduces the Azure Hybrid Services tool, and brings features
that were previously in preview to the GA channel.
Version 1903 brings email notifications from Azure Monitor, the ability to add Server or PC connections from
Active Directory, and new tools to manage Active Directory, DHCP, and DNS.
Version 1902 added a shared connection list & improvements to software defined network (SDN )
management, including new SDN tools to manage ACLs, gateway connections, and logical networks.
Version 1812 added dark theme (in preview ), power configuration settings, BMC info, and PowerShell support
to manage extensions and connections.
Version 1809.5 is a GA cumulative update that includes various quality and functional improvements and bug
fixes throughout the platform and a few new features in the hyper-converged infrastructure management
solution.
Version 1809 was a GA release that brought features that were previously in preview to the GA channel.
Version 1808 added Installed Apps tool, lots of under the hood improvements, and major updates to the
preview SDK.
Version 1807 added a streamlined Azure connect experience, improvements to VM inventory page, file sharing
functionality, Azure update management integration, and more.
Version 1806 added show PowerShell script, SDN management, 2008 R2 connections, SDN, scheduled tasks,
and many other improvements.
Version 1804.25 - Maintenance update to support users installing Windows Admin Center in completely
offline environments.
Version 1804 - Project Honolulu becomes Windows Admin Center and adds security features and role-based
access control. Our first GA release.
Version 1803 added support for Azure AD access control, detailed logging, resizable content, and a bunch of
tool improvements.
Version 1802 added support for accessibility, localization, high-availability deployments, tagging, Hyper-V host
settings, and gateway authentication.
Version 1712 added more virtual machine features and performance improvements throughout the tools.
Version 1711 added highly anticipated tools (Remote Desktop and PowerShell) along with other
improvements.
Version 1709 launched as our first public preview release.
Stay updated
Follow us on Twitter
Read our Blogs

Windows Server Hybrid Cloud Print overview
Applies to
Windows Server 2016
What is Hybrid Cloud Print?

Hybrid Cloud Print is a new feature for Windows Server 2016 available through Features on Demand. It allows
IT professionals to support print requirements for people who bring their own devices, or use devices joined to
your Azure Active Directory. This includes mobile devices such as Windows phone, laptops, or tablets running
either Windows 10 or Windows Mobile. It provides printing support from anywhere people have access to the
Internet.
For IT Admins, Hybrid Cloud Print provides secure user access to on-premises printers by using Azure's multi-
factor authentication to validate user access. Single sign-on (SSO ) functionality simplifies the user experience.
Hybrid Cloud Print is built on Windows Print Server role, giving IT Pros an experience that is similar to
managing printers and user access security.
Hybrid Cloud Print allows people in your organization to print from the devices they use to complete their work -
even when they are away from their desk or workplace.
Hybrid Cloud Print is supported in Windows 10 Creators Update and Windows 10 S.
Feature summary
Hybrid Cloud Print consists of two main server-side components: Discovery service, and Windows Print
service.
Discovery service endpoint running on an IIS service supporting Mopria Alliance industry standard for printer
discovery in the cloud.
Windows Print service endpoint running on an IIS service supporting industry standard Internet Printing
Protocol (IPP ) to ensure the broadest client OS support.
Deployment
Hybrid Cloud Print supports a couple of different deployment options depending on where your organization
requires user authentication. Here's what a deployment could look like:
Hybrid Cloud Print solution diagram
The diagram shows:
Hybrid Cloud Print using Azure Active Directory as the user identity provider.
Windows Print service and Discovery service endpoints are registered with Azure Active Directory to enable
the client device to retrieve the required user authentication token to use against these services.
An MDM service, such as Microsoft Intune, provisions the client device with policies needed to connect Azure
Active Directory to Windows Print service and Discovery service.
This table has more info on the elements in the diagram.
ELEMENT DESCRIPTION
Azure Active Directory Provides and controls user identity and authorization
functionality
Active Directory Provides and controls user identity and authorization

functionality
Azure AD Connect Synchronizes user credentials between Azure AD and on-

premises AD.
MDM Service (Intune) Provides device policy provisioning functionality to ensure

client device (BYOD device) complies with corporate policies.
Azure AD Proxy Provides a long-lived connection that is established from

behind your firewall to Azure to allow specific configured
application traffic to flow from the Internet into the corporate
network.
Azure Web App The core of Hybrid Cloud Print solution. Provides the required
web endpoints to discover printers and send print content for
non-domain joined devices.
BYOD device / Windows Print Server Spooler / Printer These are as-is. No change in functionality in the deployment.
There are two ways to install Hybrid Cloud Print:

Features on Demand - See Configure Features on Demand in Windows Server to learn more about adding
and removing role and feature files.
Windows Server 2016 Settings - Administrators can go to Settings -> Apps -> Manage optional features
-> Add a feature and search for the Features on Demand package
PowerShell commands - In a PowerShell administrator window, run these commands:
Install-Module -Name PublishCloudPrinter

Import-Module PublishCloudPrinter
```
Deploy Windows Server Hybrid Cloud Print with Pre-
Authentication
Applies To: Windows Server 2016
This topic, for IT administrators, describes the end-to-end deployment of the Microsoft Hybrid Cloud Print
solution. This solution layers on top of existing Windows Server(s) running as Print Server, and enables Azure
Active Directory joined, and MDM managed, devices to discover and print to organization managed printers.
Pre-requisites
There are a number of subscriptions, services, and computers you'll need to acquire before starting this installation.
They are as follows:
Azure AD premium subscription
See Get started with an Azure subscription, for a trial subscription to Azure.
MDM service, such as Intune
See Microsoft Intune, for a trial subscription to Intune.
Windows Server running as Active Directory
See Step-By-Step: Setting up Active Directory in Windows Server 2016, for help setting up Active Directory.
Domain joined Windows Server 2016 running as Print Server
See Install roles, role services, and features by using the add Roles and Features Wizard, for information on
how to install roles and role services on Windows Server.
Azure AD Connect
See Custom installation of Azure AD Connect, for help setting up Azure AD Connect.
Azure Application Proxy Connector on a separate domain joined Windows Server machine
See Get started with Application Proxy and install the connector, for help setting up Azure Application Proxy
Connector.
Public facing domain name
You can use the domain name created for you by Azure, or purchase your own domain name.
Deployment steps
This guide outlines five (5) installation steps:
Step 1: Install Azure AD Connect to sync between Azure AD and on-premises AD
Step 2: Install Hybrid Cloud Print package on the Print Server
Step 3: Install Azure Application Proxy (AAP ) with Kerberos Constrained Delegation (KCD )
Step 4: Configure the required MDM policies
Step 5: Publish shared printers
Step 1 - Install Azure AD Connect to sync between Azure AD and on-premises AD
1. On the Windows Server Active Directory machine, download the Azure AD Connect software
2. Launch the Azure AD Connect installation package and select Use express settings
3. Enter the information requested in the installation process and click Install
Step 2 - Install Hybrid Cloud Print package on the Print Server
1. Install the Hybrid Cloud Print PowerShell modules
Run the following commands from an elevated PowerShell command prompt
find-module -Name "PublishCloudPrinter" to confirm that the machine can reach the PowerShell
Gallery (PSGallery)
install-module -Name "PublishCloudPrinter"
NOTE: You may see a messaging stating that 'PSGallery' is an untrusted repository. Enter 'y' to
continue with the installation.
2. Install the Hybrid Cloud Print solution

In the same elevated PowerShell command prompt, change directory to
C:\Program Files\WindowsPowerShell\Modules\PublishCloudPrinter\1.0.0.0
Run
CloudPrintDeploy.ps1 -AzureTenant <Domain name used by Azure AD Connect> -AzureTenantGuid <Azure AD
Directory ID>
3. Configure the 2 IIS endpoints to support SSL
The SSL certificate can be a self-signed cert or one issued from some trusted Certificate Authority (CA)
If using self-signed cert, make sure the cert is imported to the client machine(s)
4. Install SQLite package
Open an elevated PowerShell command prompt
Run the following command to download System.Data.SQLite nuget packages
Register-PackageSource -Name nuget.org -ProviderName NuGet -Location https://www.nuget.org/api/v2/ -
Trusted -Force
Run the following command to install the packages
Install-Package system.data.sqlite [-requiredversion x.x.x.x] -providername nuget
NOTE: It is recommended to download and install the latest version by leaving out the "-
requiredversion" option.
5. Copy the SQLite dlls to the MopriaCloudService Webapp <bin> folder

(C:\inetpub\wwwroot\MopriaCloudService\bin):
The SQLite binaries should be at “\Program Files\PackageManagement\NuGet\Packages”
\\System.Data.SQLite.**Core**.x.x.x.x\\lib\\net46\\System.Data.SQLite.dll
--\> \<bin\>\\System.Data.SQLite.dll
\\System.Data.SQLite.**Core**.x.x.x.x\\build\\net46\\x86\\SQLite.Interop.dll
--\> \<bin\>\\**x86**\\SQLite.Interop.dll
\\System.Data.SQLite.**Linq**.x.x.x.x\\lib\\net46\\System.Data.SQLite.Linq.dll
--\> \<bin\>\\System.Data.SQLite.Linq.dll
\\System.Data.SQLite.**EF6**.x.x.x.x\\lib\\net46\\System.Data.SQLite.EF6.dll
--\> \<bin\>\\System.Data.SQLite.EF6.dll
NOTE: x.x.x.x is the SQLite version installed above.
6. Update the c:\inetpub\wwwroot\MopriaCloudService\web.config file to include the SQLite version x.x.x.x in the
following <runtime>/<assemblyBinding> sections:
<dependentAssembly>
assemblyIdentity name="System.Data.SQLite" culture="neutral" publicKeyToken="db937bc2d44ff139" /
<bindingRedirect oldVersion="0.0.0.0-x.x.x.x" newVersion="x.x.x.x" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Data.SQLite.Core" culture="neutral" publicKeyToken="db937bc2d44ff139" />
<dependentAssembly>
<assemblyIdentity name="System.Data.SQLite.EF6" culture="neutral" publicKeyToken="db937bc2d44ff139" />
<dependentAssembly>
<assemblyIdentity name="System.Data.SQLite.Linq" culture="neutral" publicKeyToken="db937bc2d44ff139" />
7. Create the SQLite database:

Download and install the SQLite Tools binaries from https://www.sqlite.org/
Go to c:\inetpub\wwwroot\MopriaCloudService\Database directory
Execute the following command to create the database in this directory:
sqlite3.exe MopriaDeviceDb.db ".read MopriaSQLiteDb.sql"
From File Explorer, open up the MopriaDeviceDb.db file properties to add Users/Groups which are
allowed to publish to Mopria database in the Security tab
Recommend only adding the required Admin user group.
8. Register the 2 web app with Azure AD to support OAuth2 authentication
Login as the Global Admin to the Azure AD tenant management portal
a. Go "App registrations" tab to add print endpoint
Add application, select "New application registration"
Provide an appropriate name and select "Web app / API"
Sign-on URL = "http://MicrosoftEnterpriseCloudPrint/CloudPrint"
b. Repeat for the discovery endpoint
Sign-on URL = "http://MopriaDiscoveryService/CloudPrint"
c. Repeat for the native client application
When providing the app name, make sure you select "Native Client Application" as the
"Application type"
Redirect URI = "https://<services-machine-endpoint>/RedirectUrl"
d. Go into the Native Client App "Settings"
Copy the "Application ID" value to be used for later setup steps
Select "Required permissions"
a. Click "Add"
b. Click "Select an API"
c. Search for the print endpoint and the discovery endpoint by the name you defined
when creating the app endpoint
d. Add the 2 endpoints
e. Make sure the "Delegated Permissions" option for each app endpoint is enabled
f. Make sure you click the "Done" button at the bottom
g. Click "Grant Permissions", once both endpoints have been added. Select "Yes" when
prompted to approve request.
Go to “REDIRECT URIS” and add the following redirect URIs to the list:
ms-appx-web://Microsoft.AAD.BrokerPlugin/\<NativeClientAppID\>
ms-appx-web://Microsoft.AAD.BrokerPlugin/S-1-15-2-3784861210-599250757-1266852909-
3189164077-45880155-1246692841-283550366
Step 3 - Install Azure Application Proxy (AAP) with Kerberos Constrained Delegation (KCD)
1. Login to your Azure AD (AAD ) tenant management portal
In the AAD menu list, select "Application proxy"
Click "Enable application proxy" at the top of the screen
Download the "Application Proxy Connector" to a domain joined Windows Server machine that will act
as the Web Application Proxy (WAP ).
2. On the WAP machine, login as an Administrator and install the "Application Proxy Connector"
During installation, give the application proxy connector the credentials to your Azure tenet that you
want to enable AAP on
Make sure the WAP machine is domain joined to your on-premises Active Directory
3. On the Active Directory machine, go to Tools -> Users and Computers
Select the machine that is running the Application Proxy Connector
Right-click and select Properties -> Delegation tab
Select Trust this computer for delegation to specified services only.
Select Use any authentication protocol.
Under Services to which this account can present delegated credentials
Add the value for the SPN identity of the machine running the Services (MopriaDiscoveryService
and MicrosoftEnterpriseCloudPrint service)
For SPN, enter the SPN of the machine itself, i.e. "HOST/<MachineName>.<Domain>"
HOST/appServer.Contoso.com
4. Go back to the AAD tenant management portal and add the application proxies
Go to the Enterprise applications tab
Click New application
Select On-premises application and fill in the fields
Name: Any name you wish
Internal URL: This is the internal URL to the Mopria Discovery Cloud Service which your WAP
machine can access
External URL: Configure as appropriate for your organization
Preauthentication Method: Azure Active Directory
Note: If you don’t find all the settings above, add the proxy with the settings available and then
select the application proxy you just created and go to the Application proxy tab and add all the
above information.
Once created, go back to Enterprise applications -> All applications, select the new application
you just created
Go to Single sign-on, make sure the "Single Sign-on Mode" is set to "Integrated Windows
Authentication"
Set the "Internal Application SPN" to the SPN you specified in Step 3.3, above
Make sure the "Delegated Login Identity" is set to "User principal name"
5. Repeat 4, above, for the Enterprise Cloud Print Service and provide the Internal URL to your Enterprise
Cloud Print Service
6. Go back to the Azure AD tenant management portal and go to App registrations and select the Native
Client App -> "Settings"
Select Required permissions
Add the 2 new proxy applications you just created
Grant Delegated Permissions for these 2 applications
Once both proxy applications have been added, click "Grant Permissions". Select "Yes" when
7. Enable Windows Authentication in IIS for the Mopria Cloud Service and Enterprise Cloud Print Service
machine(s)
Make sure Windows Authentication feature is installed:
a. Open Server Manager
b. Click Manage
c. Click Add Roles and Features
d. Select Role-based or feature-based installation
e. Select the Server
f. Under Web Server (IIS ) -> Web Server -> Security, select Windows Authentication
g. Click next until you finish installation
Enable Windows Authentication in IIS:
a. Open Internet Information Services (IIS ) Manager
b. For each service/site:
a. Select the service/site
b. Double click Authentication
c. Click Windows Authentication and click Enable under Actions
Step 4 - Configure the required MDM policies
Login to your MDM provider
Find the Enterprise Cloud Print policy group and configure the policies following the guidelines below:
CloudPrintOAuthAuthority = https://login.microsoftonline.com/<Azure AD Directory ID>
CloudPrintOAuthClientId = "Application ID" value of the Native Web App that you registered in Azure
AD management portal
CloudPrinterDiscoveryEndPoint = External URL of the Mopria Discovery Service Azure Application
Proxy created in Step 3.3 (must be exactly the same but without the trailing /)
MopriaDiscoveryResourceId = External URL of the Mopria Discovery Service Azure Application Proxy
created in Step 3.4 (must be exactly the same including the trailing /)
CloudPrintResourceId = External URL of the Enterprise Cloud Print Service Azure Application Proxy
created in Step 3.5 (must be exactly the same including the trailing /)
DiscoveryMaxPrinterLimit = <a positive integer>
Note: If you are using Microsoft Intune service, you can find these settings under the "Cloud Printer" category.
INTUNE DISPLAY NAME POLICY
Printer discovery URL CloudPrinterDiscoveryEndpoint
Printer access authority URL CloudPrintOAuthAuthority

Azure native client app GUID CloudPrintOAuthClientId
Print service resource URI CloudPrintResourceId
Maximum printers to query(Mobile only) DiscoveryMaxPrinterLimit
Printer discovery service resource URI MopriaDiscoveryResourceId
Note: If the Cloud Print policy group is not available, but the MDM provider supports OMA-URI settings, then
you can set the same policies. Please refer to this article for additional info.
OMA-URI
CloudPrintOAuthAuthority = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/CloudPrintOAuthAuthority
Value = https://login.microsoftonline.com/ <Azure AD Directory ID>
CloudPrintOAuthClientId = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/CloudPrintOAuthClientId
Value = <Azure AD Native App's Application ID>
CloudPrinterDiscoveryEndPoint =
./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/CloudPrinterDiscoveryEndPoint
Value = External URL of the Mopria Discovery Service Azure Application Proxy created in Step 3.3
(must be exactly the same but without the trailing /)
MopriaDiscoveryResourceId = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/MopriaDiscoveryResourceId
(must be exactly the same including the trailing /)
CloudPrintResourceId = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/CloudPrintResourceId
Value = External URL of the Enterprise Cloud Print Service Azure Application Proxy created in
Step 3.5 (must be exactly the same including the trailing /)
DiscoveryMaxPrinterLimit = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/DiscoveryMaxPrinterLimit
Value = <a positive integer>
Step 5 - Publish desired shared printers
1. Install desired printer on the Print Server
2. Share the printer through the Printer Properties UI
3. Select the desired set of users to grant access
4. Save the changes and close out the printer properties window
5. From a Windows 10 Fall Creator Update machine, open an elevated Windows PowerShell command
prompt
a. Run the following commands
Gallery (PSGallery)
NOTE: You may see a messaging stating that 'PSGallery' is an untrusted repository. Enter
'y' to continue with the installation.
Publish-CloudPrinter
Printer = The shared printer name that was defined
Manufacturer = Printer manufacturer
Model = Printer model
OrgLocation = A JSON string specifying the printer location, e.g.:
{"attrs": [{"category":"country", "vs":"USA", "depth":0}, {"category":"organization",
"vs":"Microsoft", "depth":1}, {"category":"site", "vs":"Redmond, WA", "depth":2},
{"category":"building", "vs":"Building 1", "depth":3}, {"category":"floor\_number",
"vn":1, "depth":4}, {"category":"room\_name", "vs":"1111", "depth":5}]}
Sddl = SDDL string representing permissions for the printer. This can be obtained by
modifying the Printer Properties Security tab appropriately and then running the
following command in a command prompt:
(Get-Printer PrinterName -full).PermissionSDDL e.g. "G:DUD:( A;OICI;FA;;;WD )"
NOTE: You will need to add O:BA as prefix to the result from the command prompt
command above before setting the value as the SDDL setting. Example: SDDL =
O:BAG:DUD:(A;OICI;FA;;;WD)
DiscoveryEndpoint = External URL of the Mopria Discovery Service Azure Application

Proxy created in Step 3.4
PrintServerEndpoint = External URL of the Enterprise Cloud Print Service Azure
Application Proxy created in Step 3.5
AzureClientId = Application ID of the registered Native Web App value from above
AzureTenantGuid = Directory ID of your Azure AD tenant
DiscoveryResourceId = [Optional] Application ID of the proxied Mopria Discovery Cloud
Service
NOTE: You can enter all of the required parameter values in the command line as well.
Publish-CloudPrinter PowerShell command syntax:
Publish-CloudPrinter -Printer <string> -Manufacturer <string> -Model <string> -
OrgLocation <string> -Sddl <string> -DiscoveryEndpoint <string> -PrintServerEndpoint
<string> -AzureClientId <string> -AzureTenantGuid <string> [-DiscoveryResourceId
<string>]
Sample command:
publish-cloudprinter -Printer EcpPrintTest -Manufacturer Microsoft -Model FilePrinterEcp
-OrgLocation '{"attrs": [{"category":"country", "vs":"USA", "depth":0},
{"category":"organization", "vs":"MyCompany", "depth":1}, {"category":"site",
"vs":"MyCity, State", "depth":2}, {"category":"building", "vs":"Building 1", "depth":3},
{"category":"floor\_number", "vn":1, "depth":4}, {"category":"room\_name", "vs":"1111",
"depth":5}]}' -Sddl "O:BAG:DUD:(A;OICI;FA;;;WD)" -DiscoveryEndpoint https://<services-
machine-endpoint>/mcs -PrintServerEndpoint https://<services-machine-endpoint>/ecp -
AzureClientId <Native Web App ID> -AzureTenantGuid <Azure AD Directory ID> -
DiscoveryResourceId <Proxied Mopria Discovery Cloud Service App ID>
Verifying the deployment

On an Azure AD joined device that has the MDM policies configured:
Open a web browser and to go to https://<services-machine-endpoint>/mcs/services (the external URL for the
discovery endpoint)
You should see the JSON text describing the set of functionality of this endpoint
Go to "OS Settings -> Devices -> Printers & scanners"
You should see a "Search for cloud printers" link
Click on the link
Click the “Please select a search location” link
You should see the device location hierarchy
Pick a location and click OK and then click Search button to find the printers
Select printer and click Add device button
After successful printer installation, print to the printer from your favorite app
Note: If using the “EcpPrintTest” printer, you can find the output file in the Print Server machine under
“C:\ECPTestOutput\EcpTestPrint.xps” location.
Deploy Windows Server Hybrid Cloud Print with
Passthrough Authentication
This topic, for IT administrators, describes the end-to-end deployment of the Microsoft Hybrid Cloud Print
solution. This solution layers on top of existing Windows Server(s) running as Print Server, and enables Azure
Active Directory joined, and MDM managed, devices to discover and print to organization managed printers.
Pre-requisites
There are a number of subscriptions, services, and computers you'll need to acquire before starting this installation.
They are as follows:
Azure AD premium subscription
See Get started with an Azure subscription, for a trial subscription to Azure.
MDM service, such as Intune
See Microsoft Intune, for a trial subscription to Intune.
Windows Server running as Active Directory
See Step-By-Step: Setting up Active Directory in Windows Server 2016, for help setting up Active Directory.
Domain joined Windows Server 2016 running as Print Server
See Install roles, role services, and features by using the add Roles and Features Wizard, for information on
how to install roles and role services on Windows Server.
Azure AD Connect
See Custom installation of Azure AD Connect, for help setting up Azure AD Connect.
Azure Application Proxy Connector on a separate domain joined Windows Server machine
See Get started with Application Proxy and install the connector, for help setting up Azure Application Proxy
Connector.
Public facing domain name
You can use the domain name created for you by Azure, or purchase your own domain name.
Deployment steps
This guide outlines five (5) installation steps:
Step 1: Install Azure AD Connect to sync between Azure AD and on-premises AD
Step 2: Install Hybrid Cloud Print package on the Print Server
Step 3: Install Azure Application Proxy (AAP ) with Passthrough Authentication
Step 4: Configure the required MDM policies
Step 5: Publish shared printers
Step 1 - Install Azure AD Connect to sync between Azure AD and on-premises AD
1. On the Windows Server Active Directory machine, download the Azure AD Connect software
2. Launch the Azure AD Connect installation package and select Use express settings
3. Enter the information requested in the installation process and click Install
Step 2 - Install Hybrid Cloud Print package on the Print Server
1. Install the Hybrid Cloud Print PowerShell modules
Run the following commands from an elevated PowerShell command prompt
Gallery (PSGallery)
NOTE: You may see a messaging stating that 'PSGallery' is an untrusted repository. Enter 'y' to
continue with the installation.
2. Install the Hybrid Cloud Print solution

In the same elevated PowerShell command prompt, change directory to
C:\Program Files\WindowsPowerShell\Modules\PublishCloudPrinter\1.0.0.0
Run
CloudPrintDeploy.ps1 -AzureTenant <Domain name used by Azure AD Connect> -AzureTenantGuid <Azure AD
Directory ID>
3. Configure the 2 IIS endpoints to support SSL
The SSL certificate can be a self-signed cert or one issued from some trusted Certificate Authority (CA)
If using self-signed cert, make sure the cert is imported to the client machine(s)
4. Install SQLite package
Open an elevated PowerShell command prompt
Run the following command to download System.Data.SQLite nuget packages
Register-PackageSource -Name nuget.org -ProviderName NuGet -Location https://www.nuget.org/api/v2/ -
Trusted -Force
Run the following command to install the packages
Install-Package system.data.sqlite [-requiredversion x.x.x.x] -providername nuget
NOTE: It is recommended to download and install the latest version by leaving out the "-
requiredversion" option.
5. Copy the SQLite dlls to the MopriaCloudService Webapp <bin> folder

(C:\inetpub\wwwroot\MopriaCloudService\bin):
The SQLite binaries should be at “\Program Files\PackageManagement\NuGet\Packages”
\\System.Data.SQLite.**Core**.x.x.x.x\\lib\\net46\\System.Data.SQLite.dll
--\> \<bin\>\\System.Data.SQLite.dll
\\System.Data.SQLite.**Linq**.x.x.x.x\\lib\\net46\\System.Data.SQLite.Linq.dll
--\> \<bin\>\\System.Data.SQLite.Linq.dll
\\System.Data.SQLite.**EF6**.x.x.x.x\\lib\\net46\\System.Data.SQLite.EF6.dll
--\> \<bin\>\\System.Data.SQLite.EF6.dll
NOTE: x.x.x.x is the SQLite version installed above.
6. Update the c:\inetpub\wwwroot\MopriaCloudService\web.config file to include the SQLite version x.x.x.x in the
following <runtime>/<assemblyBinding> sections:
<dependentAssembly>
assemblyIdentity name="System.Data.SQLite" culture="neutral" publicKeyToken="db937bc2d44ff139" /
<dependentAssembly>
<assemblyIdentity name="System.Data.SQLite.Core" culture="neutral" publicKeyToken="db937bc2d44ff139" />
<dependentAssembly>
<assemblyIdentity name="System.Data.SQLite.EF6" culture="neutral" publicKeyToken="db937bc2d44ff139" />
<dependentAssembly>
<assemblyIdentity name="System.Data.SQLite.Linq" culture="neutral" publicKeyToken="db937bc2d44ff139" />
7. Create the SQLite database:

Download and install the SQLite Tools binaries from https://www.sqlite.org/
Go to c:\inetpub\wwwroot\MopriaCloudService\Database directory
Execute the following command to create the database in this directory:
sqlite3.exe MopriaDeviceDb.db ".read MopriaSQLiteDb.sql"
From File Explorer, open up the MopriaDeviceDb.db file properties to add Users/Groups which are
allowed to publish to Mopria database in the Security tab
Recommend only adding the required Admin user group.
8. Register the 2 web app with Azure AD to support OAuth2 authentication
Login as the Global Admin to the Azure AD tenant management portal
a. Go "App registrations" tab to add print endpoint
Add application, select "New application registration"
Provide an appropriate name and select "Web app / API"
Sign-on URL = "http://MicrosoftEnterpriseCloudPrint/CloudPrint"
b. Repeat for the discovery endpoint
Sign-on URL = "http://MopriaDiscoveryService/CloudPrint"
c. Repeat for the native client application
When providing the app name, make sure you select "Native Client Application" as the
"Application type"
Redirect URI = "https://<services-machine-endpoint>/RedirectUrl"
d. Go into the Native Client App "Settings"
Copy the "Application ID" value to be used for later setup steps
Select "Required permissions"
a. Click "Add"
b. Click "Select an API"
c. Search for the print endpoint and the discovery endpoint by the name you defined
when creating the app endpoint
d. Add the 2 endpoints
e. Make sure the "Delegated Permissions" option for each app endpoint is enabled
f. Make sure you click the "Done" button at the bottom
g. Click "Grant Permissions", once both endpoints have been added. Select "Yes" when
Go to “REDIRECT URIS” and add the following redirect URIs to the list:
ms-appx-web://Microsoft.AAD.BrokerPlugin/\<NativeClientAppID\>
ms-appx-web://Microsoft.AAD.BrokerPlugin/S-1-15-2-3784861210-599250757-1266852909-
3189164077-45880155-1246692841-283550366
Step 3 - Install Azure Application Proxy (AAP) with Passthrough Authentication

1. Login to your Azure AD (AAD ) tenant management portal
In the AAD menu list, select "Application proxy"
Click "Enable application proxy" at the top of the screen
Download the "Application Proxy Connector" to a domain joined Windows Server machine that will act
as the Web Application Proxy (WAP ).
2. On the WAP machine, login as an Administrator and install the "Application Proxy Connector"
During installation, give the application proxy connector the credentials to your Azure tenet that you
want to enable AAP on
Make sure the WAP machine is domain joined to your on-premises Active Directory
3. Go back to the AAD tenant management portal and add the application proxies
Go to the Enterprise applications tab
Click New application
Select On-premises application and fill in the fields
Name: Any name you wish
Internal URL: This is the internal URL to the Mopria Discovery Cloud Service which your WAP
machine can access
External URL: Configure as appropriate for your organization
Preauthentication Method: Passthrough
Note: If you don’t find all the settings above, add the proxy with the settings available and then
select the application proxy you just created and go to the Application proxy tab and add all the
above information.
4. Repeat 3, above, for the Enterprise Cloud Print Service and provide the Internal URL to your Enterprise
Cloud Print Service
Note: The https://<services-machine-endpoint>/mcs URL mentioned below should be the External URL
you setup for your Mopria Cloud Service and/or Enterprise Cloud Print Service.
Step 4 - Configure the required MDM policies

Login to your MDM provider
Find the Enterprise Cloud Print policy group and configure the policies following the guidelines below:
CloudPrintOAuthAuthority = https://login.microsoftonline.com/<Azure AD Directory ID>
CloudPrintOAuthClientId = "Application ID" value of the Native Web App that you registered in Azure
AD management portal
CloudPrinterDiscoveryEndPoint = External URL of the Mopria Discovery Service Azure Application
Proxy created in Step 3.3 (must be exactly the same but without the trailing /)
MopriaDiscoveryResourceId = The "App ID URI" of the Web app / API for the discovery endpoint
registered in Step 2.8. You can find this under the Settings -> Properties of the app
CloudPrintResourceId = The "App ID URI" of the Web app / API for the print endpoint registered in Step
2.8. You can find this under the Settings -> Properties of the app
DiscoveryMaxPrinterLimit = <a positive integer>
Note: If you are using Microsoft Intune service, you can find these settings under the "Cloud Printer" category.
Printer discovery URL CloudPrinterDiscoveryEndpoint
Printer access authority URL CloudPrintOAuthAuthority
Azure native client app GUID CloudPrintOAuthClientId
Print service resource URI CloudPrintResourceId
Maximum printers to query(Mobile only) DiscoveryMaxPrinterLimit
Printer discovery service resource URI MopriaDiscoveryResourceId
Note: If the Cloud Print policy group is not available, but the MDM provider supports OMA-URI settings, then
you can set the same policies. Please refer to this article for additional info.
OMA-URI
CloudPrintOAuthAuthority = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/CloudPrintOAuthAuthority
Value = https://login.microsoftonline.com/ <Azure AD Directory ID>
CloudPrintOAuthClientId = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/CloudPrintOAuthClientId
Value = <Azure AD Native App's Application ID>
CloudPrinterDiscoveryEndPoint =
./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/CloudPrinterDiscoveryEndPoint
(must be exactly the same but without the trailing /)
MopriaDiscoveryResourceId = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/MopriaDiscoveryResourceId
Value = The "App ID URI" of the Web app / API for the discovery endpoint registered in Step 2.8.
You can find this under the Settings -> Properties of the app
CloudPrintResourceId = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/CloudPrintResourceId
Value = The "App ID URI" of the Web app / API for the print endpoint registered in Step 2.8. You
can find this under the Settings -> Properties of the app
DiscoveryMaxPrinterLimit = ./Vendor/MSFT/Policy/Config/EnterpriseCloudPrint/DiscoveryMaxPrinterLimit
Value = <a positive integer>
Step 5 - Publish desired shared printers
1. Install desired printer on the Print Server
2. Share the printer through the Printer Properties UI
3. Select the desired set of users to grant access
4. Save the changes and close out the printer properties window
5. From a Windows 10 Fall Creator Update machine, open an elevated Windows PowerShell command
prompt
a. Run the following commands
Gallery (PSGallery)
NOTE: You may see a messaging stating that 'PSGallery' is an untrusted repository. Enter
'y' to continue with the installation.
Publish-CloudPrinter
Printer = The shared printer name that was defined
Manufacturer = Printer manufacturer
Model = Printer model
OrgLocation = A JSON string specifying the printer location, e.g.:
{"attrs": [{"category":"country", "vs":"USA", "depth":0}, {"category":"organization",
"vs":"Microsoft", "depth":1}, {"category":"site", "vs":"Redmond, WA", "depth":2},
{"category":"building", "vs":"Building 1", "depth":3}, {"category":"floor\_number",
"vn":1, "depth":4}, {"category":"room\_name", "vs":"1111", "depth":5}]}
Sddl = SDDL string representing permissions for the printer. This can be obtained by
modifying the Printer Properties Security tab appropriately and then running the
following command in a command prompt:
(Get-Printer PrinterName -full).PermissionSDDL e.g. "G:DUD:( A;OICI;FA;;;WD )"
NOTE: You will need to add O:BA as prefix to the result from the command prompt
command above before setting the value as the SDDL setting. Example: SDDL =
O:BAG:DUD:(A;OICI;FA;;;WD)
DiscoveryEndpoint = https://<services-machine-endpoint>/mcs
PrintServerEndpoint = https://<services-machine-endpoint>/ecp
AzureClientId = Application ID of the registered Native Web App value from above
AzureTenantGuid = Directory ID of your Azure AD tenant
DiscoveryResourceId = [Optional] Application ID of the proxied Mopria Discovery Cloud
Service
NOTE: You can enter all of the required parameter values in the command line as well.
Publish-CloudPrinter PowerShell command syntax:
Publish-CloudPrinter -Printer <string> -Manufacturer <string> -Model <string> -
OrgLocation <string> -Sddl <string> -DiscoveryEndpoint <string> -PrintServerEndpoint
<string> -AzureClientId <string> -AzureTenantGuid <string> [-DiscoveryResourceId
<string>]
Sample command:
publish-cloudprinter -Printer EcpPrintTest -Manufacturer Microsoft -Model FilePrinterEcp
-OrgLocation '{"attrs": [{"category":"country", "vs":"USA", "depth":0},
{"category":"organization", "vs":"MyCompany", "depth":1}, {"category":"site",
"vs":"MyCity, State", "depth":2}, {"category":"building", "vs":"Building 1", "depth":3},
{"category":"floor\_number", "vn":1, "depth":4}, {"category":"room\_name", "vs":"1111",
"depth":5}]}' -Sddl "O:BAG:DUD:(A;OICI;FA;;;WD)" -DiscoveryEndpoint https://<services-
machine-endpoint>/mcs -PrintServerEndpoint https://<services-machine-endpoint>/ecp -
AzureClientId <Native Web App ID> -AzureTenantGuid <Azure AD Directory ID> -
DiscoveryResourceId <Proxied Mopria Discovery Cloud Service App ID>
Verifing the deployment

On an Azure AD joined device that has the MDM policies configured:
Open a web browser and to go to https://<services-machine-endpoint>/mcs/services
You should see the JSON text describing the set of functionality of this endpoint
Go to "OS Settings -> Devices -> Printers & scanners"
You should see a "Search for cloud printers" link
Click on the link
Click the “Please select a search location” link
You should see the device location hierarchy
Pick a location and click OK and then click Search button to find the printers
Select printer and click Add device button
After successful printer installation, print to the printer from your favorite app
Note: If using the “EcpPrintTest” printer, you can find the output file in the Print Server machine under
“C:\ECPTestOutput\EcpTestPrint.xps” location.
What is the Server Core installation option in
Windows Server?
Applies to: Windows Server (Semi-Annual Channel) and Windows Server 2016
The Server Core option is a minimal installation option that is available when you are deploying the Standard or
Datacenter edition of Windows Server. Server Core includes most but not all server roles. Server Core has a
smaller disk footprint, and therefore a smaller attack surface due to a smaller code base.
Server (Core) vs Server with Desktop Experience

When you install Windows Server, you install only the server roles that you choose - this helps reduce the overall
footprint for Windows Server. However, the Server with Desktop Experience installation option still installs many
services and other components that are often not needed for a particular usage scenario.
That's where Server Core comes into play: the Server Core installation eliminates any services and other features
that are not essential for the support of certain commonly used server roles. For example, a Hyper-V server
doesn't need a graphical user interface (GUI), because you can manage virtually all aspects of Hyper-V either from
the command line using Windows PowerShell or remotely using the Hyper-V Manager.
The Server Core difference - core capabilities without the frills

When you finish installing Server Core on a system and sign in for the first time, you're in for a bit of a surprise.
The main difference between the Server with Desktop Experience installation option and Server Core is that Server
Core does not include the following GUI shell packages:
Microsoft-Windows-Server-Shell-Package
Microsoft-Windows-Server-Gui-Mgmt-Package
Microsoft-Windows-Server-Gui-RSAT-Package
Microsoft-Windows-Cortana-PAL -Desktop-Package
In other words, there is no desktop in Server Core, by design. While maintaining the capabilities required to
support traditional business applications and role-based workloads, Server Core does not have a traditional
desktop interface. Instead, Server Core is designed to be managed remotely through the command line,
PowerShell, or a GUI tool (like RSAT or Windows Admin Center).
In addition to no UI, Server Core also differs from the Server with Desktop Experience in the following ways:
Server Core does not have any accessibility tools
No OOBE (out-of-box-experience) for setting up Server Core
No audio support
The following table shows which applications are available locally on Server Core vs Server with Desktop
Experience. Important: In most cases, applications that are listed as "not available" below can be run remotely
from a Windows client computer and used to manage your Server Core installation.
NOTE
This list is intended for quick reference - it isn't intended to be a complete list.
APPLICATION SERVER CORE SERVER WITH DESKTOP EXPERIENCE
Command prompt available available
Windows PowerShell/ Microsoft .NET available available
Perfmon.exe not available available
Windbg (GUI) supported supported
Resmon.exe not available available
Regedit available available
Fsutil.exe available available
Disksnapshot.exe not available available
Diskpart.exe available available
Diskmgmt.msc not available available
Devmgmt.msc not available available
Server Manager not available available
Mmc.exe not available available
Eventvwr not available available
Wevtutil (Event queries) available available
Services.msc not available available
Control Panel not available available
Windows Update (GUI) not available available
Windows Explorer not available available
Taskbar not available available
Taskbar notifications not available available
Taskmgr available available
Internet Explorer or Edge not available available

APPLICATION SERVER CORE SERVER WITH DESKTOP EXPERIENCE
Built-in help system not available available
Windows 10 Shell not available available
Windows Media Player not available available
PowerShell available available
PowerShell ISE not available available
PowerShell IME available available
Mstsc.exe not available available
Remote Desktop Services available available
Hyper-V Manager not available available
For more information about what is included in Server Core, see Roles, Role Services, and Features included in
Windows Server - Server Core. And for information about what is not included in Server Core, see Roles, Role
Services, and Features not included in Server Core
Get started using Server Core

Use the following information to install, configure, and manage the Server Core installation option of Windows
Server.
Server Core installation:
Roles, Role Services, and Features included in Server Core
Roles, Role Services, and Features not in Server Core
Install the Server Core installation option
Configure Server Core with the SConfig tool
Using Server Core:
Basic Server Core administration tasks using Windows PowerShell or the command line
Manage Server Core
Patching Server Core
Configure memory dump files
Roles, Role Services, and Features included in
Windows Server - Server Core
We generally talk about what's not in Server Core - now we're going to try a different approach and tell you what's
included and whether something is installed by default. The following roles, role services, and features are in the
Server Core installation option of Windows Server. Use this information to help figure out if the Server Core
option works for your environment. Because this is a large list, consider searching for the specific role or feature
you're interested in - if that search doesn't return what you're looking for, it's not included in Server Core.
For example, if you search for "Remote Desktop Session Host" - you won't find it on this page. That's because the
RD Session Host is NOT included in the Server Core image.
Remember that you can always look at what's not included. This is just a different way to look at things.
Roles included in Server Core

The Server Core installation option includes the following server roles.
ROLE NAME INSTALLED BY DEFAULT?
Active Directory Certificate Services AD-Certificate N
Active Directory Domain Services AD-Domain-Services N
Active Directory Federation Services ADFS-Federation N
Active Directory Lightweight Directory ADLDS N

Services
Active Directory Rights Management ADRMS N

Services
Device Health Attestation DeviceHealthAttestationService N
DHCP Server DHCP N
DNS Server DNS N
File and Storage Services FileAndStorage-Services Y
Host Guardian Service HostGuardianServiceRole N
Hyper-V Hyper-V N
Print and Document Services Print-Services N

ROLE NAME INSTALLED BY DEFAULT?
Remote Access RemoteAccess N
Remote Desktop Services Remote-Desktop-Services N
Volume Activation Services VolumeActivation N
Web Server IIS Web-Server N
Windows Server Essentials Experience ServerEssentialsRole N
Windows Server Update Services UpdateServices N
Role services included in Server Core

The Server Core installation option includes the following role services.
ROLE ROLE SERVICE NAME INSTALLED BY DEFAULT?
Active Directory Certificate Certification Authority ADCS-Cert-Authority N

Services
Certificate Enrollment Policy ADCS-Enroll-Web-Pol N

Web Service
Certificate Enrollment Web ADCS-Enroll-Web-Svc N

Service
Certification Authority Web ADCS-Web-Enrollment N

Enrollment
Network Device Enrollment ADCS-Device-Enrollment N

Service
Online Responder ADCS-Online-Cert N
Active Directory Rights Active Directory Rights ADRMS-Server N

Management Management Server
Identity Federation Support ADRMS-Identity N
File and Storage Services File and iSCSI Services File-Services N
File Server FS-FileServer N
BranchCache for Network FS-BranchCache N

Files
Data Deduplication FS-Data-Deduplication N
DFS Namespaces FS-DFS-Namespace N

DFS Replication FS-DFS-Replication N
File Server Resource FS-Resource-Manager N

Manager
File Server VSS Agent Service FS-VSS-Agent N
iSCSI Target Server iSCSITarget-Server N
iSCSI Target Storage iSCSITarget-VSS-VDS N

Provider (VDS and VSS
hardware providers)
Server for NFS FS-NFS-Service N
Work Folders FS-SyncShareService N
Storage Services Storage-Services Y
Print and Document Services Print Server Print-Server N
LPD Service Print-LPD-Service N
Remote Access DirectAccess and VPN (RAS) DirectAccess-VPN N
Routing Routing N
Web Application Proxy Web-Application-Proxy N
Remote Desktop Services Remote Desktop Connection RDS-Connection-Broker N

Broker
Remote Desktop Licensing RDS-Licensing N
Remote Desktop RDS-Virtualization N

Virtualization Host
Web Server (IIS) Web Server Web-WebServer N
Common HTTP Features Web-Common-Http N
Default Document Web-Default-Doc N
Directory Browsing Web-Dir-Browsing N
HTTP Errors Web-Http-Errors N
Static Content Web-Static-Content N
HTTP Redirection Web-Http-Redirect N

WebDAV Publishing Web-DAV-Publishing N
Health and Diagnostics Web-Health N
HTTP Logging Web-Http-Logging N
Custom Logging Web-Custom-Logging N
Logging Tools Web-Log-Libraries N
ODBC Logging Web-ODBC-Logging N
Request Monitor Web-Request-Monitor N
Tracing Web-Http-Tracing N
Performance Web-Performance N
Static Content Compression Web-Stat-Compression N
Dynamic Content Web-Dyn-Compression N

Compression
Security Web-Security N
Request Filtering Web-Filtering N
Basic Authentication Web-Basic-Auth N
Centralized SSL Certificate Web-CertProvider N

Support
Client Certificate Mapping Web-Client-Auth N

Authentication
Digest Authentication Web-Digest-Auth N
IIS Client Certificate Web-Cert-Auth N

Mapping Authentication
IP and Domain Restrictions Web-IP-Security N
URL Authorization Web-Url-Auth N
Windows Authentication Web-Windows-Auth N
Application Development Web-App-Dev N
.NET Extensibility 3.5 Web-Net-Ext N
.NET Extensibility 4.6 Web-Net-Ext45 N

Application Initialization Web-AppInit N
ASP Web-ASP N
ASP.NET 3.5 Web-Asp-Net N
ASP.NET 4.6 Web-Asp-Net45 N
CGI Web-CGI N
ISAPI Extensions Web-ISAPI-Ext N
ISAPI Filters Web-ISAPI-Filter N
Server Side Includes Web-Includes N
WebSocket Protocol Web-WebSockets N
FTP Server Web-Ftp-Server N
FTP Service Web-Ftp-Service N
FTP Extensibility Web-Ftp-Ext N
Management Tools Web-Mgmt-Tools N
IIS 6 Management Web-Mgmt-Compat N

Compatibility
IIS 6 Metabase Compatibility Web-Metabase N
IIS 6 Scripting Tools Web-Lgcy-Scripting N
IIS 6 WMI Compatibility Web-WMI N
IIS Management Scripts and Web-Scripting-Tools N

Tools
Management Service Web-Mgmt-Service N
Windows Server Update WID Connectivity UpdateServices-WidDB N

Services
WSUS Services UpdateServices-Services N
SQL Server Connectivity UpdateServices-DB N
Features included in Server Core

The Server Core installation option includes the following features.
FEATURE NAME INSTALLED BY DEFAULT?
.NET Framework 3.5 Features NET-Framework-Features N
.NET Framework 3.5 (includes .NET 2.0 NET-Framework-Core (removed)

and 3.0)
HTTP Activation NET-HTTP-Activation N
Non-HTTP Activation NET-Non-HTTP-Activ N
.NET Framework 4.6 Features NET-Framework-45-Features Y
.NET Framework 4.6 NET-Framework-45-Core Y
ASP.NET 4.6 NET-Framework-45-ASPNET N
WCF Services NET-WCF-Services45 Y
HTTP Activation NET-WCF-HTTP-Activation45 N
Message Queuing (MSMQ) Activation NET-WCF-MSMQ-Activation45 N
Named Pipe Activation NET-WCF-Pipe-Activation45 N
TCP Activation NET-WCF-TCP-Activation45 N
TCP Port Sharing NET-WCF-TCP-PortSharing45 Y
Background Intelligent Transfer Service BITS N

(BITS)
Compact Server BITS-Compact-Server N
BitLocker Drive Encryption BitLocker N
BranchCache BranchCache N
Client for NFS NFS-Client N
Containers Containers N
Data Center Bridging Data-Center-Bridging N
Enhanced Storage EnhancedStorage N
Failover Clustering Failover-Clustering N
Group Policy Management GPMC N
I/O Quality of Service DiskIo-QoS N

IIS Hostable Web Core Web-WHC N
IP Address Management (IPAM) Server IPAM N
iSNS Server service ISNS N
Management OData IIS Extension ManagementOdata N
Media Foundation Server-Media-Foundation N
Message Queuing MSMQ N
Message Queuing Services MSMQ-Services N
Message Queuing Server MSMQ-Server N
Directory Service Integration MSMQ-Directory N
HTTP Support MSMQ-HTTP-Support N
Message Queuing Triggers MSMQ-Triggers N
Routing Service MSMQ-Routing N
Message Queuing DCOM Proxy MSMQ-DCOM N
Multipath I/O Multipath-IO N
MultiPoint Connector MultiPoint-Connector N
MultiPoint Connector Services MultiPoint-Connector-Services N
MultiPoint Manager and MultiPoint MultiPoint-Tools N

Dashboard
Network Load Balancing NLB N
Peer Name Resolution Protocol PNRP N
Quality Windows Audio Video qWave N

Experience
Remote Differential Compression RDC N
Remote Server Administration Tools RSAT N
Feature Administration Tools RSAT-Feature-Tools N
BitLocker Drive Encryption RSAT-Feature-Tools-BitLocker N

Administration Utilities
DataCenterBridging LLDP Tools RSAT-DataCenterBridging-LLDP-Tools N
Failover Clustering Tools RSAT-Clustering N
Failover Cluster Module for Windows RSAT-Clustering-PowerShell N

PowerShell
Failover Cluster Automation Server RSAT-Clustering-AutomationServer N
Failover Cluster Command Interface RSAT-Clustering-CmdInterface N
IP Address Management (IPAM) Client IPAM-Client-Feature N
Shielded VM Tools RSAT-Shielded-VM-Tools N
Storage Replica Module for Windows RSAT-Storage-Replica N

PowerShell
Role Administration Tools RSAT-Role-Tools N
AD DS and AD LDS Tools RSAT-AD-Tools N
Active Directory module for Windows RSAT-AD-PowerShell N

PowerShell
AD DS Tools RSAT-ADDS N
Active Directory Administrative Center RSAT-AD-AdminCenter N
AD DS Snap-Ins and Command-Line RSAT-ADDS-Tools N

Tools
AD LDS Snap-Ins and Command-Line RSAT-ADLDS N

Tools
Hyper-V Management Tools RSAT-Hyper-V-Tools N
Hyper-V Module for Windows Hyper-V-PowerShell N

PowerShell
Windows Server Update Services Tools UpdateServices-RSAT N
API and PowerShell cmdlets UpdateServices-API N
DHCP Server Tools RSAT-DHCP N
DNS Server Tools RSAT-DNS-Server N
Remote Access Management Tools RSAT-RemoteAccess N

Remote Access module for Windows RSAT-RemoteAccess-PowerShell N

PowerShell
RPC over HTTP Proxy RPC-over-HTTP-Proxy N
Setup and Boot Event Collection Setup-and-Boot-Event-Collection N
Simple TCP/IP Services Simple-TCPIP N
SMB 1.0/CIFS File Sharing Support FS-SMB1 Y
SMB Bandwidth Limit FS-SMBBW N
SNMP Service SNMP-Service N
SNMP WMI Provider SNMP-WMI-Provider N
Telnet Client Telnet-Client N
VM Shielding Tools for Fabric FabricShieldedTools N

Management
Windows Defender Features Windows-Defender-Features Y
Windows Defender Windows-Defender Y
Windows Internal Database Windows-Internal-Database N
Windows PowerShell PowerShellRoot Y
Windows PowerShell 5.1 PowerShell Y
Windows PowerShell 2.0 Engine PowerShell-V2 (removed)
Windows PowerShell Desired State DSC-Service N

Configuration Service
Windows PowerShell Web Access WindowsPowerShellWebAccess N
Windows Process Activation Service WAS N
Process Model WAS-Process-Model N
.NET Environment 3.5 WAS-NET-Environment N
Configuration APIs WAS-Config-APIs N
Windows Server Backup Windows-Server-Backup N
Windows Server Migration Tools Migration N

Windows Standards-Based Storage WindowsStorageManagementService N

Management
WinRM IIS Extension WinRM-IIS-Ext N
WINS Server WINS N
WoW64 Support WoW64-Support Y

Administer a Server Core server
Applies To: Windows Server (Semi-Annual Channel) and Windows Server 2016
Because Server Core doesn't have a UI, you need to use Windows PowerShell cmdlets, command line tools, or
remote tools to perform basic administration tasks. The following sections outline the PowerShell cmdlets and
commands used for basic tasks. You can also use Windows Admin Center, a unified management portal currently
in public preview, to administer your installation.
Administrative tasks using PowerShell cmdlets

Use the following information to perform basic administrative tasks with Windows PowerShell cmdlets.
Set a static IP address
When you install a Server Core server, by default it has A DHCP address. If you need a static IP address, you can
set it using the following steps.
To view your current network configuration, use Get-NetIPConfiguration.
To view the IP addresses you're already using, use Get-NetIPAddress.
To set a static IP address, do the following:
1. Run Get-NetIPInterface.
2. Note the number in the IfIndex column for your IP interface or the InterfaceDescription string. If you have
more than one network adapter, note the number or string corresponding to the interface you want to set the
static IP address for.
3. Run the following cmdlet to set the static IP address:
New-NetIPaddress -InterfaceIndex 12 -IPAddress 192.0.2.2 -PrefixLength 24 -DefaultGateway 192.0.2.1
where:
InterfaceIndex is the value of IfIndex from step 2. (In our example, 12)
IPAddress is the static IP address you want to set. (In our example, 191.0.2.2)
PrefixLength is the prefix length (another form of subnet mask) for the IP address you're setting. (For
our example, 24)
DefaultGateway is the IP address to the default gateway. (For our example, 192.0.2.1)
4. Run the following cmdlet to set the DNS client server address:
Set-DNSClientServerAddress –InterfaceIndex 12 -ServerAddresses 192.0.2.4
where:
InterfaceIndex is the value of IfIndex from step 2.
ServerAddresses is the IP address of your DNS server.
5. To add multiple DNS servers, run the following cmdlet:
Set-DNSClientServerAddress –InterfaceIndex 12 -ServerAddresses 192.0.2.4,192.0.2.5
where, in this example, 192.0.2.4 and 192.0.2.5 are both IP addresses of DNS servers.
If you need to switch to using DHCP, run Set-DnsClientServerAddress –InterfaceIndex 12 –
ResetServerAddresses.
Join a domain
Use the following cmdlets to join a computer to a domain.
1. Run Add-Computer. You'll be prompted for both credentials to join the domain and the domain name.
2. If you need to add a domain user account to the local Administrators group, run the following command at
a command prompt (not in the PowerShell window ):
net localgroup administrators /add <DomainName>\<UserName>
3. Restart the computer. You can do this by running Restart-Computer.

Rename the server
Use the following steps to rename the server.
1. Determine the current name of the server with the hostname or ipconfig command.
2. Run Rename-Computer -ComputerName <new_name>.
3. Restart the computer.
Activate the server
Run slmgr.vbs –ipk<productkey>. Then run slmgr.vbs –ato. If activation succeeds, you won't get a message.
NOTE
You can also activate the server by phone, using a Key Management Service (KMS) server, or remotely. To activate remotely,
run the following cmdlet from a remote computer:
**cscript windows\system32\slmgr.vbs <ServerName> <UserName> <password>:-ato**
Configure Windows Firewall

You can configure Windows Firewall locally on the Server Core computer using Windows PowerShell cmdlets and
scripts. See NetSecurity for the cmdlets you can use to configure Windows Firewall.
Enable Windows PowerShell remoting
You can enable Windows PowerShell Remoting, in which commands typed in Windows PowerShell on one
computer run on another computer. Enable Windows PowerShell Remoting with Enable-PSRemoting.
For more information, see About Remote FAQ
Administrative tasks from the command line

Use the following reference information to perform administrative tasks from the command line.
Configuration and installation
TASK COMMAND
Set the local administrative password net user administrator *
Join a computer to a domain netdom join %computername% /domain:<domain>

/userd:<domain\username> /passwordd:*
Restart the computer.
Confirm that the domain has changed set
Remove a computer from a domain netdom remove <computername>
Add a user to the local Administrators group net localgroup Administrators /add
<domain\username>
Remove a user from the local Administrators group net localgroup Administrators /delete
<domain\username>
Add a user to the local computer net user <domain\username> * /add
Add a group to the local computer net localgroup <group name> /add
Change the name of a domain-joined computer netdom renamecomputer %computername%

/NewName:<new computer name> /userd:
<domain\username> /passwordd: *
Confirm the new computer name set
Change the name of a computer in a work group netdom renamecomputer <currentcomputername>

/NewName:<newcomputername>
Restart the computer.
Disable paging file management wmic computersystem where name="<computername>"

set AutomaticManagedPagefile=False
Configure the paging file wmic pagefileset where name=”<path/filename>” set

InitialSize=<initialsize>,MaximumSize=<maxsize>
Where path/filename is the path to and name of the paging
file, initialsize is the starting size of the paging file, in bytes,
and maxsize is the maximum size of the page file, in bytes.
Change to a static IP address ipconfig /all

Record the relevant information or redirect it to a text file
(ipconfig /all >ipconfig.txt).
netsh interface ipv4 show interfaces
Verify that there is an interface list.
netsh interface ipv4 set address name <ID from interface
list> source=static address=<preferred IP address>
gateway=<gateway address>
Run ipconfig /all to verify that DHCP enabled is set to No.
TASK COMMAND
Set a static DNS address. netsh interface ipv4 add dnsserver name=<name or ID
of the network interface card> address=<IP address of
the primary DNS server> index=1
netsh interface ipv4 add dnsserver name=<name of
secondary DNS server> address=<IP address of the
secondary DNS server> index=2**
Repeat as appropriate to add additional servers.
Run ipconfig /all to verify that the addresses are correct.
Change to a DHCP-provided IP address from a static IP netsh interface ipv4 set address name=<IP address of
address local system> source=DHCP
Run ipconfig /all to verify that DCHP enabled is set to Yes.
Enter a product key slmgr.vbs –ipk <product key>
Activate the server locally slmgr.vbs -ato
Activate the server remotely cscript slmgr.vbs –ipk <product key><server name>
<username><password>
cscript slmgr.vbs -ato <servername> <username>
<password>
Get the GUID of the computer by running cscript slmgr.vbs
-did
Run cscript slmgr.vbs -dli <GUID>
Verify that License status is set to Licensed (activated).
Networking and firewall

TASK COMMAND
Configure your server to use a proxy server netsh Winhttp set proxy <servername>:<port number>
Note: Server Core installations can't access the Internet
through a proxy that requires a password to allow
connections.
Configure your server to bypass the proxy for Internet netsh winttp set proxy <servername>:<port number>
addresses bypass-list="<local>"
Display or modify IPSEC configuration netsh ipsec
Display or modify NAP configuration netsh nap
Display or modify IP to physical address translation arp
Display or configure the local routing table route
View or configure DNS server settings nslookup
Display protocol statistics and current TCP/IP network netstat

connections
Display protocol statistics and current TCP/IP connections nbtstat

using NetBIOS over TCP/IP (NBT)
TASK COMMAND
Display hops for network connections pathping
Trace hops for network connections tracert
Display the configuration of the multicast router mrinfo
Enable remote administration of the firewall netsh advfirewall firewall set rule group=”Windows
Firewall Remote Management” new enable=yes
Updates, error reporting, and feedback

TASK COMMAND
Install an update wusa <update>.msu /quiet
List installed updates systeminfo
Remove an update expand /f:* <update>.msu c:\test

Navigate to c:\test\ and open <update>.xml in a text editor.
Replace Install with Remove and save the file.
pkgmgr /n:<update>.xml
Configure automatic updates To verify the current setting: cscript

%systemroot%\system32\scregedit.wsf /AU /v **
To enable automatic updates: **cscript scregedit.wsf /AU
4
To disable automatic updates: cscript
%systemroot%\system32\scregedit.wsf /AU 1
Enable error reporting To verify the current setting: serverWerOptin /query

To automatically send detailed reports: serverWerOptin
/detailed
To automatically send summary reports: serverWerOptin
/summary
To disable error reporting: serverWerOptin /disable
Participate in the Customer Experience Improvement Program To verify the current setting: serverCEIPOptin /query
(CEIP) To enable CEIP: serverCEIPOptin /enable
To disable CEIP: serverCEIPOptin /disable
Services, processes, and performance

TASK COMMAND
List the running services sc query or net start
Start a service sc start <service name> or net start <service name>
Stop a service sc stop <service name> or net stop <service name>
Retrieve a list of running applications and associated processes tasklist
Start Task Manager taskmgr

TASK COMMAND
Create and manage event trace session and performance logs To create a counter, trace, configuration data collection or API:
logman ceate
To query data collector properties: logman query
To start or stop data collection: logman start|stop
To delete a collector: logman delete
To update the properties of a collector: logman update
To import a data collector set from an XML file or export it to
an XML file: logman import|export
Event logs
TASK COMMAND
List event logs wevtutil el
Query events in a specified log wevtutil qe /f:text <log name>
Export an event log wevtutil epl <log name>
Clear an event log wevtutil cl <log name>
Disk and file system

TASK COMMAND
Manage disk partitions For a complete list of commands, run diskpart /?
Manage software RAID For a complete list of commands, run diskraid /?
Manage volume mount points For a complete list of commands, run mountvol /?
Defragment a volume For a complete list of commands, run defrag /?
Convert a volume to the NTFS file system convert <volume letter> /FS:NTFS
Compact a file For a complete list of commands, run compact /?
Administer open files For a complete list of commands, run openfiles /?
Administer VSS folders For a complete list of commands, run vssadmin /?
Administer the file system For a complete list of commands, run fsutil /?
Take ownership of a file or folder For a complete list of commands, run icacls /?
Hardware
TASK COMMAND
Add a driver for a new hardware device Copy the driver to a folder at %homedrive%\<driver folder>.
Run pnputil -i -a %homedrive%\<driver folder>\
<driver>.inf
TASK COMMAND
Remove a driver for a hardware device For a list of loaded drivers, run sc query type= driver. Then
run sc delete <service_name>
Manage a Server Core server
You can manage a Server Core server in the following ways:

Using Windows Admin Center
Using Remote Server Administration Tools running on Windows 10
Locally and remotely using Windows PowerShell
Remotely using Server Manager
Remotely using an MMC snap-in
Remotely with Remote Desktop Services
You can also add hardware and manage drivers locally, as long as you do that from the command line.
There are some important limitations and tips to keep in mind when you work with Server Core:
If you close all command prompt windows and want to open a new Command Prompt window, you can do that
from the Task Manager. Press CTRL+ALT+DELETE, click Start Task Manager, click More Details > File >
Run, and then type cmd.exe. (Type Powershell.exe to open a PowerShell command windows.) Alternatively,
you can sign out and then sign back in.
Any command or tool that attempts to start Windows Explorer will not work. For example, running start . from
a command prompt won't work.
There is no support for HTML rendering or HTML help in Server Core.
Server Core supports Windows Installer in quiet mode so that you can install tools and utilities from Windows
Installer files. When installing Windows Installer packages on Server Core, use the /qb option to display the
basic user interface.
To change the time zone, run Set-Date.
To change international settings, run control intl.cpl.
Control.exe won't run on its own. You must run it with either Timedate.cpl or Intl.cpl.
Winver.exe isn't available in Server Core. To obtain version information use Systeminfo.exe.
Managing Server Core with Windows Admin Center

Windows Admin Center is a browser-based management app that enables on-premises administration of
Windows Servers with no Azure or cloud dependency. Windows Admin Center gives you full control over all
aspects of your server infrastructure and is particularly useful for management on private networks that are not
connected to the Internet. You can install Windows Admin Center on Windows 10, on a gateway server, or on an
installation of Windows Server with Desktop Experience, and then connect to the Server Core system that you
want to manage.
Managing Server Core remotely with Server Manager

Server Manager is a management console in Windows Server that helps you provision and manage both local and
remote Windows-based servers from your desktops, without requiring either physical access to servers, or the
need to enable Remote Desktop protocol (RDP ) connections to each server. Server Manager supports remote,
multi-server management.
To enable your local server to be managed by Server Manager running on a remote server, run the Windows
PowerShell cmdlet Configure-SMRemoting.exe –Enable.
Managing with Microsoft Management Console

You can use many snap-ins for Microsoft Management Console (MMC ) remotely to manage your Server Core
server.
To use an MMC snap-in to manage a Server Core server that is a domain member:
1. Start an MMC snap-in, such as Computer Management.
2. Right-click the snap-in, and then click Connect to another computer.
3. Type the computer name of the Server Core server, and then click OK. You can now use the MMC snap-in to
manage the Server Core server as you would any other PC or server.
To use an MMC snap-in to manage a Server Core server that is not a domain member:
1. Establish alternate credentials to use to connect to the Server Core computer by typing the following
command at a command prompt on the remote computer:
cmdkey /add:<ServerName> /user:<UserName> /pass:<password>
If you want to be prompted for a password, omit the /pass option.

2. When prompted, type the password for the user name you specified. If the firewall on the Server Core
server is not already configured to allow MMC snap-ins to connect, follow the steps below to configure
Windows Firewall to allow MMC snap-in. Then continue with step 3.
3. On a different computer, start an MMC snap-in, such as Computer Management.
4. In the left pane, right-click the snap-in, and then click Connect to another computer. (For example, in the
Computer Management example, you would right-click Computer Management (Local).)
5. In Another computer, type the computer name of the Server Core server, and then click OK. You can now use
the MMC snap-in to manage the Server Core server as you would any other computer running a Windows
Server operating system.
To configure Windows Firewall to allow MMC snap-in(s) to connect
To allow all MMC snap-ins to connect, run the following command:
Enable-NetFirewallRule -DisplayGroup "Remote Administration"
To allow only specific MMC snap-ins to connect, run the following:
Enable-NetFirewallRule -DisplayGroup "<rulegroup>"
Where rulegroup is one of the following, depending on which snap-in you want to connect:
MMC SNAP-IN RULE GROUP
Event Viewer Remote Event Log Management
Services Remote Service Management
Shared Folders File and Printer Sharing

MMC SNAP-IN RULE GROUP
Task Scheduler Performance Logs and Alerts, File and Printer Sharing
Disk Management Remote Volume Management
Windows Firewall and Advanced Security Windows Firewall Remote Management
NOTE
Some MMC snap-ins don't have a corresponding rule group that allows them to connect through the firewall. However,
enabling the rule groups for Event Viewer, Services, or Shared Folders will allow most other snap-ins to connect.
Additionally, certain snap-ins require further configuration before they can connect through Windows Firewall:
Disk Management. You must first start the Virtual Disk Service (VDS) on the Server Core computer. You must also
configure the Disk Management rules appropriately on the computer that is running the MMC snap-in.
IP Security Monitor. You must first enable remote management of this snap-in. To do this, at a command prompt, type
Cscript \windows\system32\scregedit.wsf /im 1
Reliability and Performance. The snap-in does not require any further configuration, but when you use it to monitor a
Server Core computer, you can only monitor performance data. Reliability data is not available.
Managing with Remote Desktop Services

You can use Remote Desktop to manage a Server Core server from remote computers.
Before you can access Server Core, you'll need to run the following command:
cscript C:\Windows\System32\Scregedit.wsf /ar 0
This enables the Remote Desktop for Administration mode to accept connections.
Add hardware and manage drivers locally

To add hardware to a Server Core server, follow the instructions provided by the hardware vendor for installing
new hardware.
If the hardware is not plug and play, you'll need to manually install the driver. To do that, copy the driver files to a
temporary location on the server, and then run the following command:
pnputil –i –a <driverinf>
Where driverinf is the file name of the .inf file for the driver.
If prompted, restart the computer.
To see what drivers are installed, run the following command:
sc query type= driver

NOTE
You must include the space after the equal sign for the command to complete successfully.
To disable a device driver, run the following:
sc delete <service_name>
Where service_name is the name of the service that you got when you ran sc query type= driver.
Configure memory dump files for Server Core
installation
Applies To: Windows Server (Semi-Annual Channel) and Windows Server 2016
Use the following steps to configure a memory dump for your Server Core installation.
Step 1: Disable the automatic system page file management

The first step is to manually configure your system failure and recovery options. This is required to complete the
remaining steps.
Run the following command:
wmic computersystem set AutomaticManagedPagefile=False
Step 2: Configure the destination path for a memory dump

You don't have to have the page file on the partition where the operating system is installed. To put the page file on
another partition, you must create a new registry entry named DedicatedDumpFile. You can define the size of
the paging file by using the DumpFileSize registry entry. To create the DedicatedDumpFile and DumpFileSize
registry entries, follow these steps:
1. At the command prompt, run the regedit command to open the Registry Editor.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
3. Click Edit > New > String Value.
4. Name the new value DedicatedDumpFile, and then press ENTER.
5. Right-click DedicatedDumpFile, and then click Modify.
6. In Value data type <Drive>:\<Dedicateddumpfile.sys>, and then click OK.
NOTE
Replace <Drive> with a drive that has enough disk space for the paging file, and replace <Dedicateddumpfile.dmp>
with the full path to the dedicated file.
7. Click Edit > New > DWORD Value.

8. Type DumpFileSize, and then press ENTER.
9. Right-click DumpFileSize, and then click Modify.
10. In Edit DWORD Value, under Base, click Decimal.
11. In Value data, type the appropriate value, and then click OK. >[!NOTE ] > The size of the dump file is in
megabytes (MB ).
12. Exit the Registry Editor.
After you determine the partition location of the memory dump, configure the destination path for the page file. To
view the current destination path for the page file, run the following command:
wmic RECOVEROS get DebugFilePath
The default destination for DebugFilePath is %systemroot%\memory.dmp. To change the current destination
path, run the following command:
wmic RECOVEROS set DebugFilePath = <FilePath>
Set <FilePath> to the destination path. For example, the following command sets the memory dump destination
path to C:\WINDOWS\MEMORY.DMP:
wmic RECOVEROS set DebugFilePath = C:\WINDOWS\MEMORY.DMP
Step 3: Set the type of memory dump

Determine the type of memory dump to configure for your server. To view the current memory dump type, run the
following command:
wmic RECOVEROS get DebugInfoType
To change the current memory dump type, run the following command:
wmic RECOVEROS set DebugInfoType = <Value>
<Value> can be 0, 1, 2, or 3, as defined below.

0: Disable the removal of a memory dump.
1: Full memory dump. Records all of the contents of system memory when your computer stops unexpectedly.
A full memory dump may contain data from processes that were running when the memory dump was
collected.
2: Kernel memory dump (default). Records only the kernel memory. This speeds up the process of recording
information in a log file when your computer stops unexpectedly.
3: Small memory dump. Records the smallest set of useful information that may help identify why your
computer stopped unexpectedly.
Step 4: Configure the server to restart automatically after generating a

memory dump
By default, the server automatically restarts after it generates a memory dump. To view the current configuration,
run the following command:
wmic RECOVEROS get AutoReboot
If the value for AutoReboot is TRUE, the server will restart automatically after generating a memory dump. No
configuration is needed and you can proceed to the next step.
If the value for AutoReboot is FALSE, the server will not restart automatically. Run the following command to
change the value:
wmic RECOVEROS set AutoReboot = true
Step 5: Configure the server to overwrite the existing memory dump

file
By default, the server overwrites the existing memory dump file when a new one is created. To determine if
existing memory dump files are already configured to be overwritten, run the following command:
wmic RECOVEROS get OverwriteExistingDebugFile
If the value is 1, the server will overwrite the existing memory dump file. No configuration is needed, and you can
proceed to the next step.
If the value is 0, the server won't overwrite the existing memory dump file. Run the following command to change
the value:
wmic RECOVEROS set OverwriteExistingDebugFile = 1
Step 6: Set an administrative alert

Determine whether an administrative alert is appropriate and set SendAdminAlert accordingly. To view the
current value for SendAdminAlert, run the following command:
wmic RECOVEROS get SendAdminAlert
The possible values for SendAdminAlert are TRUE or FALSE. To modify the existing SendAdminAlert value to true,
run the following command:
wmic RECOVEROS set SendAdminAlert = true
Step 7: Set the memory dump's page file size

To check the current page file settings, run one of the following commands:
wmic.exe pagefile
or
wmic.exe pagefile list /format:list
For example, run the following command to configure the initial and maximum sizes of your page file:
wmic pagefileset where name="c:\\pagefile.sys" set InitialSize=1000,MaximumSize=5000
Step 8: Configure the server to generate a manual memory dump

You can manually generate a memory dump by using a PS/2 keyboard. This feature is disabled by default, and it is
not available for Universal Serial Bus (USB ) keyboards.
To enable manual memory dumps by using a PS/2 keyboard, run the following command:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters /v CrashOnCtrlScroll /t

REG_DWORD /d 1 /f
To determine if the feature has been enabled properly, run the following command:
Reg query HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters / v

CrashOnCtrlScroll
You must restart the server for the changes to take effect. You can restart the server by running the following
command:
Shutdown / r / t 0
You can generate manual memory dumps with a PS/2 keyboard that is connected to your server by holding the
RIGHT CTRL key while pressing the SCROLL LOCK key two times. This makes the computer bug check with error
code 0xE2. After you restart the server, a new dump file appears in the destination path that you established in step
2.
Step 9: Verify that memory dump files are being created correctly
You can use the dumpchk.exe utlity to verify that the memory dump files are being created correctly. The
dumpchk.exe utility isn't installed with the Server Core installation option, so you'll have to run it from a server
with the Desktop Experience or from Windows 10. Additionally, the debugging tools for Windows products must
be installed.
The dumpchk.exe utility lets you transfer the memory dump file from your Server Core installation of Windows
Server 2008 to the other computer by using the medium of your choice.
WARNING
Page files can be very large, so carefully consider the transfer method and the resources that method requires.
Additional References
For general information about using memory dump files, see Overview of memory dump file options for
Windows.
For more information about dedicated dump files, see How to use the DedicatedDeumpFile registry value to
overcome space limitations on the system drive while capturing a system memory dump.
Patch a Server Core installation
You can patch a server running Server Core installation in the following ways:
Using Windows Update automatically or with Windows Server Update Services (WSUS ). By using
Windows Update, either automatically or with command-line tools, or Windows Server Update Services
(WSUS ), you can service servers running a Server Core installation.
Manually. Even in organizations that do not use Windows update or WSUS, you can apply updates
manually.
View the updates installed on your Server Core server

Before you add a new update to Server Core, it's a good idea to see what updates have already been installed.
To view updates by using Windows PowerShell, run Get-Hotfix.
To view updates by running a command, run systeminfo.exe. There might be a short delay while the tool inspects
your system.
You can also run wmic qfe list from the command line.
Patch Server Core automatically with Windows Update

Use the following steps to patch the server automatically with Windows Update:
1. Verify the current Windows Update setting:
%systemroot%\system32\Cscript scregedit.wsf /AU /v
2. To enable automatic updates:
Net stop wuauserv

%systemroot%\system32\Cscript scregedit.wsf /AU 4
Net start wuauserv
3. To disable automatic updates, run:
Net stop wuauserv

%systemroot%\system32\Cscript scregedit.wsf /AU 1
Net start wuauserv
If the server is a member of a domain, you can also configure Windows Update using Group Policy. For more
information, see https://go.microsoft.com/fwlink/?LinkId=192470. However, when you use this method, only
option 4 ("Auto download and schedule the install") is relevant to Server Core installations because of the lack of a
graphical interface. For more control over which updates are installed and when, you can use a script which
provides a command-line equivalent of most of the Windows Update graphical interface. For information about
the script, see https://go.microsoft.com/fwlink/?LinkId=192471.
To force Windows Update to immediately detect and install any available updates, run the following command:
Wuauclt /detectnow
Depending on the updates that are installed, you may need to restart the computer, although the system will not
notify you of this. To determine if the installation process has completed, use Task Manager to verify that the
Wuauclt or Trusted Installer processes are not actively running. You can also use the methods in View the
updates installed on your Server Core server to check the list of installed updates.
Patch the server with WSUS

If the Server Core server is a member of a domain, you can configure it to use a WSUS server with Group Policy.
For more information, download the Group Policy reference information. You can also review Configure Group
Policy Settings for Automatic Updates
Patch the server manually

Download the update and make it available to the Server Core installation. At a command prompt, run the
following command:
Wusa <update>.msu /quiet
Depending on the updates that are installed, you may need to restart the computer, although the system will not
notify you of this.
To uninstall an update manually, run the following command:
Wusa /uninstall <update>.msu /quiet

Server Manager
Applies To: Windows Server (Semi-Annual Channel), 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 enterprise-level 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
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.
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
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.
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.
TARGETED AT
SERVER MANAGER WINDOWS SERVER
SOURCE TARGETED AT TARGETED AT TARGETED AT 2008 R2 OR TARGETED AT
OPERATING WINDOWS SERVER WINDOWS SERVER WINDOWS SERVER WINDOWS SERVER WINDOWS SERVER
SYSTEM 2016 2012 R2 2012 2008 2003
Windows 10 or Full support Full support Full support After Software Not supported
Windows Server and configuration
2016 requirements are
satisfied, can
perform most
management
tasks, but no role
or feature
installation or
uninstallation
Windows 8.1 or Not supported Full support Full support After Software Limited support;
Windows Server and configuration online and offline
2012 R2 requirements are status only
satisfied, can
perform most
management
tasks, but no role
or feature
installation or
uninstallation
Windows 8 or Not supported Not supported Full support After Software Limited support;
Windows Server and configuration online and offline
2012 requirements are status only
satisfied, can
perform most
management
tasks, but no role
or feature
installation or
uninstallation
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, Enable-
ServerManagerStandardUserremoting 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

TASK DESCRIPTION BUILT-IN ADMINISTRATOR ACCOUNT) STANDARD SERVER USERS
add remote servers to a pool of servers Yes No

that Server Manager can be used to
manage.
create and edit custom groups of Yes Yes

servers, such as servers that are in a
specific geographic location or serve a
specific purpose.
Install or uninstall roles, role services, Yes No

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.
View and make changes to server roles Yes Standard users can view and manage
and features that are installed on either roles and features, and perform tasks
local or remote servers. Note: In Server such as viewing role events, but cannot
Manager, role and feature data is add or remove role services.
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.
ADMINISTRATORS (INCLUDING THE
TASK DESCRIPTION BUILT-IN ADMINISTRATOR ACCOUNT) STANDARD SERVER USERS
start management tools such as Yes Yes

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 snap-
ins from the Tools menu of the Server
Manager console, and then point the
mmc toward a remote computer after
the snap-in is open.
Manage remote servers with different Yes No

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.
Perform management tasks associated Yes Standard users cannot start or stop
with the operational lifecycle of servers, services. They can change the local
such as starting or stopping services; server's name, workgroup, or domain
and start other tools that allow you to membership and Remote Desktop
configure a server's network settings, settings, but are prompted by User
users and groups, and Remote Desktop Account Control to provide
connections. Administrator credentials before they
can complete these tasks. They cannot
change remote management settings.
Perform management tasks associated Yes Standard users cannot run Best
with the operational lifecycle of roles Practices Analyzer scans.
that are installed on servers, including
scanning roles for compliance with best
practices.
Determine server status, identify critical Yes Yes

events, and analyze and troubleshoot
configuration issues or failures.
Customize the events, performance Yes Yes

data, services, and Best Practices
Analyzer results about which you want
to be alerted on the Server Manager
dashboard.
Restart servers. Yes No
Refresh data that is displayed in the Yes No

Server Manager console about
managed servers.
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.
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.
%localappdata%\Microsoft_Corporation\ServerManager.exe_StrongName_GUID\6.2.0.0\us
er.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.
%localappdata%\Microsoft_Corporation\ServerManager.exe_StrongName_GUID\6.2.0.0\user.confi
g
Manage the Local Server and the Server Manager
Console
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 Displays the domain or workgroup of which the server is a
domain) 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
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 MANAGEABILITY
Windows Server 2012 R2 or Windows - .NET Framework 4.6

Server 2012 - 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 .
OPERATING SYSTEM REQUIRED SOFTWARE MANAGEABILITY
Windows Server 2008 R2 - .NET Framework 4.5

- Windows Management Framework
4.0. The Windows Management
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.
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
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.
with Knowledge Base article 2682011
lets Server Manager collect performance
data from Windows Server 2008 .
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-Management-
Core\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
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.
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.

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.
2. On the Manage menu, click add Servers.
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
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
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.
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.
taskbar.
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 client-
based 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.
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.
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
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.
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
NOTE
If you are uninstalling roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
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.
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.
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

NOTE
if you are installing roles and features from a remote server, you do not need to run Windows PowerShell with
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
NOTE
if you are installing roles and features from a remote server, you do not need to run Windows PowerShell with
Administrator.
On the Windows Start screen, right-click the Windows PowerShell tile, and then on the app bar, click
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
This topic describes how to remove feature files in a Features on Demand configuration by using the Uninstall-
WindowsFeature 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 Install-WindowsFeature cmdlet, by adding the Source
parameter
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
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
NOTE
if you are uninstalling roles and features from a remote server, you do not need to run Windows PowerShell with
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 computerName parameter if you are running the cmdlet from a computer that is running Windows
8.1 or Windows 8.
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
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.
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
taskbar.
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.
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
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.
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
View Task details and Notifications
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
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.
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 : Microsoft/Windows/FileServices
SubmodelId :
Success : True
Scantime : 1/01/2012 12:18:40 PM
ScantimeUtcOffset : -08:00:00
detail : {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

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

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
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 : 14
ResultId : 1557706192
modelId : Microsoft/Windows/FileServices
SubmodelId : FSRM
RuleId : 16
computerName : server_name1, server_name2
Context : FileServices
Source : server_name1
Severity : Information
Category : Configuration
Title : Access Denied remediation requires remote management be enabled on this server
Problem :
Impact :
Resolution :
compliance : The File Server Best Practices Analyzer scan has determined that you are in
compliance with this best practice.
help :
Excluded : 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
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
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
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
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.
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
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
2. In an Events, Performance, Best Practices Analyzer, Services, or Roles and Features tile, expand the query-
building 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 query-
building 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
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
Roles and Server Groups tile Alt+R
Console Header Controls
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
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
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) Alt+B
tile
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
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
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
Tasks menu Alt+T
Filter control Alt+F
query control Alt+Q
Save queries Alt+S

Remote Server Administration Tools
Applies To: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
This topic supports Remote Server Administration Tools for Windows 10.
IMPORTANT
Starting with Windows 10 October 2018 Update, RSAT is included as a set of Features on Demand in Windows 10 itself.
See When to use which RSAT version below for installation instructions.
RSAT lets IT admins manage Windows Server roles and features from a Windows 10 PC.
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 operating systems.
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 and turn off/on RSAT tools

Use Features on Demand (FoD) to install specific RSAT tools on Windows 10 October 2018 Update, or later
Starting with Windows 10 October 2018 Update, RSAT is included as a set of Features on Demand right from
Windows 10. Now, instead of downloading an RSAT package you can just go to Manage optional features in
Settings and click Add a feature to see the list of available RSAT tools. Select and install the specific RSAT tools
you need. To see installation progress, click the Back button to view status on the Manage optional features
page.
See the list of RSAT tools available via Features on Demand. In addition to installing via the graphical Settings
app, you can also install specific RSAT tools via command line or automation using DISM /Add-Capability.
One benefit of Features on Demand is that installed features persist across Windows 10 version upgrades!
To uninstall specific RSAT tools on Windows 10 October 2018 Update or later (after installing with FoD)
On Windows 10, open the Settings app, go to Manage optional features, select and uninstall the specific RSAT
tools you wish to remove. Note that in some cases, you will need to manually uninstall dependencies. Specifically,
if RSAT tool A is needed by RSAT tool B, then choosing to uninstall RSAT tool A will fail if RSAT tool B is still
installed. In this case, uninstall RSAT tool B first, and then uninstall RSAT tool A. Also note that in some cases,
uninstalling an RSAT tool may appear to succeed even though the tool is still installed. In this case, restarting the
PC will complete the removal of the tool.
See the list of RSAT tools including dependencies. In addition to uninstalling via the graphical Settings app, you
can also uninstall specific RSAT tools via command line or automation using DISM /Remove-Capability.
When to use which RSAT version
If you have a version of Windows 10 prior to the October 2018 Update (1809), you will not be able to use
Features on Demand. You will need to download and install the RSAT package.
Install RSAT FODs directly from Windows 10, as outlined above: When installing on Windows 10
October 2018 Update (1809) or later, for managing Windows Server 2019 or previous versions.
Download and install WS_1803 RSAT package, as outlined below: When installing on Windows 10
April 2018 Update (1803) or earlier, for managing Windows Server, version 1803 or Windows Server,
version 1709.
Download and install WS2016 RSAT package, as outlined below: When installing on Windows 10
April 2018 Update (1803) or earlier, for managing Windows Server 2016 or previous versions.
Download the RSAT package 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.
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 (a ft e r R SA T p a c k a g e i n st a l l )
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 (a ft e r R SA T p a c k a g e i n st a l l )
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.
Known issues
Issue : RSAT FOD installation fails with error code 0x800f0954
Impact: RSAT FODs on Windows 10 1809 (October 2018 Update) in WSUS/SCCM environments
Resolution: To install FODs on a domain-joined PC which receives updates through WSUS or SCCM, you
will need to change a Group Policy setting to enable downloading FODs directly from Windows Update or a
local share. For more details and instructions on how to change that setting, see How to make Features on
Demand and language packs available when you're using WSUS/SCCM.
Issue : RSAT FOD installation via Settings app does not show status/progress
Impact: RSAT FODs on Windows 10 1809 (October 2018 Update)
Resolution: To see installation progress, click the Back button to view status on the Manage optional
features page.
Issue : RSAT FOD uninstallation via Settings app may fail

Resolution: In some cases, uninstallation failures are due to the need to manually uninstall dependencies.
Specifically, if RSAT tool A is needed by RSAT tool B, then choosing to uninstall RSAT tool A will fail if RSAT
tool B is still installed. In this case, uninstall RSAT tool B first, and then uninstall RSAT tool A. See the list of
RSAT FODs including dependencies.
Issue : RSAT FOD uninstallation appears to succeed, but the tool is still installed
Resolution: Restarting the PC will complete the removal of the tool.
Issue : RSAT missing after Windows 10 upgrade

Impact: Any RSAT .MSU package installation (prior to RSAT FODs) not automatically reinstalled
Resolution: An RSAT installation cannot be persisted across OS upgrades due to the RSAT .MSU being
delivered as a Windows Update package. Please install RSAT again after upgrading Windows 10. Note that
this limitation is one of the reasons why we've moved to FODs starting with Windows 10 1809. RSAT FODs
which are installed will persist across future Windows 10 version upgrades.
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
OpenSSH in Windows
OpenSSH is the open-source version of the Secure Shell (SSH) tools used by administrators of Linux and other
non-Windows for cross-platform management of remote systems. OpenSSH has been added to Windows as of
autumn 2018, and is included in Windows 10 and Windows Server 2019.
SSH is based on a client-server architecture where the system the user is working on is the client and the remote
system being managed is the server. OpenSSH includes a range of components and tools designed to provide a
secure and straightforward approach to remote system administration, including:
sshd.exe, which is the SSH server component that must be running on the system being managed remotely
ssh.exe, which is the SSH client component that runs on the user's local system
ssh-keygen.exe generates, manages and converts authentication keys for SSH
ssh-agent.exe stores private keys used for public key authentication
ssh-add.exe adds private keys to the list allowed by the server
ssh-keyscan.exe aids in collecting the public SSH host keys from a number of hosts
sftp.exe is the service that provides the Secure File Transfer Protocol, and runs over SSH
scp.exe is a file copy utility that runs on SSH
Documentation in this section focuses on how OpenSSH is used on Windows, including installation, and Windows-
specific configuration and use cases. Here are the topics:
Installing and Uninstalling OpenSSH For Windows Server 2019 and Windows 10
Additional detailed documentation for common OpenSSH features is available online at OpenSSH.com.
The master OpenSSH open source project is managed by developers at the OpenBSD Project. The Microsoft fork
of this project is in Github. Feedback on Windows OpenSSH is welcomed and can be provided by creating Github
issues in our OpenSSH Github repo.
Installation of OpenSSH For Windows Server 2019
and Windows 10
The OpenSSH Client and OpenSSH Server are separately installable components in Windows Server 2019 and
Windows 10 1809. Users with these Windows versions should use the instructions that follow to install and
configure OpenSSH.
NOTE
Users who acquired OpenSSH from the PowerShell Github repo (https://github.com/PowerShell/OpenSSH-Portable) should
use the instructions from there, and should not use these instructions.
Installing OpenSSH from the Settings UI on Windows Server 2019 or

Windows 10 1809
OpenSSH client and server are installable features of Windows 10 1809.
To install OpenSSH, start Settings then go to Apps > Apps and Features > Manage Optional Features.
Scan this list to see if OpenSSH client is already installed. If not, then at the top of the page select "Add a feature",
then:
To install the OpenSSH client, locate "OpenSSH Client", then click "Install".
To install the OpenSSH server, locate "OpenSSH Server", then click "Install".
Once the installation completes, return to Apps > Apps and Features > Manage Optional Features and you should
see the OpenSSH component(s) listed.
NOTE
Installing OpenSSH Server will create and enable a firewall rule named "OpenSSH-Server-In-TCP". This allows inbound SSH
traffic on port 22.
Installing OpenSSH with PowerShell

To install OpenSSH using PowerShell, first launch PowerShell as an Administrator. To make sure that the
OpenSSH features are available for install:
Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'
# This should return the following output:
Name : OpenSSH.Client~~~~0.0.1.0
State : NotPresent
Name : OpenSSH.Server~~~~0.0.1.0
State : NotPresent
Then, install the server and/or client features:

# Install the OpenSSH Client
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
# Install the OpenSSH Server

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
# Both of these should return the following output:
Path :
Online : True
RestartNeeded : False
Uninstalling OpenSSH
To uninstall OpenSSH using the Windows Settings, start Settings then go to Apps > Apps and Features > Manage
Optional Features. In the list of installed features, select the OpenSSH Client or OpenSSH Server component, then
select Uninstall.
To uninstall OpenSSH using PowerShell, use one of the following commands:
# Uninstall the OpenSSH Client

Remove-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
# Uninstall the OpenSSH Server

Remove-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
A Windows restart may be required after removing OpenSSH, if the service is in use at the time it was uninstalled.
Initial Configuration of SSH Server

To configure the OpenSSH server for initial use on Windows, launch PowerShell as an administrator, then run the
following commands to start the SSHD service:
Start-Service sshd
# OPTIONAL but recommended:
Set-Service -Name sshd -StartupType 'Automatic'
# Confirm the Firewall rule is configured. It should be created automatically by setup.
Get-NetFirewallRule -Name *ssh*
# There should be a firewall rule named "OpenSSH-Server-In-TCP", which should be enabled
Initial use of SSH

Once you have installed the OpenSSH Server on Windows, you can quickly test it using PowerShell from any
Windows device with the SSH Client installed. In PowerShell type the following command:
Ssh username@servername
The first connection to any server will result in a message similar to the following:
The authenticity of host 'servername (10.00.00.001)' can't be established.

ECDSA key fingerprint is SHA256:(<a large string>).
Are you sure you want to continue connecting (yes/no)?
The answer must be either “yes” or “no”. Answering Yes will add that server to the local system’s list of known ssh
hosts.
You will be prompted for the password at this point. As a security precaution, your password will not be displayed
as you type.
Once you connect you will see a command shell prompt similar to the following:
domain\username@SERVERNAME C:\Users\username>
The default shell used by Windows OpenSSH server is the Windows command shell.
OpenSSH Server Configuration for Windows 10 1809
and Server 2019#
This topic covers the Windows-specific configuration for OpenSSH Server (sshd).
OpenSSH maintains detailed documentation for configuration options online at OpenSSH.com, which is not be
duplicated in this documentation set.
Configuring the default shell for OpenSSH in Windows

The default command shell provides the experience a user sees when connecting to the server using SSH. The
initial default Windows is the Windows Command shell (cmd.exe). Windows also includes PowerShell and Bash,
and third party command shells are also available for Windows and may be configured as the default shell for a
server.
To set the default command shell, first confirm that the OpenSSH installation folder is on the system path. For
Windows, the default installation folder is SystemDrive:WindowsDirectory\System32\openssh. The following
commands shows the current path setting, and add the default OpenSSH installation folder to it.
COMMAND SHELL COMMAND TO USE
Command path
PowerShell $env:path
Configuring the default ssh shell is done in the Windows registry by adding the full path to the shell executable to
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH in the string value DefaultShell.
As an example, the following Powershell command sets the default shell to be PowerShell.exe:
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force
Windows Configurations in sshd_config

In Windows, sshd reads configuration data from %programdata%\ssh\sshd_config by default, or a different
configuration file may be specified by launching sshd.exe with the -f parameter. If the file is absent, sshd generates
one with the default configuration when the service is started.
The elements listed below provide Windows-specific configuration possible through entries in sshd_config. There
are other configuration settings possible in that are not listed here, as they are covered in detail in the online Win32
OpenSSH documentation.
AllowGroups, AllowUsers, DenyGroups, DenyUsers
Controlling which users and groups can connect to the server is done using the AllowGroups, AllowUsers,
DenyGroups and DenyUsers directives. The allow/deny directives are processed in the following order: DenyUsers,
AllowUsers, DenyGroups, and finally AllowGroups. All account names must be specified in lower case. See
PATTERNS in ssh_config for more information on patterns for wildcards.
When configuring user/group based rules with a domain user or group, use the following format: user?domain* .
Windows allows multiple of formats for specifying domain principals, but many conflict with standard Linux
patterns. For that reason, * is added to cover FQDNs. Also, this approach uses "?", instead of @, to avoid conflicts
with the username@host format.
Work group users/groups and internet-connected accounts are always resolved to their local account name (no
domain part, similar to standard Unix names). Domain users and groups are strictly resolved to
NameSamCompatible format - domain_short_name\user_name. All user/group based configuration rules need to
adhere to this format.
Examples for domain users and groups
DenyUsers contoso\admin@192.168.2.23 : blocks contoso\admin from 192.168.2.23

DenyUsers contoso\* : blocks all users from contoso domain
AllowGroups contoso\sshusers : only allow users from contoso\sshusers group
Examples for local users and groups
AllowUsers localuser@192.168.2.23
AllowGroups sshusers
AuthenticationMethods
For Windows OpenSSH, the only available authentication methods are "password" and "publickey".
AuthorizedKeysFile
The default is “.ssh/authorized_keys .ssh/authorized_keys2”. If the path is not absolute, it is taken relative to user's
home directory (or profile image path). Ex. c:\users\user.
ChrootDirectory (Support added in v7.7.0.0)
This directive is only supported with sftp sessions. A remote session into cmd.exe wouldn't honor this. To setup a
sftp-only chroot server, set ForceCommand to internal-sftp. You may also set up scp with chroot, by implementing
a custom shell that would only allow scp and sftp.
HostKey
The defaults are %programdata%/ssh/ssh_host_ecdsa_key, %programdata%/ssh/ssh_host_ed25519_key and
%programdata%/ssh/ssh_host_rsa_key. If the defaults are not present, sshd automatically generates these on a
service start.
Match
Note that pattern rules in this section. User and group names should be in lower case.
PermitRootLogin
Not applicable in Windows. To prevent administrator login, use Administrators with DenyGroups directive.
SyslogFacility
If you need file based logging, use LOCAL0. Logs are generated under %programdata%\ssh\logs. Any other value,
including the default value AUTH directs logging to ETW. For more info see Logging Facilities in Windows.
Not supported
The following configuration options are not available in the OpenSSH version that ships in Windows Server 2019
and Windows 10 1809:
AcceptEnv
AllowStreamLocalForwarding
AuthorizedKeysCommand
AuthorizedKeysCommandUser
AuthorizedPrincipalsCommand
AuthorizedPrincipalsCommandUser
Compression
ExposeAuthInfo
GSSAPIAuthentication
GSSAPICleanupCredentials
GSSAPIStrictAcceptorCheck
HostbasedAcceptedKeyTypes
HostbasedAuthentication
HostbasedUsesNameFromPacketOnly
IgnoreRhosts
IgnoreUserKnownHosts
KbdInteractiveAuthentication
KerberosAuthentication
KerberosGetAFSToken
KerberosOrLocalPasswd
KerberosTicketCleanup
PermitTunnel
PermitUserEnvironment
PermitUserRC
PidFile
PrintLastLog
RDomain
StreamLocalBindMask
StreamLocalBindUnlink
StrictModes
X11DisplayOffset
X11Forwarding
X11UseLocalhost
XAuthLocation
OpenSSH Key Management
Most authentication in Windows environments is done with a username-password pair. This works well for systems
that share a common domain. When working across domains, such as between on-premise and cloud-hosted
systems, it becomes more difficult.
By comparison, Linux environments commonly use public-key/private-key pairs to drive authentication. OpenSSH
includes tools to help support this, specifically:
ssh-keygen for generating secure keys
ssh-agent and ssh-add for securely storing private keys
scp and sftp to securely copy public key files during initial use of a server
This document provides an overview of how to use these tools on Windows to begin using key authentication with
SSH. If you are unfamiliar with SSH key management, we strongly recommend you review NIST document IR
7966 titled “Security of Interactive and Automated Access Management Using Secure Shell (SSH).”
About key pairs

Key pairs refer to the public and private key files that are used by certain authentication protocols.
SSH public-key authentication uses asymmetric cryptographic algorithms to generate two key files – one "private"
and the other "public". The private key files are the equivalent of a password, and should protected under all
circumstances. If someone acquires your private key, they can log in as you to any SSH server you have access to.
The public key is what is placed on the SSH server, and may be shared without compromising the private key.
When using key authentication with an SSH server, the SSH server and client compare the public key for username
provided against the private key. If the public key cannot be validated against the client-side private key,
authentication fails.
Multi-factor authentication may be implemented with key pairs by requiring that a passphrase be supplied when
the key pair is generated (see key generation below ). During authentication the user is prompted for the
passphrase, which is used along with the presence of the private key on the SSH client to authenticate the user.
Host key generation

Public keys have specific ACL requirements that, on Windows, equate to only allowing access to administrators and
System. To make this easier,
The OpenSSHUtils PowerShell module has been created to set the key ACLs properly, and should be installed
on the server
On first use of sshd, the key pair for the host will be automatically generated. If ssh-agent is running, the keys
will be automatically added to the local store.
To make key authentication easy with an SSH server, run the following commands from an elevated PowerShell
prompt:
# Install the OpenSSHUtils module to the server. This will be valuable when deploying user keys.
Install-Module -Force OpenSSHUtils -Scope AllUsers
# Start the ssh-agent service to preserve the server keys

Start-Service ssh-agent
# Now start the sshd service

Start-Service sshd
Since there is no user associated with the sshd service, the host keys are stored under \ProgramData\ssh.
User key generation

To use key-based authentication, you first need to generate some public/private key pairs for your client. From
PowerShell or cmd, use ssh-keygen to generate some key files.
cd ~\.ssh\
ssh-keygen
This should display something like the following (where "username" is replaced by your user name)
Generating public/private ed25519 key pair.

Enter file in which to save the key (C:\Users\username\.ssh\id_ed25519):
You can hit Enter to accept the default, or specify a path where you’d like your keys to be generated. At this point,
you’ll be prompted to use a passphrase to encrypt your private key files. The passphrase works with the key file to
provide 2-factor authentication. For this example, we are leaving the passphrase empty.
Enter passphrase (empty for no passphrase):

Enter same passphrase again:
Your identification has been saved in C:\Users\username\.ssh\id_ed25519.
Your public key has been saved in C:\Users\username\.ssh\id_ed25519.pub.
The key fingerprint is:
SHA256:OIzc1yE7joL2Bzy8!gS0j8eGK7bYaH1FmF3sDuMeSj8 username@server@LOCAL-HOSTNAME
The key's randomart image is:

+--[ED25519 256]--+
| . |
| o |
| . + + . |
| o B * = . |
| o= B S . |
| .=B O o |
| + =+% o |
| *oo.O.E |
|+.o+=o. . |
+----[SHA256]-----+
Now you have a public/private ED25519 key pair (the .pub files are public keys and the rest are private keys):
Mode LastWriteTime Length Name

---- ------------- ------ ----
-a---- 9/28/2018 11:09 AM 1679 id_ed25519
-a---- 9/28/2018 11:09 AM 414 id_ed25519.pub
Remember that private key files are the equivalent of a password should be protected the same way you protect
your password. To help with that, use ssh-agent to securely store the private keys within a Windows security
context, associated with your Windows login. To do that, start the ssh-agent service as Administrator and use ssh-
add to store the private key.
# Make sure you're running as an Administrator

Start-Service ssh-agent
# This should return a status of Running

Get-Service ssh-agent
# Now load your key files into ssh-agent

ssh-add ~\.ssh\id_ed25519
After completing these steps, whenever a private key is needed for authentication from this client, ssh-agent will
automatically retrieve the local private key and pass it to your SSH client.
NOTE
It is strongly recommended that you back up your private key to a secure location, then delete it from the local system, after
adding it to ssh-agent. The private key cannot be retrieved from the agent. If you lose access to the private key, you would
have to create a new key pair and update the public key on all systems you interact with.
Deploying the public key

To use the user key that was created above, the public key needs to be placed on the server into a text file called
authorized_keys under users\username\ssh. The OpenSSH tools include scp, which is a secure file-transfer utility,
to help with this.
To move the contents of your public key (~.ssh\id_ed25519.pub) into a text file called authorized_keys in ~.ssh\ on
your server/host.
This example uses the Repair-AuthorizedKeyPermissions function in the OpenSSHUtils module which was
previously installed on the host in the instructions above.
# Make sure that the .ssh directory exists in your server's home folder
ssh user1@domain1@contoso.com mkdir C:\users\user1\.ssh\
# Use scp to opy the public key file generated previously to authorized_keys on your server
scp C:\Users\user1\.ssh\id_ed25519.pub user1@domain1@contoso.com:C:\Users\user1\.ssh\authorized_keys
# Appropriately ACL the authorized_keys file on your server

ssh --% user1@domain1@contoso.com powershell -c $ConfirmPreference = 'None'; Repair-AuthorizedKeyPermission
C:\Users\user1\.ssh\authorized_keys
These steps complete the configuration required to use key-based authentication with SSH on Windows. After this,
the user can connect to the sshd host from any client that has the private key.
Windows Server Update Services (WSUS)
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:
Manage Updates using Windows Server Update Services
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.
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 Plan a WSUS design for optimized performance.
Intelligent Transfer Service
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. On Windows
Server 2016, WSUS requires Microsoft Report Viewer Runtime 2012
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 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.
3. Enterprise devices running Windows 10, version 1709 or version 1803, cannot install any Features on
Demand directly from WSUS. To install Features on Demand, create a feature file (side-by-side store) or
obtain the Feature on Demand package from one of the following sources:
Volume Licensing Service Center (VLSC ) - VL access is required
OEM Portal - OEM access is required
MSDN Download - MSDN subscription is required
Individually-obtained Feature on Demand packages can be installed using DISM command-line
options.
WSUS database requirements
WSUS requires one of the following databases:
Windows Internal Database (WID )
Microsoft SQL Server 2017
Microsoft SQL Server 2008 R2
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
that have a hierarchy of five levels deep have been tested by Microsoft.
Also, downstream servers must be at the same version or an earlier version of WSUS as the upstream server synchronization
source.
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 SQL 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 2008 .
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.
1. 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 deploying 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.
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.
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 Use the WSUS Configuration wizard to perform the base
Wizard 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
https://download.microsoft.com
http://*.download.windowsupdate.com
http://wustat.windows.com
http://ntservicepack.microsoft.com
http://go.microsoft.com
http://dl.delivery.mp.microsoft.com
https://dl.delivery.mp.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, 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 SUS 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:
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
custom-signed 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.
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
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 null

Microsoft Products Support Lifecycle.
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.
Windows operating systems that are still within their 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.
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. Non-
administrative 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.

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.
Windows operating systems that are still within their 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.
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.

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.

NOTE
if the "No auto-restart with logged on users for scheduled automatic updates installations" policy setting is enabled, this
policy has no effect.
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.

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
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.

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).
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.

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.
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.

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.
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

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 Microsoft 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 Microsoft Store to stop working.
starting with Windows Server 2012 R2 , Windows 8.1 or null

Windows RT 8.1, Windows operating systems that are still
within their Microsoft Products Support Lifecycle.
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.
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.

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.

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

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.

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

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.
starting with Windows Vista and Windows Server 2008 ( null

Windows 7 ), Windows operating systems that are still within
their Microsoft Products Support Lifecycle.
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.

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.

NOTE
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.

Re-prompt for restart with scheduled installations
Specifies the amount of time for Automatic Updates to wait before prompting again with a scheduled restart.

IMPORTANT
NOTE
This policy has no effect on computers running Windows RT.

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.

NOTE
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.
Windows operating systems that are still within their 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
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.
starting with Windows Vista, Windows operating systems that null

are still within their Microsoft Products Support Lifecycle.
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.

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.
starting with Windows Server 2008 (Windows Vista) and null

Windows 7 , Windows operating systems that are still within
their Microsoft Products Support Lifecycle.
NOTE
By default, this policy setting is disabled.
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.

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.

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.

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.

NOTE
By default, when enabled, the regular maintenance random delay is set to PT4H.
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.

NOTE
if the operating computer's power-wake policy is explicitly disabled, this setting has no effect.
NOTE
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.

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.

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.

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.
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.

Remove access to use all Windows Update features
This setting enables you to remove WSUS client access to Windows Update.

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 https://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.
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.
To create a new Group Policy object and open for editing:
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.
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.
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 starting in Windows Server 2012 , the WSUS server role is
versions 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 In Windows Server 2008 (and earlier versions of Windows
Server) with WSUS 3.2 and earlier 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
- Microsoft 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
- Microsoft 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 Microsoft 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
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:
Managing WSUS Client computers and WSUS computer Groups
Updates Operations
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.

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.
NOTE
The synchronization is initiated by the downstream server.
Managing WSUS Client computers and WSUS
computer Groups
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.
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
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
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 non-

critical, non-security related bugs.
Icons used for updates in Windows Server Update Services

Updates in WSUS are represented by one of the following icons.
To view these icons, you have to enable the Supersedence column in the Update Services console.
No Icon
The update has no supersedence relationship with any other update.
Operational Concerns:
There are no operational concerns.
Superseding Icon
This update supersedes other updates.
There are no operational concerns.
Superseded & Superseding Icon
This update is superseded by another update, and supersedes other updates.
Replace these updates with the superseding updates when possible.
Superseded Icon
This update is superseded by another update.
Replace these updates with the superseding updates when possible.
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
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
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
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
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 deadline-
installed. 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.
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
WARNING
In a WSUS hierarchy, it is strongly recommended that you run the cleanup process on the lower-most,
downstream/replica WSUS server first, and then move up the hierarchy. Incorrectly running cleanup on any
upstream server prior to running cleanup on every downstream server can cause a mismatch between the data that
is present in upstream databases and downstream databases. The data mismatch can lead to synchronization
failures between the upstream and downstream servers.
IMPORTANT
If you remove unnecessary content by using the Server Cleanup Wizard, all the private update files that you have
downloaded from the Microsoft Update Catalog site are also removed. You must reimport these files after you run
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."
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
Windows Server 2012
This topic 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

This message is generated in the WSUS console when a WSUS client computer does not send information to the
WSUS server to indicate its current update state. This issue is typically caused by the WSUS client computer, not
the WSUS server.
The most common reasons are:
The computer has lost connectivity to the network:
The network cable is unplugged.
An intervening network cable is faulty.
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 turned off. (It has been shut down or is in sleep or hibernation mode.)
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

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.
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.
Express update delivery ISV support
Applies To: Windows 10, Windows Server 2016
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
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.0-
kb3195781-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.
Monthly Delta update ISV support without WSUS
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows 10
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 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 is available for servicing of Windows 10, version 1607 (Anniversary Update), version 1703 (Creators
Update), and version 1709 (Fall Creators Update). For releases after version 1709, 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 Single update with all new fixes for that
that month month and all previous months
Application Can only be applied if the previous Can be applied at any time
month’s update was applied
(Cumulative or Delta)
Delivery Published only to Windows Update Published to Windows Update (where all
Catalog where it can be downloaded consumer PCs will install it), WSUS, and
for use with other tools or processes. the Windows Update Catalog
Not offered to PCs that are connected
to Windows Update
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 remove-
package 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 is available for servicing of Windows 10, version 1607 (Anniversary Update), version 1703 (Creators
Update), and version 1709 (Fall Creators Update). For releases after version 1709, you will need to implement a
deployment infrastructure that supports Express update delivery to continue taking advantage of incremental updates.
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.
Migrating the WSUS database

Stop the IIS and WSUS services on the WSUS server
From PowerShell (elevated), run:
Stop-Service IISADMIN
Stop-Service WsusService
Detach SUSDB from the Windows Internal Database

Using SQL Management Studio
1. Right-click SUSDB -> Tasks -> click Detach:
2. Check Drop Existing Connections and click OK (optional, if active connections exist).
Using Command Prompt
IMPORTANT
These steps show how 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.
1. Open an elevated command prompt
2. Run the following SQL command to detach the WSUS database (SUSDB) from the Windows Internal Database instance by
using the sqlcmd utility:
sqlcmd -S \\.\pipe\Microsoft##WID\tsql\query
use master
GO
alter database SUSDB set single_user with rollback immediate
GO
sp_detach_db SUSDB
GO
Copy the SUSDB files to the SQL Server

1. Copy SUSDB.mdf and SUSDB_log.ldf from the WID Data Folder (%SystemDrive%*Windows\WID\Data*)
to the SQL Instance Data Folder.
TIP
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
Attach SUSDB to the SQL Instance

1. In SQL Server Management Studio, under the Instance node, right-click Databases, and then click Attach.
2. 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.
TIP
This is also able to be done using Transact-Sql. Please see the SQL documentation for attaching a database for its
instructions.
Example (using paths from previous example):
USE master;
GO
CREATE DATABASE SUSDB
ON
(FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data\SUSDB.mdf'),
(FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log\SUSDB_Log.ldf')
FOR ATTACH;
GO
Verify SQL Server and Database Logins and Permissions

SQL Server Login Permissions
After attaching the SUSDB, verify that NT AUTHORITY\NETWORK SERVICE has login permissions to the
instance of SQL Server by doing the following:
1. Go into SQL Server Management Studio
2. Opening the Instance
3. Click Security
4. 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.
IMPORTANT
If the SQL Instance is on a different machine from WSUS, the WSUS Server's computer account should be listed in the format
[FQDN]\[WSUSComputerName]$. If not, the steps below can be used to add it, replacing NT AUTHORITY\NETWORK
SERVICE with the WSUS Server's computer account ([FQDN]\[WSUSComputerName]$) This would be in addition to
granting rights to NT AUTHORITY\NETWORK SERVICE
A d d i n g N T A U T H O R I T Y \ N E T W O R K SE R V I C E a n d g r a n t i n g i t r i g h t s
1. Right Click Logins and click New Login…
2. On the General page, fill out the Login name (NT AUTHORITY\NETWORK SERVICE ), and set the Default
database to SUSDB.
3. On the Server Roles page, ensure public and sysadmin are selected.
4. On the User Mapping page:
Under Users mapped to this login: select SUSDB
Under Database role membership for: SUSDB, ensure the following are checked:
public
webService
5. Click OK
You should now see NT AUTHORITY\NETWORK SERVICE under Logins.
Database Permissions
1. Right-click the SUSDB
2. Select Properties
3. Click Permissions
The NT AUTHORITY\NETWORK SERVICE account should be listed.
1. If it is not, add the account.
2. On the Login name textbox, enter the WSUS machine in the following format: > [FQDN ]\
[WSUSComputerName]$
3. Verify that the Default database is set to SUSDB.
TIP
In the following example, the FQDN is Contosto.com and the WSUS machine name is WsusMachine:
4. On the User Mapping page, select the SUSDB Database under "Users mapped to this login"
5. Check webservice under the "Database role membership for: SUSDB":
6. Click OK to save settings. > [!NOTE ] > You may need to restart the SQL Service for the changes to take effect.
Edit the registry to point WSUS to the SQL Server Instance
IMPORTANT
Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you
modify it, back up the registry for restoration in case problems occur.
1. Click Start, click Run, type regedit, and then click OK.
2. Locate the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\UpdateServices\Server\Setup\SqlServerName
3. In the Value text box, type [ServerName]\[InstanceName], and then click OK. If the instance name is the
default instance, type [ServerName].
4. Locate the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update
Services\Server\Setup\Installed Role Services\UpdateServices-WidDatabase
5. 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.
Start the IIS and WSUS services on the WSUS server

From PowerShell (elevated), run:
Start-Service IISADMIN
Start-Service WsusService
NOTE
If you are using the WSUS Console, close and restart it.
Uninstalling the WID role (not recommended)

WARNING
Removing the WID role also removes a database folder (%SystemDrive%\Program Files\Update Services\Database) that
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.
Using PowerShell:
Uninstall-WindowsFeature -Name 'Windows-Internal-Database'
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
System Insights overview
System Insights is a new predictive analytics feature in Windows Server 2019. The System Insights predictive
capabilities - each backed by a machine-learning model - locally analyze Windows Server system data, such as
performance counters and events, providing insight into the functioning of your servers and helping you reduce
the operational expenses associated with reactively managing issues in your deployments.
In Windows Server 2019, System Insights ships with four default capabilities focused on capacity forecasting,
predicting future resource for compute, networking, and storage based on your previous usage patterns. System
Insights also ships with an extensible infrastructure, so Microsoft and 3rd parties can add new predictive
capabilities to System Insights without updating the operating system.
You can manage System Insights through an intuitive Windows Admin Center extension or directly through
PowerShell, and System Insights allows you to configure each predictive capability separately according to the
needs of your deployment. All prediction results are published to the event log, which allows you to use Azure
Monitor or System Center Operations Manager to easily aggregate and see predictions across a group of
machines.
Local functionality
System Insights runs completely locally on Windows Server. Using new functionality introduced in Windows
Server 2019, all of your data is collected, persisted, and analyzed directly on your machine, allowing you to realize
predictive analytics capabilities without any cloud-connectivity.
Your system data is stored on your machine, and this data is analyzed by predictive capabilities that don't require
retraining in the cloud. With System Insights, you can retain your data on your machine and still benefit from
predictive analytics capabilities.
Get started
https://www.youtube-nocookie.com/embed/AJxQkx5WSaA
TIP
Watch these short videos to learn the information you need to get started and confidently manage System Insights: Getting
started with System Insights in 10 minutes
Requirements
System Insights is available on any Windows Server 2019 instance. It runs on both host and guest machines, on
any hypervisor, and in any cloud.
Install System Insights
IMPORTANT
System Insights collects and stores up to a year's worth of data locally. If you would like to retain your data when upgrading
your operating system, make sure you use In-Place Upgrade.
Install the feature

You can install System Insights using the extension within Windows Admin Center:
You can also install System Insights directly through Server Manager by adding the System -Insights feature, or
by using PowerShell:
Add-WindowsFeature System-Insights -IncludeManagementTools
Provide feedback
We'd love to hear your feedback to help us improve this feature. You can use the following channels to submit
feedback:
Feedback Hub: Use the Feedback Hub tool in Windows 10 to file a bug or feedback. When doing so, please
specify:
Category: Server
Subcategory: System Insights
UserVoice: Submit feature requests through our UserVoice page. Share with your colleagues to upvote items
that are important to you.
Email: If you'd like to submit your feedback privately to the feature team, send an email to system-insights-
feed@microsoft.com. Please keep in mind that we still may request you to use Feedback Hub or UserVoice.
See also
To learn more about System Insights, use the following resources:
System Insights FAQ
This topic defines the concept of capabilities in System Insights and introduces the default capabilities available in
Windows Server 2019.
This topic also describes the data sources, prediction timelines, and prediction statuses used for the default
capabilities.
Capability overview
A System Insights capability is a machine learning or statistics model that analyzes system data to help give you
increased insight into the functioning of your deployment. System Insights introduces an initial set of default
capabilities, and it allows you to add new capabilities dynamically, without needing to update the operating
system.
NOTE
Detailed documentation explaining how to create, add, and update capabilities is available here, and the managing
capabilities document provides more high-level information about this functionality.
Additionally, each capability runs locally on a Windows Server instance, and each capability can be managed
individually.
Capability outputs
When a capability is invoked, it provides an output to help explain the result of its analysis or prediction. Each
output must contain a Status and a Status Description to describe the prediction, and each result can optionally
contain capability-specific data associated with the prediction. The Status Description helps provides a
contextual explaination for the Status, and the capability reports either an OK, Warning, or Critical status.
Additionally, a capability can use an Error or None status if no prediction was made. Together, here are the
capability statuses and their basic meanings:
Ok - Everything looks good.
Warning - No immediate attention required, but you should take a look.
Critical - You should take a look soon.
Error - An unknown problem caused the capability to fail.
None - No prediction was made. This could be due to a lack of data or any other capability-specific reason for
not making a prediction.
Additionally, any capability-specific data contained in the result will be placed in a user-accessible JSON file, and
the file path can be found using PowerShell.
Default capabilities
In Windows Server 2019, System Insights introduces four default capabilities focused on capacity forecasting:
CPU capacity forecasting - Forecasts CPU usage.
Networking capacity forecasting - Forecasts network usage for each network adapter.
Total storage consumption forecasting - Forecasts total storage consumption across all local drives.
Volume consumption forecasting - Forecasts storage consumption for each volume.
Each capability analyzes past historical data to predict future usage, and all of the forecasting capabilities are
designed to forecast long-term trends rather than short-term behavior, helping administrators correctly
provision hardware and tune their workloads to avoid future resource contention. Because these capabilities focus
on long-term usage, these capabilities analyze daily data.
Forecasting model
The default capabilities use a forecasting model to predict future usage, and for each prediction, the model is
trained locally on your machine's data. This model is designed to help detect longer term trends, and retraining on
each Windows Server instance enables the capability to adapt to the specific behavior and nuances of each
machine's usage.
NOTE
Determining what type of model to use required testing many models using a dataset containing tens of thousands of
machines. After analyzing and tweaking these models, we decided to use an auto-regressive forecasting model, as it
produces highly-accurate and visually intuitive predictions while not requiring too much time to train. This model, however,
requires three weeks of training data, so each capability uses a basic linear trend until three weeks of data are available.
Forecasting timelines
The default capabilities forecast a certain number of days into the future based on the number of days for which
data has been collected. The following table shows the prediction timelines of these capabilities:
INPUT DATA SIZE FORECAST LENGTH
0-5 days No prediction is made.
6-180 days 1/3 * size of input data
180-365 days 60 days
Forecasting data
Each capability analyzes daily data to forecast future usage. CPU, networking, and even storage usage, however,
can frequently change throughout the day, dynamically adjusting to the workloads on the machine. Because usage
isn't constant throughout the day, it's important to properly represent daily usage in a single data point. The table
below details the specific data points and how the data is processed:
CAPABILITY NAME DATA SOURCE(S) FILTERING LOGIC
Volume consumption forecasting Volume size Maximum daily usage
Total storage consumption forecasting Sum of volume sizes, sum of disk sizes Maximum daily usage
CPU capacity forecasting % Processor Time Maximum 2-hour average per day
Networking capacity forecasting Bytes Total/sec Maximum 2-hour average per day
When evaluating the filtering logic above, it’s important to note that each capability seeks to inform
administrators when future usage will meaningfully exceed the available capacity – even though CPU
momentarily hit 100% utilization, CPU usage may not have caused meaningful performance degradation or
resource contention. For CPU and networking, then, there should be sustained high usage rather than momentary
spikes. Averaging CPU and networking usage throughout the whole day, however, would lose important usage
information, as a few hours of high CPU or networking usage could meaningfully impact the performance of your
critical workloads. The maximum 2-hour average during each day avoids these extremes and still produces
meaningful data for each capability to analyze.
For volume and total storage usage, however, storage usage can't exceed the available capacity, even momentarily,
so the maximum daily usage is used for these capabilities.
Forecasting statuses
All System Insights capabilities must output a status associated with each prediction. Each default capability uses
the following logic to define each prediction status:
OK: The forecast does not exceed the available capacity.
Warning: The forecast exceeds the available capacity in the next 30 days.
Critical: The forecast exceeds the available capacity in the next 7 days.
Error: The capability ran into an unexpected error.
None: There isn’t enough data to make a prediction. This could be due to a lack of data or because no data has
been reported recently.
NOTE
If a capability forecasts on multiple instances - such as multiple volumes or network adapters - the status reflects the most
severe status across all instances. Individual statuses for each volume or network adapter are visible in Windows Admin
Center or within the data contained in the output of each capability. For instructions on how to parse the JSON output of
the default capabilities, visit this blog.
See also
System Insights FAQ
In Windows Server 2019, System Insights exposes a variety of settings that can be configured for each capability,
and these settings can be tuned to address the specific needs of your deployment. This topic describes how to
manage the various settings for each capability through Windows Admin Center or PowerShell, providing basic
PowerShell examples and Windows Admin Center screenshots to demonstrate how to adjust these settings.
TIP
You can also use these short videos to help you get started and confidently manage System Insights: Getting started with
System Insights in 10 minutes
Though this section provides PowerShell examples, you can use the System Insights PowerShell documentation
to see all of the cmdlets, parameters, and parameter sets within System Insights.
Viewing capabilities
To get started, you can list all of the available capabilities using the Get-InsightsCapability cmdlet:
Get-InsightsCapability
These capabilities are also visible in System Insights extension:
Enabling and disabling a capability

Each capability can be enabled or disabled. Disabling a capability prevents that capability from being invoked, and
for non-default capabilities, disabling a capability stops all data collection for that capability. By default, all
capabilities are enabled, and you can check the state of a capability using the Get-InsightsCapability cmdlet.
To enable or disable a capability, use the Enable-InsightsCapability and the Disable-InsightsCapability
cmdlets:
Enable-InsightsCapability -Name "CPU capacity forecasting"

Disable-InsightsCapability -Name "Networking capacity forecasting"
These settings can also be toggled by selected a capability in Windows Admin Center clicking the Enable or
Disable buttons.
Invoking a capability
Invoking a capability immediately runs the capability to retrieve a prediction, and administrators can invoke a
capability any time by clicking the Invoke button in Windows Admin Center or by using the Invoke-
InsightsCapability cmdlet:
Invoke-InsightsCapability -Name "CPU capacity forecasting"
TIP
To make sure invoking a capability doesn't conflict with critical operations on your machine, consider scheduling predictions
during off-business hours.
Retrieving capability results

Once a capability has been invoked, the most recent results are visible using Get-InsightsCapability or Get-
InsightsCapabilityResult. These cmdlets output the most recent Status and Status Description of each
capability, which describe the result of each prediction. The Status and Status Description fields are further
described in the understanding capabilities document.
Additionally, you can use the Get-InsightsCapabilityResult cmdlet to view the last 30 prediction results and to
retrieve the data associated with the prediction:
# Specify the History parameter to see the last 30 prediction results.

Get-InsightsCapabilityResult -Name "CPU capacity forecasting" -History
# Use the Output field to locate and then show the results of "CPU capacity forecasting."
# Specify the encoding as UTF8, so that Get-Content correctly parses non-English characters.
$Output = Get-Content (Get-InsightsCapabilityResult -Name "CPU capacity forecasting").Output -Encoding UTF8 |
ConvertFrom-Json
$Output.ForecastingResults
The System Insights extension automatically shows the prediction history and parses the results of the JSON
result, giving you an intuitive, high-fidelity graph of each forecast:
Using the event log to retrieve capability results
System Insights logs an event each time a capability finishes a prediction. These events are visible in the
Microsoft-Windows-System -Insights/Admin channel, and System Insights publishes a different event ID for
each status:
PREDICTION STATUS EVENT ID
Ok 151
Warning 148
Critical 150
Error 149
None 132
TIP
Use Azure Monitor or System Center Operations Manager to aggregate these events and see prediction results across a
group of machines.
Setting a capability schedule

In addition to on-demand predictions, you can configure periodic predictions for each capability so that the
specified capability is automatically invoked on a predefined schedule. Use the Get-InsightsCapabilitySchedule
cmdlet to see capability schedules:
TIP
Use the pipeline operator in PowerShell to see information for all capabilities returned by the Get-InsightsCapability
cmdlet.
Get-InsightsCapability | Get-InsightsCapabilitySchedule
Periodic predictions are enabled by default though they can be disabled at any time using the Enable-
InsightsCapabilitySchedule and Disable-InsightsCapabilitySchedule cmdlets:
Enable-InsightsCapabilitySchedule -Name "Total storage consumption forecasting"

Disable-InsightsCapabilitySchedule -Name "Volume consumption forecasting"
Each default capability is scheduled to run every day at 3am. You can, however, create custom schedules for each
capability, and System Insights supports a variety of schedule types, which can be configured using the Set-
InsightsCapabilitySchedule cmdlet:
Set-InsightsCapabilitySchedule -Name "CPU capacity forecasting" -Daily -DaysInterval 2 -At 4:00PM

Set-InsightsCapabilitySchedule -Name "Networking capacity forecasting" -Daily -DaysOfWeek Saturday, Sunday -
At 2:30AM
Set-InsightsCapabilitySchedule -Name "Total storage consumption forecasting" -Hourly -HoursInterval 2 -
DaysOfWeek Monday, Wednesday, Friday
Set-InsightsCapabilitySchedule -Name "Volume consumption forecasting" -Minute -MinutesInterval 30
NOTE
Because the default capabilities analyze daily data, it's recommended to use daily schedules for these capabilities. Learn more
about the default capabilities here.
You can also use Windows Admin Center to view and set schedules for each capability by clicking Settings. The
current schedule is shown on the Schedule tab, and you can use the GUI tools to create a new schedule:
Creating remediation actions

System Insights enables you to kick off custom remediation scripts based on the result of a capability. For each
capability, you can configure a custom PowerShell script for each prediction status, allowing administrators to
take corrective action automatically, rather than requiring manual intervention.
Sample remediation actions include running disk cleanup, extending a volume, running deduplication, live
migrating VMs, and setting up Azure File Sync.
You can see the actions for each capability using the Get-InsightsCapabilityAction cmdlet:
Get-InsightsCapability | Get-InsightsCapabilityAction
You can create new actions or delete existing actions using the Set-InsightsCapabilityAction and Remove-
InsightsCapabilityAction cmdlets. Each action is run using credentials that are specified in the
ActionCredential parameter.
NOTE
In the initial System Insights release, you must specify remediation scripts outside of user directories. This will be fixed in an
upcoming release.
$Cred = Get-Credential
Set-InsightsCapabilityAction -Name "CPU capacity forecasting" -Type Warning -Action
"C:\Users\Public\WarningScript.ps1" -ActionCredential $Cred
Set-InsightsCapabilityAction -Name "CPU capacity forecasting" -Type Critical -Action
"C:\Users\Public\CriticalScript.ps1" -ActionCredential $Cred
Remove-InsightsCapabilityAction -Name "CPU capacity forecasting" -Type Warning
You can also use Windows Admin Center to set remediation actions by using the Actions tab within the Settings
page:
See also
System Insights FAQ
Adding and developing new capabilities
System Insights enables you to add new predictive capabilities to System Insights, without requiring any OS
updates. This enables developers, including Microsoft and third parties, to create and deliver new capabilities
mid-release to address the scenarios you care about.
Any new capability can integrate with and extend the existing System Insights infrastructure:
New capabilities can specify any performance counter or system event, which will be collected, persisted
locally, and returned to the capability for analysis when the capability is invoked.
New capabilities can leverage the existing Windows Admin Center and PowerShell management
planes. Not only will new capabilities be discoverable in System Insights, they also benefit from custom
schedules and remediation actions.
Manage new capabilities

Learn how to add, remove, and update capabilities using PowerShell.
Develop a capability
Use the following resources to help you get started writing your own custom capabilities:
Learn about the data sources you can collect.
Download the System Insights NuGet package, which contains the classes and interfaces you need to write a
capability.
Visit the API documentation to learn about the System Insights classes and interfaces.
Use the System Insights sample capability to help you get started. This shows you how to register a capability,
specify the data sources to collect, and start analyzing system data.
NOTE
This is prerelease functionality. It's subject to change, as we add new functionality and incorporate feedback.
See also
System Insights FAQ
System Insights enables you to create new capabilities that leverage the existing data collection and management
functionality. Once these capabilities are created, however, it's equally important that you also have the platform
support to manage the addition, removal, and updates of these capabilities.
This topic describes the high-level functionality to add, remove, and update capabilities in System Insights.
Adding a capability
System Insights allows you to add new capabilities anytime using the Add-InsightsCapability cmdlet. The Add-
InsightsCapability requires you to specify a capability name and the capability library. The capability library
contains the capability description, data sources, and prediction logic.
Add-InsightsCapability -Name "Sample capability" -Library "C:\SampleCapability.dll"
After a capability has been added to System Insights, you can immediately invoke and manage the capability using
PowerShell or Windows Admin Center.
Updating a capability
System Insights also enables you to update a capability using the Update-InsightsCapability cmdlet.
Update-InsightsCapability -Name "Sample capability" -Library "C:\SampleCapabilityv2.dll"
Updating a capability allows you to specify a new capability library, which allows you to change the capability
description, the data sources, and the prediction logic associated with that capability. Importantly, updating a
capability preserves all configuration and historical information about that capability, including custom schedules,
actions, and historical prediction results.
Removing a capability
You can also remove capabilities in System Insights using the Remove-InsightsCapability cmdlet.
Remove-InsightsCapability -Name "Sample capability"
NOTE
The default forecasting capabilities can't be removed.
Removing a capability permanently deletes the capability and all associated information, including the schedule,
any remediation actions, and past prediction results.
TIP
Consider disabling a capability rather than removing it if you are worried about permanently deleting all information
associated with the capability.
See also
System Insights FAQ
System Insights data sources
System Insights introduces extensible data collection functionality. When writing a new capability, you can specify
existing or new data sources to collect locally and analyze. This topic describes the data sources that you can
choose when registering a new capability.
Data sources
When writing a new capability, you must identify the specific data sources to collect for each capability. The data
sources that you specify will be collected and persisted directly on your machine, and you can choose from three
types of data sources:
Performance counters:
Specify the counter path, name, and instances, and System Insights collects the relevant data reported by
these performance counters.
System events:
Specify the channel name and event ID, and System Insights will record how many times that event has
occurred.
Well-known series
System Insights collects some basic information on your machine for a few, well-defined resources.
These series are used for the default capabilities, but they can also be used by any custom capability.
These collect the following information:
Disk:
Properties: Guid
Data: Size
Volume:
Properties: UniqueId, DriveLetter, FileSystemLabel, Size
Data: Used Size
Network Adapter:
Properties: InterfaceGuid, InterfaceDescription, Speed
Data: Bytes Received/sec, Bytes Sent/sec, Bytes Total/sec
CPU:
Properties: -
Data: % Processor Time
Specify a well-known series, and System Insights will return the data collected by that series.
Retention timelines and collection intervals

The data sources above have different retention timelines and collection intervals. The table below reveals how
long and how often each data source is collected:
DATA SOURCE RETENTION TIMELINE COLLECTION INTERVAL
Performance counters 3 months 15 minutes
System events 3 months 15 minutes
Well-known series 1 year 1 hour
Aggregation types
Because each series record only one data point for each collection interval, each series has an aggregation type
assocated it. The table below describes the data source and the corresponding aggregation type:
NOTE
For performance counters, you can choose from a few different aggregation types.
DATA SOURCE AGGREGATION TYPES
Performance counters Sum, average, max, min
System events Count
Disk well-known series Last (latest value in the collection interval)
Volume well-known series Last (latest value in the collection interval)
CPU well-known series Average
Network well-known series Average
Data footprint
System Insights collects all data locally on your C drive (C:). In general, the System Insights data footprint is
modest. It depends directly on the type and number of data sources each capability specifies, and the table below
details the storage usage for each data type:
DATA SOURCE MAXIMUM FOOTPRINT
Performance counters 240 KB
System events 200 KB
Disk well-known series 200 KB per disk
Volume well-known series 300 KB per volume
CPU well-known series 100 KB
Network well-known series 300 KB per network adapter

NOTE
For the default forecasting capabilities, the maximum footprint should be less than 10 MB for most stand alone
machines.
See also
System Insights FAQ
System Insights FAQ
How can you use System Insights with Azure Monitor or System
Center Operations Manager?
Azure Monitor and System Center Operations Manager provide operational information across your
deployments to help you manage your infrastructure. System Insights, in contrast, is a Windows Server feature
that introduces local predictive analytics capabilities. Together, System Insights and Azure Monitor or SCOM can
help surface the predictions across a population of devices:
Azure Monitor or SCOM can key off the events created by System Insights, as System Insights outputs the result
of each prediction to the event log. They can surface these machine-specific predictions across a fleet of Windows
Servers, enabling you to have a unified view of these predictions across a group of server instances.
See the channel and event IDs for each prediction here.
How does System Insights relate to Windows ML?

Windows ML is a platform that enables developers to import and score pre-trained machine learning models on
Windows devices. These models benefit from hardware acceleration, and they can be scored locally.
System Insights is a feature in Windows Server 2019 that offers local predictive capabilities together with a
complete management experience, including PowerShell and Windows Admin Center integration.
Can I use System Insights for my cluster?

Yes. System Insights can independently run on each individual failover cluster node, and the default behavior of
System Insights forecasts usage across local storage, volume, CPU, and networking. You can also enable
forecasting for clustered storage, so the storage forecasting capabilities predict usage for clustered volumes
and storage.
You can manage these settings in Windows Admin Center or PowerShell, and more detailed information about
this functionality is available here.
How expensive is it to run the default capabilities?

Each default capability is inexpensive to run. Each capability will take longer to run as you collect more data, but
they typically should complete in a just a few seconds.
See also
Get started with Setup and Boot Event Collection
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:
Set-Item -Force WSMan:\localhost\Client\TrustedHosts "<target1>,<target2>,..." , followed by
Set-Item -Force WSMan:\localhost\Client\AllowUnencrypted true where <target1>, etc. are the names
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 <target_name> 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 <a.b.c.d> 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 <target_name> 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, <mac value="11:22:33:44:55:66"/> or
<mac value="11-22-33-44-55-66"/>) or SMBIOS GUID (for example, <guid value="{269076F9-4B77-46E1-B03B-
CA5003775B88}"/>) 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
Enable-SbecAutoLogger -Path C:\NanoServer\Workloads\IncludingWorkloads.vhd . This adds a basic list of
the most typical setup and boot events; you can research others at Controlling Event Tracing Sessions.
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 - This can happen if

option is not you misspell the
recognized in this feature name. Verify
context 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 /get-
features | ?{$_ -
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 Same as above

unknown.
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: <collector
configVersionMajor="1" minlog="verbose">.
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:
<collector configVersionMajor="1" minlog="debug"
log="c:\ProgramData\Microsoft\BootEventCollector\Logs\log.txt">
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
$result = (Get-Content .\newconfig.xml | Set-SbecActiveConfig); $result , then the variable $result will contain
information about the deployment. You can query this variable to get different information out of it:
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

Target computer Target is not - The target computer

connecting to the didn't get restarted
Collector 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/EVENT-
NET 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 Verify that the IP

events after migrating address of the
the VM my collector is collector computer
hosted on. has not changed. If it
has, review "To enable
sending of ETW
events through the
transport remotely."
Collector The ETL files are not Get- The target computer
created. SbecForwarding has probably not sent
shows that the target any data yet; ETL files
has connected, with are only created when
no errors, but the ETL data is received.
files are not created.
Collector An event is not The target computer - The event could still
showing in the ETL has sent an event but be in the buffer.
file. when the ETL file is Events aren't written
read with Event to the ETL file until a
Viewer of Message full 64 KB buffer is
Analyzer, the event is collected or a timeout
not present. 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.
Get Started with Software Inventory Logging
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2019, 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.
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 Cmdlets in Windows PowerShell
Microsoft Assessment and Planning Toolkit Volume Activation Management Tool
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2019, 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-inventory-
logging.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

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 Start-
SilLogging, 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
Get-SilData 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 Get-
SilSoftware.
Output Example
PS C:\> Get-SilData
ID : 961FF8A1-8549-4BEC-8DF6-3B3E32C26FFA
UUID : B49ACB4C-7D9C-4806-9917-AE750BB3DA84
VMGUID : E84CCCBD-0D0F-486B-A424-9780C7CF92E4
Name : Server01Guest.Test.Contoso.com
HypervisorHostName : Server01.Test.Contoso.com
ID : {F0C3E5D1-1ADE-321E-8167-68EF0DE699A5}
Name : Microsoft Visual C++ 2010 x86 Redistributable - 10.0.40219
InstallDate : 12/5/2013
Publisher : Microsoft Corporation
Version : 10.0.40219
ID : {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00}
Name : Microsoft Silverlight
InstallDate : 3/20/2014
Publisher : Microsoft Corporation
Version : 5.1.30214.0
ChassisSerialNumber : 4452-0564-0284-2290-0113-6804-05
CollectedDateTime : 10/27/2014 4:01:33 PM
Model : Virtual Machine
Name : Server01Guest.Test.Contoso.com
NumberOfCores : 1
NumberOfLogicalProcessors : 1
NumberOfProcessors : 1
OSName : Microsoft Windows Server 2012 R2 Datacenter
OSSku : 8
OSSuite : 400
OSSuiteMask : 400
OSVersion : 6.3.9600
ProcessorFamily : 179
ProcessorManufacturer : GenuineIntel
ProcessorName : Intel(R) Xeon(R) CPU E5440 @ 2.83GHz
SystemManufacturer : 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, Stop-

SilLogging
Specifies target aggregation TargetUri string Set-SilLogging -TargetURI

point on the network
Specifies Certificate CertificateThumbprint string Set-SilLogging -

Thumbprint or Hash of the CertificateThumbprint
certificate used for SSL
authentication for the target
web server
Specifies the date and time CollectionTime Default: 2000-01- Set-SilLogging -TimeOfDay
that the feature should start 01T03:00:00
(if value set is in the future
according to local system
time)
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, Get-
SilComputerIdentity, 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 Cmdlets in Windows PowerShell
Import-BinaryMiLog
Export-BinaryMiLog
Applies To: 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 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)
NOTE
When using the Windows Management Framework, there is a known compatibility issue with WMF release 5.1, on the SIL
Aggregator only. It is not necessary to exceed WMF version 4.0 on servers with SIL Aggregator installed.
Software Inventory Logging (SIL ) exists in Windows Server versions with the following updates installed:
Windows Server 2016, or higher
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 (Set-
SilAggregator, 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 Publish-SilReport under the SIL
Aggregator Cmdlet Details section.
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 Stop-SilAggregator . When the prompt returns, SIL
Aggregator has stopped.
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 <\server\path to share

which holds your pfx certificate file> -credential $mycreds
Copy-Item ${firstAvailableDriveLetter}:\ <certificatename.pfx file in directory of new drive> c:

<location of your choice>
Remove-PSDrive –Name $firstAvailableDriveLetter
$mypwd = ConvertTo-SecureString -String " " -Force –AsPlainText
Import-PfxCertificate -FilePath c:\ <location\certificatename.pfx>

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
high-water 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 high-
water 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.
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.
COLUMN HEADER DESCRIPTION
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.
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".
SIL AGGREGATOR HYPERVISORTYPE

HYPERVISOR VERSION SIL AGGREGATOR HOSTTYPE VALUE 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.
When using the Windows Management Framework in your environment:
Be sure the server(s) with SILA installed do not have WMF 5.1 installed. It is possible to hit an error in
the event log regarding the DLL 'mpunits.dll'. This will prevent proper operation. SILA only requires
WMF 4.0.
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 –AddCertificateThumbprint cmdlet to add the new
thumbprint the SIL Aggregator.
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 Set-SilLogging –CertificateThumbprint cmdlet to update to the
thumbprint of the new certificate.
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
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.
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 non-
Microsoft 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 Internet-
accessible 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 real- Up to three years of data can be saved. Important:
time. 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 UAL enables a single view of ongoing usage data. Server and
to retrieve client request data on a local or remote server. 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.
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
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
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.
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.
Get-UalSystemId 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.
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 : 1
FirstSeen : 6/23/2012 5:06:50 AM
IPAddress : 10.36.206.112
LastSeen : 6/23/2012 5:06:50 AM
ProductName : Windows Server 2012 Datacenter
RoleGuid : 10a9226f-50ee-49d8-a393-9a501d47ce04
RoleName : File Server
TenantIdentifier : 00000000-0000-0000-0000-000000000000
PSComputerName
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
3. Add the registry value:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WMI\AutoLogger\Sum\PollingInt
erval (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
Performance Tuning Guidelines for Windows Server
2016
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
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 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.
Windows Server 2012, Windows 10, Windows 8
This user guide for Microsoft Server Performance Advisor (SPA) provides guidelines about how to use SPA to
identify performance bottlenecks in systems deployed in various server roles.
SPA can help you with the following things:
Manage your server performance and troubleshoot server performance issues.
Provide data reports and recommendations about common configuration and performance issues.
Provide best pratice recommendations based on the data collected.
NOTE
The SPA Console does not make any changes to the servers.
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 does 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
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 uses this account to write logs to the folder. The SPA console uses 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\LocalAccountTokenFilte
rPolicy.
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 is 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 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 is 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 creates a database and
generates 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 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 does 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 is 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
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 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 does 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 finds and highlights 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 is listed in
the Warning area. Otherwise, the results are 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 side-
by-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 are 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 exports 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 displays 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 is enabled. Click the
Provision button.
4. When provisioning is complete, the Installed version field for the selected advisor pack contains 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 is 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
is 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 has 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 are 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 is only be applied to reports that are generated after the changes.
Existing reports are 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 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 is not to 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 shows 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 overwrites all the SQL scripts that are related to the advisor pack and reset all the default thresholds
values. This keeps 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
removes 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 automatically fills 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 uses 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 execute the scripts
automatically. Otherwise, it opens 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 PARAMETERS DESCRIPTION

CMDLET NAME PARAMETERS DESCRIPTION
Start-SpaAnalysis -ServerName Name of the target Starts a SPA data collection session on
server. 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 runs 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 Attempts to stop a running SPA

Server instance. session. If a session is already complete,
-SqlDatabaseName Name of the SPA it returns without doing anything.
project database.
-ServerName Name of the target
server.
Get-SpaServer -SqlInstanceName Name of the SQL Gets the server list in the database. It
Server instance. returns a list of objects, including these
-SqlDatabaseName Name of the SPA properties: Name, Status, FileShare, and
project database. Remark.
Get-SpaAdvisorPacks -SqlInstanceName Name of the SQL Gets the advisor pack list in the
Server instance database. It returns a list of objects,
-SqlDatabaseName Name of the SPA including these properties: Name,
project database 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 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 only logs 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 attempts to delete those
temporary log files when the data import completes, there is no guarantee that those log files are 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 do
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 fails. 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 are 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 does 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 can 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 is 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
Windows Server 2012, Windows 8, Windows 10
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 ).
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 user-
specified 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-9647-
2261c00e86ef]
"Description"=
FriendlyName = Power Source Optimized
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes\db310065-829b-4671-9647-
2261c00e86ef \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...\PowerSchem 1 db310065-829b-4671-9647-
es 2261c00e86ef
\db310065-829b-4671-9647- 2
2261c00e86ef\Description
\db310065-829b-4671-9647- 2 Power Source Optimized

2261c00e86ef\FriendlyName
...\6738e2c4-e8a5-4a42-b16a- 4 180
e040e769756e\ACSettingIndex
...\6738e2c4-e8a5-4a42-b16a- 4 30
e040e769756e\DCSettingIndex
The schema for the #registryKeys table is a 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_PageFileUsage Win32_PageFileUsage 1

.Name=
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
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
#WmiObjectProperties table schema
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
#WmiQueries table schema
Id Int NOT NULL >Unique query ID
query Nvarchar(4000) NOT NULL Original query string in the provision

metadata
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:
INSTANCE VALUE OF INSTANCE VALUE OF 0

TIMESTAMP CATEGORYNAME COUNTERNAME _TOTAL C: D:
13:45:52.630 PhysicalDisk Avg. Disk sec/Transfer 0.001000083624739 0.001000083624739

95 95

87 87

48 48

224 224
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
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
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%...\applicatio C:\Windows C:\Windows applicationHost.confi 0x3C3F78

nHost.config ...\applicationHost.con ...\config
fig
#Files table schema
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:
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>
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:
ADVISORYPACKA REPORTSTATUSI LASTUPDATETIM THRESHOLDVERS

ID SESSIONID GEID D E IONID
12 17 1 2 2011-05-11 1
05:35:24.387
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
PASCAL CASING CAMEL CASING UPPERCASE
Names in Parameter names Use for all SQL reserved keywords

ProvisionMetadata.xml Local variables
Stored procedures
Functions
View names
Temporary table names
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
DATA TYPE SUPPORT DYNAMIC DATA CAN BE REFERENCED
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 that you CANNOT do any of the following:
Change the schema name
Change the data type of any single value group or the columns of a list value table
Add or remove thresholds
Add or remove rules
Add or remove advice
Add or remove single values
Add or remove list values
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
Performance counter Perfcounter: Perfcounter: Process/% Processor time

<CategoryName>/<InstanceName>
registry registry: <registerKey> registry: HKLM\SOFTWARE\Microsoft

\ASP.NET\Rootver
Configuration file ConfigFile: <Filepath>[; Xpath: ConfigFile:

<Xpath>] windir%\System32\inetsrv\config\applic
Note ationHost.config
Xpath is optional and it is valid only Xpath:
when the file is an xml file. configuration&frasl;system.webServer
&frasl;httpProtocol&frasl;@allowKeepAl
ive
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
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
Usertime BigInt NOT NULL User time
#EventProperties table schema
SequenceID Int NOT NULL Correlation sequence ID
Name Nvarchar(100) Property name
Value Nvarchar(4000) Value
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 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
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.
Windows Commands
All supported versions of Windows (server and client) have a set of Win32 console commands built in.
This set of documentation describes the Windows Commands you can use to automate tasks by using scripts or
scripting tools.
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 PDF applies to:
Windows Server 2019
Windows Server (Semi-Annual Channel)
Windows Server 2016
Windows Server 2012
Windows Server 2008
Windows 10
Windows 8.1
Command shell overview
The Command shell was the first shell built into Windows to automate routine tasks, like user account
management or nightly backups, with batch (.bat) files. With Windows Script Host you could 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.
Windows has two command shells: The Command shell and PowerShell. Each shell is a software program that
provides direct communication between you and the operating system or application, providing an environment to
automate IT operations.
PowerShell was designed to extend the capabilities of the Command shell to run PowerShell commands called
cmdlets. Cmdlets are similar to Windows Commands but provide a more extensible scripting language. You can
run Windows Commands and PowerShell cmdlets in Powershell, but the Command shell can only run Windows
Commands and not PowerShell cmdlets.
For the most robust, up-to-date Windows automation, we recommend using PowerShell instead of Windows
Commands or Windows Script Host for Windows automation.
NOTE
You can also download and install PowerShell Core, the open source version of PowerShell.
Cau t i on
Incorrectly editing the registry may severely damage your system. Before making the following changes to the
registry, you should back up any valued data on the computer.
NOTE
To enable or disable file and directory name completion in the Command shell 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.
Command-line reference A-Z

To find information about a specific Windows 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)
A
append
arp
assoc
at
atmadm
attrib
auditpol
autochk
autoconv
autofmt
B
bcdboot
bcdedit
bdehdcfg
bitsadmin
bitsadmin addfile
bitsadmin addfileset
bitsadmin addfilewithranges
bitsadmin cancel
bitsadmin complete
bitsadmin create
bitsadmin getaclflags
bitsadmin getbytestotal
bitsadmin getbytestransferred
bitsadmin getcompletiontime
bitsadmin getcreationtime
bitsadmin getdescription
bitsadmin getdisplayname
bitsadmin geterror
bitsadmin geterrorcount
bitsadmin getfilestotal
bitsadmin getfilestransferred
bitsadmin getminretrydelay
bitsadmin getmodificationtime
bitsadmin getnoprogresstimeout
bitsadmin getnotifycmdline
bitsadmin getnotifyflags
bitsadmin getnotifyinterface
bitsadmin getowner
bitsadmin get priority
bitsadmin getproxybypasslist
bitsadmin getproxylist
bitsadmin getproxyusage
bitsadmin getreplydata
bitsadmin getreplyfilename
bitsadmin getreplyprogress
bitsadmin getstate
bitsadmin gettype
bitsadmin help
bitsadmin info
bitsadmin list
bitsadmin listfiles
bitsadmin monitor
bitsadmin nowrap
bitsadmin rawreturn
bitsadmin removecredentials
bitsadmin replaceremoteprefix
bitsadmin reset
bitsadmin resume
bitsadmin setaclflag
bitsadmin setcredentials
bitsadmin setdescription
bitsadmin setdisplayname
bitsadmin setminretrydelay
bitsadmin setnoprogresstimeout
bitsadmin setnotifycmdline
bitsadmin setnotifyflags
bitsadmin setpriority
bitsadmin setproxysettings
bitsadmin setreplyfilename
bitsadmin suspend
bitsadmin takeownership
bitsadmin Transfer
bitsadmin util
bitsadmin wrap
bootcfg
bootcfg addsw
bootcfg copy
bootcfg dbg1394
bootcfg debug
bootcfg default
bootcfg delete
bootcfg ems
bootcfg query
bootcfg raw
bootcfg rmsw
bootcfg timeout
break
C
cacls
call
cd
certreq
certutil
change
change logon
change port
change user
chcp
chdir
chglogon
chgport
chgusr
chkdsk
chkntfs
choice
cipher
clip
cls
Cmd
cmdkey
cmstp
color
comp
compact
convert
copy
cprofile
cscript
D
date
dcgpofix
defrag
del
dfsrmig
diantz
dir
diskcomp
diskcopy
diskpart
diskperf
diskraid
diskshadow
dispdiag
dnscmd
doskey
driverquery
E
echo
edit
endlocal
erase
eventcreate
eventquery
eventtriggers
evntcmd
exit
expand
extract
F
fc
find
findstr
finger
flattemp
fondue
for
forfiles
format
freedisk
fsutil
fsutil 8dot3name
fsutil behavior
fsutil file
fsutil fsinfo
fsutil hardlink
fsutil objectid
fsutil quota
fsutil repair
fsutil reparsepoint
fsutil resource
fsutil sparse
fsutil tiering
fsutil transaction
fsutil usn
fsutil volume
fsutil wim
ftp
ftype
fveupdate
G
getmac
gettype
goto
gpfixup
gpresult
gpupdate
graftabl
H
help
helpctr
hostname
I
icacls
if
inuse
ipconfig
ipxroute
irftp
J
jetpack
K
klist
ksetup
ksetup:setrealm
ksetup:mapuser
ksetup:addkdc
ksetup:delkdc
ksetup:addkpasswd
ksetup:delkpasswd
ksetup:server
ksetup:setcomputerpassword
ksetup:removerealm
ksetup:domain
ksetup:changepassword
ksetup:listrealmflags
ksetup:setrealmflags
ksetup:addrealmflags
ksetup:delrealmflags
ksetup:dumpstate
ksetup:addhosttorealmmap
ksetup:delhosttorealmmap
ksetup:setenctypeattr
ksetup:getenctypeattr
ksetup:addenctypeattr
ksetup:delenctypeattr
ktmutil
ktpass
L
label
lodctr
logman
logman create
logman query
logman start &124; stop
logman delete
logman update
logman import &124; export
logoff
lpq
lpr
M
macfile
makecab
manage-bde
manage-bde: status
manage-bde: on
manage-bde: off
manage-bde: pause
manage-bde: resume
manage-bde: lock
manage-bde: unlock
manage-bde: autounlock
manage-bde: protectors
manage-bde: tpm
manage-bde: setidentifier
manage-bde: ForceRecovery
manage-bde: changepassword
manage-bde: changepin
manage-bde: changekey
manage-bde: KeyPackage
manage-bde: upgrade
manage-bde: WipeFreeSpace
mapadmin
Md
mkdir
mklink
mmc
mode
more
mount
mountvol
move
mqbkup
mqsvc
mqtgsvc
msdt
msg
msiexec
msinfo32
mstsc
N
nbtstat
netcfg
netsh
netstat
Net print
nfsadmin
nfsshare
nfsstat
nlbmgr
nslookup
nslookup exit command
nslookup finger command
nslookup help
nslookup ls
nslookup lserver
nslookup root
nslookup server
nslookup set
nslookup set all
nslookup set class
nslookup set d2
nslookup set debug
nslookup set domain
nslookup set port
nslookup set querytype
nslookup set recurse
nslookup set retry
nslookup set root
nslookup set search
nslookup set srchlist
nslookup set timeout
nslookup set type
nslookup set vc
nslookup view
ntbackup
ntcmdprompt
ntfrsutl
O
openfiles
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
Q
qappsrv
qprocess
query
quser
qwinsta
R
rcp
rd
rdpsign
recover
reg
reg add
reg compare
reg copy
reg delete
reg export
reg import
reg load
reg query
reg restore
reg save
reg unload
regini
regsvr32
relog
rem
ren
rename
repair-bde
replace
reset session
rexec
risetup
rmdir
robocopy
route_ws2008
rpcinfo
rpcping
rsh
rundll32
rwinsta
S
schtasks
scwcmd
scwcmd: analyze
scwcmd: configure
scwcmd: register
scwcmd: rollback
scwcmd: transform
scwcmd: view
secedit
secedit:analyze
secedit:configure
secedit:export
secedit:generaterollback
secedit:import
secedit:validate
serverceipoptin
Servermanagercmd
serverweroptin
set
setlocal
setx
sfc
shadow
shift
showmount
shutdown
sort
start
subst
sxstrace
sysocmgr
systeminfo
T
takeown
tapicfg
taskkill
tasklist
tcmsetup
telnet
tftp
time
timeout
title
tlntadmn
tpmvscmgr
tracerpt
tracert
tree
tscon
tsdiscon
tsecimp
tskill
tsprof
type
typeperf
tzutil
U
unlodctr
V
ver
verifier
verify
vol
vssadmin-
W
waitfor
wbadmin
wbadmin enable backup
wbadmin disable backup
wbadmin start backup
wbadmin stop job
wbadmin get versions
wbadmin get items
wbadmin start recovery
wbadmin get status
wbadmin get disks
wbadmin start systemstaterecovery
wbadmin start systemstatebackup
wbadmin delete systemstatebackup
wbadmin start sysrecovery
wbadmin restore catalog
wbadmin delete catalog
wdsutil
wecutil
wevtutil
where
whoami
winnt
winnt32
winpop
winrs
wlbs
wmic
wscript
X
xcopy

Windows Admin Center

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Windows Admin Center

Diunggah oleh

Hak Cipta:

Format Tersedia

Contents

INS TALL & R U N W IND O W S R U N S ER V ER MANAG ER O N R U N S ER V ER MANAG ER IN

Sitting at a Windows Server X X X

Sitting at a Windows Server X (install on Windows 10, use to X

Sitting far away from my X X

Sitting far away from my X Use RDS to remote into the X

Manage Windows Server systems and environments

Manage on-premises systems with Server Manager

Manage updates to Windows Server systems

Gather information about your environment

Setup and Boot Event Collection

Software Inventory Logging (SIL)

User Access Logging (UAL)

Tune your Windows Server environment for performance

Performance tuning guidelines

Microsoft Server Performance Advisor

Automate Windows Server management

Automate Windows Server management

Applies To: Windows Admin Center, Windows Admin Center Preview

Download the PDF

Use Connect to Azure

Read our Blogs

What is Hybrid Cloud Print?

Active Directory Provides and controls user identity and authorization

Azure AD Connect Synchronizes user credentials between Azure AD and on-

MDM Service (Intune) Provides device policy provisioning functionality to ensure

Azure AD Proxy Provides a long-lived connection that is established from

There are two ways to install Hybrid Cloud Print:

Install-Module -Name PublishCloudPrinter

Applies To: Windows Server 2016

2. Install the Hybrid Cloud Print solution

5. Copy the SQLite dlls to the MopriaCloudService Webapp <bin> folder

7. Create the SQLite database:

INTUNE DISPLAY NAME POLICY

Printer discovery URL CloudPrinterDiscoveryEndpoint

Printer access authority URL CloudPrintOAuthAuthority

Azure native client app GUID CloudPrintOAuthClientId

Print service resource URI CloudPrintResourceId

Maximum printers to query(Mobile only) DiscoveryMaxPrinterLimit

Printer discovery service resource URI MopriaDiscoveryResourceId

DiscoveryEndpoint = External URL of the Mopria Discovery Service Azure Application

Verifying the deployment

Applies To: Windows Server 2016

2. Install the Hybrid Cloud Print solution

5. Copy the SQLite dlls to the MopriaCloudService Webapp <bin> folder

7. Create the SQLite database:

Step 3 - Install Azure Application Proxy (AAP) with Passthrough Authentication

Step 4 - Configure the required MDM policies

INTUNE DISPLAY NAME POLICY

Printer discovery URL CloudPrinterDiscoveryEndpoint

Printer access authority URL CloudPrintOAuthAuthority

Azure native client app GUID CloudPrintOAuthClientId

Print service resource URI CloudPrintResourceId

Maximum printers to query(Mobile only) DiscoveryMaxPrinterLimit

Printer discovery service resource URI MopriaDiscoveryResourceId

Verifing the deployment

Server (Core) vs Server with Desktop Experience

The Server Core difference - core capabilities without the frills

APPLICATION SERVER CORE SERVER WITH DESKTOP EXPERIENCE

Command prompt available available

Windows PowerShell/ Microsoft .NET available available

Perfmon.exe not available available

Windbg (GUI) supported supported

Resmon.exe not available available