Академический Документы
Профессиональный Документы
Культура Документы
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.
Sitting at a Windows 10 PC X X
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 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 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
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
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
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
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
Applies to
Windows Server 2016
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
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.
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.
NOTE: It is recommended to download and install the latest version by leaving out the "-
requiredversion" option.
\\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.**Core**.x.x.x.x\\build\\net46\\x64\\SQLite.Interop.dll
--\> \<bin\>\\**x64**\\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" />
<bindingRedirect oldVersion="0.0.0.0-x.x.x.x" newVersion="x.x.x.x" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Data.SQLite.EF6" 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.Linq" culture="neutral" publicKeyToken="db937bc2d44ff139" />
<bindingRedirect oldVersion="0.0.0.0-x.x.x.x" newVersion="x.x.x.x" />
</dependentAssembly>
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
prompted to approve request.
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.
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
Value = External URL of the Mopria Discovery Service Azure Application Proxy created in Step 3.4
(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
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.
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)
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>
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
3/12/2019 • 9 minutes to read • Edit Online
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
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.
NOTE: It is recommended to download and install the latest version by leaving out the "-
requiredversion" option.
\\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.**Core**.x.x.x.x\\build\\net46\\x64\\SQLite.Interop.dll
--\> \<bin\>\\**x64**\\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" />
<bindingRedirect oldVersion="0.0.0.0-x.x.x.x" newVersion="x.x.x.x" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Data.SQLite.EF6" 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.Linq" culture="neutral" publicKeyToken="db937bc2d44ff139" />
<bindingRedirect oldVersion="0.0.0.0-x.x.x.x" newVersion="x.x.x.x" />
</dependentAssembly>
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.
Note: If you are using Microsoft Intune service, you can find these settings under the "Cloud Printer" category.
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
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
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.
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>
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?
3/12/2019 • 3 minutes to read • Edit Online
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.
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
Applies to: Windows Server (Semi-Annual Channel) and Windows Server 2016
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.
Hyper-V Hyper-V N
Routing Routing N
Tracing Web-Http-Tracing N
Performance Web-Performance N
Security Web-Security N
ASP Web-ASP N
CGI Web-CGI N
BranchCache BranchCache N
Containers Containers N
AD DS Tools RSAT-ADDS N
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.
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:
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 ):
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:
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 group to the local computer net localgroup <group name> /add
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.
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).
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>"
Enable remote administration of the firewall netsh advfirewall firewall set rule group=”Windows
Firewall Remote Management” new enable=yes
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
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
Manage volume mount points For a complete list of commands, run mountvol /?
Convert a volume to the NTFS file system convert <volume letter> /FS:NTFS
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
3/12/2019 • 5 minutes to read • Edit Online
Applies to: Windows Server (Semi-Annual Channel) and Windows Server 2016
Where rulegroup is one of the following, depending on which snap-in you want to connect:
Task Scheduler Performance Logs and Alerts, File and Printer Sharing
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.
This enables the Remote Desktop for Administration mode to accept connections.
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 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
3/12/2019 • 5 minutes to read • Edit Online
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.
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.
The default destination for DebugFilePath is %systemroot%\memory.dmp. To change the current destination
path, run the following command:
Set <FilePath> to the destination path. For example, the following command sets the memory dump destination
path to C:\WINDOWS\MEMORY.DMP:
To change the current memory dump type, run the following command:
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
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:
The possible values for SendAdminAlert are TRUE or FALSE. To modify the existing SendAdminAlert value to true,
run the following command:
wmic.exe pagefile
or
For example, run the following command to configure the initial and maximum sizes of your page file:
To determine if the feature has been enabled properly, run the following command:
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
5/2/2019 • 2 minutes to read • Edit Online
Applies to: Windows Server (Semi-Annual Channel) and Windows Server 2016
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.
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.
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:
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
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.
NOTE
This command also works in a command prompt that has been opened with elevated user rights (Run as
Administrator).
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 .
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
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.
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.
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.
NOTE
Manage As (or alternate) credentials for servers in your server pool are not stored in the roaming profile. Server
Manager users must add them on each computer from which they want to manage.
The network share roaming profile is not created until a user logs on to the network, and then logs off for the first time.
The Serverlist.xml file is created at this time.
You can export Server Manager settings, make Server Manager settings portable, or use them on other
computers in one of the following two ways.
To export settings to another domain-joined computer, configure the Server Manager user to have a
roaming profile in active directory Users and computers. You must be a Domain Administrator to change
user properties in active directory Users and computers.
To export settings to another computer in a workgroup, copy the preceding two files to the same location
on the computer from which you want to manage by using Server Manager.
To export Server Manager settings to other domain-joined computers
1. In active directory Users and computers, open the Properties dialog box for a Server Manager user.
2. On the Profile tab, add a path to a network share to store the user's profile.
3. Do one of the following.
On U.S. English (en-us) builds, changes to the Serverlist.xml file are automatically saved to the
profile. Go on to the next step.
On other builds, copy the following two files from the computer that is running Server Manager to
the network share that is part of the user's roaming profile.
%appdata%\Microsoft\Windows\ServerManager\Serverlist.xml
%localappdata%\Microsoft_Corporation\ServerManager.exe_StrongName_GUID\6.2.0.0\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.
%appdata%\Microsoft\Windows\ServerManager\Serverlist.xml
%localappdata%\Microsoft_Corporation\ServerManager.exe_StrongName_GUID\6.2.0.0\user.confi
g
Manage the Local Server and the Server Manager
Console
3/12/2019 • 14 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
In Windows Server, Server Manager lets you manage both the local server (if you are running Server Manager on
Windows Server, and not on a Windows-based client operating system) and remote servers that are running
Windows Server 2008 and newer releases of the Windows Server operating system.
The Local Server page in Server Manager displays server properties, events, service and performance counter
data, and Best Practices Analyzer (BPA) results for the local server. Event, service, BPA, and performance tiles
function as they do on role and server group pages. For more information about configuring the data that is
displayed in these tiles, see View and Configure Performance, Event, and Service Data and Run Best Practices
Analyzer Scans and Manage Scan Results.
Menu commands and settings in the Server Manager console heading bars apply globally to all servers in your
server pool, and let you use Server Manager to manage the entire server pool.
This topic contains the following sections.
Shut down the local server
Configure Server Manager properties
Manage the Server Manager console
Customize tools that are displayed in the Tools menu
Manage roles on role home pages
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.
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 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.
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.
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.
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.
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.
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.
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
5/24/2019 • 10 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
In Windows Server, you can use Server Manager to perform management tasks on remote servers. remote
management is enabled by default on servers that are running Windows Server 2016. To manage a server
remotely by using Server Manager, you add the server to the Server Manager server pool.
You can use Server Manager to manage remote servers that are running older releases of Windows Server, but
the following updates are required to fully manage these older operating systems.
To manage servers that are running Windows Server releases older than Windows Server 2016, install the
following software and updates to make the older releases of Windows Server manageable by using Server
Manager in Windows Server 2016.
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.
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.
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.
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
3/12/2019 • 11 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
In Windows Server you can manage multiple remote servers by using a single Server Manager console. Servers
that you want to manage by using Server Manager can be running Windows Server 2016, Windows Server
2012 R2, Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008. Note that you cannot
manage a newer release of Windows Server with an older release of Server Manager.
This topic describes how to add servers to the Server Manager server pool.
NOTE
In our tests, Server Manager in Windows Server 2012 and later releases of Windows Server can be used to manage up to
100 servers that are configured with a typical workload. The number of servers that you can manage by using a single
Server Manager console can vary depending on the amount of data that you request from managed servers, and
hardware and network resources available to the computer running Server Manager. As the amount of data you want to
display approaches that computer's resource capacity, you can experience slow responses from Server Manager, and delays
in the completion of refreshes. To help increase the number of servers that you can manage by using Server Manager, we
recommend limiting the event data that Server Manager gets from your managed servers, by using settings in the
Configure Event Data dialog box. Configure Event Data can be opened from the Tasks menu in the Events tile. If you
need to manage an enterprise-level number of servers in your organization, we recommend evaluating products in the
Microsoft System Center suite.
Server Manager can receive only online or offline status from servers that are running Windows Server 2003. Although you
can use Server Manager to perform management tasks on servers that are running Windows Server 2008 R2 or Windows
Server 2008 , you cannot add roles and features to servers that are running Windows Server 2008 R2 , Windows Server
2008 or Windows Server 2003.
Server Manager cannot be used to manage a newer release of the Windows Server operating system. Server Manager
running on Windows Server 2012 R2, Windows Server 2012, Windows 8.1, or Windows 8 cannot be used to manage
servers that are running Windows Server 2016.
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.
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.
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.
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.
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
5/24/2019 • 29 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
In Windows Server, the Server Manager console and Windows PowerShell cmdlets for Server Manager allow
installation of roles and features to local or remote servers, or offline virtual hard disks (VHDs). You can install
multiple roles and features on a single remote server or offline VHD in a single add Roles and Features Wizard or
Windows PowerShell session.
IMPORTANT
Server Manager cannot be used to manage a newer release of the Windows Server operating system. Server Manager
running on Windows Server 2012 R2 or Windows 8.1 cannot be used to install roles, role services, and features on servers
that are running Windows Server 2016.
You must be logged on to a server as an administrator to install or uninstall roles, role services, and features. If you
are logged on to the local computer with an account that does not have administrator rights on your target server,
right-click the target server in the Servers tile, and then click Manage As to provide an account that has
administrator rights. The server on which you want to mount an offline VHD must be added to Server Manager,
and you must have Administrator rights on that server.
For more information about what roles, role services, and features are, see Roles, Role Services, and Features.
This topic contains the following sections.
Install roles, role services, and features by using the add Roles and Features Wizard
Install roles, role services, and features by using Windows PowerShell cmdlets
Remove roles, role services, and features by using the remove Roles and Features Wizard
Remove roles, role services, and features by using Windows PowerShell cmdlets
Install roles and features on multiple servers by running a Windows PowerShell script
Install .NET Framework 3.5 and other features on-demand
Install roles, role services, and features by using the add Roles and
Features Wizard
In a single session in the add Roles and Features Wizard, you can install roles, role services, and features on the
local server, a remote server that has been added to Server Manager, or an offline VHD. For more information
about how to add a server to Server Manager to manage, see Add Servers to Server Manager.
NOTE
If you are running Server Manager on Windows Server 2016 or Windows 10, you can use the add Roles and Features Wizard
to install roles and features only on servers and offline VHDs that are running Windows Server 2016.
To install roles and features by using the add Roles and Features Wizard
1. If Server Manager is already open, go on to the next step. If Server Manager is not already open, open it by
doing one of the following.
On the Windows desktop, start Server Manager by clicking Server Manager in the Windows
taskbar.
On the Windows start screen, click the Server Manager tile.
2. On the Manage menu, click add Roles and Features.
3. On the Before you begin page, verify that your destination server and network environment are prepared
for the role and feature you want to install. Click Next.
4. On the Select installation type page, select Role-based or feature-based installation to install all parts
of roles or features on a single server, or Remote Desktop Services installation to install either a virtual
machine-based desktop infrastructure or a session-based desktop infrastructure for Remote Desktop
Services. The Remote Desktop Services installation option distributes logical parts of the Remote
Desktop Services role across different servers as needed by administrators. Click Next.
5. On the Select destination server page, select a server from the server pool, or select an offline VHD. To
select an offline VHD as your destination server, first select the server on which to mount the VHD, and
then select the VHD file. For information about how to add servers to your server pool, see Add Servers to
Server Manager. After you have selected the destination server, click Next.
NOTE
To install roles and features on offline VHDs, target VHDs must meet the following requirements.
VHDs must be running the release of Windows Server that matches the version of Server Manager you are
running. See the note at the start of Install roles, role services, and features by using the add Roles and Features
Wizard.
VHDs cannot have more than one system volume or partition.
The network shared folder in which the VHD file is stored must grant the following access rights to the
computer (or local system) account of server that you have selected to mount the VHD. User-only account
access is not sufficient. The share can grant Read and Write permissions to the Everyone group to allow
access to the VHD, but for security reasons, this is not recommended.
Read/Write access on the File Sharing dialog box.
Full Control access on the Security tab, file or folder Properties dialog box.
6. Select roles, select role services for the role if applicable, and then click Next to select features.
As you proceed, the add Roles and Features Wizard automatically informs you if conflicts were found on the
destination server that can prevent selected roles or features from installation or normal operation. You are
also prompted to add any roles, role services, or features that are required by the roles or features that you
have selected.
Additionally, if you plan to manage the role remotely, either from another server, or from a Windows 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.
NOTE
If you are installing roles and features on a remote server, you do not need to run Windows PowerShell with elevated
user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows Start screen, right-click the tile for Windows PowerShell, and then on the app bar,
click Run as Administrator.
2. Type Get-WindowsFeature and then press Enter to view a list of available and installed roles and features
on the local server. If the local computer is not a server, or if you want information about a remote server,
run Get-WindowsFeature -computerName <computer_name>, in which computer_name represents the
name of a remote computer that is running Windows Server 2016. The results of the cmdlet contain the
command names of roles and features that you add to your cmdlet in step 4.
NOTE
In Windows PowerShell 3.0 and later releases of Windows PowerShell, there is no need to import the Server Manager
cmdlet module into the Windows PowerShell session before running cmdlets that are part of the module. A module
is automatically imported the first time you run a cmdlet that is part of the module. Also, neither Windows
PowerShell cmdlets nor the feature names used with the cmdlets are case-sensitive.
3. type Get-help Install-WindowsFeature, and then press Enter to view the syntax and accepted
parameters for the Install-WindowsFeature cmdlet.
4. type the following, and then press Enter, where feature_name represents the command name of a role or
feature that you want to install (obtained in step 2), and computer_name represents a remote computer on
which you want to install roles and features. Separate multiple values for feature_name by using commas.
The Restart parameter automatically restarts the destination server if required by the role or feature
installation.
To install roles and features on an offline VHD, add both the computerName parameter and the VHD
parameter. If you do not add the computerName parameter, the cmdlet assumes that the local computer is
mounted to access the VHD. The computerName parameter contains the name of the server on which to
mount the VHD, and the VHD parameter contains the path to the VHD file on the specified server.
NOTE
You must add the computerName parameter if you are running the cmdlet from a computer that is running a
Windows client operating system.
To install roles and features on offline VHDs, target VHDs must meet the following requirements.
VHDs must be running the release of Windows Server that matches the version of Server Manager you are
running. See the note at the start of Install roles, role services, and features by using the add Roles and Features
Wizard.
VHDs cannot have more than one system volume or partition.
The network shared folder in which the VHD file is stored must grant the following access rights to the
computer (or local system) account of server that you have selected to mount the VHD. User-only account
access is not sufficient. The share can grant Read and Write permissions to the Everyone group to allow
access to the VHD, but for security reasons, this is not recommended.
Read/Write access on the File Sharing dialog box.
Full Control access on the Security tab, file or folder Properties dialog box.
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.
5. When installation is finished, verify installation by opening the All Servers page in Server Manager,
selecting a server on which you installed roles and features, and viewing the Roles and Features tile on the
page for the selected server. You can also run the Get-WindowsFeature cmdlet targeted at the selected server
(Get-WindowsFeature -computerName <computer_name>) to view a list of roles and features that are
installed on the server.
Remove roles, role services, and features by using the remove Roles
and Features Wizard
You must be logged on to a server as an administrator to uninstall roles, role services, and features. If you are
logged on to the local computer with an account that does not have administrator rights on your uninstallation
target server, right-click the target server in the Servers tile, and then click Manage As to provide an account that
has administrator rights. The server on which you want to mount an offline VHD must be added to Server
Manager, and you must have Administrator rights on that server.
To remove roles and features by using the remove Roles and Features Wizard
1. If Server Manager is already open, go on to the next step. If Server Manager is not already open, open it by
doing one of the following.
On the Windows desktop, start Server Manager by clicking Server Manager in the Windows
taskbar.
On the Windows Start screen, click the Server Manager tile.
2. On the Manage menu, click Remove Roles and Features.
3. On the Before you begin page, verify that you have prepared for removing roles or features from a server.
Click Next.
4. On the Select Destination Server page, select a server from the server pool, or select an offline VHD. To
select an offline VHD, first select the server on which to mount the VHD, and then select the VHD file.
NOTE
The network shared folder in which the VHD file is stored must grant the following access rights to the computer (or
local system) account of server that you have selected to mount the VHD. User-only account access is not sufficient.
The share can grant Read and Write permissions to the Everyone group to allow access to the VHD, but for
security reasons, this is not recommended.
Read/Write access on the File Sharing dialog box.
Full Control access on the Security tab , file or folder Properties dialog box.
For information about how to add servers to your server pool, see add Servers to Server Manager. After
you have selected the destination server, click Next.
NOTE
You can use the remove Roles and Features Wizard to remove roles and features from servers that are running the
same release of Windows Server that supports the version of Server Manager that you are using. You cannot remove
roles, role services, or features from servers that are running Windows Server 2016, if you are running Server
Manager on Windows Server 2012 R2, Windows Server 2012, or Windows 8. You cannot use the remove Roles and
Features Wizard to remove roles and features from servers that are running Windows Server 2008 or Windows
Server 2008 R2.
5. Select roles, select role services for the role if applicable, and then click Next to select features.
As you proceed, the remove Roles and Features Wizard automatically prompts you to remove any roles,
role services, or features that cannot run without the roles or features that you are removing.
additionally, you can opt to remove management tools and snap-ins for roles on the destination server. By
default, in the remove Roles and Features Wizard, management tools are selected for removal. You can
leave management tools and snap-ins if you plan to use the selected server to manage the role on other
remote servers.
6. On the Confirm removal selections page, review your role, feature, and server selections. If you are ready
to remove the roles or features, click remove.
7. After you click remove, the removal progress page displays removal progress, results, and messages such
as warnings, failures, or post-removal configuration steps that are required, such as restarting the
destination server. In Windows Server 2012 and later releases of Windows Server, you can close the
remove Roles and Features Wizard while removal is still in progress, and view removal results or other
messages in the Notifications area at the top of the Server Manager console. Click the Notifications flag
to see more details about removals or other tasks that you are performing in Server Manager.
NOTE
If you are uninstalling roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
2. Type Get-WindowsFeature and then press Enter to view a list of available and installed roles and features
on the local server. If the local computer is not a server, or if you want information about a remote server,
run Get-WindowsFeature -computerName <computer_name>, in which computer_name represents the
name of a remote computer that is running Windows Server 2016. The results of the cmdlet contain the
command names of roles and features that you add to your cmdlet in step 4.
NOTE
In Windows PowerShell 3.0 and later releases of Windows PowerShell, there is no need to import the Server Manager
cmdlet module into the Windows PowerShell session before running cmdlets that are part of the module. A module
is automatically imported the first time you run a cmdlet that is part of the module. Also, neither Windows
PowerShell cmdlets nor the feature names used with the cmdlets are case-sensitive.
3. type Get-help Uninstall-WindowsFeature, and then press Enter to view the syntax and accepted
parameters for the Uninstall-WindowsFeature cmdlet.
4. Type the following, and then press Enter, where feature_name represents the command name of a role or
feature that you want to remove (obtained in step 2), and computer_name represents a remote computer
from which you want to remove roles and features. Separate multiple values for feature_name by using
commas. The Restart parameter automatically restarts destination servers if required by the role or
feature removal.
To remove roles and features from an offline VHD, add both the computerName parameter and the VHD
parameter. If you do not add the computerName parameter, the cmdlet assumes that the local computer is
mounted to access the VHD. The computerName parameter contains the name of the server on which to
mount the VHD, and the VHD parameter contains the path to the VHD file on the specified server.
NOTE
You must add the computerName parameter if you are running the cmdlet from a computer that is running a
Windows client operating system.
The network shared folder in which the VHD file is stored must grant the following access rights to the computer (or
local system) account of server that you have selected to mount the VHD. User-only account access is not sufficient.
The share can grant Read and Write permissions to the Everyone group to allow access to the VHD, but for
security reasons, this is not recommended.
Read/Write access on the File Sharing dialog box.
Full Control access on the Security tab, file or folder Properties dialog box.
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.
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.
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.
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.
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.
NOTE
if you are installing roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
On a server that is running the Server Core installation option of Windows Server 2012 R2 or
Windows Server 2012 , type PowerShell into a command prompt, and then press Enter.
2. type the following command, and then press Enter. In the following example, the source files are located in
a side-by-side store (abbreviated to as SxS ) in installation media on drive D.
NOTE
if you are installing roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows Start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
On a server that is running the Server Core installation option, type PowerShell into a command
prompt, and then press Enter.
2. Run one of the following DISM commands.
if the computer has access to Windows Update, or a default source file location has already been
configured in Group Policy, run the following command.
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.
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
3/12/2019 • 6 minutes to read • Edit Online
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
This topic contains the following sections.
Create a feature file or side-by-side store
Methods of removing feature files
Remove feature files by using Uninstall-WindowsFeature
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.
IMPORTANT
When you delete feature files for a role, role service, or feature, roles, role services, and features that depend upon the files
you are removing are also deleted. If you are deleting feature files for a role service or subfeature, and no other role services
or subfeatures for the parent role or feature remain installed, then files for the entire parent role or feature are deleted. To
view all feature files that would be deleted by the Uninstall-WindowsFeature -remove command, add the whatif
parameter to the command to run it and view results without actually deleting feature files.
To remove role and feature files by using Uninstall-WindowsFeature
1. Do one of the following to open a Windows PowerShell session with elevated user rights.
NOTE
if you are uninstalling roles and features from a remote server, you do not need to run Windows PowerShell with
elevated user rights.
On the Windows desktop, right-click Windows PowerShell on the taskbar, and then click Run as
Administrator.
On the Windows start screen, right-click the Windows PowerShell tile, and then on the app bar, click
Run as Administrator.
On a server that is running the Server Core installation option, type PowerShell into a command
prompt, and then press Enter.
2. Type the following, and then press Enter.
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.
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.
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
3/12/2019 • 15 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
This topic describes how to view and configure the event log entries, performance counters, and service alerts that
are displayed for local and remote servers in Server Manager.
Event, service, and performance log data is displayed in two places in the Server Manager console in Windows
Server.
On the dashboard, you can click the Events, Performance, and Services rows of thumbnails to configure
event, performance, and service log data that you want to see for roles, the entire Server Manager server
pool, user-created groups of servers, and the local server. Clicking the hypertext rows opens detail View
dialog boxes that let you specify the data about which you want to be alerted in the dashboard. After you
configure event, service, and performance log data that you want to be highlighted in the dashboard
thumbnails, log entries that match the criteria you have specified are listed at the bottom of the detail
View dialog boxes.
Events, Services, and Performance tiles are part of role and group home pages. Commands on the Tasks
menu of these tiles let you specify the data that you want collected from managed servers. The tiles include
filters and queries to further limit the log entries that are displayed in the tile, if desired.
This topic contains the following sections.
What are thumbnails?
View and configure events
View and configure performance counters
Manage services and configure service alerts
View and copy event or performance entries
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.
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.
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.
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.
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.
NOTE
for virtual machines that have Dynamic Memory turned on, increasing the performance alerts threshold can result in
false positive alerts.
7. To refresh the list of performance alerts that are collected from your servers, on the Tasks menu, click
Refresh.
To configure the performance alerts highlighted in thumbnails
1. On the dashboard page, in a thumbnail in the Roles and Server Groups tile, click the Performance row.
2. In the Performance detail View dialog box, select or clear check boxes for resource performance
thresholds about which you want to be alerted in the Resource type field. Note that the number of
performance alerts displayed in the detail View dialog box can increase when you add a resource
performance threshold about which you want to be alerted.
3. if this thumbnail is for a role that is installed on multiple servers, or a group of multiple servers, you can
select the servers for which you want performance alerts in the Servers drop-down list.
4. In the time period field, specify a time period up to 1440 minutes, 24 hours, or 1 day.
5. As you change the criteria for which alerts are displayed, the number of alerts that are displayed in the
results pane at the bottom of the dialog box might change. Click Hide Alerts to hide all alerts older than
the current time, and prevent them from affecting the alert count that is displayed in the source thumbnail.
6. Click Show All to return hidden alerts to the list.
7. Click OK to save your changes, close the detail View dialog box, and view the performance alert changes
in the source thumbnail.
To view the properties of performance alerts
1. Do one of the following.
On the dashboard page, in a thumbnail in the Roles and Server Groups tile, click the Performance
row.
Open a role or group home page, and locate the Performance tile for the role or group.
2. Double-click a performance alert in the list to view its properties. Alternatively, you can right-click a
performance alert, and then click View Properties.
3. In the Performance Alert Properties dialog box, select log entries to view information about the
processes that are associated with the entry in the Processes area.
4. When you are finished viewing performance alert properties, close the dialog box.
Analyze performance data and solve problems
for more information about analyzing performance counter data that you view in Server Manager, and solving
performance problems on managed servers, see the following resources.
Analyzing performance data
Solving performance problems
for more information about advanced performance monitoring and analysis tools that are available for Windows
Server 2012 and later releases of Windows Server, including Server Performance Advisor 3.0, see Performance on
MSDN.
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.
See Also
Server Manager
Filter, sort, and query Data in Server Manager Tiles
View Task details and Notifications
3/12/2019 • 3 minutes to read • Edit Online
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.
See Also
Filter, sort, and query Data in Server Manager Tiles Server Manager Troubleshooting Guide
Run Best Practices Analyzer Scans and Manage Scan
Results
3/12/2019 • 14 minutes to read • Edit Online
In Windows management, best practices are guidelines that are considered the ideal way, under typical
circumstances, to configure a server as defined by experts. For example, it is considered a best practice for most
server applications to keep open only those ports required for the applications to communicate with other
networked computers, and block unused ports. Although best practice violations, even crucial ones, are not
necessarily problematic, they indicate server configurations that can result in poor performance, poor reliability,
unexpected conflicts, increased security risks, or other potential problems.
Best Practices Analyzer (BPA) is a server management tool that is available in Windows Server 2012 R2, Windows
Server 2012, and Windows Server 2008 R2. BPA can help administrators reduce best practice violations by
scanning roles that are installed on managed servers that are running Windows Server 2012 or Windows Server
2008 R2, and reporting best practice violations to the administrator.
You can run Best Practices Analyzer (BPA) scans either from Server Manager, by using the BPA GUI, or by using
cmdlets in Windows PowerShell. starting with Windows Server 2012, you can scan one role or multiple roles at
one time, on multiple servers, whether you use the Best Practices Analyzer tile in the Server Manager console or
Windows PowerShell cmdlets to run scans. You can also instruct BPA to exclude or ignore scan results that you do
not want to see.
This topic contains the following sections.
find BPA
How BPA works
Performing Best Practices Analyzer scans on roles
Manage scan results
find BPA
You can find the Best Practices Analyzer tile on role and server group pages of Server Manager in Windows Server
2012 R2 and Windows Server 2012, or you can open a Windows PowerShell session with elevated user rights to
run Best Practices Analyzer cmdlets.
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
Rule categories
The following table describes the best practice rules categories against which roles are measured during a Best
Practices Analyzer scan.
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.
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>
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.
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}
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.
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.
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
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
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
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
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>
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
3/12/2019 • 2 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
This topic describes how to create custom, user-defined groups of servers in Server Manager in Windows Server.
Server groups
Servers that you add to the server pool are displayed on the All Servers page in Server Manager. You can create
custom groups of servers that you have added. Server groups allow you to view and manage a smaller subset of
your server pool as a logical unit; for example, you can create a group called Accounting Servers for all servers
in your organization's Accounting department, or a group called Chicago for all servers that are geographically
located in Chicago. After you create a server group, the group's home page in Server Manager displays
information about events, services, performance counters, Best Practices Analyzer results, and installed roles and
features for the group as a whole.
Servers can be a member of more than one group.
To create a new server group
1. On the Manage menu, click create Server Group.
2. In the Server group name text box, type a friendly name for your server group, such as Accounting
Servers.
3. add servers to the selected list from the server pool, or add other servers to the group by using the active
directory, DNS, or import tabs. For more information about how to use these tabs, see add Servers to
Server Manager in this guide.
4. When you have finished adding servers to the group, click OK. The new group is displayed in the Server
Manager navigation pane under the All Servers group.
To edit an existing server group
1. Do one of the following.
In the Server Manager navigation pane, right-click a server group, and then click edit Server
Group.
On the home page for the server group, open the Tasks menu on the Servers tile, and then click
edit Server Group.
2. change the group name, or add or remove servers from the group.
NOTE
removing servers from a server group does not remove servers from Server Manager. Servers that you remove from
a group remain in the All Servers group, in the server pool.
3. When you are finished with changes to the group, click OK.
To delete an existing server group
1. Do one of the following.
In the Server Manager navigation pane, right-click a server group, and then click delete Server
Group.
On the home page for the server group, open the Tasks menu on the Servers tile, and then click
delete Server Group.
2. When you are prompted to make sure you want to delete the server group, click Yes.
NOTE
deleting a server group does not remove servers from Server Manager. Servers that were in a deleted group remain
in the All Servers group, in the server pool.
3. When you are finished with changes to the group, click OK.
See Also
add Servers to Server Manager Server Manager
Filter, sort, and query Data in Server Manager Tiles
3/12/2019 • 3 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
In Windows Server, tiles in Server Manager let you filter and sort data, and create and save custom queries. You
can sort, use keyword filters, and run queries on list entries in the Events, Performance, Best Practices Analyzer,
Services, and Roles and Features tiles on server role or group pages in Server Manager.
This topic contains the following sections.
Filter list entries in tiles
sort list entries in tiles
create and run custom queries on tile data
See Also
Server Manager
View and Configure Performance, Event, and Service Data
Keyboard Shortcuts for Server Manager
3/12/2019 • 2 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
Because Server Manager was fully redesigned starting in Windows Server 2012, keyboard shortcuts that worked
in the Server Manager console in Windows Server 2008 R2 or Windows Server 2008 are not necessarily the same
commands. This topic describes the new keyboard shortcuts and access keys for Server Manager in Windows
Server 2012 and newer releases of Windows Server.
Commands that do not have their own keyboard shortcuts or access keys are accessible by pressing the Tab key,
and tabbing through their control group when it is in focus.
Access keys
active Control Area in Server Manager
Welcome Tile
Refresh F5
Role, group, or local server page Best Practices Analyzer (BPA) Alt+B
tile
Role, group, or local server page Roles and Features tile Alt+A
Navigating within Events, Services, BPA, Performance, and Roles and Features tiles
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.
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.
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 appears to succeed, but the tool is still installed
Impact: RSAT FODs on Windows 10 1809 (October 2018 Update)
Resolution: Restarting the PC will complete the removal of the tool.
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
3/12/2019 • 2 minutes to read • Edit Online
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
3/12/2019 • 2 minutes to read • Edit Online
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.
NOTE
Installing OpenSSH Server will create and enable a firewall rule named "OpenSSH-Server-In-TCP". This allows inbound SSH
traffic on port 22.
Name : OpenSSH.Client~~~~0.0.1.0
State : NotPresent
Name : OpenSSH.Server~~~~0.0.1.0
State : NotPresent
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:
A Windows restart may be required after removing OpenSSH, if the service is in use at the time it was uninstalled.
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
Ssh username@servername
The first connection to any server will result in a message similar to the following:
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#
4/23/2019 • 3 minutes to read • Edit Online
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.
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:
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
3/12/2019 • 5 minutes to read • Edit Online
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).”
Since there is no user associated with the sshd service, the host keys are stored under \ProgramData\ssh.
cd ~\.ssh\
ssh-keygen
This should display something like the following (where "username" is replaced by your user name)
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.
Now you have a public/private ED25519 key pair (the .pub files are public keys and the rest are private keys):
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.
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.
# 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
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)
3/12/2019 • 3 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
Windows Server Update Services (WSUS ) enables information technology administrators to deploy the latest
Microsoft product updates. You can use WSUS to fully manage the distribution of updates that are released
through Microsoft Update to computers on your network. This topic provides an overview of this server role and
more information about how to deploy and maintain WSUS.
NOTE
Upgrade from any version of Windows Server that supports WSUS 3.2 to Windows Server 2012 R2 requires that you first
uninstall WSUS 3.2.
In Windows Server 2012, upgrading from any version of Windows Server with WSUS 3.2 installed is blocked during the
installation process if WSUS 3.2 is detected. In that case, you will be prompted to first uninstall Windows Server Update
Services prior to upgrading your server.
However, because of changes in this release of Windows Server and Windows Server 2012 R2, when upgrading from any
version of Windows Server and WSUS 3.2, the installation is not blocked. Failure to uninstall WSUS 3.2 prior to performing a
Windows Server 2012 R2 upgrade will cause the post installation tasks for WSUS in Windows Server 2012 R2 to fail. In this
case, the only known corrective measure is to format the hard drive and reinstall Windows Server.
Windows Server Update Services is a built-in server role that includes the following enhancements:
Can be added and removed by using the Server Manager
Includes Windows PowerShell cmdlets to manage the most important administrative tasks in WSUS
Adds SHA256 hash capability for additional security
Provides client and server separation: versions of the Windows Update Agent (WUA) can ship
independently of WSUS
Using Windows PowerShell to manage WSUS
For system administrators to automate their operations, they need coverage through command-line automation.
The main goal is to facilitate WSUS administration by allowing system administrators to automate their day-to-day
operations.
What value does this change add?
By exposing core WSUS operations through Windows PowerShell, system administrators can increase
productivity, reduce the learning curve for new tools, and reduce errors due to failed expectations resulting from a
lack of consistency across similar operations.
What works differently?
In earlier versions of the Windows Server operating system, there were no Windows PowerShell cmdlets, and
update management automation was challenging. The Windows PowerShell cmdlets for WSUS operations add
flexibility and agility for the system administrator.
In this collection
The following guides for planning, deploying, and managing WSUS are in this collection:
Deploy Windows Server Update Services
Manage Updates using Windows Server Update Services
Deploy Windows Server Update Services
3/12/2019 • 2 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
Windows Server Update Services (WSUS ) enables information technology administrators to deploy the latest
Microsoft product updates. WSUS is a Windows Server server role that can be installed to manage and distribute
updates. A WSUS server can be the update source for other WSUS servers within the organization. The WSUS
server that acts as an update source is called an upstream server.
In a WSUS implementation, at least one WSUS server in the network must connect to Microsoft Update to get
available update information. You can determine, based on network security and configuration, how many other
servers connect directly to Microsoft Update.
This guide provides conceptual information for planning and deploying Windows Server Update Service.
Plan your WSUS deployment
Step 1: Install the WSUS Server Role
Step 2: Configure WSUS
Step 3: Approve and Deploy Updates in WSUS
Step 4: Configure Group Policy Settings for Automatic Updates
Plan your WSUS deployment
5/24/2019 • 29 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
The first step in the deployment of Windows Server Update Services (WSUS ) is to make important decisions, such
as deciding the WSUS deployment scenario, choosing a network topology, and understanding the system
requirements. The following checklist summarizes the steps that are involved in preparing for your deployment.
TASK DESCRIPTION
1.1. Review considerations and system requirements Review the list of considerations and system requirements to
ensure that you have all the necessary hardware and software
to deploy WSUS.
1.2. Choose a WSUS deployment scenario Decide which WSUS deployment scenario will be used.
1.3. Choose a WSUS storage strategy Decide which WSUS storage strategy best fits your
deployment.
1.4. Choose WSUS update languages Decide which WSUS update languages will be installed.
1.5. Plan WSUS computer groups Plan the WSUS computer group approach that you will use for
your deployment.
1.6. Plan WSUS Performance Considerations: Background 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.
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 2016
Microsoft SQL Server 2014
Microsoft SQL Server 2012
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.
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.
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).
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.
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.
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.
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
The next step in the deployment of your WSUS server is to install the WSUS server role. The following procedure
describes how to install the WSUS server role by using Server Manager.
IMPORTANT
This installation procedure only covers how to install WSUS using Windows Internal Database (WID). The procedures to install
WSUS using Microsoft SQL Server are documented in this article.
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.
TIP
You must select one Database type. If the database options are all cleared (not selected), post installation tasks will
fail.
10. On the Content location selection page, type a valid location to store the updates. For example, you can
create a folder named WSUS_database at the root of drive K specifically for this purpose, and type
k:\WSUS_database as the valid location.
11. Click Next. The Web Server Role (IIS ) page opens. Review the information, and then click Next. In select
the role services to install for Web Server (IIS ), retain the defaults, and then click Next.
12. On the Confirm installation selections page, review the selected options, and then click Install. The
WSUS installation wizard runs. This might take several minutes to complete.
13. Once WSUS installation is complete, in the summary window on the Installation progress page, click
Launch Post-Installation tasks. The text changes, requesting: Please wait while your server is
configured. When the task has finished, the text changes to: Configuration successfully completed.
Click Close.
14. In Server Manager, verify if a notification appears to inform you that a restart is required. This can vary
according to the installed server role. If it requires a restart make sure to restart the server to complete the
installation.
IMPORTANT
At this point the installation process is finished, however for WSUS to be functional you need to proceed to Step 2: Configure
WSUS.
Step 2: Configure WSUS
3/12/2019 • 22 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
After installing the WSUS server role on your server, you need to properly configure it. The following checklist
summarises the steps involved in performing the initial configuration for your WSUS server.
TASK DESCRIPTION
2.1. Configure network connections Configure the cluster network by using the Network
Configuration Wizard.
2.2. Configure WSUS by using the WSUS Configuration 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).
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.
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.
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.
IMPORTANT
The following procedures assume that your network runs active directory. These procedures also assume that you are
familiar with Group Policy and you use it to manage the network.
Use the following procedures to configure Automatic Updates for client computers:
Step 4: Configure Group Policy Settings for Automatic Updates
2.3. Configure computer groups in this topic
Configure Automatic Updates in Group Policy
if you have set up active directory in your network, you can configure one or multiple computers simultaneously
by including them in a Group Policy Object (GPO ), and then configuring that GPO with WSUS settings. We
recommend that you create a new GPO that contains only WSUS settings.
Link this WSUS GPO to an active directory container that is appropriate for your environment. In a simple
environment, you might link a single WSUS GPO to the domain. In a more complex environment, you might link
multiple WSUS GPOs to several organizational units (OUs), which will enable you to apply different WSUS policy
settings to different types of computers.
To e n a b l e W SU S t h r o u g h a d o m a i n G P O
1. In the Group Policy Management Console (GPMC ), browse to the GPO on which you want to configure
WSUS, and then click edit.
2. In the GPMC, expand computer Configuration, expand Policies, expand Administrative Templates,
expand Windows components, and then click Windows Update.
3. In the details pane, double-click Configure Automatic Updates. The Configure Automatic Updates
policy opens.
4. Click Enabled, and then select one of the following options under the Configure automatic updating
setting:
Notify for download and notify for install. This option notifies a logged-on administrative user
before you download and install the updates.
Auto download and notify for install. This option automatically begins downloading updates and
then notifies a logged-on administrative user before installing the updates. By default, this option is
selected.
Auto download and schedule the install. This option automatically begins downloading updates
and then installs the updates on the day and time that you specify.
Allow local admin to choose setting. This option lets local administrators to use Automatic
Updates in Control Panel to select a configuration option. For example, they can choose a scheduled
installation time. Local administrators cannot disable Automatic Updates.
5. select Enable client-side targeting, select Enabled, and then type the name of the WSUS computer
group to which you want to add this computer in the Target group name for this computer box.
NOTE
Enable client-side targeting enables client computers to add themselves to target computer groups on the WSUS
server, when Automatic Updates is redirected to a WSUS server. if the status is set to Enabled, this computer will
identify itself as a member of a particular computer group when it sends information to the WSUS server, which uses
it to determine which updates are deployed to this computer. This setting indicates to the WSUS server which group
the client computer will use. You must create the group on the WSUS server, and add domain-member computers to
that group.
6. Click OK to close the Enable client-side targeting policy and return to the Windows Update details pane.
7. Click OK to close the Configure Automatic Updates policy and return to the Windows Update details
pane.
8. In the Windows Update details pane, double-click Specify intranet Microsoft update service
location.
9. Click Enabled, and then, server in the Set the intranet update service for detecting updates and Set
the intranet statistics server text boxes, type the same URL of the WSUS server. For example, type
http://servername in both boxes (where servername is the name of the WSUS server).
WARNING
When you type the intranet address of your WSUS server make sure to specify which port is going to be used. By
default WSUS will use port 8530 for HTTP and 8531 for HTTPS. For example, if you are using HTTP, you should type
http://servername:8530.
1. On the client computer, open a Command prompt window with elevated privileges.
2. type wuauclt.exe /detectnow, and then press ENTER.
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.
Step 3: Approve and Deploy Updates in WSUS
3/12/2019 • 3 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
Computers in a computer group automatically contact the WSUS server over the next 24 hours to obtain updates.
You can use the WSUS reporting feature to determine whether those updates were deployed to the test
computers. When the tests are successfully completed, you can approve the updates for the applicable computer
groups in your organization. The following checklist describes the steps to approve and deploy updates by using
WSUS management console.
TASK DESCRIPTION
3.1. Approve and deploy WSUS updates Approve and deploy WSUS updates by using the WSUS
Management Console.
3.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.
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
In an active directory environment, you can use Group Policy to define how computers and users (referred to in
this document as WSUS clients) can interact with Windows Updates to obtain automatic updates from Windows
Server Update Services (WSUS ).
This topic contains two main sections:
Group Policy settings for WSUS client updates, which provides prescriptive guidance and behavioral details about
the Windows Update and Maintenance Scheduler settings of Group Policy that control how WSUS clients can
interact with Windows Update to obtain automatic updates.
Supplemental information has the following sections:
Accessing the Windows Update settings in Group Policy, which provides general guidance about using
Group Policy Management editor, and information about accessing the Update Services policy extensions
and Maintenance Scheduler settings in Group Policy.
Changes to WSUS relevant to this guide: for administrators familiar with WSUS 3.2 and previous versions,
this section gives a brief summary of key differences between the current and past version of WSUS
relevant to this guide.
Terms and Definitions: definitions for various terms pertaining to WSUS and update services that are used
in this guide.
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.
NOTE
By default, these settings are not configured.
NOTE
if the "Configure Automatic Updates" policy setting is set to Disabled, this policy has no effect.
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.
Windows operating systems that are still within their See details in the table below.
Microsoft Products Support Lifecycle.
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.
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.
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.
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
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 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).
Policy setting state Behavior
Not Configured Specifies that the use of automatic updates is not specified at
the Group Policy level. However, a computer administrator
can still configure automatic updates in the Control Panel.
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.
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.
Policy setting state Behavior
Not Configured Specifies that Install Updates and Shut Down will be the
default option in the Shut Down Windows dialog box if
updates are available for installation at the time the user
selects the Shut Down option to shut down the computer.
Enabled if you enable this policy setting, the user's last shut down
choice (for example, Hibernate or Restart), is the default
option in the Shut Down Windows dialog box, regardless of
whether the Install Updates and Shut Down option is
available in the What do you want the computer to do?
menu.
Disabled Specifies that Install Updates and Shut Down will be the
default option in the Shut Down Windows dialog box if
updates are available for installation at the time the user
selects the Shut Down option to shut down the computer.
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.
Not Configured Specifies that the Install Updates and Shut Down option is
available in the Shut Down Windows dialog box if updates
are available when the user selects the Shut Down option to
shut down the computer. A local administrator can change
this setting by using local policy.
Enabled Specifies that Install Updates and Shut Down will not appear
as a choice in the Shut Down Windows dialog box, even if
updates are available for installation when the user selects the
Shut Down option to shut down the computer.
Disabled Specifies that the Install Updates and Shut Down option will
be the default option in the Shut Down Windows dialog box
if updates are available for installation at the time the user
selects the Shut Down option to shut down the computer.
NOTE
This policy applies only when this computer is configured to support the specified target group names in WSUS. If the target
group name doesn't exist in WSUS, it will be ignored until it is created. If the "Specify intranet Microsoft update service
location" policy setting is disabled or not configured, this policy has no effect.
NOTE
This policy is not supported on Windows RT. Enabling this policy will not have any effect on computers running Windows RT.
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.
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.
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 Automatic Updates will notify the user that the
computer will automatically restart in five minutes to
complete the installation.
Disabled Specifies that Automatic Updates will notify the user that the
computer will automatically restart in five minutes to
complete the installation.
IMPORTANT
This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the
"Configure Automatic Updates" policy setting is disabled, this policy has no effect.
NOTE
This policy has no effect on computers running Windows RT.
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
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 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.
Options: When this policy setting is enabled, you can use it to specify a number of minutes after the computer is
next started, that a scheduled installation that did not take place earlier will occur.
Specify intranet Microsoft update service location
Specifies an intranet server to host updates from Microsoft Update. You can then use WSUS to automatically
update computers on your network.
SUPPORTED ON: EXCLUDING:
Windows operating systems that are still within their Windows RT.
Microsoft Products Support Lifecycle.
This setting enables you to specify a WSUS server on your network that will function as an internal update
service. Instead of using Microsoft Updates on the Internet, WSUS clients will search this service for updates that
apply.
To use this setting, you must set two server name values: the server from which the client detects and downloads
updates, and the server to which updated workstations upload statistics. The values need not be different if both
services are configured on the same server.
NOTE
if the "Configure Automatic Updates" policy setting is disabled, this policy has no effect.
NOTE
This policy is not supported on Windows RT. Enabling this policy will not have any effect on computers running Windows RT.
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.
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:
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.
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.
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.
NOTE
This setting is related to option 4 in Configure Automatic Updates. If you did not select option 4 in Configure Automatic
Updates, it is not necessary to configure this setting.
By default, when enabled, the regular maintenance random delay is set to PT4H.
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 you do not configure this policy setting, the wake-up
setting as specified in the Action Center > Automatic
Maintenance Control Panel will apply.
NOTE
By default, unless otherwise noted, these settings are not configured.
TIP
for each of these settings, you can use the following steps to enable, disable, or navigate between settings:
Do not display 'Install Updates and Shut Down' option in Shut Down Windows dialog box
Specifies whether the Install Updates and Shut Down option is displayed in the Shut Down Windows dialog
box.
SUPPORTED ON: EXCLUDING:
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.
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.
Not Configured Users are able to connect to the Windows Update website.
Supplemental information
This section provides addition information about using opening, and saving WSUS settings in Group Policies, and
definitions for terms used in this guide. For administrators familiar with past versions of WSUS (WSUS 3.2 and
previous versions), there is a table that briefly summarizes differences between WSUS versions.
Accessing the Windows Update settings in Group Policy
The procedure that follows describes how to open the GPMC on your domain controller. The procedure then
describes how to either open an existing domain-level Group Policy Object (GPO ) for editing, or create a new
domain-level GPO and open it for editing.
NOTE
You must be a member of the Domain Admins group or equivalent, to perform this procedure.
To o p e n o r a d d a n d o p e n a G r o u p P o l i c y O b j e c t
1. On your domain controller, go to Server Manager, > Tools, > Group Policy Management. The Group
Policy Management Console opens.
2. In the left pane, expand your forest. For example, double-click forest: example.com.
3. In the left pane, double-click Domains, and then double-click the domain for which you want to manage a
Group Policy object. For example, double-click example.com.
4. Do one of the following:
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
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
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.
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.
internal update service A casual reference to a network infrastructure that uses one
or more WSUS servers to distribute updates.
Software Update Services (SUS) SUS was the predecessor product for Windows Server Update
Services (WSUS).
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.
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.
- Microsoft Update
- Windows Update
- Microsoft Store
- An Internet (network) update service (WSUS)
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
You should check the WSUS administration console home page regularly to view overall update compliance and
network health. Check application logs frequently, if you suspect problems such as download failures or client
computers that are failing to report to the WSUS server. This guide provides information to help you manage
Windows Server Update Services.
In this guide
In this guide, you will find information about:
Setting up Update Synchronizations
Managing WSUS Client computers and WSUS computer Groups
Viewing and Managing Updates
WSUS and the Catalog Site
Updates Operations
The Server cleanup Wizard
Running WSUS Replica mode
WSUS Messages and Troubleshooting Tips
Setting up Update Synchronizations
3/12/2019 • 7 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
During synchronization, a WSUS server downloads updates (update metadata and files) from an update source. It
also downloads new product classifications and categories, if any. When your WSUS server synchronizes for the
first time, it will download all of the updates that you specified when you configured synchronization options. After
the first synchronization, your WSUS server downloads only updates from the update source, as well as revisions
in metadata for existing updates, and expirations to updates.
The first time a WSUS server downloads updates may take a long time. If you are setting up multiple WSUS
servers, you can speed up the process to a certain extent by downloading all the updates on one WSUS server and
then copying the updates to the content directories of the other WSUS servers.
You can copy content from one WSUS server's content directory to another. The location of the content directory
is specified when you run the WSUS post installation procedure. You can use the wsusutil.exe tool to export update
metadata from one WSUS server to a file. You can then import that file into other WSUS servers.
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.
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.
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.
NOTE
The synchronization is initiated by the downstream server.
Managing WSUS Client computers and WSUS
computer Groups
5/24/2019 • 4 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
The computers node is central access point in the WSUS administrative console for managing WSUS client
computers and devices. Under this node you can find the different groups you have set up (plus the default group,
Unassigned computers).
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.
NOTE
If a WSUS server is running in replica mode, computer groups cannot be created on that server. All the computer groups
needed for clients of the replica server must be created on the WSUS server that is the root of the WSUS server hierarchy.
For more information about replica mode, see Running WSUS Replica mode and for more information about server-side and
client-side targeting, see section 1.5. Plan WSUS computer groups of Step 1: Prepare for Your WSUS Deployment in the
WSUS deployment guide.
Viewing and Managing Updates
5/24/2019 • 8 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
You can use the WSUS console to view and manage updates.
Viewing Updates
On the Updates page, you can do the following:
View updates. The update overview displays updates that have been synchronized from the update source
to your WSUS server and are available for approval.
Filter updates. In the default view you can filter updates by approval status and installation status. The
default setting is for unapproved updates that are needed by some clients or that have had installation
failures on some clients. You can change this view by changing the approval status and installation status
filters, and then clicking Refresh.
Create new update views. In the Actions pane, click New Update View. You can filter updates by
classification, product, the group for which they have been approved, and synchronization date. You can sort
the list by clicking the appropriate column heading in the title bar.
Search for updates. You can search for an individual update or set of updates by title, description,
Knowledge Base article, or the Microsoft Security Response Center number for the update.
View details, status, and revision history for each update.
Approve and Decline updates.
To view updates
1. In the WSUS administration console, expand the Updates node, and then click All Updates.
2. By default, updates are displayed with their title, classification, installed/not applicable percentage, and
approval status. If you wish to display more or different update properties, right-click the column heading
bar and select the appropriate columns.
3. To sort by different criteria, such as download status, title, classification, release date, or approval status, click
the appropriate column heading.
To filter the list of updates displayed on the Updates page
1. In the WSUS administration console, expand Updates, and then click All Updates.
2. In the center pane next to Approval, select the desired approval status, and next to Status select the desired
installation status. Click Refresh.
To create a new update view on WSUS
1. In the WSUS administration console, expand Updates, and then click All Updates.
2. In the Actions pane, click New Update View.
3. In the Add Update View window, under Step 1: select properties, select the properties you need to filter
the update view:
Select Updates are in a specific classification to filter on updates belonging to one or more update
classifications.
Select Updates are for a specific product to filter on updates for one or more products or product
families.
Select Updates are approved for a specific group to filter on updates approved for one or more
computer groups.
Select Updates were synchronized within a specific time period to filter on updates synchronized at a
specific time.
Select Updates are WSUS updates to filter on WSUS updates.
4. Under Step 2: edit the properties, click the underlined words to pick the values you want.
5. Under Step 3: Specify a name, give your new view a name.
6. Click OK.
Your new view will appear in the tree view pane under Updates. It will be displayed, like the standard views, in the
center pane when you select it.
To search for an update
1. Select the Updates node (or any node under it).
2. In the Actions pane, click Search.
3. In the Search window, on the Updates tab, enter your search criteria. You can use text from the Title,
Description, and Microsoft Knowledge Base (KB ) article number fields. Each of these items is a
property listed on the details tab in the update properties.
To view the properties for an update
1. In the WSUS administration console, expand Updates, and then click All Updates.
2. In the list of updates, click the update you want to view.
3. In the lower pane, you will see the different property sections:
The title bar displays the title of the update; for example, Security Update for Windows Media Player
9 (KB911565).
The Status section displays the installation status of the update (the computers on which it needs to
be installed, computers on which it was installed with errors, computers on which it has been
installed or is not applicable, and computers that have not reported status for the update), as well as
general information (KB and MSRC numbers release date, etc.).
The Description section displays a brief description of the update.
The additional details section displays the following information:
The installation behavior of the update (whether or not it is removable, requests a restart,
requires user input, or must be installed exclusively).
Whether or not the update has Microsoft Software License Terms
The products to which the update applies
The updates that supersede this update
The updates that are superseded by this update
The languages supported by the update
The update ID
Note that you can perform this procedure on only one update at a time. If you select multiple updates, only the first
update in the list will be displayed in the Properties pane.
Critical Updates Broadly released fixes for specific problems addressing critical,
non-security related bugs.
Feature packs New feature releases, usually rolled into products at the next
release.
Security updates Broadly released fixes for specific products, addressing security
issues.
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
The Catalog Site is the Microsoft location from which you can import hotfixes and hardware drivers.
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.
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
After updates have been synchronized to your WSUS server, they will be scanned automatically for relevance to
the server's client computers. However, you must approve the updates before they are deployed to the computers
on your network. When you approve an update, you are essentially telling WSUS what to do with it (your choices
are Install or Decline for a new update). You can approve updates for the All computers group or for
subgroups. If you do not approve an update, its approval status remains Not approved, and your WSUS server
allows clients to evaluate whether or not they need the update.
If your WSUS server is running in replica mode, you will not be able to approve updates on your WSUS server.
For more information about replica mode, see Running WSUS Replica mode.
Approving Updates
You can approve the installation of updates for all the computers in your WSUS network or for different computer
groups. After approving an update, you can do one (or more) of the following:
Apply this approval to child groups, if any.
Set a deadline for automatic installation. When you select this option, you set specific times and dates to
install updates, overriding any settings on the client computers. In addition, you can specify a past date for
the deadline if you want to approve an update immediately (to be installed the next time client computers
contact the WSUS server).
Remove an installed update if that update supports removal.
There are two IMPORTANT considerations that you should keep in mind:
First, you cannot set a deadline for automatic installation for an update if user input is required (for
example, specifying a setting relevant to the update). To determine whether an update will require user
input, look at the May request user input field in the update properties for an update displayed on the
Updates page. Also check for a message in the Approve Updates box that says, "The selected update
requires user input and does not support an installation deadline."
If there are updates to the WSUS server component, you cannot approve other updates to client systems
until the WSUS update is approved. You will see this warning message in the Approve Updates dialog:
"There are WSUS updates that have not been approved. You should approve the WSUS updates before
approving this update." In this case, you should click the WSUS Updates node and make sure that all of the
updates in that view have been approved before returning to the general updates.
To approve updates
1. In the WSUS administrative console, click Updates and then click All Updates.
2. In the list of updates, select the update that you want to approve and right-click (or go to the Actions pane),
and in the Approve Updates dialog, select the computer group for which you want to approve the update,
and click the arrow next to it.
3. Select Approved for Install, and then click Approve.
4. The Approval Progress window will display the progress toward completing the approval. When the
process is complete, the Close button appears. Click Close.
5. You can select a deadline by right-clicking the update, selecting the appropriate computer group, clicking
the arrow next to it, and then clicking Deadline.
You can select one of the standard deadlines (one week, two weeks, one month), or you can click
Custom to specify a date and time.
If you want an update to be installed as soon as the client computers contact the server, click
Custom, and then set a date and time to the current date and time or to one in the past.
To approve multiple updates
1. In the WSUS administrative console, click Updates and then click All Updates.
2. To select multiple contiguous updates, press shift while selecting updates. To select multiple noncontiguous
updates, press and hold down CTRL while selecting updates.
3. Right-click the selection and click Approve. The Approve Updates dialog opens with the Approval
status set to Keep existing approvals and the OK button disabled.
4. You can change the approvals for the individual groups, but doing so will not affect child approvals. select
the group for which you want to change the approval, and click the arrow to its left. In the shortcut menu,
click Approved for Install.
5. The approval for the selected group changes to Install. If there are any child groups, their approval remains
Keep existing approval. To change the approval for the child groups, click the group and click the arrow to
its left. In the shortcut menu, click Apply to Children.
6. To set a specific child to inherit all its approval from the parent, click the child and click the arrow to its left.
In the shortcut menu, click Same as Parent. If you set a child to inherit approvals, but are not changing the
parent approvals, the child will inherit the existing approvals of the parent.
7. If you want the approval behavior to change for all children, approve All computers, and then choose
Apply to Children.
8. Click OK after setting all your approvals. The Approval Progress window will display the progress toward
completing the approval. When the process is complete, the Close button will be available. Click Close.
Declining updates
if you select this option, the update is removed from the default list of available updates and the WSUS server will
not offer the update to clients, either for evaluation or installation. You can reach this option by selecting an update
or group of updates and right-clicking or going to the Actions pane. Declined updates will appear in the updates
list only if you select Declined in the Approval list when specifying the filter for the update list under View.
To decline updates
1. In the WSUS administrative console, click Updates, and then click All Updates.
2. In the list of updates, select one or more updates that you want to decline.
3. select Decline, and then click Yes on the confirmation message.
NOTE
A revision is a version of an update that has changed (for example, it might have expired or have updated applicability rules).
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.
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
The Server cleanup Wizard is integrated into the user interface and can be used to help you manage your disk
space. This wizard can do the following operations:
Remove unused updates and update revisions remove all older updates and update revisions that have not
been approved.
Delete computers not contacting the server delete all client computers that have not contacted the server in
thirty days or more.
Delete unneeded update files delete all update files that are not needed by updates or by downstream
servers.
Decline expired updates decline all updates that have been expired by Microsoft.
Decline superseded updates decline all updates that meet all the following criteria:
The superseded update is not mandatory
The superseded update has been on the server for thirty days or more
The superseded update is not currently reported as needed by any client
The superseded update has not been explicitly deployed to a computer group for ninety days or
more
The superseding update must be approved for install to a computer group
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."
Running WSUS Replica mode
3/12/2019 • 2 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
A WSUS server running in replica mode inherits the update approvals and computer groups created on an
administration server. In a scenario that uses replica mode, you typically have a single administration server, and
one or more subordinate replica WSUS servers spread out throughout the organization, based on site or
organizational topography. You approve updates and create computer groups on the administration server, which
the replica mode servers will then mirror. Replica mode servers can be set up only during WSUS Setup, and if you
implemented this scenario, it is likely because it is important in your organization that update approvals and
computer groups are managed centrally.
If your WSUS server is running in replica mode, you will be able to perform only limited administration
capabilities on the server, which will primarily consist of:
Adding and removing computers from computer groups. Computer group membership is not distributed
to replica servers, only the computer groups themselves. Therefore, on a replica mode server, you will
inherit the computer groups that you created on the administration server. However, the computer groups
will be empty. You must then assign the client computers that connect to the replica server to the computer
groups.
Setting a synchronization schedule
Specifying proxy-server settings
Specifying the update source. This can be a server other than the administration server
Viewing available updates
Monitoring update, synchronization, computer status, and WSUS settings on the server
Running all standard WSUS reports available on replica mode servers
WSUS Messages and Troubleshooting Tips
3/12/2019 • 3 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
When you attempt to open Update Services on the WSUS server you receive the following error:
In addition to the above, attempts to access the URL for the WSUS Administration website (i.e.,
http://CM12CAS:8530) fails with the error:
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.
NOTE
Requires Cumulative Update for Windows 10 Version 1607 release in (or after) January 2017 (KB3213986 (OS Build
14393.693) to be installed.
The ISV client agent determines which updates to approve, and when do download and install updates
The WU client determines byte ranges to download and initiates the download request
Step 1: Configure WSUS
WSUS serves as the interface to Windows Update and manages all metadata describing Express packages that
need to be downloaded. If you need to deploy, see Overview of Windows Server Update Services 3.0 SP2.
Once WSUS has been deployed, the primary consideration is whether or not to store update content locally on the
WSUS server. When configuring WSUS, we recommend not storing updates locally. This assumes that you
already have software directing deployment of these packages in your environment. For more about how to
configure WSUS local storage, see Determine Where to Store Updates.
Step 2: Specify and Populate the ISV File Cache
Specify the ISV File Cache
New client-side Group Policy and Mobile Device Management (MDM ) settings detailed in the Configuration
service provider reference define the location of the ISV file cache.
NAME DESCRIPTION
Configure an alternate download location for updates. Specifies an alternate intranet server to host updates from
Microsoft Update. You can then use this update service to
automatically update computers on your network
There are two options when setting up the alternate download location for the ISV file cache:
1. Specify an ISV HTTP server hostname, which is the ISV file cache
This approach configures the WU client to make download requests to the HTTP server specified in the
policy
2. Specify localhost
This approach configures the WU client to make download requests to localhost. This allows the ISV client
agent to handle these requests and route as appropriate to fulfill the download request.
IMPORTANT
The ISV file cache requires the following:
The server must be HTTP 1.1 compliant per the RFC: http://www.w3.org/Protocols/rfc2616/rfc2616.html
Specifically, the web server needs to support HEAD and GET requests
- Partial Range requests
- Keep-alive
- Do not use "Transfer-Encoding:chunked"
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:
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:
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>
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.
3/12/2019 • 4 minutes to read • Edit Online
Applies to: Windows Server 2012, Windows Server 2012 R2, Windows Server 2016
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.
Stop-Service IISADMIN
Stop-Service WsusService
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
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
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
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
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-Service IISADMIN
Start-Service WsusService
NOTE
If you are using the WSUS Console, close and restart it.
Using PowerShell:
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
3/12/2019 • 2 minutes to read • Edit Online
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.
You can also install System Insights directly through Server Manager by adding the System -Insights feature, or
by using PowerShell:
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:
Understanding capabilities
Managing capabilities
Adding and developing capabilities
System Insights FAQ
Understanding capabilities
3/12/2019 • 5 minutes to read • Edit Online
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:
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:
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
To learn more about System Insights, use the following resources:
System Insights overview
Managing capabilities
Adding and developing capabilities
System Insights FAQ
Managing capabilities
3/12/2019 • 4 minutes to read • Edit Online
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 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:
TIP
To make sure invoking a capability doesn't conflict with critical operations on your machine, consider scheduling predictions
during off-business hours.
# 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:
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.
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:
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:
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:
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
You can also use Windows Admin Center to set remediation actions by using the Actions tab within the Settings
page:
See also
To learn more about System Insights, use the following resources:
System Insights overview
Understanding capabilities
Adding and developing capabilities
System Insights FAQ
Adding and developing new capabilities
3/12/2019 • 2 minutes to read • Edit Online
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.
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
To learn more about System Insights, use the following resources:
System Insights overview
Understanding capabilities
Managing capabilities
Adding, removing, and updating capabilities
System Insights FAQ
Adding, removing, and updating capabilities
3/12/2019 • 2 minutes to read • Edit Online
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.
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.
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.
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
To learn more about System Insights, use the following resources:
System Insights overview
Understanding capabilities
Managing capabilities
Adding and developing capabilities
System Insights FAQ
System Insights data sources
3/12/2019 • 2 minutes to read • Edit Online
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.
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 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:
See also
To learn more about System Insights, use the following resources:
System Insights overview
Understanding capabilities
Managing capabilities
Adding and developing capabilities
System Insights FAQ
System Insights FAQ
3/12/2019 • 2 minutes to read • Edit Online
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.
See also
To learn more about System Insights, use the following resources:
System Insights overview
Understanding capabilities
Managing capabilities
Adding and developing capabilities
Get started with Setup and Boot Event Collection
3/12/2019 • 21 minutes to read • Edit Online
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:
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.
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. 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
<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
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).
Troubleshooting
Troubleshooting installation of the feature
ERROR ERROR DESCRIPTION SYMPTOM POTENTIAL PROBLEM
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.
ERROR ERROR DESCRIPTION SYMPTOM POTENTIAL PROBLEM
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
3/12/2019 • 2 minutes to read • Edit Online
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.
Practical applications
Software Inventory Logging is intended to reduce the operational costs of retrieving accurate information
regarding the Microsoft software deployed locally on a server, but especially across many servers in an IT
environment (assuming it is deployed and enabled across the IT environment). The ability to forward this data to
an aggregation server (if set up separately by an IT administrator), allows the data to be collected in one place by a
uniform, automatic process. While this can also be achieved by querying the interfaces directly, Software Inventory
Logging, by employing a forwarding (over the network) architecture initiated by each server, can overcome
machine discovery challenges typical for many software inventory and asset management scenarios. SSL is used
to secure data forwarded over HTTPS to an administrator’s aggregation server. Having the data in one place (on
one server) makes the data easier to analyze, manipulate and report on. It is important to note that none of this
data is sent to Microsoft as part of the feature functionality. Software Inventory Logging data and functionality is
meant for the sole use of the server software’s licensed owner and administrators.
Software Inventory Logging can assist server administrators in performing the following tasks:
Retrieving software and server inventory information from Windows Servers, remotely and on-demand.
Aggregating software and server inventory information for a wide variety of software asset management
scenarios by enabling each server’s Software Inventory Logging feature and choosing a web server target
URI, and certificate thumbprint for authentication.
See Also
Software Inventory Logging Aggregator
Manage Software Inventory Logging
Software Inventory Logging Cmdlets in Windows PowerShell
Microsoft Assessment and Planning Toolkit Volume Activation Management Tool
Manage Software Inventory Logging
4/26/2019 • 12 minutes to read • Edit Online
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.
NOTE
Make sure you have WMF 4.0 installed before applying the update package below.
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.
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.
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.
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.
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.
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.
When using Software Inventory Logging on a Windows Server 2012 R2 Hyper-V host, it is possible to retrieve SIL
data from Windows Server 2012 R2 guests that are running locally, if SIL logging has been started in the guest(s).
However, this is only possible when using the Get-SilData and Publish-SilData Powershell cmdlets, and only
possible with WIndows Server 2012 R2 in both host and guest. The purpose of this capability is to allow data
center administrators that provide guest VMs to tenants, or other entities of a large corporation, to capture
software inventory data at the hypervisor host and subsequently forward all of this data to an aggregator (or
target URI).
Below are two examples of what the output on the PowerShell console would look like (much abbreviated) on a
Windows Server 2012 R2 Hyper-V host running one Windows Server 2012 R2 guest VM with SIL logging
started. You will notice the first example, which uses Get-SilData alone, will output all data from the host as
expected. Also included is all SIL data from the guest, but in a collapsed format. To expand and view this data from
the guest, simply cut and paste the snippet used in the second example below. SIL data objects from the guest will
always have the VM GUID associated within the object.
NOTE
Since SIL data is output on the console, when using the Get-SilData cmdlet, in data streams, objects will not always be output
in a predictive order. In the two examples below, the text has been color coded (blue for physical host data and green for
virtual guest data) only as an illustrative tool for this document.
Output Example 1
Output Example 2 (w/ Expand-SilData function)
See Also
Get Started with Software Inventory Logging
Software Inventory Logging Aggregator
Software Inventory Logging Cmdlets in Windows PowerShell
Import-BinaryMiLog
Export-BinaryMiLog
Software Inventory Logging Aggregator
4/26/2019 • 33 minutes to read • Edit Online
IMPORTANT
No Data is sent to Microsoft with the use of this software.
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. 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.
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
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.
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.
$firstAvailableDriveLetter = $availableDriveLetters[0]
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).
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.
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.
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.
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.
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.
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".
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).
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
3/12/2019 • 4 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
User Access Logging (UAL ) is feature in Windows Server that aggregates client usage data by role and products
on a local server. It helps Windows server administrators quantify requests from client computers for roles and
services on a local server.
UAL is installed and enabled by default, and collects data in nearly real-time. No administrator configuration is
required, although UAL can be disabled or enabled. For more information, see Manage User Access Logging. The
User Access Logging service aggregates client usage data by roles and products into local database files. IT
administrators can later use Windows Management Instrumentation (WMI) or Windows PowerShell cmdlets to
retrieve quantities and instances by server role (or software product), by user, by device, by the local server, and by
date.
NOTE
UAL supports the Microsoft Assessment and Planning Toolkit.
Practical applications
UAL aggregates unique client device and user request events that are logged into a local database. These records
are then made available (through a query by a server administrator) to retrieve quantities and instances by server
role, by user, by device, by the local server, and by date. In addition, UAL has been extended to enable 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.
NOTE
UAL collects Hyper-V data every 24 hours, and there is a separate UAL cmdlet for this scenario.
WARNING
To use UAL with IIS, you must use iisual.exe. For more information, see Analyzing Client Usage Data with IIS User
Access Logging.
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.
DATA DESCRIPTION
UserName The user name on the client that accompanies the UAL entries
from installed roles and products, if applicable.
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.
DATA DESCRIPTION
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
Software requirements
UAL can be used on any computer running versions of Windows Server after Windows Server 2012.
See also
User Access Logging on MSDN.
Manage User Access Logging
Manage User Access Logging
3/12/2019 • 10 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
NOTE
You can use the Get-Service UALSVC PowerShell cmdlet to retrieve information about the UAL Service including whether it
is running or stopped and whether it is enabled or disabled.
To stop and disable the UAL service by using the Services console
1. Sign in to the server with an account that has local administrator privileges.
2. In Server Manager, point to Tools, and then click Services.
3. Scroll down and select User Access Logging Service.Click Stop the service.
4. Right-click the service name and select Properties. On the General tab, change the Startup type to
Disabled, and then click OK.
To stop and disable UAL from the command line
1. Sign in to the server with an account that has local administrator privileges.
2. Press the Windows logo + R, then type cmd to open a Command Prompt window.
IMPORTANT
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click
Yes.
Stop-service ualsvc
Disable-ual
If at a later date you want to restart and re-enable UAL you can do so with the following procedures.
To start and enable the UAL service by using the Services console
1. Sign in to the server an account that has local administrator privileges.
2. In Server Manager, point to Tools, and then click Services.
3. Scroll down and select User Access Logging Service.Click Start the service.
4. Right-click the service name and select Properties. On the General tab, change the Startup type to
Automatic, and then click OK.
To start and enable UAL from the command line
1. Sign in to the server with local administrator credentials.
2. Press the Windows logo + R, then type cmd to open a Command Prompt window.
IMPORTANT
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click
Yes.
Start-service ualsvc
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.
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:
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
1. Sign in to the server with an account that has local administrator privileges.
2. Press the Windows logo + R, then type cmd to open a Command Prompt window.
3. Add the registry value:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WMI\AutoLogger\Sum\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.
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:
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
3/12/2019 • 2 minutes to read • Edit Online
When you run a server system in your organization, you might have business needs not met using default server
settings. For example, you might need the lowest possible energy consumption, or the lowest possible latency, or
the maximum possible throughput on your server. This guide provides a set of guidelines that you can use to tune
the server settings in Windows Server 2016 and obtain incremental performance or energy efficiency gains,
especially when the nature of the workload varies little over time.
It is important that your tuning changes consider the hardware, the workload, the power budgets, and the
performance goals of your server. This guide describes each setting and its potential effect to help you make an
informed decision about its relevance to your system, workload, performance, and energy usage goals.
WARNING
Registry settings and tuning parameters changed significantly between versions of Windows Server. Be sure to use the latest
tuning guidelines to avoid unexpected results.
In this guide
This guide organizes performance and tuning guidance for Windows Server 2016 across three tuning categories:
Hardware performance considerations Active Directory Servers Cache and memory management
Web Servers
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
Download Microsoft Server Performance Advisor (SPA) to help diagnose performance issues in a Windows Server
2012 R2, Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008 deployment. SPA generates
comprehensive diagnostic reports and charts and provides recommendations to help you quickly analyze issues
and develop corrective actions.
Overview of Server Performance Advisor
Download Server Performance Advisor
Server Performance Advisor User's Guide
Server Performance Advisor Pack Development Guide
Caution When you extract the .cab file, SPA must preserve the hierarchical directory structure to function correctly.
Depending on the CAB tools that are installed on your server, extraction may result in a non-operational directory
structure. To retain the hierarchical directory structure, you can use a CAB extraction utility tool that extracts a file
directory structure.
If the CAB extraction tool properly extracted the files, subfolders will automatically appear in the extraction target
folder.
SPA prerequisites
The SPA Console requires that the following software is installed:
Microsoft .NET Framework 4
SQL Server 2008 R2 Express SP1 or Microsoft SQL Server 2008 R2 SP1
Newer versions may be compatible. Any known product incompatibilities with SPA Console will be noted.
Server Performance Advisor User's Guide
4/23/2019 • 59 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
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.
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:
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 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:
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.
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'
# 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:
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
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.
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
3/12/2019 • 41 minutes to read • Edit Online
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
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.
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.
<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>
<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:
[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
<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:
HKEY_LOCAL_MACHINE...\PowerSchem 1 db310065-829b-4671-9647-
es 2261c00e86ef
\db310065-829b-4671-9647- 2
2261c00e86ef\Description
...\6738e2c4-e8a5-4a42-b16a- 4 180
e040e769756e\ACSettingIndex
...\6738e2c4-e8a5-4a42-b16a- 4 30
e040e769756e\DCSettingIndex
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:
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
#WmiObjectsProperties table
ID QUERY
#WmiQueries table
ID QUERY
SequenceId Int NOT NULL Correlate the row and its properties
SequenceId Int NOT NULL Correlate the row and its properties
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:
To import the data to the database, the data will be normalized into a table called #PerformanceCounters.
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
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>
Fullpath Nvarchar(300) NOT NULL Absolute file path and file name
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
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.
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.
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.
The following single-value group has an attribute, section, and it can point to any section, based on your UI
design.
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.
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
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.
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"
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.
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:
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].
The name attribute will be used as a database schema name, such as a namespace. This rule applies to all other
database objects that belong to the current advisor pack, such as list value and stored procedures.
Benefits to having this schema name in front of the database objects include:
Avoiding naming conflict for different advisor packs
Providing greater security
In the SQL Server database, the default schema name is dbo. Database owner credentials are usually required to
operate database objects under dbo. If we do not create a schema for each advisor pack, it is likely that two
advisor packs will define a list value with the same name. This should be irrelevant because you can introduce a
schema name to solve this issue. In addition, deprovisioning an advisor pack is much easier. Because the advisor
pack object belongs to a schema other than dbo, this allows SPA to use a lower user privilege to access them.
A normal report script does the following:
Accesses raw collected data
Performs calculations based on the raw data
Changes alerts and recommendations
Prepares data for the report view
Access raw collected data
All collected data is imported into the following corresponding tables. For more info about the table schema, see
Defining the data collector set.
registry
#registryKeys
WMI
#WMIObjects
#WmiObjectProperties
#WmiQueries
Performance counter
#PerformanceCounters
File
#Files
ETW
#Events
#EventProperties
Set rule status
The [dbo].[SetNotification] API sets the rule status, so you can see a Success or Warning icon in the UI.
@ruleName nvarchar(50)
@adviceName nvarchar(50)
The alert and recommendation messages are stored in the provision metadata XML file. This makes the report
script easier to manage.
Initially, every rule status is N/A. You can use this API to set a rule status by specifying an advice name. The level
of the advice name will be used as the rule status.
Recall that we defined the following rule earlier:
<rule name="freediskSize" caption="Free Disk Size on System Drive" description="This rule checks free disk
size on the system drive ">
<advice name="SuccessAdvice" level="Success" message="No issue found.">No recommendation.</advice>
<advice name="WarningAdvice" level="Warning" message="Not enough free space on system drive.">Install the
operating system on a larger disk.</advice>
</rule>
Assuming the free space is less than 2 GB, we need set the rule to the Warning level. The SQL script will be as
follows:
if (@freediskSizeInGB < 2)
BEGIN
exec dbo.SetNotification N'freediskSize', N'WarningAdvice'
END
ELSE
BEGIN
exec dbo.SetNotification N'freediskSize', N'SuccessAdvice'
END
NOTE
The thresholds are name-value pairs, and they can be referenced in any rules. The system administrators can use the SPA
console to adjust the thresholds.
Continuing with the previous example, for a threshold, the definition will be as follows:
<thresholds>
<threshold name="freediskSize" caption="Free Disk Size (GB)" description="Free Disk Size value="10" />
</thresholds>
<rule name="freediskSize" caption="Free Disk Size on System Drive" description="This rule checks free disk
size on system drive ">
<advice name="SuccessAdvice" level="Success" message="No issue found.">No recommendation.</advice>
<advice name="WarningAdvice" level="Warning" message="Not enough free space on the system drive.">
Install the operating system on a larger disk.</advice>
<dependencies>
<threshold ref="freediskSize"/>
</dependencies>
</rule>
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.
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:
You can then write a SQL script to insert, update, or delete the results:
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.
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
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:
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:
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>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:
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:
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.
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
5/23/2019 • 6 minutes to read • Edit Online
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 R2
Windows Server 2012
Windows Server 2008 R2
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.