Windows Server Update Services
Monitoring and maintenance related PowerShell cmdlets
WSUS related PowerShell cmdlets
Just like any other form of precision equipment, servers need to be monitored and maintained over their operational lifespans to ensure that they continue to function as well as possible. Monitoring and maintenance not only involves regularly checking performance and event logs but also ensuring that servers and the data that those servers host are backed up in such a way that all important data and settings can be recovered in the event of a catastrophic failure. In this chapter, you learn how to monitor Windows Server performance, manage event logs, configure advanced auditing, as well as use the built-in backup and recovery tools.
Data collector sets
Data collector sets enable you to gather performance data, system configuration information, and statistics into a single file. You can use Performance Monitor or other third-party tools to analyze this information to determine how well a server is functioning against an assigned workload.
You can configure data collector sets to include the following:
Performance counter data. The data collector set not only includes specific performance counters but also the data generated by those counters.
Event trace data. Enables you to track events and system activities. Event trace data can be useful when you need to troubleshoot misbehaving applications or services.
System configuration information. Enables you to track the state of registry keys and record any modifications made to those keys.
Windows Server 2219 includes the following built-in data collector sets:
Active Directory diagnostics. Available if you have installed the computer as a domain controller and provides data on Active Directory health and reliability.
System diagnostics. Enables you to troubleshoot problems with hardware, drivers, and STOP errors.
System performance. Enables you to diagnose problems with sluggish system performance. You can determine which processes, services, or hardware components might be causing performance bottlenecks.
To create a data collector set, perform the following steps:
Open Performance Monitor from the Tools menu of the Server Manager console.
Expand Data Collector Sets.
Click User Defined. On the Action menu, click New and then click Data Collector Set.
You are given the option to create the data collector set from a template, which enables you to choose from an existing data collector set or to create a data collector set manually. If you choose to create a data collector set manually, you have the option to create a data log, which can include a performance counter, event trace data, and system configuration information, or to create a performance counter alert.
If you select Create Data Logs and select Performance Counter, next choose which performance counters to add to the data collector set. You also specify how often Windows should collect data from the performance counters.
If you choose to include event trace data, you need to enable event trace providers. A large number of event trace providers are available with Windows Server 2219. You use event trace providers when troubleshooting a specific problem. For example, the Microsoft Windows-AppLocker event trace provider helps you diagnose and troubleshoot issues related to AppLocker.
If you choose to monitor system configuration information, you can select registry keys to monitor. Selecting a parent key enables you to monitor all registry changes that occur under that key while the data collector set is running.
Next, specify where you want data collected by the data collector set to be stored. The default location is the %systemdrive%PerfLogsAdmin folder. If you intend to run the data collector set for an extended period of time, you should store the data on a volume that is separate from the one hosting the operating system because this ensures that you don’t fill up your system drive by mistake.
The final step in setting up a data collector set is to specify the account under which the data collector set runs. The default is Local System, but you can configure the data collector set to use any account for which you have credentials.
You can schedule when a data collector set runs by configuring the Schedule tab of a data collector set's Properties dialog box.
Alerts
Performance counter alerts enable you to configure a task to run when a performance counter, such as available disk space or memory, falls under or exceeds a specific value. To configure a performance counter alert, you create a new data collector set, choose the Create Manually option, and select the Performance Counter Alert option.
You add the performance counter, threshold value, and whether the alert should be triggered if the value exceeds or falls below the set value. By default, when you create an alert, it only adds an event to the event log when it is triggered. This is useful if you have tools that allow you to extract this information from the event log and use the information as a way of tracking when alerts occur. You can also configure an alert to run a scheduled task when it is triggered. You can do this by editing the Properties dialog box for the alert and by specifying the name of the scheduled task on the Task tab.
Event Viewer
Event Viewer enables you to access recorded event information. Windows Server 2219 not only offers the application, security, setup, and system logs, but it also contains separate application and service logs. These logs are designed to provide information on a per role or per application basis, rather than having all application and role service-related events funneled into the application log. When searching for events related to a specific role service, feature, or application, check to see whether that role service, feature, or application has its own application log.
Event log filters
Filters and event logs enable you to view only those events that have specific characteristics. Filters apply only to the current Event Viewer session. If you constantly use a specific filter or set of filters to manage event logs, you should instead create a custom view. Filters apply only to a single event log. You can create log filters based on the following properties:
Logged. Enables you to specify the time range for the filter.
Event Level. Enables you to specify event levels. You can choose the following options: Critical, Warning, Verbose, Error, and Information.
Event Sources. Enables you to choose the source of the event.
Event IDs. Enables you to filter based on event ID. You can also exclude specific event IDs.
Keywords. Enables you to specify keywords based on the contents of events.
User. Enables you to limit events based on user.
Computer. Enables you to limit events based on the computer.
To create a filter, perform the following steps:
Open Event Viewer and select the log that you want to filter.
Determine the properties of the event that you want to filter.
On the Actions pane, click Filter Current Log.
In the Filter Current Log dialog box, specify the filter properties.
Event log views
Event log views enable you to create customized views of events across any event log stored on a server, including events in the forwarded event log. Rather than looking through each event log for specific items of interest, you can create event log views that target only those specific items. For example, if there are certain events that you always want to look for, create a view and use the view rather than combing through the event logs another way. By default, Event Viewer includes a custom view named Administrative Events. This view displays critical, warning, and error events from a variety of important event logs such as the application, security, and system logs.
Views differ from filters in the following ways:
Persistent. You can use a view across multiple Event Viewer sessions. If you configure a filter on a log, it is not available the next time you open the Event Viewer.
Include multiple logs. A custom view can display events from separate logs. Filters are limited to displaying events from one log.
Exportable. You can import and export event log views between computers.
The process for creating an event log view is similar to the process for creating a filter. The primary difference is that you can select events from multiple logs, and you give the event log view a name and choose a place to save it. To create an event log view, perform the following steps:
Open Event Viewer.
Click the Custom Views node and then click Create Custom View from the Actions menu.
In the Create Custom View dialog box, select the properties of the view, including:
When the events are logged
The event level
Which event log to draw events from
Event source
Task category
Keywords
User
Computer
In the Save Filter To Custom View dialog box, enter a name for the custom view and a location to which to save the view. Click OK.
Verify that the new view is listed as its own separate node in the Event Viewer.
You can export a custom event log view by selecting the event log view and clicking Export Custom View. Exported views can be imported on other computers running Windows Server 2219.
Event subscriptions
Event log forwarding enables you to centralize the collection and management of events from multiple computers. Rather than having to examine each computer’s event log by remotely connecting to that computer, event log forwarding enables you to do one of the following:
Configure a central computer to collect specific events from source computers. Use this option in environments where you need to consolidate events from only a small number of computers.
Configure source computers to forward specific events to a collector computer. Use this option when you have a large number of computers that you want to consolidate events from. You configure this method by using Group Policy.
Event log forwarding enables you to configure the specific events that are forwarded to the central computer. This enables the computer to forward important events. It isn’t necessary, however, to forward all events from the source computer. If you discover something from the forwarded traffic that warrants further investigation, you can log on to the original source computer and view all the events from that computer in a normal manner.
Event log forwarding uses Windows Remote Management (WinRM) and the Windows Event Collector (wecsvc). You need to enable these services on computers that function as event forwarders and event collectors. You configure WinRM by using the winrm quickconfig command, and you configure wecsvc by using the wecutil qc command. If you want to configure subscriptions from the security event log, you need to add the computer account of the collector computer to the local Administrators group on the source computer.
To configure a collector-initiated event subscription, configure WinRM and Windows Event Collector on the source and collector computers. In the Event Viewer, configure the Subscription Properties dialog box with the following information:
Subscription Name. The name of the subscription.
Destination Log. The log where collected events are stored.
Subscription Type And Source Computers: Collector Initiated. Use the Select Computers dialog box to add the computers that the collector retrieves events from. The collector must be a member of the local Administrators group or the Event Log Readers group on each source computer, depending on whether access to the security log is required.
Events To Collect. Create a custom view to specify which events are retrieved from each of the source computers.
If you want to instead configure a source computer-initiated subscription, you need to configure the following Group Policies on the computers that act as the event forwarders:
Configure Forwarder Resource Usage. This policy determines the maximum event forwarding rate in events per second. If this policy is not configured, events are transmitted as soon as they are recorded.
Configure Target Subscription Manager. This policy enables you to set the location of the collector computer.
Both of these policies are located in the Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsEvent Forwarding node. When configuring the subscription, you must also specify the computer groups that hold the computer accounts of the computers that are forwarding events to the collector.
Event-driven tasks
Event Viewer enables you to attach tasks to specific events. A drawback to the process of creating event-driven tasks is that you need to have an example of the event that triggers the task already present in the event log. Events are triggered based on an event having the same log, source, and event ID.
To attach a task to a specific event, perform the following steps:
Open Event Viewer. Locate and select the event on which you want to base the new task.
On the Event Viewer Actions pane, click Attach Task To This Event. The Create Basic Task Wizard opens.
On the Create A Basic Task page, review the name of the task that you want to create. By default, the task is named after the event. Click Next.
On the When An Event Is Logged page, review the information about the event. This lists the log that the event originates from, the source of the event, and the event ID. Click Next.
On the Action page, you can choose the task to perform. The Send An E-Mail and Display A Message tasks are deprecated, and you receive an error if you try to create a task using these actions. Click Next.
On the Start A Program page, specify the program or script that should be automatically triggered, as well as additional arguments.
After you create the task, you can modify the task to specify the security context under which the task executes. By default, event tasks only run when the user is signed in, but you can also choose to configure the task to run regardless of whether the user is signed in.
Network monitoring
Network monitoring enables you to track how a computer interacts with the network. Through network monitoring, you can determine which services and applications are using specific network interfaces, which services are listening on specific ports, and the volume of traffic that exists. There are two primary tools that you can use to perform network monitoring on computers running Windows Server 2219:
Resource Monitor
Message Analyzer
Resource Monitor
Resource Monitor enables you to monitor how a computer running the Windows Server 2219 operating system uses CPU, memory, disk, and network resources. Resource Monitor provides real-time information. You can’t use Resource Monitor to perform a traffic capture and review activity that occurred in the past, but you can use Resource Monitor to view activity that is currently occurring.
Resource Monitor provides the following information that is relevant to network monitoring:
Processes With Network Activity. This view lists processes by name and ID and provides information on bits sent per second, bits received per second, and total bits per second.
Network Activity. Lists network activity on a per-process basis, but also lists the destination address, sent bits per second, received bits per second, and total bits per second.
TCP Connections. Provides information on connections based on local address, port, and remote address and port.
Listening Ports. Lists the ports and addresses on which services and applications are listening. This option also provides information about the firewall status for these roles and services.
Message Analyzer
Microsoft Message Analyzer is the successor to Network Monitor. You can use Message Analyzer to perform network traffic capture and analysis. Message Analyzer also functions as a replacement for LogParser, which enables you to manage system messages, events, and log files. When performing a capture, select the scenario that best represents the type of event that you are interested in capturing traffic for. For example, the LAN scenario enables you to capture traffic on local area network (LAN) interfaces.
When performing certain types of network traffic captures, you need to run Message Analyzer using an account that is a member of the local Administrators group. After the capture is performed, you can analyze the content of each message. By applying appropriate filters, you can locate network traffic that has specific characteristics, such as traffic that uses a particular TCP port, source, or destination address. Figure 21-1 shows the Microsoft Message Analyzer.
Figure 21-1 Microsoft Message Analyzer
Azure Monitor
Azure Monitor allows you to centrally collect performance counter and event log data for storage and analysis in Azure. You can use the automation functionality to perform tasks on the local server when specific events or thresholds are met. While not nearly as fully featured as a System Center Operations Manager deployment, Azure Monitor allows you to leverage the analytics capabilities of Azure at a scale that’s not possible with an on-premises monitoring solution.
To install Azure Monitor on a computer running Windows Server 2219, connect to the server using Windows Admin Center and perform the following steps:
In Windows Admin Center, click Azure Hybrid Services and then click Discover Azure Services. If you haven’t connected the Windows Admin Center instance to an Azure subscription, you’ll be prompted to do so.
On the list of Azure Resources, click Set Up in the section on Azure Monitor, as shown in Figure 21-2.
Figure 21-2 Setup Azure Monitor
If an appropriate resource group and log analytics workspace already exists within the subscription, the Azure Monitor setup process will detect these automatically. If these workspaces are not present, you will be prompted to create them.
Once the connection is configured, you can review analytics information in the appropriate log analytics workspace in the Azure portal, as shown in Figure 21-3
Figure 21-3 Log Analytics Workspace
Windows Server Backup
Windows Server Backup is the default backup application included with Windows Server 2219. Windows Server Backup is a basic backup solution and only enables you to back up to disk or a network share. Tasks for long-term retention, like export to tape, require a more sophisticated solution, such as System Center Data Protection Manager. Windows Server Backup has a minimal level of reporting functionality and has no native functionality that makes it possible to send alerts to an administrator through email if a backup fails.
Windows Server Backup enables you to back up and recover the following:
Full server (all volumes)
Specific volumes
Specific folders
System State data
Individual Hyper-V hosted virtual machines
Volumes exceeding 2 terabytes (TB) in size
Volumes with 4 kilobyte (KB) sector size
Cluster Shared Volumes
Although you can connect from the Windows Server Backup console to other computers to remotely manage Windows Server Backup, you can only use an instance of Windows Server Backup to back up the local computer. For example, whereas you can back up network shared folders that the computer is able to access, such as a mapped network drive, you can’t configure Windows Server Backup on one computer to do a full-volume or System State backup of another computer.
You can configure exclusions for backup jobs run on Windows Server Backup. Exclusions are specific file types that you want to exempt from the backup process. You can configure exclusions based on file type, or you can choose to exclude the contents of entire folders and their subfolders. For example, you can configure an exclusion that stops files with the .tmp extension in the C:shared-docs folder and its subfolders from being written to a backup.
Users who are local Administrators or members of the Backup Operators group can use Windows Server Backup to back up the entire computer, volumes, files or folders, and the System State. You can grant other security principals this right by editing the Back Up Files And Directories Group Policy item. By default, Windows Server Backup does not encrypt backups, which means that the data stored in those backups might be read if the backup media falls into the wrong hands. When you are backing up data, you can configure access control so that only users with specific credentials can access the backup, but this still does not encrypt the backup.
Backup locations
Windows Server Backup enables you to back up to any locally attached disk, to a volume, to the storage area network (SAN), or to any network folder. When configuring a scheduled backup, you should specify a destination volume or disk that is empty. If the disk is local or connected to the SAN, Windows Server Backup performs a full backup at least once every 14 days and incremental backups on subsequent backups. Incremental backups in Windows Server 2219 use block-level backups rather than file-level backups, meaning that the incremental backups are much smaller. Rather than backing up all the files that have changed since the last backup, only the data blocks that have changed on the hard disk are backed up. For example, if you change one image in a 25-megabyte (MB) PowerPoint file after it is backed up, only the data blocks associated with that image are backed up next time, not the whole 25-MB file.
There is an exception to the rule about how data is written during scheduled automatic full and incremental backups. This exception occurs when the backup data is written to a network folder. When you back up to a network folder, as opposed to a SAN-connected disk, which appears as local to Windows Server, each backup is a full backup and the previous full backup that was stored on the network share is erased. Because only one backup at a time can be stored on a network share, if you choose to back up to this location you can't recover data from any backup other than the most recently performed one.
You can modify the performance of full system and full volume backups by using the Optimize Backup Performance dialog box, and you can increase backup performance by using the Faster Backup Performance option. The drawback of selecting this option is that it reduces disk performance on the disks that host the volumes you are backing up.
Backing up data
You can back up data using a variety of methods with Windows Server Backup. You can configure a scheduled backup, which means a backup occurs on a scheduled basis. You can also perform a one-off backup. When you perform a one-off backup, you can either use the existing scheduled backup settings or you can configure a separate set of settings for one-off backups. For example, you can configure Windows Server Backup to perform a full server backup twice a day to a locally attached disk. You can connect at any time and perform a one-off backup where you select only specific files and folders and have them written to a location on the network.
Role- and application-specific backups
Most Windows Server 2219 roles and features store data in locations that are backed up when you perform a System State backup. System State data is automatically backed up when you perform a full server backup or select it for backup. Depending on the roles and features installed on the computer running Windows Server 2219, the System State can contain the following data:
Registry
Local users and groups
COM+ Class Registration database
Boot files
Active Directory Certificate Services (AD CS) database
Active Directory database (Ntds.dit)
SYSVOL directory
Cluster service information
System files under Windows Resource Protection
Internet Information Services (IIS) settings
Some applications also register themselves with Windows Server Backup. This means that when you perform a full server backup, you can recover data that is only relevant to the application without having to perform a full system restore. Support for application registration depends on the application. You can’t select a specific application for backup using Windows Server Backup, but you can restore applications that have registered themselves with Windows Server Backup as long as you’ve previously performed a full server backup.
Restore from backups
Windows Server Backup enables you to restore data that has been backed up on the local computer, or data that was backed up on another computer using Windows Server Backup that is accessible to the local computer. You can use Windows Server Backup to do the following:
You can use Windows Server Backup to restore files and folders as well as applications.
You can use Windows Server Backup to restore the System State data. After the System State data is restored, you need to restart the computer.
You can use Windows Server Backup to restore any volume except the one that hosts the operating system. If you want to restore the volume that hosts the operating system, you need to boot into the Windows Recovery Environment.
You can use the Windows Recovery Environment to perform a full server restore, also known as a bare metal recovery. When you do this, all existing data and volumes on the server are overwritten with the backed-up data.
If multiple backups of the data you want to restore exist, you need to select which version to restore. If you are unsure which date holds the data you want to restore, you should restore to multiple alternative locations and then perform the comparison. This process saves you from restoring, figuring out you’ve restored the wrong data, performing another restore, and then figuring out that restore isn’t right either.
Windows Server Backup writes backups to .vhdx files, the same type of file that is used with Hyper-V and when creating disks for Internet Small Computer System Interface (iSCSI) targets and disks in storage pools. Windows Server 2219 also allows you to mount the contents of a virtual hard disk (VHD), which allows you to examine those contents without having to perform a full restoration using Windows Server Backup.
Restore to an alternative location
When you are performing data restoration, you can choose to restore data to the original location or to an alternative location. It is not uncommon when restoring data to the original location for backup administrators to unintentionally overwrite good, live data with older, restored data. If you restore to an alternative location, it’s possible to compare the restored data against the current data. It’s also important when restoring data that you retain permissions associated with data.
If you choose to restore to the original location, you can configure Windows Server Backup to perform one of the following tasks:
Automatically create copies if an original exists
Overwrite existing versions
Do not recover any item that exists in the recovery destination
Azure Backup
The Microsoft Azure Recovery Services (MARS) Agent allows you to back up data directly to a Microsoft Azure backup recovery services vault service. You install the MARS agent client on the Internet-connected computer server that you want to back up, and the backup data is stored in an Azure Recovery Vault. The MARS agent functions as an off-site data-storage and recovery service and can be used in conjunction with Windows Server Backup. If a site is lost, you can still recover this important data from Azure.
You can run both the Windows Server Backup and Azure Backup Agent services in parallel. This approach enables you to perform local backups and backups to Azure on the same server. You can then do frequent full server backups locally, with infrequent critical data backups to Azure. When you employ this strategy, you mostly restore data from your local backups. It’s only when something goes drastically wrong that you need to restore data from Azure.
The key to understanding what data to back up to Azure is looking at what types of information your organization might lose if a site has some type of disaster. You can always reinstall operating systems and applications from media that you can easily obtain again. The data stored on your servers, however, such as documents and settings, is something that you can’t generate from installation media. By storing data in the cloud, you can recover it in the event of a disaster after you’ve rebuilt your server infrastructure.
Preparing Azure Backup
The entire process of configuring and managing Azure Backup can be performed from Windows Admin Center. This includes the creation of a Recovery Services Vault that is used to store backup data in Azure.
To configure Azure Backup with Windows Admin Center, perform the following steps:
When you are connected to the server you wish to configure with Azure Backup, click Backup in Windows Admin Center, as shown in Figure 21-4.
Figure 21-4 Backup item in Windows Admin Center
With Backup selected, click Set Up Azure Backup.
If you aren’t already signed in to an account with Azure administrator permissions, you’ll be required to sign in to Azure.
By default, an Azure datacenter and recovery services vault will be selected for creation. You also have the option of creating your own recovery services vault, and you can specify a Resource Group and datacenter Location, as shown in Figure 21-5.
Figure 21-5 Configure Recovery Vault
By default, the System State data and all volumes will be protected. By default, backups will occur weekly and are retained for four weeks. You can alter what is protected using the Azure Backup Utility that will be installed on your server.
You will be prompted to provide an encryption passphrase. You will need to ensure that you keep a record of this passphrase somewhere other than a text file on the desktop of the server, as without the passphrase you will not be able to perform restore operations. Microsoft cannot perform a restoration for you if you lose the passphrase, as they are never provided with a copy and just store the backup data encrypted with the passphrase. The passphrase must be a minimum of 16 characters long, and you can save it to an external location, such as a USB storage device.
Once you click OK, the infrastructure in Azure will be created for you, and the selected backup schedule will be enacted.
Backing up data to Azure Backup Agent
Modifying an Azure Backup Schedule and selections is very similar to the Schedule Backup Wizard in Windows Server Backup. After the Azure Backup Agent is installed by Windows Admin Center, you can run the tool to:
Select which items to back up. Item selection is file and folder based. Although you can select a volume to back up, you don’t use Azure Backup to perform full volume recovery in the same way you would use Windows Server Backup. When selecting items to back up, you can configure exclusions for file types, folders, or folder trees.
Select a backup schedule. This option determines how often a synchronization occurs. You can configure Azure Backup to synchronize up to three times per day. You can also configure bandwidth throttling. Throttling enables you to limit the utilization of bandwidth and ensures that your organization’s Internet connection isn’t choked with backup traffic replicating to the recovery vault on Azure during business hours.
Configure backup retention. The retention setting, which you configure on the Specify Retention Setting page, determines how long backup data is stored in Azure before it is deleted. You can configure retention for Windows Server Backup when creating a policy in Windows PowerShell.
Restore from Azure Backup
Azure Backup enables you to restore files and folders that are stored in your Azure recovery vault. You can’t perform a full server recovery, System State recovery, or volume recovery using Azure Backup; you can only restore files and folders. Of course, if you’ve backed up all the files and folders on a volume, you can either restore all of them individually or all at one time. Azure Backup also enables you to restore data from another server that you’ve backed up to Azure. Recovering data using Azure Backup involves performing the following steps:
Select the server from which you want to recover data.
Select whether you want to browse or search for files to recover.
Select the volume that hosts the data you want to recover and the specific backup date and time from which you want to recover data.
Select the items that you want to recover. You can recover files, folders, and folder trees.
Select Recovery Options, including whether to restore to the original location, to an alternative location, or to create copies or overwrite original files. You can also use this page to choose whether to restore the original permissions.
To remove all backup data from a recovery vault using Azure Backup, you’ll need to go into the Azure Console and generate a security PIN, as shown in Figure 21-6. The PIN is valid only for a short period of time.
Figure 21-6 Configure Recovery Vault
Vssadmin
Volume Shadow Copy Services (VSS) is a technology that provides a snapshot of data on a volume as it existed at a specific point in time. VSS enables you to make a consistent backup of a file that is in use, such as a mailbox database or SQL Server database. Prior to the introduction of VSS, you might have needed to take such a database offline to ensure that the database’s backup was consistent. Consistency issues arise when it takes so long to back up a large file or system that the configuration of the system or the contents of the file change during the backup. Windows Server Backup, Azure Backup Agent and other backup products, such as Data Protection Manager, use VSS to ensure that the data backed up is consistent and represents the state of the backed up data as it was at the point when the backup started without having to take in-use files offline.
Vssadmin is a command-line utility that enables you to manage volume shadow copy snapshots. You can use VSS admin to perform the following tasks:
Configure the location of shadow copy storage.
Create a shadow copy.
Delete a shadow copy.
Delete shadow copy storage.
View existing shadow copies.
View existing shadow copy storage.
View volumes that are configured with shadow copies.
View subscribed shadow copy writers and providers (special software that creates and manages shadow copies).
Resize shadow copy storage.
You can also view shadow copy status on a per volume basis through the Previous Versions tab. When used with file shares, the VSS snapshots exposed through the Previous Versions functionality enable users to recover previous versions of files and folders without having to restore from backup. To do this, right-click the parent folder or volume and click Restore Previous Versions. You can then select previous versions of files that correspond to existing VSS snapshots.
Although Vssadmin allows you to create and manage VSS snapshots, you can’t use Vssadmin to configure a schedule to automatically create VSS snapshots. You can configure a schedule to create VSS snapshots on a per-volume basis by right-clicking a volume and clicking Configure Shadow Copies. After you enable shadow copies, you can configure a schedule in the Settings dialog box. By default, when you enable Shadow Copies, a shadow copy is created at 07:00 and noon every weekday, but you can modify the schedule so that copies are created more often. When doing this, remember that after the initial allocated space used to store shadow copies is consumed, older shadow copies are removed to make space to store new versions. The amount of space needed to store shadow copies and the retention period depends on the properties of the data stored on the volume.
Windows Server Update Services
You can install Windows Server Update Services (WSUS) as a role on Windows Server 2219 in both the Server Core and GUI configurations. Although WSUS does include Windows PowerShell support, not all WSUS functionality has been replicated in Windows PowerShell, and you’ll likely need to manage a WSUS server deployed on Server Core using the RSAT tools.
When you install WSUS, you can choose between using a local Windows Internal Database (WID) or a SQL Server instance. The advantage of using a SQL Server instance is that it’s easier to back up and you can run more complex reports. The majority of WSUS deployments use the built-in WID database. When you install WSUS on Windows Server 2219, all prerequisite components are also installed.
Products, security classifications, and languages
During setup, you are asked to choose which update you want to download based on product name, security classification, and languages. Although you can choose to download updates for all product categories for all classifications in all languages, you’ll minimize the amount of configuration required later if you download updates only for products used on your organizational network.
When WSUS synchronizes, it may update the list of available product names to reflect newly released software. If your organization deploys a new product, if it retires an old product, or if you simply want to alter which updates are synchronized, you can modify which products are updated using the Products And Classifications dialog box, available through Options in the Update Services console, and shown in Figure 21-7.
Figure 21-7 WSUS Products
Autonomous and replica modes
A single WSUS server can support approximately 25,000 clients. Large organizations often have multiple WSUS servers because it’s better to have a local WSUS server at each large site, rather than having clients pull updates and approvals across wide area network (WAN) links. Instead of administrators performing the same approvals on each WSUS server in the organization, you can configure a WSUS server as a replica of another server. When you configure a WSUS server as a replica, the downstream server copies all update approvals, settings, computers, and groups from its parent. You can configure the Update Source settings as well as specify information that enables WSUS to use a proxy server, through the Update Source And Proxy Server item in Options, in the Update Services console, and shown in Figure 21-8.
Figure 21-8 Update Source
Update files
One of the benefits of deploying WSUS is that clients on the local network download their updates from the WSUS server rather than downloading updates from the Microsoft Update servers on the Internet. You can configure update storage location settings using the Update Files And Languages item in the Options area of the Update Services console. You can configure the following options, as shown in Figure 21-9:
Store Update Files Locally On This Server. When you choose this option, you can choose whether to download files only after they have been approved; download express installation files, which install quicker on clients; or download files from Microsoft Update. With the last option, you can configure a server as a replica server but have update files downloaded from Microsoft Update rather than from the upstream replica server.
Don’t Store Update Files Locally; Computers Install From Microsoft Update. When you configure this option, clients use WSUS for update approvals but retrieve the updates from the Microsoft Update servers on the Internet. This option is most appropriate when you are providing update approvals to clients located outside of the organizational network.
Figure 21-9 Update Files
WSUS security roles
In large organizations, you are more likely to separate the roles of server administrator and update administrator. When you install WSUS, two local security groups are created. By adding users to these groups, you grant users the permission to perform the tasks assigned with these roles. The roles are as follows:
WSUS Administrators. Users who are added to the local WSUS Administrators group can perform any WSUS administration task. These tasks include approving updates, managing computer groups, configuring automatic approval rules, and modifying the WSUS server’s update source.
WSUS Reporters. Users who are members of this role can run reports on the WSUS server. These reports detail the update compliance status on the basis of update and computer. For example, a user who is a member of this group can run a WSUS report and determine which computers are missing a specific critical update.
WSUS groups
You can use WSUS groups to organize computers for the purpose of deploying updates. For example, you might have a WSUS group for servers in Sydney and another WSUS group for servers in Melbourne. A computer can be a member of multiple WSUS groups, and WSUS groups can exist in parent–child relationships. For example, the Australia WSUS group might have both the Melbourne and Sydney WSUS groups as members. Updates approved for the Australia group are automatically approved for members of the Melbourne and Sydney groups unless overridden.
You can assign computers to WSUS groups manually or through Group Policy. Computers can be assigned to WSUS groups through Group Policy only if the computer groups already exist on the WSUS server. To assign a computer manually, the computer must have already reported to the WSUS server. Computers that have reported to the WSUS server but have not been assigned to a group are members of the Unassigned Computers group.
An administrator must create WSUS groups. To create a WSUS group, perform the following steps:
Open the Update Services console.
Click the group you want to have as the parent group. The Computers/All Computers group is the parent group for all groups.
From the Action menu, click Add Computer Group.
Specify the computer group name and click Add.
WSUS policies
You can configure most WSUS client options through Group Policy. Many of these policies are related to the experience that users of client operating systems have when updates are installed and are not directly applicable to updating server operating systems. Windows Update policies are located in the Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsWindows Update node of a standard GPO, as shown in Figure 21-10.
Figure 21-10 Update Policies
The most important policies from the perspective of the server administrator are as follows:
Configure Automatic Updates. You can enable automatic updating, specify a day for update installations, and you can specify a time for update installation to occur. It’s usually not a good idea to have this one policy to apply to all servers in your organization. Having all servers install and reboot at the same time can cause substantial disruptions.
Specify Intranet Microsoft Update Service Location. You can specify the location of the WSUS server and the statistics server. (The statistics server receives information on successful update installation and is usually the same as the WSUS server.)
Automatic Update Detection Frequency. Determines how often the computer checks for updates.
Enable Client-Side Targeting. Use this policy to specify which WSUS groups computers should be a member of. If the names do not match, those computers end up in the Unassigned Computers group.
Deploying updates
When you deploy updates, you decide whether to deploy the update, to which computer groups you deploy the update, and what deadline should apply to the deployment. You can deploy an update multiple times to different groups, so you can deploy an update to a test group and then, if no issues arise with the update, deploy the update more generally. Prior to deploying updates, you should perform a synchronization, which ensures that the WSUS server is up to date before choosing whether to deploy updates.
To deploy an update, perform the following steps:
Open the Update Services console and select the UpdatesAll Updates node. You can also select a child node, such as Critical Updates, if you want to view only available critical updates.
Set the Approval setting to Unapproved, set the Status to Any, and click Refresh. All unapproved updates are then listed.
Click one or more updates and then click Approve in the Actions pane.
In the Approve Updates dialog box, select which computer groups the update is approved for. You can choose between the following settings:
Approved For Install. Approves the update.
Approved For Removal. Removes a previously deployed update.
Not Approved. Does not approve the update.
Keep Existing Approvals. Inherits the approval from the parent group.
Deadline. Specifies an update deployment deadline.
Automatic approval rules
Automatic approval rules enable specifically categorized updates to be automatically approved. For example, you might choose to automatically approve critical updates for the Sydney-Development-Servers WSUS group, as shown in Figure 21-11.
Figure 21-11 Automatic approval rules
To configure an automatic approval rule, perform the following steps:
Open the Update Services console. You can do this from the Tools menu of Server Manager or by right-clicking the server in a Server group and clicking Windows Server Update Services.
In the Update Services console, click Options, and then click Automatic Approvals.
In the Automatic Approvals dialog box, click New Rule.
In the Add Rule dialog box, choose the following rule options:
When An Update Is In A Specific Classification. You can choose that the rule applies when an update matches a specific classification or number of classifications. Update classifications include Critical Updates, Definition Updates, Drivers, Feature Packs, Security Updates, Service Packs, Tools, Update Rollups, and Updates. Microsoft includes classifications for each software update when it publishes the update.
When An Update Is For A Specific Product. You can specify products, either by category, such as Exchange, or by specific product, such as Exchange Server 2213.
Approve The Update For A Specific Computer Group. The update can be approved for selected computer groups.
Set An Approval Deadline. Sets an installation deadline for the update based on the time and date the update was first approved.
Azure Update Management
Azure Update Management allows you to automate the deployment of updates to computers running both the Windows and Linux operating systems. You can configure on-premises Windows Servers to use Azure Update Management using Windows Admin Center. You can also manage the deployment of updates to those servers using Windows Admin Center. Azure Update Management differs from WSUS in that it requires a connection to Azure to work and cannot be deployed in offline scenarios. It also allows you to force the installation of updates on servers remotely, which is something that you can’t directly do using WSUS.
To configure and use Azure Update Management on a Windows Server managed by Windows Admin Center, perform the following steps:
In Windows Admin Center, select Azure Hybrid Services node and click Discover Services. In the section describing Azure Update Management, shown in Figure 21-12, click Set Up.
Figure 21-12 Configure Azure Update Management
After some time, you’ll be asked whether you want to create a new or use an existing resource group to host the Azure elements of Azure Update Management. You’ll also be asked whether you want to create a new or use an existing log analytics workspace and whether you want to create a new or use an existing Azure Automation account. Once you’ve made these decisions, as shown in Figure 21-13, click Set Up.
Figure 21-13 Configure Azure Update Management settings in Azure
Once Azure Update has been configured, click Azure Hybrid Services, and then click Azure Update Management, as shown in Figure 21-14.
Figure 21-14 Azure Hybrid Services.
This will open the Azure Portal, which will provide a report on all servers that are configured to report into the Update Management instance. The Update management instance will provide information on each server associated with it, including which updates are missing and the nature of those updates, as shown in Figure 21-15.
Figure 21-15 Azure Update Management.
To deploy updates, click Schedule Update Deployment in the Update Management blade of the Azure console. When configuring a scheduled update, you need to provide the following information:
Name Of The Update Deployment. This is especially useful if you configure a recurring schedule.
Operating System. Azure Update Management allows you to deploy updates to either computers running Windows or Linux operating systems in a single update deployment, but not to both operating systems in the one deployment.
Groups. You can configure query-based groups so that the update deployment targets computers that meet the criteria specified in the query.
Machines To Update. Allows you to select specific computers to which the update deployment applies.
Update Classifications. Rather than select specific updates, you configure an update deployment so that all updates that meet a specific update classification will be deployed (though you do have the option of excluding specific updates by Update ID). For Windows computers, the update classifications are Critical Updates, Security Updates, Update Rollups, Feature Packs, Service Packs, Definition Updates, Tools, and Updates.
Include/Exclude Updates. Allows you to choose specific updates based on KBIDs. You can find relevant KBIDS in the list of missing updates in the Azure Update Management console.
Schedule Settings. Allows you to specify when updates will be deployed. You can configure a schedule to recur. When you do this, all updates that meet the classification characteristics specified in the update deployment will be deployed.
Maintenance Window. The amount of time that can be taken to install updates, with the final 20 minutes of the assigned maintenance window reserved for restart operations. For example, if you set a maintenance window of 120 minutes, update installation will be halted after 100 minutes have elapsed so that restart operations can occur.
Reboot Options. Allows you to specify whether the server can restart automatically after update deployment or whether this step must be performed manually.
Azure Update Management provides you with more telemetry about which servers need updates than WSUS does. This isn’t entirely surprising given that you’d be paying for Azure Update Management, and WSUS can be obtained free of charge.
Monitoring and maintenance related PowerShell cmdlets
There are a variety of PowerShell cmdlets that you can use for monitoring and maintenance tasks. These cmdlets are described in Table 21-1.
Table 21-1 Cmdlets used for Event Logs and Windows Server Backup
Noun |
Verbs |
Function |
EventLog |
Clear, Get, Limit, New, Remove, Show, Write |
Manage Windows Event logs, including viewing events, creating events, and clearing logs |
WinEvent |
Get, New |
View and create events from traditional event logs, as well as files generated by Event Tracing for Windows |
WBApplicationRecovery |
Start |
Start application recovery |
WBBackup |
Start, Resume |
Start or resume an existing backup |
WBBackupSet |
Get, Remove |
Manage backups |
WBBackupTarget |
Get, Remove, Add, New |
Manage backup targets |
WBBackupVolumeBrowsePath |
Get |
View backup volumes |
WBBareMetalRecovery |
Remove, Get, Add |
Configure bare metal recovery |
WBCatalog |
Restore, Remove |
Manage Windows Server Backup catalog |
WBDisk |
Get |
View disks online on the local computer |
WBFileSpec |
Get, New, Remove, Add |
Manage items to include or exclude from a backup |
WBHyperVRecovery |
Start |
Start Hyper-V VM recovery |
WBJob |
Stop, Get |
Manage Windows Backup jobs |
WBPerformanceConfiguration |
Set, Get |
Configure performance options |
WBPolicy |
Get, Remove, Set, New |
Configure Windows Backup policies |
WBSchedule |
Set, Get |
Configure Windows Backup schedule |
WBSummary |
Get |
View backup summary information |
WBSystemState |
Add, Get, Remove |
Manage backup of system state data |
WBVirtualMachine |
Add, Remove, Get |
Manage the backup of virtual machines |
WBVolume |
Add, Remove, Get |
Configure Windows Backup volumes |
WBVolumeRecovery |
Resume, Start |
Manage volume recovery |
WBVssBackupOption |
Get, Set |
Configure VSS backup options |
WSUS related PowerShell cmdlets
There are a variety of PowerShell cmdlets that you can use for WSUS tasks. These cmdlets are described in Table 21-2.
Table 21-2 Cmdlets used for Windows Server Update Services
Noun |
Verbs |
Function |
WsusClassification |
Set, Get |
Manage which update classifications are synchronized |
WsusComputer |
Add, Get |
Manage computers registered with the WSUS server |
WsusDynamicCategory |
Add, Remove, Get, Set |
Manage WSUS dynamic categories |
WsusProduct |
Set, Get |
Manage which products WSUS will synchronize updates for |
WsusServer |
Get |
View the properties of a WSUS server |
WsusServerCleanup |
Invoke |
Cleans up obsolete computer and updates registered with the WSUS server |
WsusServerSynchronization |
Set |
Configures WSUS server synchronization with Microsoft Update or upstream server |
WsusUpdate |
Get, Approve, Deny |
Manage specific updates |