Chapter 3: Server Infrastructure Management – Mastering Windows Security and Hardening

Chapter 3: Server Infrastructure Management

The data center is constantly evolving and services traditionally used by hosting servers in physical data centers are now virtualized and using serverless computing models in the cloud. No matter how your infrastructure is deployed or what infrastructure is used, each presents a unique security challenge for an organization. In this chapter, we will provide an overview of the data center and cloud models as they exist today. We will discuss security access strategies for Windows servers as they are relevant to all infrastructure models to ensure not just anyone can access Windows without going through the proper access controls. You will learn about the available management tools used for on-premises, hybrid, and cloud deployments, as well as how to leverage Azure services to expand your data center reach to the cloud. Then, we will provide an overview of the Azure services that are used to manage Windows servers, including the Azure portal and Azure Resource Manager. It's important to understand the existence of these tools and services so that you have a high-level understanding of each when building out your security program. Depending on the size of your organization, services such as these may require several teams to control access, including physical security, a security operations center (SOC), and identity and access management teams. All of these play a vital role in ensuring your Windows systems are properly managed and protected.

In this chapter, we will cover the following topics:

  • Overview of the data center and the cloud (IaaS, PaaS, SaaS)
  • Implementing access management in Windows servers
  • Understanding Windows Server management tools
  • Using Azure services to manage Windows servers

Technical requirements

Throughout this chapter, we will be referencing different services available in Azure. If you would like to follow along, you can sign up for a free Azure account for 30 days and get $200 credit at

To complete the RBAC example provided later in this chapter, you will need the following:

Check out the following video to see the Code in Action:

Overview of the data center and the cloud

Over the years, we have shifted our data centers strategies quite significantly as it relates to the hardware our services run on. The OS types, versions, and virtualization of those services have recently shifted to fully cloud-based technologies. A traditional enterprise data center typically consisted of mainframes to store and access information. Data centers during these times were located on location or at a separate facility under management of the organization. As technology evolved, there was a shift from mainframe to server-based data centers. This is where the Windows Server family became widely adopted and grew in popularity.

Moving beyond standard hardware-based server models comes virtualization. The ability to run many servers on only a few physical servers changed the dynamics of the data center significantly. Today, we are in a major shift to cloud computing. Organizations are slowly moving away from the traditional on-premise data center and moving all their workloads into cloud environments. With the cloud data center, organizations can continue to run traditional servers and services, but the overhead of owning and managing physical infrastructure is greatly reduced or eliminated.

Another major change with a shift to the cloud is the elimination of onsite facility management and physical operations. Building and maintaining a data center is an enormous undertaking that is challenging and comes with substantial cost implications when designing for highly available services and disaster recovery as part of a business continuity plan. Moving to the cloud changes these dynamics significantly. Your cost model changes to a subscription model with no ownership of any hardware or physical facilities, and a robust business continuity plan becomes more feasible to design.

This shift also changes the dynamics of security for the data center. Traditionally, physical security with access controls, locks, badge readers, and security cameras was all that was needed. This goes away with the cloud, but how do you ensure the cloud provider is protecting the access and controls? How do you ensure your data is safe? These are all valid concerns and change the way we manage security as opposed to the traditional data center perspective. We will cover these questions in more detail throughout this book.

Next, let's look at the three common types of scenarios for the data center.

Types of data center

This section will provide an overview of each of the current scenarios mostly being used today.


As mentioned previously, an on-premise data center is considered the traditional model. Organizations build out and operate their infrastructure on your business's property or off-site at a separate facility. In this model, you are fully responsible for everything in the physical infrastructure (building, power, cooling, hardware, security, access, and so on) and everything that runs on the hardware. The following is an example of a traditional on-premise model:

Figure 3.1 – On-premise data center


As we look further into the cloud model, it is important to understand public and private cloud offerings. A public cloud is where the services are hosted by the provider and the underlying infrastructure is shared with other organizations. Your environment will be logically separated from other organizations, but the underlying hardware, network, and storage is shared with other subscribers on the same service. A private cloud offering is where the services are hosted in a dedicated environment and only your organization runs on the underlying services. Determining the appropriate model will most likely be dictated by your organization's industry and compliance requirements.


You can find more information on public versus private here:

The following is an example of a cloud model:

Figure 3.2 – Cloud model

Cloud solutions have three different types of primary services available for consumption:

  • Infrastructure as a Service (IaaS):

    IaaS requires the most involvement from your organization and is operated very similarly to a virtualized environment on-premises. The difference is that businesses have no responsibility for physical infrastructure and the servers, storage, and network are all managed by the hosting provider. You can simply turn on virtual machines and services as needed.

    Important note

    What is IaaS?:

  • Platform as a Service (PaaS):

    With PaaS, you are provided with the required platform from the cloud provider. In addition to the physical infrastructure, the operating system, middleware, and other tools to run services are also managed by the hosting provider. For example, in a traditional IaaS Windows environment, you would need to install Internet Information Services (IIS) to deploy a web server or install SQL to deploy a database server. With PaaS, you simply subscribe to an Azure Web App or Azure SQL database and you consume the service once it’s available. There is no install or maintenance of any underlying software to run these apps.

    Important note

    What is PaaS?:

  • Software as a Service (SaaS):

    The third available service is Software as a Service. This service requires the least involvement and essentially provides you with the entire software solution to be consumed. In addition to what is managed for both the IaaS and PaaS services, the hosting provider also maintains the application itself, including keeping it current and up-to-date. An example of a SaaS offering would be Exchange Online, in which your entire Exchange environment is hosted, kept up to date, and managed by Microsoft. You simply consume the email services for your organization.

    Important note

    What is SaaS?:

Now that we have covered what each of the cloud services are, let's look at some examples of what falls within the Microsoft ecosystem for each of these services. The following diagram provides some examples of what you can subscribe to within each of the services:

Figure 3.3 – Microsoft IaaS, PaaS, and SaaS examples


The last model we will review is the hybrid model. A hybrid model essentially combines the on-premise model with the cloud model, allowing an organization to use their on-premise data center at the same time as they're consuming cloud services. This model is most likely going to be preferred for most organizations simply because mature and expensive on-premise data centers can't easily be moved to a cloud model overnight. What the hybrid model does is allow a pathway from on-premise to the cloud while providing services from both environments.

Figure 3.4 – Hybrid model

The focus of this book will be primarily around the on-premise, hybrid, and IaaS models as this is where your Windows servers will reside and operate. With the PaaS and SaaS models, the underlying OS is managed and secured by the service provider.

Now that we've covered the different models available for operating data centers, we will move on and discuss access management as it relates to Windows Server. In the next few sections, we will cover securing access to Windows Server and introduce common strategies and security access best practices used by organizations.

Implementing access management in Windows servers

The concept of building a solid access foundation is critical as it relates to server management as part of the overall infrastructure. You must consider everything, from physical access to the servers to protecting unified management consoles for managing multiple virtual servers at once. In the next few sections, we will discuss physical access and user access to the infrastructure and the importance of each. Next, we will discuss privileged isolation through a tiered model approach and provide an overview of privileged access management (PAM) and privileged identity management (PIM) solutions. Implementing these tools will help you provide a robust system of server access management. It is highly recommended that you become familiar with the topics mentioned in this section and understand how critical they are when implemented in your organization. First, let's look at physical access and security.

Physical and user access security

An important factor to consider with the on-premise model is to ensure all physical access to any server locations is protected and only accessible to those defined through their role. Your Windows servers and other physical infrastructure are typically located in a server room, a closet in your office building, or in a remote facility that is under your ownership. Because of this, it is equally important that well-enforced security access controls are in place, in addition to server hardening. The physical access needs to be locked down to avoid equipment being stolen and help prevent insider attacks that could open an opportunity for malware to be installed, such as a keylogger through a USB device. Encryption needs to be enabled on all Windows servers in the event theft does occur to help circumvent any information from being stolen.


Don’t forget that your facility management and physical site access policies are just as important as your user access management to the servers.

As you make your move into the cloud world, your access management changes considerably. Physical access is now the responsibility of the cloud provider. The challenge is, how do you validate they are protecting your data with the utmost standards? This is where your contracts come into play, but more importantly, your due diligence, as it relates to audit requirements and SaaS questionnaires being provided by the cloud provider. We will cover audits in more detail in Chapter 13, Testing and Auditing.

The next consideration with the cloud model is management planes. On-premises deployments allows management solutions to be isolated from the internet and only accessible from your corporate network. With the cloud, the management pane and unified portals are internet-accessible and provide a single pane where you can access all your resources in one place, including your Windows servers. The downside? Anyone who compromises your access could have the keys to the kingdom. This is where a very stringent access policy is needed for your privileged identities. You need to ensure your regular user accounts are separate from your privileged accounts and that you enforce extremely strong access controls on your privileged accounts – no exceptions! The number of privileged accounts in your environment should be limited. Role-based access control (RBAC) needs to be defined if you wish to carve out a scope of who needs to access what resource.


Ensure that you separate privileged accounts from standard user accounts. No employee should ever use their regular identity to administer the environment.

Next, let's look at securing access using privileged access management, just-in-time access, and privileged identity management.

Privileged Access Management, Just-in-Time Access, and Privileged Identity Management

Continuing from the previous tip on identity, let's introduce three critical access models that need to be considered for implementation within your server environment. Privileged Access Management (PAM), Just-In-Time (JIT) access, and Privileged Identity Management (PIM) are all privileged access models that provide an additional layer of protection to your admins while they access your infrastructure. These models help ensure that privileged user accounts are only available as needed, have an expiration date regarding their usage, and are fully audited and monitored when accessing Windows. Privileged accounts can be your weakest link if they're not protected properly and investing in these models should be a requirement.

We will cover each of these models in full detail in Chapter 7, Identity and Access Management.

Equally as important as implementing an access management solution is creating a segregation layer between your servers. To do this, organizations architect a tiering model to isolate different groups of servers based on its criticality to the infrastructure. In the next section, you will learn about using a tiered model and what it means for privileged access security.

Using a tiered model for privileged access

The concept of the tiered model is to isolate and build layers of containment between the Windows systems in your environment. This is accomplished through Active Directory (AD) Organizational Units (OU) by designing a structure that is divided into three or more parent containers. They are labeled tier 0, tier 1, and tier 2. Tier 0 contains the systems, accounts, and security groups of the highest security concern such as domain controllers, Azure AD connect servers, and identity management systems. The goal of this isolation or "tiered" approach is to prevent escalation by provisioning account access to only the tier they need access to in order to perform an operation. If an account from a lower tier gets compromised, its elevation will be restricted to its assigned tier or lower in the model. For example, a user account in tier 1 will only access systems in tier 1 or tier 2. They wouldn't be allowed access to tier 0. Let's review each of the tiers in a three-tier model in more detail.

Tier 0

Tier 0 (top level) typically contains a small number of assets and those deemed critical to your infrastructure. Admins in tier 0 usually have administrative rights to each level tier below. Here, an actor can exhibit domain dominance if breached and have direct control over your environment. We would want to limit the use of and accessibility to tier 0 servers as much as possible and limit the number of accounts with provisioned access. Further logon and access restrictions should also apply to assets in tier 0 to ensure only clean sources are accessing them, including the restriction to the use of non-critical functions from these servers such as checking email or browsing the internet. Organizations should deploy a privileged access management solution within the server environment. The PAM solution must include password rotation, an approval request flow process, auditing logs, session recording, and even remote RDP or SSH launchers where credentials are hidden.


To take this a step further, restrict the use of non-critical functions such checking email or browsing the internet. Implement application control policies through Windows Defender Application Control to prevent unauthorized software from running. You can also limit access to systems by funneling traffic through SSH proxies from a PAM solution.

Tier 1

Tier 1 is your middle tier and contains systems such as business servers, file servers, web application servers, and database servers. Administrators with access to tier 1 will be able to control servers in both tier 1 and tier 2. These servers need to be protected with similar precautions as the ones outlined for tier 0. When architecting the organizational structure of the tiered model, create child Organizational Units (OU) nested under the tier 1 parent and label them by business unit, application name, or function. Group policy can be used to define restricted groups that explicitly grant access permissions to security groups created and named to fit the labeling schema. Group members have access rights to RDP and only log on interactively to these defined tier 1 servers and not all servers in the tier 1 hierarchy. This provides more granularity and levels of organization. It may be necessary to restrict the use of non-critical functions from these servers such as checking emails or browsing the internet. Certain precautions need to be taken in the event an account becomes compromised. A best practice is to implement a PAM solution where an administrator is required to check out a different account to access these systems altogether. Once the account is checked back in, the password is immediately rotated. This creates a separation of privileges.

Tier 2

Tier 2 (bottom level) will contain more common devices seen in the everyday workplace. This includes end user workstations, laptops, printers, and virtual desktops. This tier is used by your level 1 support desk and field IT employees. Tier 2 administrators should only be allowed to log on to assets that are in tier 2 or lower if they exist. In Chapter 7, Identity and Access Management, we'll discuss implementing access management in more detail, including a discussion around local administrative access to workstations. Depending on your environment, the approach may differ, as there are unique considerations for each environment.

The following screenshot shows an example of an OU structure that is recommended to support the tiered model approach. As you can see, in tier 0, there are separate OUs for admin accounts and server objects. This helps when creating policies that are either user targeted or computer targeted:

Figure 3.5 – An example OU structure of a tiered model approach

Now, let's look at some important things to consider.

Important considerations

Regardless of how many tiers are in the access model, there are important considerations worth discussing. Coupled with the tiered approach, each consideration – individually or combined – can add a substantial layer of security to your Windows systems. Let's take a look:

  • For RDP and interactive logon scenarios, the source should be restricted to a privileged access workstation (PAW) or isolated management environment requiring a form of biometric or multifactor authentication.
  • Network restrictions should be considered in tier 0 access scenarios by locking down incoming RDP connections and other management ports to sources from known VNETs, subnets, and workstations.
  • When designing your tiered solution, be mindful and think about built-in security groups with escalated permissions such as Enterprise Admins, Domain Admins, Schema Admins, and Server Operators, to name a few.
  • Local accounts can also become a problem if they’re not managed properly and are an easy way for someone to create a backdoor without your knowledge. A PAM solution with discovery alert rules can be used to notify security teams when these accounts are created. If you’re leveraging local accounts in an Active Directory domain, you can also implement Microsoft’s Local Admin Password Solution (LAPS) to rotate passwords.
  • Implement fine-grained password policies per tier to enforce stricter password requirements for administrative accounts.
  • Leverage security baselines and group policy to further restrict access using defined restricted groups. Lock down logon types where credentials are exposed such as remote desktop or RunAs (interactive) so that they only come from trusted sources such as a PAW.

By using services from the Azure cloud, privileged access workstations can be deployed using a virtualized desktop service such as Windows Virtual Desktop or Citrix. Azure also has PaaS offerings available to cater for this scenario, such as the Azure Bastion service. Azure Bastion allows you to securely RDP or SSH directly to virtual machines over SSL, eliminating the need to expose your servers directly to the internet. This can all be done directly in the Azure portal, with no additional infrastructure. For on-premises installations, an enhanced security administrative environment (ESAE) can be used to administer the production forest.

Enhanced security administrative environment

The next design we will review is the ESAE administrative forest model. At a high level, you will set up a separate Active Directory forest that will be used for administrative purposes only. In this forest, you will build your user accounts and groups that will be provided with privileged access in the production user forest to complete any administrative tasks. To enable cross-forest access, one-way trust is created from the production user forest to the administrative forest. This allows the privileged administrator accounts to manage the production user forest. With this approach, you can completely isolate your privileged accounts from your standard user accounts, reducing the risk of compromise with elevated access within your production environment. This architecture, which is outlined in the following diagram, is also used by Microsoft's cybersecurity professional services teams to protect its customers:

Figure 3.6 – The ESAE model

There is a lot more involved in setting up these models for your environment. To review additional details on both the tiered model and ESAE model for privileged access security, visit


Both models require time and investment to implement correctly. It is easy to fall back and apply elevated access to standard users and over permission accounts to meet deadlines and so on. Don’t fall into this trap! Ensure you spend time implementing these models correctly from the ground up and clearly define the account provisioning process. Enforcing these models will help ensure success with your security and hardening.

Now, let's recap and talk about access management best practices.

Access management best practices

Securing access to your environment can be a long and complex journey with many considerations to keep in mind. Security is an ever-evolving space due to the complexity and frequency of cyberattacks. New tools and services are regularly becoming available for organizations to help drive their business and are for those that simply don't have the resources, funds, or capabilities to deploy the solutions needed to protect them. Here is a high-level list of best practices to keep in mind when thinking about the scope of privileged access for your Windows servers and business services:

  • Enforcing multi-factor authentication (MFA) should be at the top of the list. Require MFA for all cloud-based accounts using Azure MFA or another provider. For on-premise servers, you can install Azure MFA Server and have finer control over MFA methods.
  • Deploy a Privileged Access Management (PAM) solution.
  • Use just-in-time access to assign permissions dynamically and avoid permanent assignment for your privileged accounts. Helpful services include Azure Privileged Identity Management (PIM) coupled with Azure Security Center just-in-time access.
  • Have an effective account provisioning and deprovision process. Automate disabling accounts when employees leave the company.
  • Frequently audit privileged accounts in your environment.
  • Limit the number of administrators. Always consider job role and function when provisioning administrative accounts and ensure the principal of least privilege applies.
  • Separate administrative accounts with regular user’s accounts. This will help mitigate credential exposure if the administrator’s workstation becomes compromised.
  • Limit access to email and internet browsing when applicable from privileged systems.
  • Enforce strict fine-grained password policies on administrative accounts.
  • Limit the amount of emergency “backdoor” accounts and monitor their usage.
  • Ensure any changes to the environment go through an approval process by a change advisory board. This can include access to highly sensitive systems.

Go here for additional information on securing privileged access:

Now that you have an understanding of the different models used for access to Windows workstations and servers, next, we will discuss the tools used to help manage them. Although some are common, it is important to be aware of their utility when building baselines and hardening Windows.

Understanding Windows Server management tools

There are many tools available for Windows Server that are useful for both managing and securing the infrastructure. Management technologies were traditionally developed for on-premises deployments, but now, with cloud-based SaaS offerings, it seems the available solutions are growing exponentially. Microsoft offers solutions for enterprise-grade management through its System Center suite of tools such as Operations Manager (SCOM) and Configuration Manager (SCCM). There are also third-party paid solutions from companies such as ConnectWise, SolarWinds, and CA Technologies, to name a few. Each offers a different feature set, depending on your management needs and varying price points. In this section, we will review the more common built-in tools available in Windows Server, including Server Manager, Event Viewer, and Windows Server update services for patch management. Then, we will discuss Windows Admin Center and how it can be used to help transition workloads into the Azure cloud.

Introducing Server Manager

Server Manager was introduced in Server 2008. It provides a centralized management tool for servers and can support up to 100 remote servers. The number of remote servers will vary, depending on their workload system performance of the server running it. Server Manager can also be installed on a workstation computer with Remote Server Administration Tools (RSAT). To remotely manage servers, remote management must be enabled through Server Manager or with PowerShell. This is enabled by default in Windows 2012 and later. A list of tasks that can be completed through Server Manager include the following:

  • Create, edit, or add custom server groups or pools of servers and clusters.
  • Install, uninstall, or make changes to roles and features on both the local and remote servers.
  • Open management tools such as Computer Management, Windows PowerShell, Registry Editor, and other MMC tools.
  • Start and stop services, identify events, and collect performance data for analysis.
  • Restart servers.
  • Export settings to be imported on another system.

To add remote servers to Server Manager from the Dashboard view, right-click All Servers and choose Add Servers. Once servers have been added, all the roles that are capable of being managed will be added to the left-hand column. These roles are now available for management from a centralized point. Creating a server group will create a link on the left column for quick access to different sets of servers. The following screenshot shows the MyServers server group:

Figure 3.7 – A custom server group named MyServers, useful for quick access

Server Manager is a great place to view events, services, and performance from a single application. Events can be viewed and configured from every page except the dashboard. Certain event logs such as application logs are selected by default and include Critical, Error, and Warning severity levels, but they can be customized to fit your needs. The thumbnail alerts can be configured to include other events, and different severities can be included in alert highlighting. Only critical events are highlighted by default.

Using the Best Practices Analyzer (BPA)

The Best Practices Analyzer (BPA) tool is used to help reduce vulnerabilities by scanning the configured roles and comparing your configurations to what experts believe to be best practice guidelines. BPA can be executed from Server Manager as well as through Windows PowerShell. After the scan completes, the results can be viewed. These show whether a role is compliant with these best practices. The summary outlines the problem in detail, as well as list the impact and resolution steps. This can be seen in the following screenshot:

Fig 3.8 – Results from a BPA scan on Windows Server 2016 showing misconfigurations

For more information, please go to

Next, we'll look at using Event Viewer and examine common event IDs.

Looking at Event Viewer

Event Viewer is used to view log files from applications, including security and system-related events. Events are separated into error, warning, and informational events, which can also be useful for troubleshooting performance issues. PowerShell can be used to query events and Event Viewer can be used to view logs from remote computers. Event Viewer can be opened by using Windows Search and typing in Event Viewer. Once opened, to view logs from a remote computer, right-click on Event Viewer (local) at the top of the tree and choose Connect to Another Computer….

Event Viewer can also be used for automating actions. Using Attach a Task to this Event action, a basic scheduled task can be created and run based on a specific event.


Event Viewer is very important for monitoring Windows events from a security perspective. Security professionals should pay close attention to sources from login activities, application crashes, network firewall rule changes, clearing of event logs, audit policy changes, and group policy changes.

Security-specific logs can be found in Windows Logs > Security. The following screenshot shows Event ID 4624, which indicates a successful logon. This Event ID contains a lot of information, including the Logon Type, account information, and network information about the user who has logged on:

Figure 3.9 – Event 4624, successful logon in Event Viewer

There are common security events to look for under Windows Logs > Security that could indicate an attacker attempting to grant access rights or access the system. While these event IDs are normal and typically do not indicate an attack, in the event a compromise was recognized, they are useful to mention and can help build a picture around the attack's timing and provide additional details during analysis:

  • 4625: Audit Failure Logon
  • 4624: Audit Success Logon
  • 4648: Login with explicit credentials
  • 4735: Security-Enabled local group was changed
  • 4728, 4732, and 4756: Member added to a security group
  • 4740: Account Lockout
  • 1102:Log Clear may indicate an evasive tactic by an attacker

Event ID 4624 includes a logon type field, which is useful for identifying how an account has logged into the system. The following table demonstrates the different logon types that are associated with Event ID 4624:

Figure 3.10 – Logon types for Event ID 4624

Windows Defender Event Viewer logs are useful for security monitoring and can be found under Applications and Services Log > Microsoft > Windows > Windows Defender. Interesting event IDs, including those for canceling or pausing malware protection scans, could indicate a malicious actor, prevalence of malware, or warrant further investigation.

Important note

Further reading on Windows Defender antivirus event IDs can be found at

From an operational perspective, especially when a security operations center (SOC) needs to monitor many systems, looking at Event IDs on servers individually isn't the most effective method. It is recommended to incorporate a security information and event management (SIEM) solution to better track and analyze event logs. Examples of a SIEM solution include Microsoft's security monitoring tools such as Azure Sentinel, Defender Advanced Threat Protection, Cloud App Security, and Azure Security Center or third-party tools such as Splunk, which can be used for log repositories and analysis. We'll cover SIEM tools and security monitoring in more detail in Chapter 11, Security Monitoring and Reporting, and Chapter 12, Security Operations.

Next, let's look at how to leverage Windows Server Update Services to manage security updates and patch vulnerabilities in the operating system.

Using Windows Server Update Services

Windows Server Update Services (WSUS) is used to keep standard security patch levels across your servers. In some instances, maintaining the same patch level is critical for applications to run, and relying on the standalone Windows Updates service doesn't suffice for this level of control. WSUS allows you to approve updates and choose when to deploy them. In a simple WSUS architecture, the WSUS downstream server talks to the Microsoft Update upstream server to act as the intermediary. Using a centralized console allows administrators to download critical updates, security patches, rollups, service packs, feature packs, Microsoft product updates, and antivirus definition files. Computers can be grouped together and targeted for a deployment.

For most deployments, WSUS requires minimal processing power on the host computer to operate and a single WSUS instance can host upward of 100,000 clients. For environments greater than 100,000 clients, multiple WSUS servers can be deployed by using a load balancer frontend. A single SQL server database will need to be deployed and shared by each WSUS instance if you're using a single centralized WSUS management solution to serve multiple locations and branch offices.

From a firewall perspective, clients connect to WSUS over HTTP/TCP port 8530. It is recommended to secure communications by deploying a custom SSL for clients to connect HTTPS/TCP over port 8531. IIS is required if you wish to use WSUS in both scenarios:

Figure 3.11 – List of security updates available for approval in the WSUS management console

Windows Defender Antivirus is the AV solution built into Windows 10 and Windows Server 2016 and later. If you're using WSUS, definition updates need to be scoped and downloaded from Microsoft Updates. Administering definition updates works similarly to Windows Updates and will require approval before your endpoints receive them. Consider creating automatic approvals for antivirus definition updates to ease the administrative overhead required to manage WSUS. Automatic Approvals allow you to automatically approve the installation for new updates for specified groups of systems.

WSUS can also deploy third-party updates for commonly used software such as Adobe Reader. Combining WSUS with a Configuration Manager software update point allows you to create a third-party software update catalog. Here, you can subscribe to a partner catalog that's connected to various software vendors that have partnered with Microsoft for releasing updates to their products. We will cover Configuration Manager in more detail in Chapter 4, End User Device Management, and Chapter 8, Administration and Remote Management. WSUS can be enhanced further by leveraging a cloud solution called Azure Automation Update Management. Update Management can manage updates for Windows and Linux systems hosted in Azure and on-premises directly with the Azure portal. This service supports Windows server downward to 2008 R2 and will be covered in more detail later in this chapter and in Chapter 10, Keeping Your Windows Server Secure.

As discussed in Chapter 1, Fundamentals of Windows Security, here are some helpful links for staying up to date on security updates:

In the next section, we will look at Windows Admin Center, a recently released tool that can help manage your servers.

Introducing Windows Admin Center

Windows Admin Center was released in April 2018 and provides an alternative to classic MMC and other remote management tools. Windows Admin Center is a browser-based tool that can be installed on Windows 10 or Windows Server 2016+. It supports the management of servers down to 2008R2 but may have limited functionality. No agents are required, and the UI frontend is fully built on WMI with PowerShell over WinRM to execute operations. To support down-level servers, Windows Management Framework (WMF) 5.1 is required. More information, including how to install MSI, can be downloaded from


Windows Admin Center runs in HTML 5 and requires Microsoft Edge or Google Chrome browser to run on Windows Server. It cannot be installed directly on a domain controller.

Windows Admin Center's tools include Active Directory, DHCP, DNS, Firewall, Remote Desktop, Roles and Features, Scheduled Tasks, and Updates, to name a few. Many more features are available through extensions, including support for third-party developers.

Windows Admin Center can be used to manage on-premises and IaaS servers. It is included for free with your Windows Server license. A real piece of added value is that it allows you to shift on-premises workloads to Azure directly from the UI. With the appropriate tenant details and permissions, you can deploy and configure the Azure services directly through Windows Admin Center without having to open the Azure portal.

The Azure services available through Windows Admin Center include the following:

  • Azure Site Recovery
  • Azure Backup
  • Azure File Sync
  • Azure Monitor
  • Azure Update Management
  • Azure Active Directory Authentication

Windows Admin Center can be fully integrated with Azure Active Directory for authentication and supports MFA. The following screenshot shows the overview pane of Windows Admin Center:

Fig 3.12 – Overview page of Windows Admin Center in Google Chrome

Next, let's look at Azure services that are useful for managing Windows Server environments.

Using Azure services to manage Windows servers

As discussed in the Understanding Windows Server management tools section, Windows Admin Center exposes Azure cloud services that can provide additional benefits for managing Windows servers. It is recommended that you start moving workloads to the cloud not only as part of your digital transformation, but also as a security initiative. Azure Active Directory roles and role-based access control (RBAC) allow for a fine-grained level of access provisioning over the management plane. In the next section, you will learn about the Azure services that are available for managing Windows servers for both IaaS and on-premises deployments. We will cover the following topics:

  • The Azure portal and Marketplace
  • RBAC
  • Azure Resource Manager
  • Azure Backup
  • Azure Update Management
  • Azure Site Recovery

The Azure portal and Marketplace

Simply put, the Azure portal is the user interface that's used to manage resources in the Azure cloud. Most operations can be performed directly through the Azure portal, but some advanced configurations will require the Azure Command-Line Interface (CLI), Azure PowerShell, or direct calls to the Graph API. Microsoft is doing a great job of adding many operations only supported by these command-line tools directly to the user interface in the portal. Follow these steps to access the portal:

  1. Open a browser and navigate to
  2. Sign in with your Azure account username and password.
  3. If you don’t have an Azure account, click Create one! to set one up.

To view and access your virtual servers within the Azure portal, simply click on Virtual Machines. You will be provided with the Virtual machines management page:

Fig 3.13 – Microsoft Azure portal Virtual machines page

We won't be going into detail around navigating the Azure portal, but we do want to call it out as an important tool for not only managing Windows servers, but also all cloud resources. For detailed instructions on customizing its look and feel, as well as creating custom dashboards and setting favorites, you can visit

Using the Azure Marketplace

The Azure Marketplace is the storefront in Azure where you purchase resources and solutions and deploy them directly to your tenant. There are many offerings available, from custom VM images, to databases, networking solutions, IoT, DevOps, and more. It can be accessed from the Azure portal or by going to

In respect to Windows Server, the marketplace is useful for deploying pre-built images, which can be done in just a few clicks directly from the portal. You can use the Azure Marketplace to customize and create a Windows Server instance and then capture the customizations in a JSON template. By using this JSON, multiple servers can now be deployed at scale with all your custom configurations:

Figure 3.14 – Windows Server purchasing option from the Azure Marketplace in the Azure portal

With Azure Active Directory roles and role-based access controls, resource creation is typically locked down for Global Administrators or roles with contributor rights.

Next, we'll look at how to lock down access to Azure resources by implementing RBAC. We will also learn how to create a custom role using PowerShell and JSON.

Implementing role-based access control

RBAC in Azure is used to authorize access to resources through role assignments. A role assignment consists of a user, group, or service principal that has a set of permissions assigned. Those permissions are then scoped to a subscription, resource group, or resource. Permissions are inherited from parent scopes, so if a role assignment is set on the resource group level, all resources nested under that resource group will be in scope of the role assignment. When assigning permissions, RBAC takes an additive model. If the user is assigned to multiple roles, the least restrictive role won't take effect and will be assigned any additional rights for each additional role. Explicit Deny assignments must be applied to determine which set of actions are not allowed; otherwise, access is granted.

There are four main roles in Azure RBAC, and these are the standard levels of roles that can be applied to a scope. These are owner, contributor, user access administrator, and reader. Only the owner and user access administrator roles have permission to grant access rights for other users. Each role has the concept of action types such as Actions, NotActions, DataActions, and NotDataActions. When building a role definition, Actions refers to the management operations of the resource and controls things such as access, where DataActions refers to the underlying data operations such as read blobs in a container. Azure offers over 70 additional built-in RBAC roles that are preconfigured for specific use cases as they pertain to certain resources. Using JSON, you can export a built-in RBAC role and build custom roles to fit your needs. For more information regarding the role definition structure, go to

In the following example, we will edit the Virtual Machine Contributor role and make a custom RBAC that contains all the VM contributor role permissions, including DataAction, to administratively log in to virtual machines. Let's get started:

  1. Open PowerShell as an Administrator and install the Azure module. Choose [A] Yes to All when asked to install from an untrusted repository. Then, connect to Azure using the Connect-AzAccount cmdlet and retrieve your subscription ID. Take a note of the subscription ID; you will need this later:

    Install-Module -Name Az


    Get-AzSubscription | Select ID

  2. Enter your credentials at the password prompt and perform MFA to connect to your Azure tenant.
  3. The first step is to export the built-in Virtual Machine Contributor role as the JSON template to build the custom role. We will export the role definition as JSON using the Get-AzRoleDefinition cmdlet:

    Get-AzRoleDefinition -Name “Virtual Machine Contributor” | ConvertTo-Json | Out-File “C:\MyFolder\VMContributor.json”

  4. Open the VMContributor.json file we exported previously using a code editor of your choice, such as Notepad++, Code Writer, or even basic Notepad. We will need to make some modifications and save the file as a JSON, ready to be reimported.
  5. On line 2, change the value of “Name” to Administrative Virtual Machine Contributor:

    “Name”: “Administrative Virtual Machine Contributor”

  6. On line 4, change the value of “IsCustom” to true:

    “IsCustom”: true,

  7. Modify “Description” on line 5 so that it reads as follows:

    “Description”: Lets you manage virtual machines, but not access to them, and not to the virtual network or storage account they are connected to.  Allow administrator login.”,

  8. To allow administrative login, we will need to add the ARM resource provider operation called Microsoft.AAD for the DataAction action type and the Microsoft.Compute/virtualMachines/login/action and Microsoft.Compute/virtualMachines/loginAsAdmin/action operations.
  9. On line 50 in the JSON, add these two lines:



  10. Next, we need to populate the “AssignableScopes” section. If you exported the built-in role, the / root value will be prepopulated, but this is only applicable to built-in roles. Assignable scopes can be scoped to multiple subscriptions, management groups, resource groups, or resources. In this example, we are going to use the subscription ID of our tenant. The subscription ID can be found using the PowerShell cmdlet, as we saw earlier, or through the Azure portal UI and typing “subscriptions” in the search field. Modify line 57 so that it includes the subscription ID:

    “AssignableScopes”: [



  11. Finally, save the edited JSON file. We will now import it using the New-AzRoleDefinition cmdlet:

    New-AzRoleDefinition -InputFile “C:\MyFolder\VMContributor.Json”

If its creation was successful, the custom role will be seen from the Access control (IAM) blade in your Azure subscription:

Figure 3.15 – Successful creation of the Administrative Virtual Machine Contributor role in the Azure portal

For more information about the resource provider operations that are available, visit this link:

For more information about JSON, visit this link:

Next, we'll take a look at the current management plane for Azure resources, which is called Azure Resource Manager.

Azure Resource Manager

It is important to be aware of Azure Resource Manager if you're working with Azure cloud to deploy Windows servers and other infrastructure. Currently, Azure Resource Manager is defined as a highly resilient management plane for all services that run in Azure. Any controls used that directly affect the management and security of resources is done through Azure Resource Manager. Azure Resource Manager, or ARM for short, can be manipulated directly using the Azure portal, Azure PowerShell, Azure CLI, or through APIs and custom tools developed with a software development kit (SDK). Custom templates written in JSON can be created and declaratively deploy resources repeatedly, at scale, and tracked directly in the Azure portal. More information about creating Azure Resource Manager templates, including the sections that make up the JSON, can be found at


Additional information, including key terminology, benefits, and a descriptive understanding of the scope of the management plane, can be found at

In the next section, we will talk about using Azure Backup for creating backups of our servers.

Understanding Azure Backup

Azure Backup is a cloud service that can be used to replace an on-premises backup solution or used as an automatic storage management tool for hybrid scenarios where data is stored both on-premises and in the cloud. It requires zero infrastructure, has unlimited scaling capabilities, provides application-consistent backups, and data is encrypted both in transit and at rest. Azure Backup offers unlimited data transfers ingress and egress from Azure at no additional cost. There are locally redundant (LRS) and geo-redundant (GRS) storage options available, depending on your high availability needs. There is no time limit regarding data retention, and you can store up to 9,999 recovery points.

Important Note

For additional information on the Azure Backup service, go to

In Windows Admin Center. you can take advantage of the built-in management and monitoring tools all from within the Backup dashboard.

Azure Backup's requirements include the following:

  • A valid subscription
  • Resource Group
  • Recovery Services Vault
  • Agent Deployment

Azure Backup includes Application- and Crash-consistent backups:

  • Application-Consistent Backup: Use Windows VSS writers to create the backup and capture memory content and pending I/O operations. When recovering a VM using an app-consistent snapshot, there is no data loss.
  • Crash-Consistent Backup: This occurs if an Azure VM shuts down during the time of a backup. Only disk data at the time of the backup is captured and a recovery doesn’t guarantee data consistency.

These two options can be seen in the following screenshot:

Fig 3.16 – Restore points of a Windows Azure VM with Application-Consistent restore points

Securing Azure Backup

For on-premises backups, encryption is done using a customer-specified passphrase. Once in transit, data is encrypted using AES256 and sent over HTTPS to Azure. For Azure VMs, data at rest is encrypted using Storage Service Encryption (SSE) and protected by HTTPS in transit while never leaving Azure. Azure Backup can also back up VMs that are encrypted using Azure Disk Encryption.


For customer specified passphrases, DO NOT lose the encryption passphrase. It is required to restore backups. Microsoft CANNOT recover this for you.

Backup data contains highly critical information and needs to be properly secured from unauthorized access. Access can be managed using Azure RBAC. Authentication also takes place through Azure Active Directory and monitoring is supported using Log Analytics. Let's highlight the built-in RBAC roles for Azure Backup:

  • Backup Contributor has permissions to create and manage backups but cannot grant access or delete Recovery Services vaults.
  • Backup Operator has similar permissions to the contributor except for removing backups and changing policies.
  • Backup Reader can view all backup operations for monitoring purposes only.

For hybrid scenarios, additional security features are available, such as configuring retention periods, notifications for changes, and the ability to create security pins.

Another security feature for backups is soft delete. Soft delete is a feature that retains backups for 14 days after a deletion action and allows recovery without data loss at no additional cost. While this feature is enabled by default, you can permanently delete soft deleted backup items immediately or disable the feature altogether.

Important note

More information about Azure Backup RBAC can be found at

In the next section, we will discuss using Azure Update Management to deploy updates to our servers.

Introducing Azure Update Management

As described earlier in Using Windows Server Update Services , Update Management is the Azure cloud-based solution to managing system updates for Windows. Update Management is available for the cloud and on-premises deployments.

The requirements to deploy Azure Update Management are as follows:

  • Azure Subscription
  • New or existing resource group
  • Log Analytics workspace
  • Azure Automation account
  • Deployment of the Microsoft Monitoring Agent (MMA)
  • Microsoft Update or WSUS configured on your systems

Update Management can be deployed using Windows Admin Center by following the onboarding steps directly in the portal. For information about onboarding multiple VMs from the Azure portal, go to The following is a screenshot of Update Management from the Azure portal automation account:

Figure 3.17 – Update Management dashboard, which shows the update compliance of individual Windows servers

The compliance comparison for the servers listed in the Update Management page will be compared to your WSUS server or directly to Windows Update services. Machines can be added by clicking on Add Azure VMs at the top of the page. For Non-Azure servers, the Microsoft Monitoring Agent can be deployed and configured to use the Update Management Log Analytics workspace during setup or when onboarded with Windows Admin Center. The following screenshot shows the missing updates tab, which lists all missing updates from your systems and includes columns that display details about the update name, classification, machines missing updates, operating system, and a KB information hyperlink:

Figure 3.18 – Overview of available updates and the machines missing each update

Update deployments using update groups can be scheduled using the Schedule Update Deployment option at the top of the toolbar. Update groups can be created by using dynamic queries based on resource groups, locations, and tags, or you can explicitly select the machines you wish to include. There is a dropdown to scope which classification of update to deploy, as well as options to include or exclude specific KBs. The schedule settings allow you to set a one-time or recurring deployment. Additional options include setting a maintenance window time and several options for reboot behaviors.

The deployment status can be monitored with alerts using Azure Monitor. Action groups allow notifications via email/SMS/push/voice and can even trigger a webhook or Azure Automation runbook.

For additional information about the Update Management solution in Azure, go to

The following are the Windows operating systems supported by Azure Update Management:

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 and R2
  • Windows Server 2008 R2


    Windows Clients and Windows 2016 Nano Server are not supported at this time.

We will cover how to set up and configure Azure Update Management in more detail in Chapter 10, Keeping Your Windows Server Secure.

Next, we'll look at Azure Site Recovery (ASR). Azure Site Recovery can be used as a disaster recovery scenario or as a tool to move systems in Azure.

Leveraging Azure Site Recovery

Azure Site Recovery is a business continuity and disaster recovery solution built into Azure for all types of workloads. The solution covers both Azure and on-premises Windows servers and VMs. Azure Site Recovery (ASR) consists of two major components:

  • Site Recovery Services: Used for the replication of virtual machines and workloads from a primary to a secondary region in Azure.
  • Backup Services: Azure Backup service for data backup and recovery.

For more information on Azure Site Recovery, visit this link:

When building a business continuity (BC) and disaster recovery (DR) strategy, most organizations outline recovery time objectives (RTOs) and recovery point objectives (RPOs) for business-critical services and applications. By using the Azure Site Recovery service, these workloads and virtual machines are replicated from primary to secondary sites. If a regional outage occurs in Azure, you can initiate a failover to the secondary region to meet the RTO/RPO objectives of the business continuity plan. Let's take a look at these in more detail:

  • Recovery Time Objective (RTO): The established duration of time for each business process in which services must be restored to meet SLAs.
  • Recovery Point Objective (RPO): The maximum amount of data that could be lost during a major outage. For example, if the RPO is 24 hours and the last backup was completed 6 hours ago at the time of an outage, there is 18 hours of time until the business will suffer a significant volume of data loss, as defined by the business objective’s RPO.

ASR supports building customized recovery plans that allow you to strategically plan what services, VMs, and critical infrastructure fail over and when. Using PowerShell and Azure Automation, many tasks during the failover/recovery process can be automated. ASR also supports testing the failover through recovery plans. Using the overview dashboard, organizations can monitor the site recovery and backup of resources that are scoped for the Azure Site Recovery service:

Figure 3.19 - Site Recovery dashboard view, which shows an overview of configured recovery services


Azure Site Recovery is a great solution for migrating on-premises machines to Azure using the same steps that were defined for disaster recovery, but without the failback! For more information, go to

There is an overwhelming number of tools and services available in Azure that support the management of your Windows infrastructure and Azure environment. Unfortunately, we won't be able to cover them all in this book, but you can view a comprehensive list of all Azure resources here:


In this chapter, we provided an overview of the traditional on-premise data center and the most current model available, known as the cloud. Within the cloud model, we covered the three primary services, known as IaaS, PaaS, and SaaS, and then finished this section with an overview of the hybrid model. Next, we reviewed secure access management as it relates to both physical and user access to Windows servers and infrastructure. We then covered privileged access models with best practices for secure access management.

The following section covered Windows Server management tools, including Server Manager, Event Viewer, WSUS, and Windows Admin Center. The final section of this chapter moved on to Azure services for managing Windows servers. In this section, we provided details about the Azure portal and Marketplace, Azure RBAC, Azure Resource Manager, Azure Backup, Azure Update Management, and Azure Site Recovery. While we quickly scratched the surface of many available tools, we hope the acknowledgement of these services may spark an interest in you to research further. These concepts may eventually lead to these services being implemented in your own environment, which will increase your overall security posture.

In the next chapter, we will shift our focus away from the server infrastructure to end user device management. This chapter will cover the evolution of device management and the tools that have been used over the years. We will then cover these tools in more detail, specifically the ones regarding device imaging and Windows autopilot, Microsoft Endpoint Configuration Manager (formerly System Center Configuration Manager), and Intune.