Mastering Windows Server 2025

Copyright © 2025 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Early Access Publication: Mastering Windows Server 2025

Early Access Production Reference: B32320

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK

ISBN: 978-1-83702-991-4

www.packt.com

Mastering Windows Server 2025 Fifth Edition: Advance from IT Pro to SysAdmin with hands-on labs, tools, and real-world scenarios

Welcome to Packt Early Access. We’re giving you an exclusive preview of this book before it goes on sale. It can take many months to write a book, but our authors have cutting-edge information to share with you today. Early Access gives you an insight into the latest developments by making chapter drafts available. The chapters may be a little rough around the edges right now, but our authors will update them over time.You can dip in and out of this book or follow along from start to finish; Early Access is designed to be flexible. We hope you enjoy getting to know more about the process of writing a Packt book.

Chapter 1: Getting Started with Windows Server 2025

Chapter 2: Installation and Management

Chapter 3: Active Directory

Chapter 4: DNS and DHCP

Chapter 5: Group Policy

Chapter 6: File Management

Chapter 7: Certificates

Chapter 8: Networking with Windows Server 2025

Chapter 9: Remote Access

Chapter 10: Hardening and Security

Chapter 11: Server Core

Chapter 12: PowerShell

Chapter 13: Redundancy in Windows Server 2025

Chapter 14: Containers

Chapter 15: Hyper-V

Chapter 16: Remote Desktop Services

Chapter 17: Troubleshooting

1 Getting Started with Windows Server 2025

Join our book community on Discord

https://packt.link/zYovfDriving around the interface of a Windows Server is usually comfortable territory for anybody who is regularly working on a Windows computer. This is because historically Windows Server operating systems have utilized the same code-base for a graphical interface as their workstation counterparts. Additionally, in most cases throughout Windows rollout history it has been true that any release of a major version of Windows Server follows closely on the heels of a Windows workstation version increase, and familiarity with your desktop equates to automatic ease of navigation on the new server. In fact, let’s take a minute and walk through that history for anybody here who is not on the gray-hair side of IT (me) and may not have this historical context.Many years ago, Microsoft adjusted its operating system release ideology so that the latest Windows Server operating system maintained a similar graphical structure, and very similar release date, to whatever the latest and greatest Windows client operating system was going to have. This has been the trend for some time now, with Server 2008 R2 closely reflecting Windows 7, Server 2012 feeling a lot like Windows 8 (unfortunately), and many of the same usability features that came with the Windows 8.1 update also included with Server 2012 R2. This, of course, carried over to Server 2016 as well—giving it the same look and feel as if you were logged into a Windows 10 workstation.At the time of Server 2016’s release, we were already familiar and comfortable with the Windows 10 interface, and it felt quite natural to jump right into Server 2016 and start giving it a test drive. Windows Server 2019 diverted from this standard path a little bit, by maintaining a look and feel that was very similar to its predecessor, Server 2016. Why did Server 2019 not come with a fancy new graphical interface to match the new version of a Windows client Operating System (OS)? Because Microsoft changed the game with Windows 10. Now, instead of releasing new versions of Windows (11, 12, 13, and so on), we were, for the time being, simply sticking with Windows 10 and giving it sub-version numbers, indicative of the dates when each operating system version was released. For example, Windows 10 version 1703 was released around March 2017. Windows 10 version 1709 was released in September 2017.Then came 1803 and 1809—although 1809 was delayed a little and didn’t release until somewhere closer to November, which wasn’t the original plan. Follow that up with 1903 and 1909, and you start to see a pattern emerging. Then we moved into the year 2020, and suddenly our spring release of Windows 10 was called 2004. Hmm… 2004 sounds fine when you pronounce it “twenty-oh-four”, indicating the year 2020 and the month of April, but when seeing 2004 on paper, most folks started calling it “two-thousand-four”, which sounds quite old and outdated, don’t you think? I can’t say for sure, but perhaps this is part of the reason that the next release version of Windows 10 went by the name 20H2. This nomenclature seems to have stuck around, and we are continuing the trend with bi-annual client OS releases that reflect this pattern. All in all, you can see that Microsoft’s current plan is to continue releasing a new feature release version of the Windows operating system every 6 months or so.However, expecting IT departments to lift and shift all of their servers just for the purposes of moving to an OS that is 6 months newer is crazy; sometimes it takes longer than that simply to plan a migration, let alone execute it.Anyway, I’m getting ahead of myself a little, as we will discuss the versioning of Windows Server later in this chapter, in our Windows Server versions and licensing section. The point here is that Windows Server 2019 looks and feels like the latest version of the Windows client operating system that was released at about the same time—that OS being Windows 10 1809.Now forget everything I ever told you, as we queue the caveat of Windows Server 2022. When this last major server version hit shelves, it was after Windows 11 was out in the wild, yet Server 2022 stuck with the more traditional Windows 10 graphical interface. At the time I thought this to be a good idea, and indeed I maintain that given some discomforts with Windows 11 at the time this seems to have been a good move, whether it was intentional or a side effect of the updated GUI not being quite ready to ride on a server. Whatever the true reason, Microsoft essentially left the GUI alone when releasing Windows Server 2022. It is genuinely difficult to tell, graphically, whether you are working on a 2019 or a 2022 without checking System Properties.So, what about Windows Server 2025? I just finished creating an instance of this brand-new operating system, it booted successfully, and I’m staring this in the face.

Figure 1.1: The Server 2025 lock screen

I’m sure you saw where this was going, we now have the Windows 11 graphical interface! At this point in the Windows 11 journey, you should be quite comfortable with using it. Indeed, as I type these words we are facing the fact that Windows 10 goes end-of-life in less than one year. We will see much more of this updated interface as we work throughout the entire book, but for the purpose of this chapter I want to discuss more of the conceptual enhancements and benefits brought to us through Windows Server 2025.Before we get started talking about the features of Windows Server, it is important to establish a baseline for usability and familiarity with the operating system itself before diving deeper into the technologies running under the hood.Let’s spend a few minutes exploring the new graphical interface and options that are available for finding your way around this latest release of Windows Server, as we cover the following topics:

The purpose of Windows Server

Your head in the clouds

Windows Server versions and licensing

Overview of new and updated features

Features deprecated in Server 2025

Navigating the interface

Windows Settings

Task Manager

Task View

Let’s get started!

The purpose of Windows Server

What is a server? Is that a silly question? I don’t think so. It’s a good question to ponder, especially now that the definition of servers and server workloads is changing on a regular basis. The answer to this question for Windows clients is simpler. A Windows client machine is a requester, consumer, and contributor of data.Data. Data is life for many businesses. Where is this data kept? From where is this data being pushed and pulled? What enables the mechanisms and applications running on the client operating systems to interface with this data? What secures these users and their data? The answers to these questions reveal the purpose of servers in general. Servers house, protect, and serve up data to be consumed by clients.Everything revolves around data in business today. Our email, documents, databases, customer lists— everything that we need to do business—is data. That data is critical to us. Servers are what we use to build the fabric upon which we trust our data to reside.We traditionally think about servers using a client-server interface mentality. A user opens a program on their client computer, this program reaches out to a server in order to retrieve something, and the server responds as needed. This idea can be correctly applied to almost every transaction you may have with a server. When your domain-joined computer needs to authenticate you as a user, it reaches out to Active Directory on the server to validate your credentials and receive an authentication token. When you need to contact a resource by name, your computer asks a DNS server how to get there. If you need to open a file, you ask the file server to send it your way.Servers are designed to be the brains of our operation, and often by doing so transparently. In recent years, large strides have been taken to ensure resources are always available and accessible in ways that don’t require training or a large effort on the part of our employees. It used to be true that the general user population knew the name of your server and how to contact it because that was required for them to be able to get the information they needed.If their mapped drives disappeared, it wasn’t uncommon that everyone would know how to throw \\ server\share into File Explorer to get there via Plan B.It also used to be the case that your average business only ran one single server, enabling Plan B above to be true. Today our server landscape is vastly different, with even small businesses running a virtualization host that typically contains a dozen or more virtual servers, and much effort is made so that your workforce doesn’t know or care anything about that server infrastructure; they simply expect to have access to their data, 100% of the time.In most organizations, many different servers are needed to provide your workforce with the capabilities they require. Each service inside Windows Server is provided as, or as part of, a role. When you talk about needing new servers or configuring a new server for any particular task, what you are really referring to is the individual role or roles that are going to be configured on that server to get the work done. A server without any roles installed is useless, though depending on the chassis can make an excellent paperweight. A 3U SAN device could weigh upward of 100 pounds and keep your desk orderly even in the middle of a hurricane!If you think of roles as the meat and potatoes of a server, then the next bit we will discuss is sort of like adding salt and pepper. Beyond the overhead roles you will install and configure on your servers, Windows also contains many features that can be installed, which sometimes stand alone but, more often, complement specific roles in the operating system. Features may add functionality to the base operating system, such as is the case with Telnet Client. Or a feature may be added to a server in order to enhance an existing role, such as adding the Network Load Balancing feature to an already equipped remote access or IIS server. The combination of roles and features inside Windows Server is what equips that piece of metal to do work.This book will, quite obviously, focus on a Microsoft-centric infrastructure. In these environments, the Windows Server operating system is king and is prevalent across all facets of technology. There are alternatives to Windows Server and different products that can provide some of the same functions for an organization, but it is quite rare to find a business environment anywhere that is running without some semblance of a Microsoft infrastructure.Windows Server contains an incredible amount of technology, all wrapped up in one small installation disk. With Windows Server 2025, Microsoft has us thinking out of the box about what it means to be a server in the first place, and it comes with some exciting new capabilities, which we will spend time covering in these pages. Things such as PowerShell, Containers, Windows Admin Center, software-defined storage, and software-defined networking are changing the way that we manage and size our computing environments; these are exciting times to be or to become a server administrator!

Your head in the clouds

The cloud. You’ve probably heard of it. In fact, you have likely heard it in many different contexts, some of which don’t make any sense at all. That is the power of a buzzword in the technical world, it often ends up misused and spoken of inappropriately. Those things aside, the idea of cloud infrastructure is an incredibly powerful one that anybody working in IT needs to understand.A cloud fabric is one that revolves around virtual resources—virtual machines (VMs), virtual disks, and even virtual networks. Being “plugged into” the cloud typically enables things like the ability to spin up new servers on a whim, or even the ability for particular services themselves to increase or decrease their needed resources automatically, based on utilization.Think of a simple e-commerce website where a consumer can go to order goods. Perhaps 75% of the year, the company can operate this website on a single web server with limited resources, resulting in a fairly low cost of service. But the other 25% of the year, maybe around the holiday seasons, utilization ramps way up, requiring much more computing power. Prior to cloud mentality, this would mean that the company would need to size its environment to fit the maximum requirements all the time, in case it was ever needed. They would be paying for more servers and much more computing power than was needed for much of the year. With a cloud fabric, which gives the website the ability to increase or decrease the number of servers it has at its disposal as needed, the total cost of such a website or service can be drastically decreased. This is a major driving factor of the cloud in business today.

Public cloud

Most of the time, when your neighbor Suzzi Knowitall talks to you about the cloud, she is simply talking about the internet. Well, more accurately, she is talking about some service that she uses, which she connects to by using the internet. For example, Office 365, Google Drive, OneDrive, and Dropbox—these are all public cloud resources, as they store your data in the cloud. In reality, your data is just sitting on servers that you access via the internet, but you can’t see those servers and you don’t have to administer and maintain those servers, which is why it feels like magic and is then referred to as the cloud.To IT departments, the term cloud more often means one of the big three cloud hosting providers. Since this is a Microsoft-driven book, and since I truly feel this way anyway, Microsoft Azure is top-notch in this category. Azure itself is another topic for another book (or many other books) but is a centralized cloud computing architecture that can host your data, your services, or even your entire network of servers.Moving your datacenter to Azure enables you to stop worrying or caring about server hardware, re- placing hard drives, and much more. Rather than purchasing servers, unboxing them, racking them, installing Windows on them, and then setting up the roles you want configured, you simply click a few buttons to spin up new virtual servers that can be resized at any time for growth. You then pay ongoing op-ex costs for these servers—monthly or annual fees for running systems in the cloud—rather than the big upfront cap-ex costs for server hardware.Other cloud providers with similar capabilities are numerous, but the big three are Azure, Amazon (AWS), and Google. As far as enterprise is concerned, Azure simply takes the cake and eats it too. I’m not sure that the others will ever be able to catch up with all of the changes and updates that Microsoft constantly makes to the Azure infrastructure.

Private cloud

While most people working in the IT sector these days have a pretty good understanding of what it means to be part of a cloud service, and many are indeed doing so today, a term that is being pushed into enterprises everywhere and is still many times misunderstood is private cloud. At first, I took this to be a silly marketing ploy, a gross misuse of the term “cloud” to try and appeal to those hooked by buzzwords. Boy, was I wrong. In the early days of private clouds, the technology wasn’t quite ready to stand up to what was being advertised.Today, however, that story has changed. It is now entirely possible to take the same fabric that is running up in the true, public cloud and install it right inside your datacenter. This enables you to provide your company with cloud benefits such as the ability to spin resources up and down, run everything virtualized, and implement all of the neat tips and tricks of cloud environments, with all of the serving power and data storage remaining locally owned and secured by you. Trusting cloud storage companies to keep data safe and secure is absolutely one of the biggest blockers to implementation on the true public cloud, but by installing your own private cloud, you get the best of both worlds, stretchable compute environments with the security of knowing you still control and own all of your data.This is not a book about clouds, public or private. I mention this to give a baseline for some of the items we will discuss in later chapters, and also to get your mouth watering a little bit to dig in and do a little reading yourself on cloud technology. You will find that Windows Server 2025 interacts in many ways with the cloud and will notice that so many of the underlying systems available in Server 2025 are similar to, if not the same as, those becoming available in Microsoft Azure.In these pages, we will not focus on the capabilities of Azure, but rather a more traditional sense of Windows Server as would be utilized on-premises. With the big push toward cloud technologies, it’s easy to get caught with blinders on and think that everything and everyone is quickly running to the cloud for all of their technology needs, but it simply isn’t true. Most companies will have the need for many on-premise servers for many years to come; in fact, many may never put full trust in the cloud and will forever maintain their own datacenters. These datacenters will have local servers, which will require server administrators to manage them. That’s where you come in.

Windows Server versions and licensing

Anyone who has worked with the design or installation of Windows Server in recent years is probably wondering which direction we are taking in this book. You see, there are different capability editions, different technical versions, plus different licensing models of Windows Server. Let’s take a few minutes to cover those differences to give you a well-rounded knowledge of the different options, and so that we can define which portions we plan to discuss over the course of this book.

Standard versus Datacenter

When installing the Windows Server 2025 operating system onto a piece of hardware, as you will experience in Chapter 2, Installing and Managing Windows Server 2025, you will encounter two different choices of server capability.

The first is Server 2025 Standard, which is the default option and one that includes most of your traditional Windows Server roles. While I cannot give you firm details on pricing because that could potentially be different for every company, depending on your agreements with Microsoft, Standard is the cheaper option and is most commonly used for installations of Windows Server 2025.

Datacenter, on the other hand, is the luxury model. There are some roles and features within Windows Server 2025 that only work with the Datacenter version of the operating system, and they are not available in Standard. If ever you are looking for a new piece of Microsoft technology to serve a purpose in your environment, make sure to check the requirements to find out whether you will have to build a Datacenter server. Keep in mind that Datacenter can cost significantly more money than Standard, so you generally only use it in places where it is actually required. For example, if you are interested in hosting a Storage Spaces Direct (S2D) environment, you will be required to run the Server 2025 Datacenter edition on those servers.

One of the biggest differences between Standard and Datacenter that even small businesses may need to consider is the number of Virtual Machines (VMs) that they can legally host. Out-of-the-box Server 2025 Standard can only run two VMs on it at any given time, which is a pretty limiting factor if you are looking to build out a Hyper-V server. Datacenter allows you to run unlimited numbers of VMs, which makes it a no-brainer when building your virtualization host servers. For running Hyper-V, the Datacenter edition is often the way to go.There is more information on this topic that makes the previous paragraph complicated. Both Server 2025 Standard and Server 2025 Datacenter have the technical ability to run many VMs. Whether or not you are allowed to do so comes down to licensing. We will discuss more on this topic when we talk about Windows Server licensing structures later in this chapter.Running a container infrastructure will also impact your decision-making on Windows Server licensing. While your host container server can run an unlimited number of traditional containers, whether that host server is Windows Server Standard or Datacenter, if you want to move into the enhanced world of Hyper-V-isolated containers, similar restrictions apply. A container host server running Windows Server Standard is limited to running two Hyper-V containers, but bumping up your host to Windows Server Datacenter will bring you back into the unlimited category. An easy way to remember this is that each Hyper-V container is essentially its own VM, and so the limit of two applies in the Standard OS, whether talking about regular VMs or Hyper-V container VMs. Again, remember that this is a licensing limitation, not a technical one.

Windows Server 2025 Essentials

Some of you may remember the Small Business Server (SBS) editions of Windows Server, which were sort of an all-in-one variant of the Windows Server operating system, intended to be the one and only server inside a small business environment. While SBS fell by the wayside many years ago, Microsoft has offered an Essentials edition of each Windows Server release since that time, to fill the small business gap. If your organization has fewer than 25 users and fewer than 50 devices, and if you do not intend to grow beyond that point, purchasing and installing Windows Server 2025 Essentials can be a coupon clipper to getting your data infrastructure up and running in a cost-friendly way. Keep in mind that it comes with limitations and as soon as you want to grow your business to more than 25 users, you’ll have to bite the bullet and purchase Server Standard, and migrate over to it.

Windows Server 2025 Datacenter: Azure Edition

Hold up, what is this thing? The Windows Server 2022 rollout introduced us to this brand new thing, a special version of Windows Server that obviously has some tie-ins to Azure. But what does this mean for you? Whether or not you will ever touch the new Azure Edition depends on what kinds of things you are doing in the Azure world. If you host virtual machines in Azure, you now have the option of selecting your new VM to run this special Azure Edition, and it then enables some cool new features that are unique to this edition. What is most interesting to me about the latest 2025 release of Azure Edition is that some of the capabilities that you could only find through 2022 Azure Edition have now been ported over into the normal Server 2025 Datacenter. For example, in 2022 you could only do Hotpatching and SMB over QUIC if you deployed 2022 Azure Edition. This is no longer the case, and both of those functions exist in normal Server 2025 Datacenter. However, new feature sets were added into 2025 Azure Edition that do not (yet) exist in normal 2025 Datacenter, so you see how this trend continues.The big catch with Azure Edition is just that – it can only run in an Azure environment. So if you have Azure cloud-hosted VMs, you can now get those VMs to run Azure Edition. Without making this too complicated, since we are talking mostly about on-premise resources in this book, there is one other special scenario where you might be able to run Windows Server 2025 Azure Edition from within the physical walls of your building. That is for those of you running something called Azure Local (formerly known as Azure Stack HCI). The scope of this book does not include Azure Local, but the easiest way to think about it is the point where rubber meets the road for a private cloud, which we already discussed. It is possible to build your own implementation of Azure, right inside your own datacenter, using Azure Local. If you are running a private cloud such as this, you will then be able to run VMs within that environment that use Windows Server 2025 Datacenter: Azure Edition.

Three different user interfaces

Now let’s discuss the different footprints and user interfaces that you can run on your Windows Server 2025 machines. There are two variants of Windows Server that can be used, and we will also fill in some history about a third option that used to exist and is still often a complication to this topic. Choosing the correct interface depends on what capabilities and security you are looking for.

Desktop Experience

This is the most common choice among Windows Servers everywhere. Whether you are building Windows Server 2025 Standard or Datacenter, you have a choice of running Windows Server with or without a graphical user interface. The point-and-click interface with a traditional look and feel is called Desktop Experience. This allows things such as RDPing into your servers, having a traditional desktop, and being able to use the graphical Server Manager right from your logged-in server, and all in all, it is the best way to go if you are new to server administration.If you are familiar with navigating around inside Windows 11, then you should be able to at least make your way around Windows Server 2025 running Desktop Experience. This is the version of Windows Server 2025 that we will focus on for the majority of this book, and almost all of the screenshots will be taken from within a Desktop Experience environment.

Server Core

As you will see when we install Windows Server 2025 together, the default option for installation is not Desktop Experience. What this means is that choosing the default install path would instead place a headless version of Windows Server onto your machine, most commonly referred to as Server Core.The nature of being headless makes Server Core faster and more efficient than the Desktop version, which makes sense because it doesn’t have to run all of that extra code and consume all of those extra resources for launching and displaying a huge graphical interface.Almost anything that you want to do within Windows Server is possible to do on either Server Core or Desktop Experience, the main differences being the interface and security. To be able to use Server Core, you definitely have to be comfortable with a command-line interface (namely PowerShell), and you also have to consider remote server management to be a reliable way of interacting with your servers. We will talk much more about Server Core in Chapter 11, Server Core.The largest benefit that Server Core brings to the table, other than performance, is security. Most malware that attempts to attack Windows Servers is reliant upon items that exist inside the GUI of Desktop Experience. Since those things aren’t even running inside Server Core—alas, you couldn’t get to a desktop even if you wanted to—attacks against Server Core machines are far, far less successful.

Nano Server – now only for containers

A third platform for Windows Server 2025 does exist, known as Nano Server. This is a tiny version of Windows Server, headless like Server Core but running an even smaller footprint. The last time I booted up Nano Server, it consumed less than 500 MB of data for the complete operating system, which is incredible.Nano Server was a hot topic surrounding the release of Server 2016, because at that time, Microsoft was pressing forward with plans to include a whole bunch of roles inside Nano Server so that we could start replacing some of our bloated, oversized everyday servers with Nano. It used to be the case that you could use the Windows Server installation media (I suppose you could still make it happen with Server 2016 installation media) to spin out a VHDX file that allowed you to boot into Nano Server and check it out, but that mentality of Nano Server as an actual server has since gone by the wayside.As of Windows Server version 1803 (we’ll discuss what Server 1803 means in the next section of this chapter), Nano Server is married to the use of containers. In fact, the only way to spin up a Nano Server is to download it as a container base OS image, and then boot that image on an existing container host server. We will discuss both in more detail in Chapter 14, Containers. If you know what containers and modern applications are, and are interested in using them, then you will benefit from learning all there is to know about Nano Server. If you are not in a position to work with containers, you will probably never run into Nano Server in your environment.

Licensing models – what happened to SAC?

Up until the release of Windows Server 2022, you had a decision to make on which licensing model and release cadence you wanted to follow. Microsoft releases some versions of Windows Server, the ones you are likely familiar with, on a 2–3 year basis, and other versions on a biannual cadence. Can you imagine new versions of Windows Server shipping twice a year? I would imagine that to be a very difficult thing to keep up with for both manufacturer and consumer, and as of August 2022 that reality seems to have sunk in as we experienced the demise of this super-aggressive release cadence. Let’s discuss the ways that Windows Server versions roll out, and what changed in 2022.

Long-Term Servicing Channel (LTSC)

Some of you probably think that LTSC is a typo, as in previous years this model was called Long-Term Servicing Branch (LTSB). While you can go with either and people will generally know what you are talking about, LTSC is now the proper term.Windows Server 2025 is an LTSC release. Essentially, LTSC releases are what we have always thought of as our traditional Windows Server operating system releases. Server 2008, Server 2008 R2, Server 2012, Server 2012 R2, Server 2016, Server 2019, Server 2022 and now Server 2025 are all LTSC releases. It is Microsoft’s expectation that LTSC versions of Windows Server will continue to be released every 2–3 years, and will include both headless as well as full graphical interface flavors of the operating system.LTSC versions of Windows Server have always been the most common; indeed, many IT administrators have never even heard of the alternative Semi-Annual Channel (SAC) releases. Anytime that you are building a server with the intention of utilizing Desktop Experience for a fully graphical interface, your only option is LTSC anyway. It has always made the most sense for any servers running with the purpose of a domain controller, certificate server, file server, etc. to run within the context of LTSC.With LTSC versions of Windows Server, you continue to get the same support we are used to seeing from Microsoft operating systems: five years of mainstream support followed by five years of available extended support.Throughout this book, we will work and gain experience with Windows Server 2025 – the LTSC release, which is now the only release.

Semi-Annual Channel (SAC) (now retired)

While this is now mostly irrelevant, it is still good to understand the history of SAC, and indeed you may well encounter SAC releases of Windows Server in your IT escapades. The first thing you will notice when stumbling upon an SAC release of Windows Server is the strange naming convention for operating system versions. Rather than calling it Server 2019, you were really running Windows Server 1803, 1809, 1903, 1909, and so on. It followed the same mentality and release cadence that Windows 10 did. What that implies is that these new versions of Windows Server SAC were released at much shorter intervals than LTSC. The SAC channel received two major releases every year—generally in the spring and the fall. Because of this fast release cadence, support for SAC versions of Windows Server lasted for a short 18 months. If you use SAC, you had better get used to always jumping on the latest version shortly after it releases.If swapping out your server operating systems twice a year sounds daunting, you’re not alone. Thankfully, Microsoft recognizes this and realizes that the general server administrator population is not going to use this model for their regular, everyday servers. Rather, SAC versions of Windows Server were only ever going to be used to run containers and containerized applications. In this new world of flexible application hosting, where applications are being written in ways that the infrastructure resources behind those applications can be spun up or spun down as needed, containers are a very important piece of that DevOps puzzle. If you host or build these kinds of applications, you will almost certainly be using containers—now or in the future. When you find yourself in the position of researching and figuring out containers, you may then stumble on information and documentation that leads you to those older SAC server releases.It is important to note that SAC versions of Windows Server only came in the Server Core flavor – you’ll find no graphical desktop interface here!While Microsoft has officially retired SAC licensing and operating systems as of August 2022, customers heavy into containerization may still find some similar benefits by moving to Azure Local (formerly Azure Stack HCI).

License purchase and packs

When defining differences between the Standard and Datacenter versions of Windows Server 2025, we referenced the fact that “out of the box” Server 2025 Standard allows for the running of two VMs, but that it wasn’t a technical limitation and that more VMs were possible. This idea segues into a bit of a confusing topic – the way that Windows Server is licensed. When you purchase “a Windows Server 2025 Standard License,” you are purchasing the rights to install Server 2025 Standard onto one physical piece of hardware, and to run two VMs on top of that host operating system. In effect, you can run three instances of Windows Server 2025 Standard. As soon as you make your move to spin up a third VM, you are required to repurchase the same amount of licensing all over again. Doing so actually gives you the ability to then run a total of four VMs. So if you only need three, well… too bad, you pay for four. Effectively, you repurchase your Windows Server 2025 Standard licensing for every two additional VMs that you need to run.In addition to considering the number of VMs, the amount of licensing you purchase in the first place depends upon the size of your hardware. More specifically, it depends upon the processors you have installed.

Core Packs (physical server licensing)

Here is where things get a little dicey. You must license each physical server based on the amount of processor cores that exist inside it. Most physical servers contain one or two CPUs. The number of cores that those CPUs contain could be vastly different. What you are required to license is the number of cores.Hyperthreading doesn’t count. If you have one CPU with one core and it can do hyperthreading (logical cores), this counts as one core. If you have dual CPUs each with 8 cores, now we’re talking about 16 cores total. This is the number to license.There is some confusing history about why these are called Core Packs instead of simply Core Licenses, but since you can never purchase a single core license (why would you, since CPU cores always come in even numbers) you will always be purchasing packs of licensing, core packs.Except…(this is the moment when you realize why large companies employ full-time staff just to deal with licensing)… there are also some rules of minimum. You cannot cover a server with four core packs, because Microsoft says you can’t. Here are the rules of a minimum license purchase:

Any physical server requires a minimum of 16 cores to be licensed.

Even if your server has fewer than 16 cores, you must adhere to the prior rule and license for at least 16 cores.

Every physical CPU requires at least 8 cores to be licensed, whether or not that CPU has 8 cores. But again, even if your server has only 1 CPU with 8 cores, you must still license the server for 16 cores based on the server-level minimum.

Wow, that is a lot of rules. Ultimately, many physical servers in smaller businesses will fall into the category of requiring the minimum of 16 cores to be licensed. That’s easy math, and in fact when faced with purchasing Windows Server licensing you will find that most places offer a 16-CPU Core Pack which perfectly fits that need. When you grow your hardware to contain more than 16 CPU cores, then you pull out the calculator and start purchasing additional core packs.

vCore Licensing (virtual server licensing)

Most on-premise servers that I encounter continue to be licensed by physical CPU cores, but introduced to us new in late 2022 is the idea of per-VM licensing, instead of physical server licensing. vCore licensing is what it sounds like, licensing for Windows Server based on the number of vCPU cores you are running, instead of physical CPU cores. There are a couple of minimums to keep in mind also, with vCore licensing:

Each VM must be licensed for at least 8 virtual cores. If you have a smaller VM that uses fewer than 8 cores, you’ll still have to pay for 8.

Each customer requires a minimum of 16 virtual cores.

You may be tempted to start looking into vCores and running numbers to find out if this new licensing model is cheaper for your environment, but there is one large caveat to keep in mind. Per-VM licensing was created for a specific purpose, primarily if you have a reason to run a small number of VMs on a large host, where physical licensing costs don’t make sense. This can sometimes be the case in cloud or hybrid-cloud scenarios, where you are using or renting host space from another entity. One requirement for vCore licensing that will be a determining factor for many businesses as to whether it can be used is that vCore licenses are only available to customers with active Software Assurance or subscription licenses.

At what point do I turn to Datacenter?

The Server 2025 Standard licensing strategy is scalable up to a certain point. Technically, you could forever increase the licensing that you purchase and the VMs that you run with that licensing, but wait a minute – didn’t we say that Server 2025 Datacenter permits you to run unlimited VMs? Indeed we did. While Server 2025 Datacenter costs a lot more than Server 2025 Standard, if you are facing a requirement to run many virtual machines, it may be more cost-effective to simply purchase Datacenter and not have to deal with all of the intricacies of Standard licensing.The breaking point is usually around 12 VMs. If you run 12 or fewer VMs on a single server, you will likely save some money by running the numbers on Standard licensing, but it depends on what physical CPUs you have. If you need to run more than 12 VMs, it is most likely true that purchasing a single (16 core) Datacenter license will be your cheaper option.

Client Access Licenses (CALs)

So far all we have talked about is Windows Server licensing, just for the server side. Microsoft also requires businesses to purchase and own CALs, to cover any user who needs to connect to resources on that server. This one is more straightforward to calculate—add up the numbers of users that you are going to point to resources on your server, and make sure you purchase that many (or more) CALs. Oftentimes when you purchase Windows Server licensing, you will find options that combine server and CAL licensing, such as “Server 2025 16 core licenses + 25 CALs.”If you have ever purchased CALs before, there is a decent chance you have been building a new server or implementing a Remote Desktop Services (RDS) environment. We will discuss RDS much more in an upcoming chapter on the topic, but RDS CALs are one type of CAL that you may find yourself purchasing, even on top of your normal Windows Server CALs. Out of the box, any Windows Server allows two user accounts to RDP into it at the same time, but no more. When implementing an RDS server, you often want many more people to be able to connect at the same time. The purchase and installation of RDS CALs is necessary for that to work properly.

Pay-as-you-go licensing

Whoa, what is this?? With the advent of Windows Server 2025, Microsoft has released a brand new way to pay for your Server 2025 instances, without needing to purchase cap-ex style perpetual licenses or core packs whatsoever. Enter pay-as-you-go licensing. Key to success with this new venture, the servers you are deploying must be tapped into Azure Arc (more on that later in this book). Assuming that you have Arc-enabled your servers, you can now license them through your Azure subscription, the cost as of this writing being $33.58 USD per CPU core, per month. As with most things in Azure, you only pay for what you need.

Overview of new and updated features

The newest version of the Windows Server operating system is always an evolution of its predecessor. There are certainly pieces of technology contained inside that are brand-new, but there are even more places where existing technologies have been updated to include new features and functionality. In the case of Windows Server 2025, there are even some functions and features that are specifically called out by Microsoft as being deprecated and leaving us for good. As is often the case with Microsoft operating system releases, there are many intricate and under-the-hood changes, but not all of them are going to impact the way that you work on servers. For a full list of changes, you can simply visit Microsoft’s Learn documentation, search “What’s new in Server 2025?” and get a play-by-play. Re-creating a cut and paste list here would be insulting to you as a reader and able-bodied IT person, so for the purposes of this chapter, I have selected new and updated feature sets that genuinely interest me as I believe these will also be the most interesting changes to you, in the businesses that you support. Let’s spend a few minutes providing an overview of some (truly interesting) changes that exist in Windows Server 2025.

CPU compatibility

For anyone who has worked with Windows Servers for a long time, you likely hold them in your mind as tightly bound with Intel Xeon processors. Historically, I have found it quite rare to experience a production physical server that is running anything other than Xeon CPUs. This mindset may suddenly shift with Windows Server 2025, as Microsoft now supports a range of both Intel and AMD processors to run their latest operating system.

Updated in-place upgrades

If you’ve been following Microsoft’s progression of Windows Server through the years, and have helped to bring environments from 2016 -> 2019 -> 2022, you probably realize already that the in-place upgrade option has been significantly enhanced and improved over these years. Upgrading servers used to be a real challenge, and it was often easier to simply create a brand new server, and transition your roles and data to it. I would say that starting with Server 2019 the option to in-place upgrade really stabilized, and has continued to improve in the years since. Why are we talking about it in the “What’s new?” section? Because you can now in-place upgrade a server right from inside Windows Update settings! This is common knowledge in the Win10 -> Win11 world, but unprecedented for Windows Server. Shortly we will spend some time installing Windows and upgrading a previous Windows Server to 2025, and we’ll also test out this new capability to allow that server to self-install Server 2025 by simply clicking some buttons inside the Windows Update settings. This is the same mechanism that Windows workstations have used to implement in-place feature updates for years. While the new Windows Update single-button mechanism for upgrading is only available on very recent servers, Microsoft has also expanded in-place upgrade capabilities when using the Windows Server 2025 installation media. As long as you have that ISO or DVD from which you can launch into an installer, you can perform what is known as N-4 versioning. That is, you can in-place upgrade 4 versions at a time! What this means in plain text is that you can pop Server 2025 installation media into a Server 2012R2 (or anything newer), and it will in-place upgrade all the way to Server 2025. Holy moly, that is impressive.

Hotpatching

Windows Server hotpatching is an idea that came to light during the Server 2022 release, but only pertained to servers running the special Windows Server 2022 Azure Edition SKU. I recently attended a Microsoft presentation where it was made known, at no surprise to anyone, that hotpatching was by far the #1 requested update for Server 2025’s release.Now integrated into Windows Server 2025, with no reliance on the special Azure Edition version, hotpatching enables your servers to continue patching their regular monthly patch cycle, without rebooting! Microsoft releases and installs these monthly security patches in a new way that puts the updated code into place in real-time, no longer requiring a restart of those services or the operating system to bring them to life. Then once per quarter, Microsoft releases a more traditional round of updates that do require a restart, but seriously if we could get away with restarting servers once per quarter rather than once per month, think about all of increased uptime percentages and decreased headaches with planning out maintenance windows.One very important thing to remember with hotpatching. Even though this capability is now built into any version of Windows Server 2025, it can only be employed if your server(s) are tapped into Azure Arc, as this is the mechanism through which hotpatching is administered and managed.

The Windows 11 experience is here!

It was a surprise to many when Windows Server 2022 hit shelves still running a Windows 10 graphical interface, as Windows 11 was already in the wild. Whatever rough edges existed at the time have now been polished, and Windows Server 2025 looks and feels like Windows 11. At this point, Win11 should be familiar territory for anyone who regularly works in IT or with computers at all, it will be nice to fall back into standards when bouncing between workstations and servers in Microsoft-centric infrastructures. Bringing the Windows 11 experience to Server 2025 also brings related toolsets, such as current Windows Terminal and the updated Task Manager, both of which we will explore within this book.

Azure Edition

We already discussed Windows Server 2025 Datacenter: Azure Edition, but it is still worth calling out that this Azure-specific version still exists and is updated in 2025. Previously, hotpatching and SMB-over-QUIC were two of the primary differentiators between a classic Server 2022 and the Azure Edition, and it is worth noting again that Microsoft is really listening to its audience, as they have now pulled these two great technologies into every version of Windows Server 2025, making them more accessible to the masses.

Bluetooth

In Windows Server 2025, we now have Bluetooth, because…why not? I’m not sure how often this will be utilized, but you can now tap Bluetooth keyboards, mice, headphones, etc. directly to your servers. Maybe this will be particularly useful for developers who might be running Server 2025 on their local workstations as they build out new software. For those not familiar with containers, anyway.

Wireless networking

Similar to my feelings about Bluetooth, when I first saw this I almost laughed out loud. Are people really going to wirelessly connect Windows Servers? I do have to admit that wireless connectivity has improved dramatically over the past 10 years, and if you’re interested in wirelessly connecting your server, the Wireless LAN Service feature is now installed by default. Microsoft doesn’t really expect this to be a common need though, and so the service is configured to Manual start by default. You will need to intentionally start the service in order to use wireless on your new server.

Microsoft accounts

Most reading this have probably added Entra accounts, Microsoft accounts, or Microsoft work/school accounts to various Windows 10 or Windows 11 computers through the Settings -> Accounts tool. This same capability to make the operating system integrally aware of a Microsoft account now exists in Windows Server 2025 as well.

Credential Guard

Credential Guard has been around as a technology for a while, but is now enabled by default in Server 2025, as long as your system meets hardware and licensing requirements. This is a technology that greatly improves security surrounding NLTM passwords, Kerberos tickets, and the credentials that get stored inside Windows, by applications. You’ve probably heard about pass-the-hash and pass-the-ticket attacks, and Credential Guard helps to block those types of attacks from happening.

Azure Local

Formerly called Azure Stack HCI, Azure Local is essentially a mechanism to utilize Windows Server 2025 to build your own private cloud. This enables you to employ Azure-specific capabilities, capacities and protections within your physical building.

Windows Admin Center (WAC)

WAC originally came to us around the same time as Windows Server 2019, and really built some steam with the release of Server 2022. With 2025’s release, WAC is even more tightly integrated with Microsoft’s cloud services, now being tied into Azure Arc. This enables you to manage your Windows Server instances from inside the Azure Arc portal, whether your servers are on-prem or cloud-based!To be clear, you can still run Windows Admin Center on a local server and allow it to manage your servers, without using Azure Arc at all. In fact, we will be deploying this free tool together, later in this book.

Active Directory improvements

There is so much talk about Azure, it can feel like the classic Server is dying. My perception is quite the opposite; the truth in many cloud migration cases is that we are still running regular ole Windows Server instances, they just happen to live in the cloud on Microsoft’s hardware instead of our own. It may seem surprising that Microsoft has pumped a bunch of improvements into something as classic as Active Directory, but ultimately AD is timeless and will still be around for decades to come. There is quite a list of under-the-hood improvements that have been made to Active Directory Domain Services (AD DS) with the release of Windows Server 2025, most of which you probably wouldn’t care too much about. One stand-out is a major improvement to the JET database that underpins AD, which has been using 8k sized page files since the year 1999. These pages have now been increased to 32k, a 4x increase which removes AD object limitations that have always existed in the past. Additionally, default machine account passwords have increased security by using randomly generated computer account passwords, and AD DS can now utilize Non-uniform Memory Access (NUMA) to take advantage of CPUs in all processor groups, where previously it could only use a single group.Active Directory also gains some major security improvements, now utilizing current algorithms and encryption methods. For example, LDAP now supports TLS1.3 and Kerberos can run AES SHA256/384.

Delegated Managed Service Accounts (dMSA)

Service Accounts in Active Directory have always been a necessary and important tool, but they can be used for evil just as quickly as for good. New with Server 2025, dSMA link the authentication of these accounts directly to a device’s identity in AD, which prevents attackers from harvesting credentials through a compromised account.

Dynamic Tracing (DTrace)

DTrace is not a brand-new toolset, but previously required installation into Windows. With Windows Server 2025 DTrace is now included out of the box, accessed via your favorite command line. This utility allows for monitoring and debugging of real-time system performance, and can even script actions to be taken based on monitored probes. We will take a closer look at DTrace in our last chapter, Troubleshooting.

Windows Local Administrator Password Solution (LAPS)

LAPS has been around for a long time, but is historically underutilized. Fresh attention has been given to this technology, which is a centralized management tool used to control local administrator passwords on all of your domain-joined machines. With LAPS, it is possible for every workstation to always have a unique local administrator password, which will keep attackers guessing for a very long time. New LAPS policies allow you to specify things like length of password, and using word phrases instead of random characters for easier readability. There is a new AD attribute as well called msLAPS-CurrentPasswordVersion that helps to solve issues caused by reimaging or rolling back workstations, where in the past that action could cause the local administrator password to be out of sync between the workstation and AD, and AD would never update itself to store the correct password. Now it can. We’ll take a look at LAPS as we implement it together later in our chapter on Security.

ReFS improvements

The Resilient File System, better known as ReFS, has some underhood improvements in Server 2025 that should automatically cause you to experience things like faster file copies and reduced storage space. Work has been done to optimize ReFS’s deduplication and compression capabilities. These updates will improve daily interaction with files, as well as enhance capabilities of Dev Drive by enabling block cloning.

Compress to…

I can’t tell you how many times I have installed third-party tools like 7Zip recently, because the built-in Windows Zip function seems to be a little flaky in recent versions of the Windows operating system. Never fear, I think we have resolution to this issue beginning in Server 2025. In fact, right-clicking on a file now gives you a new Compress to… option, which allows you to easily compress files out to ZIP, 7z, or TAR files with a single click.

SMB over QUIC

Okay, I am very excited about this one! With the release of Windows Server 2022, we learned about this cool new SMB protocol that securely enables SMB traffic (file shares) to natively map directly over the internet using TLS1.3, without needing any kind of a VPN connection. This enables mapped network drives to file servers to work directly, but still securely, over the internet. That is incredible! The downside to using SMB over QUIC was that it required you to utilize a special edition of the operating system, Windows Server 2022 Azure Edition. This is no longer a requirement! SMB over QUIC is now built natively into Windows Server 2025 Standard or Datacenter. We will take a closer look into this new file access protocol in our new chapter about File Management.

OpenSSH

In previous versions of Windows Server, you were required to install a tool manually to use OpenSSH. It is now built-in to Windows Server 2025, indicating Microsoft expects this to be more widely used moving forward. They have also added a new local group to Windows called OpenSSH Users for easy control over who can or cannot access your devices using OpenSSH.

Windows VPN hardening

Routing and Remote Access Service (RRAS) has been serving up Windows Server based VPN connectivity for many, many years. Through all of that time, there are a couple of VPN protocols that have always been enabled options, but those protocols are now considered to be unsafe, compromised, and all-around bad ideas. Namely, I’m talking about PPTP and L2TP, which you will now find disabled by default in Windows Server 2025. They can still be enabled if needed, but Microsoft rightly expects you to now be making use of SSTP or IKEv2 for all Windows based VPN connectivity.

Azure Arc

While this is not inherently a technology about Windows Server, Azure Arc is a cloud-based server management platform that could certainly interact with all instances of your Server 2025 (and more), allowing you to centrally manage even on-prem servers from Azure. Tapping local servers into Azure Arc is as simple as running through a quick wizard inside the operating system, or by using PowerShell. As Microsoft continues to add new Azure-like features to on-prem versions of Windows Server, we should expect that plugging those servers into Azure Arc will become a routine and necessary action to enable those new functions.

AI-ready

As I was researching interoperability between Windows Server 2025 and AI, I was sick to my stomach to find that many of the articles written about AI are, indeed, written by AI itself. It is still fairly obvious to the human brain at this point. In fact, I found entire websites that seem to have been created by AI. These websites were full of buzzwords and popular phrases, but in the end were lacking any real content. While there are clearly some people tying Server 2025 and AI together in what they are writing, and certainly AI written articles have decided to self-promote AI (queue end of the world scenarios), this seems to be the reality of where Server 2025 meets AI.Server 2025 includes some improvements that help this latest operating system to be better ready to service AI workloads, as companies move further and further into this space. GPU Partitioning in particular allows companies to divide GPUs across multiple applications and services, increasing system performance in a way that is particularly helpful for AI workloads. For example, a single physical GPU can be split among multiple VMs.Also, NVMe storage boost allows for up to 60% faster IOPS compared to Server 2022, which will significantly enhance data retrieval and processing, integral for large data transactions commonly associated with the AI world.

Feedback Hub

How many times have you seen or experienced something on a Windows machine and thought, “I wish I could report this to Microsoft, but would anybody actually look at it?” We now have a mechanism to do exactly that. Feedback or problems can be reported to Microsoft directly from the Server 2025 interface via Feedback Hub. You can even include screen recordings!

Hyper-Converged Infrastructure (Azure Local)

I already mentioned Azure Local, formerly known as Azure Stack HCI, in the list of new features Microsoft is offering. If the term Hyper-Converged Infrastructure (HCI) is new to you, a little backstory may prove beneficial here.When you see the term HCI, it is important to understand that we are not talking about a specific technology that exists within your server environment. Rather, HCI is a culmination of a number of different technologies that can work together and be managed together, all for the purpose of creating the mentality of a Software-Defined Datacenter (SDDC as it is sometimes referred to).Specifically, HCI in the Microsoft world is most often referred to as the combination of Hyper-V and Storage Spaces Direct (S2D) on the same cluster of servers. Clustering these services together enables some big speed and reliability benefits over hosting these roles separately, and on their own systems. It also creates a tech stack that begins to resemble the way that Azure runs, but within your own physical server infrastructure.Another component that is part of, or related to, a software-defined datacenter is Software-Defined Networking (SDN). Similar to how compute virtualization platforms (like Hyper-V) completely changed the landscape of what server computing looked like 15 or more years ago, we are now finding ourselves capable of lifting the network layer away from physical hardware and shifting the design and administration of our networks to be virtual and managed by the Windows Server platform.Where the idea of HCI really takes a leap as it relates directly to the Windows Server 2025 release is through integration with Azure Local. Now that we can run private clouds within our datacenter walls, Microsoft has provided us with true cloud capabilities through the use of Windows Server 2025 Datacenter: Azure Edition within that Azure Local environment.

Features deprecated in Server 2025

We expect each new operating system release to include new and updated features, but don’t generally think too much about what might be old enough to be removed completely when a new version releases. The removal of old, unnecessary, and insecure code can only be a healthy update for Windows Server. Removing these components in Server 2025 does not mean that Microsoft will not continue to support them on existing servers, but they have no plans to continue developing these technologies in the future. Let’s look at some deprecations for Server 2025.

SAC releases

As we have already discussed, the SAC releases of Windows Server will no longer be built and released. The future of on-premise Windows Server is through the standard LTSC release channel.

Guarded fabric and Shielded VMs

Technically, these were already deprecated with Server 2022 but it’s a big enough announcement that we should mention it again. Guarded fabric and Shielded VMs were big news in Server 2016, and Microsoft will continue to support customers who use guarded hypervisor fabrics and shielded VMs, but there are no plans for future development on this technology.

IIS6 Management Console and SMTP Server

The trusty, rusty, 20-year-old IIS console has been removed, in lieu of the newer IIS management console that has already existed for years. You would think that everyone should already be using the newer console and this would not have a large impact, but I am continually surprised to find at least a couple of customers every year who are still using IIS6 to relay SMTP mail. Yikes, get away from that thing today!

Wordpad

No real surprise here, I can’t say that I have watched anybody launch Wordpad in more than 10 years. With alternatives like Word or even Notepad, which has been recently enhanced, this old text editor is now six feet under.

NTLMv1

Hopefully you won’t notice this change, but this old authentication method has now been removed and Microsoft hopes you have everything moved over to Kerberos. While NTLMv1 specifically is the only one fully removed in Server 2025, any other flavor of NTLM is also on its way out the door and will no longer be developed by Microsoft. In other words, don’t rely on NTLMv2 as that will also be removed during a future release.

PowerShell 2.0

This engine is now removed. PowerShell 5.0 or higher has been the standard for many years at this point, applications that rely on 2.0 are due for an upgrade!

TLS 1.0 and 1.1

While not fully removed, these old protocols are disabled by default. Any applications still relying on either of these versions of TLS have gray hair at this point, and should be upgraded or replaced.

Windows Internal Database (WID)

This one came as a surprise to me! Microsoft has utilized their internal database for many functions over the years. WID is still fully in Windows Server 2025 as it is still utilized by many roles, such as ADFS, IPAM, Remote Desktop and WSUS. The big news here is that Microsoft is no longer going to develop anything new in WID, and it may be removed in a future release. They are making recommendation that companies who utilize these services start sliding them over to the free (or paid) version of SQL.

Windows Server Update Services (WSUS)

Another component that still exists in Windows Server 2025 today, but that Microsoft has announced no plans to actively develop in the future. With operating system updates now being steered by new tech like hotpatching and the update process being managed by Azure Arc or other tools, Microsoft’s own server-side update mechanism is becoming yesterday’s news. Please don’t misunderstand, you can still use WSUS today and can even build a brand new WSUS environment right now in 2025, but this news from Microsoft means you should begin researching alternatives within the next few years.

Navigating the interface

Let’s jump in the wayback machine for a minute and walk through some graphical interface history. Microsoft Windows users have always known and loved their computers, and a large part of the reason Windows became such a standard in the business world is that the global workforce is familiar with navigating a Windows world. This familiarity has paid unimaginable dividends for Microsoft over the years, but there have been a couple of bumps in the road. Unfortunately, Microsoft turned a lot of people off with the introduction of Windows 8 and Server 2012, not because functionality or reliability was lacking, but because the interface was so vastly different from what it had been before. It was almost like running two separate operating systems at the same time. You had the normal desktop experience, in which all of us spent 99.9% of our time, but then there were also those few moments where you found yourself needing to visit the full-page Start menu. More likely, you stumbled into it without wanting to. However you ended up there, inside that full screen tablet-like interface, for the remaining 0.01% of your Server 2012 experience you were left confused, disturbed, and wishing you were back in the traditional desktop. I am, of course, speaking purely from experience here. There may be variations in your personal percentages of time spent, but based on conversations I was involved in at the time, I am not alone in these views. And I haven’t even mentioned the magical self-appearing Charms bar. Some bad memories are better left in the recesses of the brain.The major update of Windows 8.1 and Server 2012 R2 came with welcome relief of these symptoms. There was an actual Start button in the corner again, and you could choose to boot primarily into the normal desktop mode. However, should you ever have the need to click on that Start button, you found yourself right back on the full-page Start screen, which I still found almost all server admins trying their best to avoid at all costs.Well, it turns out that Microsoft does listen to the people and brought some much-needed relief in Windows 10 and Windows Server 2016, and they have not deviated in such a major way since. Whether working on a Windows Server 2016 or 2019 or 2022, you will experience comfort and stability in the flavor of a Windows 10 look-and-feel, which finally wiped away the full-screen Start menu and brought balance back to the universe.Then came Windows 11…Certainly updated, but not nearly as egregiously as the Windows 8 release, Windows 11 is much more rounded and polished while still maintaining Windows-centric roots. As far as the current server graphical interface goes, Windows Server 2025 receives the same facelift, taking on the interface of Windows 11 workstations. If you are comfortable navigating inside Windows 11, you are already well suited to Windows Server 2025.For anyone new to working within Windows or just looking for some tips and tricks to get them rolling, this section is for you.

The updated Start menu

All throughout Windows 10 sub-version releases, there were small ongoing changes to the Start menu. Backpedaling from Windows 8, we rediscovered a real Start button that launches a real Start menu, one that doesn’t take over the entire desktop. To be honest, personally I almost never open the Start menu at all, other than to search for an application or feature that I want. We will cover more on that very soon.Now that we have moved into the Windows 11 interface, Start menu interoperability is relatively the same as Windows 10, though as I’m sure you noticed during your first interaction with Windows 11, the Start button and Taskbar icons have moved into the middle of your screen. Why? Nobody has been able to tell me a sure answer to that, but it takes some getting used to.Other than the arguably annoying slide of the Start button to the middle of the Taskbar, the new Start menu is quite useful. Click on that button, and a few nice things stand out:

Pinned applications. Viewing of all applications installed on the server is possible by clicking the All apps button, but we are creatures of habit and many times when the Start button is pressed, we are re-visiting an application or task that we have done a hundred time before. Pinning commonly-used items to the top of your Start menu can save time and clicks during your daily work.

Clicking that App apps button lists all applications installed on the server, in alphabetical order. This is very useful for launching an application, or for doing a quick check to find out whether a particular app or feature is installed on your server.

The bottom of the Start menu includes a couple of buttons for quick access to account or system items. Easily and more clearly accessible here than previous versions are the ability to shut down, restart, or log out of a server.

Search, the text bar on top of the Start menu is by far its most useful decoration, as you can simply click the Start button on your keyboard and immediately begin typing the name of any application, setting, or document that you want to launch.

You can see all of these functions in Figure 1.2:

Figure 1.2: The new Start menu

Now that is a breath of fresh air. A simple but useful Start menu, and more importantly, one that loads quickly over remote connections such as RDP or Hyper-V consoles.

The Quick Admin Tasks menu

As nice as it is to have a functional Start menu, as a server administrator, I still very rarely find myself needing to access the traditional menu for my day-to-day functions. This is because many items that I need to access are quickly available to me inside the Quick Admin Tasks menu, which opens by simply right-clicking on the Start button. This menu has been available to us since the release of Windows 8, but many IT professionals still make little use of this functionality.This menu has become an important part of my interaction with Windows Server operating systems, and hopefully, it will be for you as well. Right-clicking on the Start button shows us immediate quick links to do things like open Event Viewer, view the System properties, check Device Manager, and even Shut down or Restart the server.The two most common functions that I call for in this context menu are the Run function and using it to quickly launch a Terminal prompt. Even better is the ability from this menu to open either a regular user context Terminal prompt or an elevated/administrative Terminal prompt. Using this menu properly saves many mouse clicks and shortens troubleshooting time:

Figure 1.3: The Quick Admin Tasks menu

Tip

Alternatively, this menu can be invoked using the WinKey + X keyboard shortcut! In fact, accessing this menu via keyboard shortcuts has become popular enough that many people have begun referring to this admin menu as the “WinKey+X menu”, though that is not technically accurate.

Using the Search function

While the Quick Admin Tasks menu hidden behind the Start button is useful for calling common administrative tasks, using the Search function inside the Start menu is a powerful tool for interfacing with literally anything on your Windows Server. Depending on who installed applications and roles to your servers, you may or may not have shortcuts available to launch them inside the Start menu. You also may or may not have desktop shortcuts or links to open these programs from the taskbar. I find that it is often difficult to find specific settings that you are trying to tweak, but point-and-clicking your way through the interface. Control Panel is slowly being replaced by the newer Settings menu in newer versions of Windows, and sometimes this results in the discovery of particular settings being difficult. All of these troubles are alleviated with the search bar inside the Start menu. By simply clicking on the Start button or, even easier, by pressing the Windows key (WinKey) on your keyboard, you can simply start typing the name of whatever program, setting, or document that you want to open, and you will see search results from across the entire server.As a most basic example, press WinKey on your keyboard, then type notepad, and press the Enter key. You will see that good old Notepad opens right up for us. We never had to navigate anywhere in the Programs folder in order to find and open it. In fact, we never even had to touch the mouse, which is music to the ears of someone like me who loves doing everything he possibly can via the keyboard:

Figure 1.4: Windows Search

An even better example is to pick something that would be buried deep inside Settings or Control Panel. How about changing the speed of your mouse? A tradition server admin might open Control Panel (if they can find it), probably navigate to the Hardware or Appearance and Personalization sections because nothing else looks obviously correct, and still not find what they were looking for. After poking around for a few more minutes, they would start to think that Microsoft forgot to add this setting altogether. But alas, these mouse power settings are simply buried somewhere else and to be honest, I don’t think Microsoft really expects admins to manually seek things out at this point. We will discuss the new Settings screen momentarily in this chapter from which many common settings are being re-grouped into new homes, but ultimately for the purposes of this example, you are currently stuck at the point where you cannot find the setting you want to change. What’s the quick solution? Press your WinKey to open the Start menu, and type mouse speed. You’ll see in the list of available options showing in the search menu one called Change the mouse pointer display or speed. Click on that, and you will have found the setting you were looking for all along:

Figure 1.5: Searching for settings

Any other applications, settings, or even documents on your server that related to “mouse speed” will also be displayed in your search results. I don’t know of a more powerful way to open applications or settings on Windows Server 2025 than using the search bar inside the Start menu. Give it a try today!

Pinning programs to the taskbar or Start menu

While Windows Server 2025 provides great searching capabilities so that launching hard-to-find applications is very easy, sometimes it’s easier to have quick shortcuts for commonly used items to be available with a single click, down in the traditional taskbar. Alternatively, pin directly into your Start menu for easy access in the future. Whether you have sought out a particular application by browsing manually through the Start menu or have used the Search function to pull up the program that you want, you can simply right-click on the program and choose Pin to taskbar to stick a permanent shortcut to that application in the taskbar at the bottom of your screen. Once you have done this, during future logins to your session on the server, your favorite and most used applications will be waiting for you with a single click.As you can see in Figure 1.6, you also have the ability to pin programs to the Start menu, which of course is another useful place from which to launch them regularly:

Figure 1.6: Pinning programs to the taskbar

Many readers will already be very familiar with the process of pinning programs to the taskbar, so let’s take it one step further to portray an additional function you may not be aware is available to you when you have applications pinned.

The power of right-clicking

We are all familiar with right-clicking in any given area of a Windows operating system in order to do some more advanced functions. Small context menus displayed upon a right-click have existed since the two-button mouse rolled off the assembly line.We often right-click in order to copy text, copy documents, paste these, or get into a deeper set of properties for a particular file or folder. Many day-to-day tasks are accomplished with that mouse button. What I want to take a minute to point out is that software-makers, Microsoft and otherwise, have been adding even more right-click functionality into application launchers themselves, which makes it even more advantageous to have them close at hand, such as inside the taskbar.The amount of functionality provided to you when right-clicking on an application in the taskbar differs, depending on the application itself. For example, if I were to right-click on Command Prompt, I have options to either open Command Prompt, or to Unpin from taskbar. Very simple stuff. If I right-click again on the smaller menu option for Command Prompt, I have the ability to perform the same functions, but I could also get further into Properties, or Run as administrator. So, I get a little more enhanced functionality the deeper I go:

Figure 1.7: Right-click to Run as administrator

With other programs, you may find even more results. And the more you utilize your servers, the more data and options you will start to see in these right-click context menus. Two great examples are Notepad and Remote Desktop Client. On my server, I have worked on a few text configuration files, and I have used my server to jump into other servers to perform some remote tasks. I have done this using the Remote Desktop Client. Now, when I right-click on Notepad as listed in my taskbar, I have quick links to the most recent documents that I have worked on:

Figure 1.8: Right-clicking reveals recent documents

When right-clicking on my RDP icon, I now have quick links listed right here for the recent servers that I have connected to. I don’t know about you, but I RDP into a lot of different servers on a daily basis. Having a link for the Remote Desktop Client in the taskbar, automatically keeping track of the most recent servers I have visited, definitely saves me time and mouse clicks as I work through my daily tasks:

Figure 1.9: Recent RDP connections

These right-click functions have existed for a couple of operating system versions now, so it’s not new technology, but it is being expanded upon regularly as new versions of the applications are released. It is also a functionality that I don’t witness many server administrators utilizing, but perhaps they should start doing so in order to work more efficiently, which is why we are discussing it here.Something that is enhanced in the Windows 11 and Server 2025 platforms that is also very useful on a day-to-day basis is the Quick access view, which is presented by default when you open File Explorer. We all know and use File Explorer and have for a long time, but typically when you want to get to a particular place on a hard drive or to a specific file, you have many mouse clicks to go through in order to reach your destination. Windows Server 2025’s Quick access view immediately shows us both recently and frequently opened files and folders that we commonly access from the server. We, as admins, often have to visit the same places on the hard drive and open the same files time and time again. Wouldn’t it be great if File Explorer lumped all those common locations and file links in one place? That is exactly what Quick access does.You can see in the following screenshot that opening File Explorer gives you quick links to open both frequently accessed folders as well as links to your recent files. A feature like this can be a real time-saver, and regularly making use of these little bits and pieces available to you, in order to increase your efficiency, demonstrates to colleagues and those around you that you have a real familiarity and comfort level with this latest round of operating systems:

Figure 1.10: Quick access

You’ll also notice the small pushpin icons next to some of those Quick access locations. You can easily right-click on any folder location via File Explorer and choose Pin to Quick access, adding it to your Quick access menu, and Windows will maintain that pinned location right here inside the Quick access section until you choose to unpin it.

Tip

Yet another way that you can use right-clicking to your advantage is when you want to launch Terminal or PowerShell into a particular directory on a filesystem. Opening PowerShell in a standard method will land your PowerShell window directly into C:\Users\(username). Depending on what you need to do with PowerShell, you might spend many keystrokes navigating your way to the correct directory on your server from which you need to run a script or make some changes. Alternatively, if you are already inside File Explorer, you can hold down your Shift key and then right-click on any directory, and choose the option to Open in Terminal or Open PowerShell window here. This will immediately launch a new instance of Terminal or PowerShell, with your current directory being the folder you right-clicked on!

App snapping

Some of you may be familiar with add-ins to Windows called PowerTools, one of which allows you to easily carve out segments of your screen for different applications. When running multiple windows or applications on-screen at the same time, PowerTools allows an easy way to “snap” applications to a certain size or section of the screen, without any manual click-and-drag resizing of windows. Microsoft has baked some of this capability directly into Windows 11, and now that we are running the Win11 interface inside Windows Server 2025, application snapping is natively included in this newest server operating system as well. To be clear, PowerToys still offer other cool functions, but app snapping that we are discussing here is now a native capability and will work out of the box in Server 2025.App snapping is quite intuitive and you won’t need a lot of instruction to make use of it, but it’s good to know that there are three different ways you can call it to action.

Drag a window to the top-center of your screen and hold it there.

Hover your mouse over top of any window’s Maximize button.

Use WinKey+Z.

Invoking any of the above three procedures will display a nice little bar, which provides you with tons of different options about where and how you would like to position this window. Take a look at the image below, where I have hovered my mouse overtop of the Maximize button on a File Explorer window.

Figure 1.11: App snapping in action

As you can see, simply selecting one of the available screen zones will immediately snap this File Explorer window into that size and shape. My mouse is currently hovered over the option you see in blue, which would place File Explorer into the left third section of my screen. When selecting a zone that includes other gray colored zones, Windows will snap your application into that position, and then immediately ask you what application you would like to place into the other remaining open sections of screen. I use this functionality all the time when repositioning windows on my workstation, why not on servers?App snapping is fairly intuitive, as you can see in Figure 1.11, the top three options for File Explorer positioning have automatically given me options that will auto-position the other apps I currently have open on this server. Those apps are Server Manager, and the Hyper-V Manager console, which are easily identifiable by their icons. Selecting one of those top options will immediately place File Explorer on the left, with the other applications displayed alongside it toward the right. In Figure 1.12, you can see that I select the upper-right option, which laid File Explorer alongside both of the other open applications.

Figure 1.12: After snapping

One more tip related to this topic. If you know me at all, you know that I touch the mouse as little as possible, trying my best to live in a keyboard-only world. Your open applications and windows can also be snapped around your screen(s) with zero mouse interaction at all, by employing the following hotkeys:

WinKey+Left Arrow = Snap the active window to the left half of your current screen

WinKey+Right Arrow = Snap the active window to the right half of your current screen

WinKey+Up Arrow = Maximize the current window

WinKey+Down Arrow = Minimize the current window

WinKey+M = Minimize all open windows, which is pretty useful

And when using multiple monitors:

WinKey+Shift+Left = Move the current window to the next monitor on your left

WinKey+Shift+Right = Move the current window to the next monitor on your right

That may seem like a lot of keyboard functions to keep in the human memory banks, but they will become muscle memory in no time. Trust me, the time savings are worth it!

Windows Settings

If you work in IT and have used Windows 10 on a client machine for any period of time, it’s a sure bet that you have already worked within the newer Settings interface. Settings in Windows Server 2025 is just what the name implies, an interface from which you configure various settings within the operating system.What can sometimes be difficult or confusing about the existence of Settings is that we also have a different landing platform for settings contained inside Windows that has been around for a zillion years. It’s called Control Panel.The Settings menu inside Windows isn’t a brand-new idea but looks and feels quite new when compared to Control Panel. Windows Server 2012 and 2012 R2 had a quasi-presence of this newer Settings screen that, as far as I know, went largely unused by systems administrators. I believe that to be the effect of poor execution, as the Settings menu in 2012 was accessed and hidden behind the Charms bar, which most folks have decided was a terrible idea. We will not spend too much time on technology of the past, but the Charms bar in Server 2012 is a little bit like an AMC Pacer in the car world. You may have never even heard of it, or you may be old enough to have had the unfortunate experience of owning one yourself, and it is now irrevocably part of your own story. The Charms bar was a menu that presented itself when you swiped your finger in from the right edge of the screen. What’s that you ask? Servers don’t usually have touchscreens? I’m right there with you, not any that I have ever worked on, anyway. So, the Charms bar was also presented when you hovered the mouse up near the top right of the screen. It was quite difficult to access, yet seemed to always appear whenever you didn’t want it to, like when you were trying to click on something on the right side of the screen and instead you clicked on something inside the Charms bar that suddenly popped out of nowhere.I am only giving you this background information in order to segue into this next idea. Much of the user interface in Windows 10+, and therefore Windows Server 2016+, can be considered a small step backward from the realm of finger swipes and touchscreens. Windows 8 and Server 2012 were so focused on big app buttons and finger swipes that a lot of people got lost in the shuffle. It was so different from what we had ever seen before and difficult to use at an administrative level. Because of feedback received from that release, the graphical interface and user controls, including both the Start menu and the Settings menu in Windows Server 2025, are sort of smack-dab in the middle between Server 2008 and Server 2012. This backward step was the right one to take, and I have heard nothing but praise so far for the newer user interfaces.So, getting back to the Settings menu, if you click on your Start button, then click on that little gear labeled Settings, you will see this new interface:

Figure 1.13: Windows Settings

There are many settings and pieces of the operating system that you can configure in this new Settings menu. Some settings in Windows now only exist in this interface, but many can still be accessed either here or through the traditional Control Panel. The goal seems to be a shift toward all configurations being done through the new menu in future releases, but, for now, we can still administer most setting changes through our traditional methods if we so choose. I mentioned Windows Update earlier, and that is a good example to look over. Historically, we would configure our Windows Update settings via Control Panel, but they have now been completely migrated over to the new Settings menu in Windows Server 2025. Search Control Panel for Windows Update, and the only result is that you can view currently installed updates. But, if you search the new Settings menu for Windows Update, you’ll find it right away.Remember, you can always use the Windows search feature to look for any setting! Hit your WinKey and type Windows Update, and you’ll be given quick links that take you straight into the appropriate Settings menus.For the moment, you will have to use a combination of Control Panel and the Settings menu to do your work. This gets confusing occasionally. With each new release of the Windows operating system, Microsoft moves more and more functions directly into Settings, lessening the requirements on Control Panel. As an example, even in Windows Server 2022 if you wanted to change a NIC’s IP address, you would always need to visit one of the older configuration screens. You could view NIC settings inside the Settings console, but clicking the button to edit the IP address of a network card would then launch the older Network Connections screen. While Network Connections still exists and you can certainly still use it to edit NIC configurations, for the first time in the history of Windows Server you can now change your IP address directly from inside the Settings interface!Go ahead and try it out. Launch into the Settings menu and navigate to Network & internet. Then click Ethernet in the right column. Scrolling down a little bit, you will find your IP assignment displayed, alongside a button called Edit. Previously, selecting the option here to edit an IP address would immediately launch a separate window to the old style Control Panel screens, but as of today we have the ability to edit our IP address right here inside Settings!

Figure 1.14: Editing IP address inside Settings

While Microsoft continues to move Windows configuration items into the Settings console, don’t be surprised if you still run across some items that take you back to those classic Control Panel screens. They still exist, even if they are starting to collect dust on the shelf.

Two ways to do the same thing

Potentially confusing as well, until you get used to navigating around in here, is that you can sometimes accomplish the same task in either Control Panel or the Settings menu, but the process that you take in each interface can have a vastly different look and feel. Let’s take a look at that firsthand by trying to create a new user account on our server, once via Control Panel, and again via Settings.

Creating a new user through Control Panel

You are probably familiar with this. Open Control Panel and click on User Accounts. Then, click on the User Accounts heading. Now, click on the link to Manage another account. Inside this screen is your option to Add a user account. Click on that and you get the dialog box where you enter a username and password for your new user:

Figure 1.15: Adding a user account via Control Panel

Creating a new user through the Settings menu

Let’s take this newer Settings interface for a test drive. Open the Settings menu and click on Accounts. Now, click on Other users in the right column. There is a button here to Add account; go ahead and click on that:

Figure 1.16: Adding a user account via Settings

What in the world is that? Not what I expected, unfortunately. To my surprise, the old Control Panel user account launches a nice, fresh-looking interface from which I can create new user accounts. Accessing user accounts via the newer Settings console launches me into the old Local Users and Groups manager. Technically, from here I could go ahead and create new user accounts, but it seems like there is some sort of a disconnect here. You would naturally think that the new Settings would initiate the newer, nicer screen to add new user accounts, but we found the opposite to be true.We walked through this simple example of attempting to perform the same function through two different interfaces to showcase that there are some items that can, and must, be performed within the new Settings menu context, but there are many functions within Windows that still need to be accomplished through our traditional interfaces. While Control Panel continues to exist, and probably will for a very long time, you should start navigating your way around the Settings menu and figure out what is available inside, so that you can start to shape your ideas for the best combination of both worlds in order to manage your servers effectively.Just one last thing to point out as we start getting comfortable with the way that the new Settings menu looks: many of the settings that we configure in our servers are on/off types of settings. By that I mean we are setting something to either one option or another. Historically, these kinds of configurations were handled by either drop-down menus or radio buttons. That is normal; that is expected; that is Windows. Now, you will start to see little swipe bars, or sliders, that allow you to switch settings on or off, like a light switch. Anyone who has used the settings interface of any smartphone knows exactly what I am talking about. This user interface behavior has now made its way into the full Windows operating systems and is probably here to stay. Just to give you an idea of what it looks like inside the context of the new Settings menu, here is a screenshot of the current Windows Update -> Advanced options settings page.This is a good example of those on/off slider buttons:

Figure 1.17: Windows Update | Advanced options

Let’s explore the Task Manager tool next.

Task Manager

Task Manager is a tool that has existed in all Windows operating systems since the first days of the graphical interface, but it has evolved quite a bit over the years. This tool is essential for troubleshooting problems happening inside Windows, and for terminating applications or processes that seem to be “stuck”. One of the goals for Windows Server 2025 is to be even more useful and reliable than any previous version of Windows Server has been. So, it only makes sense that we finally remove Task Manager altogether, since it simply won’t be needed anymore, right?I’m kidding, of course! While Server 2025 will hopefully prove itself to indeed be the most stable and least needy operating system we have ever seen from Microsoft, Task Manager still exists and will still be needed by server administrators everywhere. If you haven’t taken a close look at Task Manager in a while, it has changed significantly over the past few releases. Now that we have adopted the Windows 11 GUI, along with it comes a brand-new Task Manager.Task Manager is still typically invoked by either hitting Ctrl + Alt + Del on your keyboard and then clicking on Task Manager, or by right-clicking on the taskbar and then choosing Task Manager. You can also launch Task Manager with the key combination Ctrl + Shift + Esc or by typing taskmgr inside the Run or Search dialog boxes. If you have already worked with Windows Server 2022, you’ll notice a change right away. Previously a miniature version of Task Manager was displayed by default, only a simple list of applications that are currently running. This was a useful interface for forcing an application to close that may be hung up, but not for much else, and my guess is that 99% of Task Manager launches were immediately followed by a click into the More details link. That miniature instance of Task Manager is gone, and launching Task Manager via any method will get you to the full toolset.We immediately notice that the displayed information is more user-friendly than in previous years, with both Apps and Background processes being categorized in a more intuitive way and multiple instances of the same application being condensed down for easy viewing. This gives a faster overhead view of what is going on with our system, while still giving us the ability to expand each application or process to see what individual components or windows are running within the application, such as in Figure 1.18:

Figure 1.18: Task Manager: Processes

Tip

One of the greatest additions to this new Task Manager is the Search bar on top! Never before has it been so easy to quickly narrow in on a problematic application or process, or to seek out specific information for your troubleshooting.

Make sure to check out the other sections available inside Task Manager as well, listed along the lefthand side. Users will show us a list of currently logged-in users and the amount of hardware resources that their user sessions are consuming. This is a nice way to identify on a Remote Desktop Session Host server, for example, an individual who might be causing a slowdown on the server. The Details tab is a little bit more of a traditional view of the Processes tab, splitting out much of the same information but in the older style that we were used to seeing in versions of the operating system long ago. Then, the Services tab is pretty self-explanatory; it shows you the Windows services currently installed on the server, their statuses, and offers the ability to start or stop these services as needed, without having to open the Services console separately. Startup apps is a quick way to see what applications are configured to start when the operating system starts, and you can easily enable or disable that from happening per application.Anyone who has been using Windows 11 for a while may already have experience with another section of this new Task Manager, called App history. Previously, Task Manager was only focused on real-time data. While certainly useful for live troubleshooting and fixing of problems that are happening right now, historical data is always part of troubleshooting methodology. We now have some historical data right here inside Task Manager! This instance of Windows Server 2025 that I am using has not been running for very long, and so the App history screen is quite boring at the moment. However, if I open the same window on my Windows 11 workstation that I have been using for a while, we see a good representation of the useful information this tool is going to present.

Figure 1.19: Task Manager: App history

The section of Task Manager that I skipped over so that I could mention it more specifically next is the Performance tab. This is a pretty powerful one. Inside, you can quickly monitor CPU, memory, and Ethernet utilization. As you can see in the following screenshot, I haven’t done a very good job of planning resources on this particular virtual machine, as my CPU is hardly being touched, but I am almost out of system memory:

Figure 1.20: Task Manager: Performance

Another useful piece of information available inside this screen is server uptime, and I visit Task Manager often for exactly this reason. Discovering the amount of time that a server has been running without a restart can be critical when troubleshooting an issue, and I watch admins time and time again calculating system uptime based on log timestamps. Using Task Manager is a much easier way to find that information!If you are interested in viewing more in-depth data about server performance, there is another application in Windows called Resource Monitor. In fact, two other technologies provided inside Windows Server 2025 are useful for monitoring system status, particularly for hardware performance: Resource Monitor and Performance Monitor. Open up these tools and start testing them out, as they can provide both troubleshooting information and essential baseline data when you spin up a new server. This baseline can then be compared against future testing data so that you can monitor how new applications or services installed on a particular server have affected their resource consumption. We will discuss these additional monitoring tools in Chapter 17, Troubleshooting.Moving back to Task Manager, there is just one other little neat trick I would like to test. Still inside the Performance tab, go ahead and right-click on any particular piece of data that you are interested in. I will right-click on the CPU information near the left side of the window. This opens up a dialog box with a few options, of which I am going to click on Summary view. This condenses the data that was previously taking up about half of my screen real estate into a tiny little window, which I can move to the corner of my screen. This is a nice way to always keep hardware utilization data on the screen as you navigate through and work on your server, so that you can watch for any spikes or increases in resource consumption when making changes to the system:

Figure 1.21: Task Manager: Summary Resources

Now let’s check out this often-underutilized function called Task View!

Task View

Task View is a sweet feature that first appeared inside Windows 10 and Windows Server 2016, which continues to carry over into Server 2025. It is a similar idea to that of holding down the Alt key and then pressing Tab in order to cycle through the applications that you currently have running. For anyone who has never tried that, go ahead and hold down those two keys on your keyboard right now. Depending on what version of Windows you are running, your screen might look slightly different from this, but, in effect, it’s the same information. You can see all of the programs you currently have open, and you can cycle through them from left to right using additional presses of the Tab button. Alternatively, use Alt + Shift + Tab in order to cycle through them in reverse order. When you have many windows open, it is perhaps easier to simply use the mouse to jump to any specific window:

Figure 1.22: ALT+TAB to shuffle between open windows

Task View is quite a bit more powerful than this, because it adds the capability of managing multiple full desktops’ worth of windows and applications. For example, if you were working on two different projects on the same server, and each project required you to have many different windows open at the same time, you would start to burn a lot of time switching back and forth between all of your different apps and windows in order to find what you were looking for. Using Task View, you could leave all of your open windows for the first project on your first desktop, and open all of the windows dealing with the second project on a second desktop. Then, with two clicks, you could easily switch back and forth between the different desktops, using the Task View button. By default, Task View is the little button down in the taskbar, immediately to the right of the search bar. Go ahead and click on it now – it looks like this:

Figure 1.23: The Task View button

You now see a listing of your currently open windows; this looks very similar to the Alt+ Tab functionality we looked at earlier. The primary difference is the option called out in Figure 1.23 which gives you the option to create a New desktop. Go ahead and click on that, and you will now discover that clicks on the Task View button show that you are running two separate Desktops, Desktop 1 and Desktop 2. Flip back and forth between the two desktops, and you will find that you can run completely separated applications between the two desktop views. In Figure 1.24 you can tell that I have different things open on Desktop 1 than I do on Desktop 2, and switching between these two desktops is very fast and easy. You can even drag and drop existing windows between different desktops, right on this Task View screen:

Figure 1.24: Navigating multiple desktops

Task View is a great way to stay organized and efficient by utilizing multiple desktops on the same server. I suppose it is kind of like running dual monitors, or three, four, or more, all from a single physical monitor screen.If you want to avoid having to click on the icon for Task View, pressing WinKey + Tab on your keyboard does the same thing!

Summary

This first chapter on Windows Server 2025 was an exploration of what it means to be a server, and to discover what new features and functions Microsoft has gifted us this year. We also spent time gaining familiarity and comfort navigating around the interface. There are various ways to interact with Server 2025, and we will discuss many of them throughout this book, but most server administrators will interface with this new operating system through the full graphical interface, using both the mouse and keyboard to perform their tasks. If you have worked with previous versions of the Windows Server operating system, then a lot of the tools that you will use to drive this new platform will be the same, or at least similar, to the ones that you have used in the past. New operating systems should always be an evolution of their predecessors, and never entirely new. I think this was a lesson learned with the release of Windows 8 and Server 2012.With Server 2025, we find a great compromise between the traditional familiarity of the prior versions of Windows and the new benefits that come with rounded edges and touch-friendly screens, which will be used more and more often as we move toward the future of Windows-based devices. In the next chapter, we’ll start putting rubber to road as we install and begin managing Windows Server 2025.

Questions

In Windows Server 2025, how can you launch an elevated Terminal prompt with two mouse clicks?

What is the keyboard combination to open the Quick Admin Tasks menu?

What is the name of Microsoft’s cloud service offering?

Which Windows Server release model has disappeared with the advent of Windows Server 2022?

How many virtual machines can run on top of a Windows Server 2025 Standard host, with default licensing?

What installation option for Windows Server 2025 does not have a graphical user interface?

Which is the correct verbiage for the latest release of Windows Server 2025, Long-Term Servicing Branch (LTSB) or Long-Term Servicing Channel (LTSC)?

What is the correct tool from which to change configurations on Windows Server 2025, Windows Settings or Control Panel?

What key combination can be used to launch Task View, without touching your mouse?

2 Installation and Management

Join our book community on Discord

https://packt.link/zYovfReading about all of the great things that Windows Server 2025 brings into your life is helpful, but I realize that some of you are sitting back thinking, that’s great to read about, but how do I really get started playing around with this for myself? Reading about technology is never as good as experiencing it for yourself, and most people learn best when they are working hands-on with their research subject. One of the biggest goals of this book is to make sure we enable you to use the product. Rattling off facts about new features and efficiency is fine and dandy but ultimately worthless if you aren’t able to make it work in real life. So, let’s make this chunk of raw server metal do some work for us.In this chapter, we will be covering the following:

Technical requirements

Installing Windows Server 2025

Installing roles and features

Centralized management and monitoring

Windows Admin Center (WAC)

Azure Arc

Quick server rollouts with Sysprep

In-place upgrading to Windows Server 2025

Let’s get started!

Technical requirements

When planning for the build of a new server, many of the decisions that you need to make are licensing-type decisions. What roles do you intend to install on this server? Do they require a special edition? Can the more common Server 2025 Standard edition handle it, or do we need the Datacenter edition for our purposes? Is Server Core going to be beneficial from a security perspective, or do we need the full Desktop Experience? In these days of Hyper-V Servers having the ability to spin up virtual machines on a whim, we oftentimes proceed without much consideration of the hardware of a server, but there are certainly still instances where physical equipment will be responsible for hosting the Windows Server 2025 operating system.In these cases, you need to be aware of the requirements for this new platform, so let us take a minute to list those specifics. This information is available in longer form on the Microsoft Learn website if you need to double-check any specifics, but here are your summarized minimum system requirements (https://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements?tabs=cpu&pivots=windows-server-2025):

CPU: 1.4 GHz 64-bit that supports a number of things—NX, DEP, CMPXCHG16b, LAHF/SAHF, PrefetchW, and SLAT.

RAM: 512 MB ECC memory minimum for Server Core, or a recommended 4 GB minimum for a server running Desktop Experience. Microsoft officially lists it as 2GB minimum, 4GB recommended but I can tell you that it is possible to install and run Desktop Experience with far fewer than 2 GB (such as inside a test lab), but the performance of that server will suffer. Interestingly, the Server 2025 installer will not even work unless your Virtual Machine (VM) server has at least 800 MB of RAM, so you’ll need to start there. Following OS installation, you could back it down lower if needed.

Disk: Server 2025 requires a PCI Express (PCIe) storage adapter. ATA/PATA/IDE are not allowed for boot drives. The minimum storage space requirement is 32 GB, but Desktop Experience consumes about 4 GB more space than Server Core, so take that into consideration.

Keep in mind, these are the bare minimum specs that your server is going to require. Any real server in a production environment will need far more memory and disk space, and there is no magic number for what you will need. It depends on what workload you are going to expect out of your server.One example of hardware that is not specifically required but is almost certainly going to be in place for 99% of servers being built is a TPM 2.0 chip. These hardware chips have been around for many years now and enable functionality such as BitLocker. You don’t necessarily need to run Bitlocker on your server, but these chips are now considered commonplace, and you really should never buy a workstation or server that does not have a TPM 2.0.In fact, there is some cool news about just how far you can go with assigning resources in this new version. Windows Server 2022 supported 48 TB of memory and 2,048 logical CPU cores, which was really impressive. Compared with Windows Server 2025, these numbers are small potatoes. Windows Server 2025 now boasts support for 4 PB of RAM (yes you read that right, Petabytes!!!), and an unlimited number of CPU cores. Administrators with an actual need to run more than 48 TB of memory in a single server are probably using it as a big-time hypervisor or as part of their Azure Local infrastructure, but can you imagine a SQL server with Petabytes of memory? It is a common thing for SQL servers to chew up however much RAM you throw at the server, causing us to impose limits within SQL itself about how much memory it can grab. Perhaps with a PB at its disposal, SQL would actually leave some unallocated for the operating system. Nah, probably not…

Installing Windows Server 2025

In general, the installation process for Microsoft operating systems has improved dramatically over the past 20 years. I assume that a lot of you, as IT professionals, are also the de facto neighborhood computer guru, constantly asked by friends and family to fix or rebuild their computers. If you’re anything like me, this means you are still occasionally rebuilding operating systems such as Windows 7, maybe even XP. Looking at the bright blue setup screens and finding a keyboard with the F8 key are imperative to this process. To spend two hours simply installing the base operating system and bringing it up to the highest service pack level is pretty normal. Compared to that timeline, installing a modern operating system (OS) such as Windows Server 2025 is almost unbelievably fast and simple.It is very likely that many readers have completed this process numerous times already, and if that is the case, feel free to skip ahead a couple of pages. But for anyone new to the Microsoft world, or new to IT in general, I’d like to take just a couple of quick pages to make sure you have a baseline to get started with. Without earning your Installing an OS 101 badge on your tool belt, that shiny server will make for an interesting piece of wall art.

Burning that ISO

The first thing you must do is acquire some installation media. The most simple and straightforward way to implement a single new server is to download a .ISO file from Microsoft, burn that .ISO to a DVD (don’t worry, we will cover USB media next), and slide that DVD in to be used for installation. If you are testing out Server 2025 for personal reasons and do not own any licensing for it, open a search engine such as Bing and search for something like Download Windows Server 2025 Evaluation. Make sure to click the link that is an actual Microsoft.com entity, and you will find options for either evaluating Windows Server 2025 inside Azure, or downloading a .ISO file and saving it onto the hard drive of your computer.If you do happen to own licensing for Server 2025, or if for any reason you have a Microsoft Visual Studio license, then there is an even better way to acquire your installation media. Simply log in to your Visual Studio portal, and use the Downloads section to search for Windows Server 2025. In the past, Microsoft software portals were quite confusing and difficult to find what you were looking for. The Visual Studio portal has been recently updated and is by far the most friendly interface for grabbing software and license keys that I have ever seen from Microsoft.

Figure 2.1: Downloading the installer with Visual Studio

In the past, the trickiest part of getting a .ISO file to be a workable DVD was the need to download some kind of third-party tool in order to burn it to a disc while making it bootable. If you are running an older client operating system on your computer, this may still be the case for you. I have watched many who are new to this process take the .ISO file, drag it over to their disc drive, and start burning the disc. This creates a DVD with the .ISO file sitting on it, but that .ISO is still packaged up and not bootable in any way, so the disc would be worthless to your new piece of server hardware. Luckily, the newer versions of the Windows client operating systems have built-in functions for dealing with.ISO files, which makes the correct burning process very simple.Once you have your .ISO file for the Windows Server 2025 installation downloaded onto your computer, insert a fresh DVD into your disc drive and browse to the new file. Simply right-click on the .ISO file, and then choose your menu option for Burn disc image. This launches a simple wizard that will extract and burn your new .ISO file the correct way onto the DVD, making it a bootable installation media for your new server, as shown in Figure 2.2:

Figure 2.2: Burning your .ISO file onto DVD

It is probable when you attempt to download Windows Server 2025 and use this Windows Disc Image Burner utility with a DVD that you grabbed off your stack of standard blank DVDs that you will receive the following error message: The disc image file is too large and will not fit on the recordable disc.This should come as no surprise because our operating system installer files have been getting larger and larger over the years. We have now reached the critical tipping point where the standard Server 2025 ISO installer is larger than a standard 4.7 GB DVD. To burn this ISO onto a DVD, you will need to hit the store and find some dual-layer discs that can handle more data.

Creating a bootable USB stick with software

DVDs can be cumbersome and annoying, and now they are also too small for our purposes. Therefore, when installing newer, larger operating systems, it is becoming commonplace to prep a USB stick to use for the installation of the operating system rather than relying on a DVD.To do this, all you need is a Windows computer, a USB stick that is at least 8 GB, and access to the internet. You will need to download the same ISO that we discussed earlier, as that contains all of the installation files for Server 2025. Then you will also need to download and install some kind of bootable USB creation tool.There are various free ones available (Rufus is pretty popular), but the one straight from Microsoft is called the Windows 7 USB/DVD Download Tool. Why does it still to this day have this crazy name that includes the words Windows 7 right in it? Don’t ask me.Regardless of the old name, it works well and is a quick, easy, and free way to prep your bootable USB sticks for fresh operating system installations. I should point out that this tool has nothing to do with Windows 7. It will take any .ISO file and turn it into a bootable USB stick. That ISO can be a Windows 10 or Server 2022 ISO file, and it still works just fine. You can also install and run the Windows 7 USB/DVD Download Tool on a Windows 10 or 11 workstation without any trouble.Once the USB DVD Download Tool is installed, launch the application and simply walk through the four-step wizard.This process will erase and format your USB stick. Make sure nothing important is stored there!You will need to identify the ISO that you want the tool to grab information from, then choose your USB stick from a drop-down list. After that, simply click the Begin copying button, and this tool will turn your USB stick into a bootable stick capable of installing the entire Windows Server 2025 OS, as shown in Figure 2.3:

Figure 2.3: Creating a bootable USB stick

Creating a bootable USB stick with PowerShell

Alternatively, there is another option to create a bootable USB drive that doesn’t involve software at all. I tend to prefer the Windows 7 Download Tool because it is very fast, and I already have it installed on my computer. If you aren’t interested in more software on your computer, Microsoft has provided a PowerShell script that serves the same purpose. Here are the steps you would take to perform this task:

Download and mount the ISO. It is important that you right-click on the ISO and choose the option to “Mount” it, which opens that ISO to see all files inside, and assigns this file a drive letter on your system. Take note of this drive letter, so that it can be specified when you run this script.

Plug in your USB stick and also take note of the drive letter that Windows assigns to this stick; you’ll need to specify it in a minute.

Launch PowerShell and paste in the following script. This script is directly from Microsoft, I make no claims on the creation of it. When run, this script will ask you to specify the drive letter being used by your USB drive, and then ask for the drive letter being used by the mounted ISO file. Once specified, the script will format this USB stick to be empty and bootable, and then copy all contents from the ISO.

Select USB drive letter

$usbDriveLetter = Read-Host "Enter USB drive letter (Ex: E)"

Format USB drive

Format-Volume -DriveLetter $usbDriveLetter -FileSystem NTFS -NewFileSystemLabel "WinServerUSB" -Confirm:$false | Out-Null

Select ISO file mount point

$isoMountPointDriveLetter = Read-Host "Enter ISO mount point drive letter (Ex: F)"

Copy ISO files to USB drive

$source = "$($isoMountPointDriveLetter):" $destination = "$($usbDriveLetter):" robocopy $source $destination /COPYALL /Z /E /SEC /R:3 /W:3

Make USB drive bootable

$usbDriveNumber = (Get-WmiObject -Class Win32_DiskDrive | Where-Object {$.InterfaceType -eq "USB" -and $.DeviceID -like "*$usbDriveLetter"}).Index bootsect /nt60 $usbDriveLetter | Out-Null

Task completion notification

Write-Host "Copy operation complete" Start-Sleep -Seconds 2

Your USB drive is now prepped and ready.

Running the installer

Now go ahead and plug your newly created DVD or bootable USB into the new server hardware. Boot to it, and you will finally see the installation wizard for Windows Server 2025. Now, there really are not that many options for you to choose from within these wizards, so we won’t spend a lot of time here. For the most part, you are simply clicking on the Next button to progress through the screens, but there are a few specific places where you will need to make decisions along the way.After choosing your language and keyboard settings, the next screen is something we have never seen previously in a Windows Server installer. Repair of server operating systems has always been a little cumbersome, requiring you to boot into Recovery Mode and seek out troubleshooting functions. Microsoft has now built a Repair my PC option directly into the installer process! While we have no reason to select that option here because we are installing a fresh server and the top option is clearly right for us today, I love this adjustment of the setup wizards. Those who have been through Windows Server setup before will also notice that this installation wizard makes more common sense than years past.On this initial screen you simply define that you intend to Install Windows Server. That makes sense and is very straightforward. In previous versions of Windows Server installation, the screen asked if you were planning to Upgrade your server or install via Custom settings. That older screen was always confusing to new admins and didn’t carry a lot of common sense. I am excited to see this change!

Figure 2.4: Installing Windows Server 2025

You may have also noticed the small link near the bottom of Figure 2.4, Previous Version of Setup. I cannot think of a technical reason why Microsoft is maintaining both versions of the installer here inside setup, so perhaps this option is simply for those who prefer the older installer and are not quite ready for the change to the updated interface. No matter the reason, if you prefer to look at the older installation wizard screens that were our home-base for installing the OS from Server 2016 through Server 2022, simply click on that little link and you will instead find yourself looking at that old familiar hue of dark blue.

Figure 2.5: Previous version of setup

Moving forward with the updated installation process, check the box shown in Figure 2.4 to acknowledge that your existing files, apps, and settings will be deleted (we are installing on a fresh drive, so nothing exists), and then we find ourselves facing another updated screen with a brand new option. The ability to utilize a product key to license your new server is nothing new, but that option to Pay-as-you-go is very unexpected! We talked about this new option in Chapter 1, rather than purchasing one-time perpetual licensing for your server operating system, you now have the ability to tie this new server into an Azure subscription, and (just as you would do for servers running inside Azure) pay for only what you use on this new server. This is quite a novel idea for on-prem server infrastructure!If you are building out a test lab or have not yet purchased your Server 2025 licensing, simply click the link near the bottom I don’t have a product key and you will progress to the next screen without specifying any information for licensing. This will place Windows Server 2025 into a fully working mode, but not legally activated and you will always have a watermark displayed in the lower-right part of your screen until you do license this new instance of Windows.

Figure 2.6: Licensing your new server

Our next screen is interesting and one where you will want to pay close attention. You will find four different installation options for Windows Server 2025. There are what seem to be the “regular” installers for Windows Server 2025 Standard or Datacenter, and then other options that include the words (Desktop Experience) for each. Typically, in the Microsoft installer world, clicking on Next through every option gives you the most typical and common installation path for whatever it is that you are installing. Not so with this wizard. If you simply glide by this screen by clicking on Next, you will find yourself with an installation of Server Core in the end.We will talk more about Server Core in a later chapter of the book, but for now, I will just say that if you are expecting to have a server that looks and feels like what we talked about in Chapter 1, Getting Started with Windows Server 2025, this default option is not going to be the one that gets you there. This “Desktop Experience” that the wizard is talking about is the full Windows Server graphical interface, which you are more than likely expecting to see once we are done with our installation. So, for the purposes of our installation here, where we want to interact with the server using full color and a mouse, go ahead and choose an option that includes Desktop Experience before clicking on the Next button, as shown in Figure 2.7:

Figure 2.7: Windows Server 2025 installation options

In some previous versions of Windows Server, we had the ability to migrate back and forth from a full Desktop Experience to Server Core and back again, even after the operating system was installed. This does not work in Windows Server 2025! The ability to transition between the two modes disappeared years ago, so it is even more important that you plan your servers properly from the beginning.After agreeing to licensing terms, we now need to decide where we want to install our new copy of Windows Server 2025. In many cases, you will simply click on Next here because your server will have just a single hard disk drive, or maybe a single RAID array of disks, and, in either case, you will see a single pool of free space onto which you can install the operating system. If you have multiple hard drives installed on your server and they have not been tied together in any way yet, then you will have multiple choices here of where to install Windows Server.We have a single hard disk attached here to my virtual server, which has never been used, so I can simply click on Next to continue. Note here that if your drives had existing or old data on them, you would have the opportunity here, with some built-in disk management tools, to format the disk or delete individual partitions. If you are using some specialized disks that take specific drivers, there is also a Load driver button, which you can use to inject these special drivers into the installation wizard in order to view and use these kinds of disks.Also, it is important to note on this screen that while there is a button to Create Partition, you do not have to do this in order to continue. Many new admins assume that you must manually create the partition, so Windows knows where to install its files. On the contrary, if you have unallocated space selected as I do in Figure 2.8 and then simply click Next, the installer will take care of creating the necessary partitions for you:

Figure 2.8: Windows installation destination

Now review your summary screen of installation options, and click that final Install button.That’s it! You will see the server installer start going to town, copying files, installing features, and getting everything ready on the hard drive. This part of the installer runs on its own for a few minutes, and the next time you need to interact with the server, it will be within the graphical interface where you get to define the administrator password. Once you have specified a password, you will find yourself on the Windows desktop. Now you are really ready to start making use of your new Windows Server 2025.

Installing roles and features

Installing the operating system gets your foot in the door, so to speak, using your server as a server. However, you can’t actually do anything useful with your server at this point. On a client desktop system, the base operating system is generally all that is needed to start working and consuming data. The server’s job is to serve up that data in the first place, and until you tell the server what its purpose is in life, there really isn’t anything useful happening in that base operating system. This is where we need to utilize roles and features. Windows Server 2025 contains many different options for roles. A role is just what the name implies: the installation of a particular role onto a server defines that server’s role in the network. In other words, a role gives a server some purpose in life. A feature, on the other hand, is more of a subset of functions that you can install onto a server. Features can complement roles or stand on their own. There are pieces of technology available in Windows Server 2025 that are not installed or turned on by default because these features wouldn’t be used in all circumstances. Everything in the later chapters of this book revolves around the functionality provided by roles and features. They are the bread and butter of a Windows server, and, without their installation, your servers make good paperweights, but not much else. As we will not take the time in each chapter to cover the installation of every particular role or feature that will be used within the chapter, let’s take some time right now to cover the most common paths that admins can take in order to get these roles and features installed onto their own servers.

Installing a role using the wizard

Without a doubt, the most common place that roles and features get installed is right inside the graphical wizards available as soon as your operating system has been installed. By default, a tool called Server Manager launches automatically every time you log in to Windows Server 2025. We will take a closer look at Server Manager itself later in this chapter, but for our purposes here, we will simply use it as a launching platform to get to our wizard, which will guide us through the installation of our first role on this new server we are putting together.Since you have just logged into this new server, you should be staring at the Server Manager dashboard. Right in the middle of the dashboard, you will see some links available to click on, a quick-start list of action items numbered one through five. If you haven’t already done so, put into place any local server configuration that you may need on this machine through the first link, which is called Configure this local server.Items that you will likely want in place are things such as a permanent hostname for the server, IP addressing, and, if you are joining this server to an existing domain (we will discuss domains in Chapter 3, Active Directory), you typically handle that process prior to implementing any new roles on the server. But, in our case, we are more specifically interested in the role installation itself, so we will assume that you have already configured these little bits and pieces to have your server identified and routing on your network.Go ahead and click on step 2, Add roles and features. Another way you can launch the same wizard is by clicking on the Manage menu from the top bar inside Server Manager and then choosing Add Roles and Features from the drop-down list. Selecting either link will bring you into our wizard for installation of the roles, as shown in Figure 2.9:

Figure 2.9: Adding roles

You are first taken to a summary screen about installing roles. Go ahead and click Next to bypass this screen. Now we get into our first option, which is an interesting one. We are first asked if we want to continue with a Role-based or feature-based installation, which is exactly what we have been talking about doing. But the second option here, Remote Desktop Services installation, is important to note. Most of us consider the Remote Desktop Services (RDS) components of Windows Server to be just another role that we can choose when setting up our server, similar to the installation of any other role. While that is basically true, it is important to note that RDS is so functionally different from the other kinds of roles that the entry path into the installation of any of the RDS components invokes its own wizard by choosing the second option here. So, if you ever find yourself looking for the option to install RDS, and you have glossed over this screen because you are so used to clicking Next through it like I am, remember that you need to head back there to tell the wizard that you want to deal with an RDS component, and the remainder of the screens will adjust accordingly. We will explore RDS more thoroughly in a later chapter of this book.At the moment, I am working on building out a new test lab full of Windows Server 2025 boxes, and I am still in need of a Domain Controller (DC) to manage Active Directory in my environment. Before installing Active Directory on a server, it is critical that I have a few prerequisites in place, so I have already accomplished those items on my new server. The items that I need to have in place prior to the AD DS role installation are:

Static IP – Assign a static IP address to this server, it is important that a DC maintains a constant IP on the network.

DNS – Define a DNS server on the NIC. If you are building a lab or the beginning of a network, this new DC may well become your first DNS server also, in which case defining 127.0.0.1 as your first DNS server is acceptable.

Hostname – Make sure to give this server a good name. Once you turn a server into a Domain Controller, it is unsupported (and will cause you grief) if you ever try to rename that server.

I have already accomplished these items on my server, so I will continue through my role installation wizard here by leaving the option set to Role-based or feature-based installation and clicking on Next, as shown in Figure 2.10:

Figure 2.10: Select Role-based or feature-based installation for most roles

Our Server Selection screen is a very powerful one. If you’ve been through this process before, you have likely glossed over this screen, simply clicking on the Next button to progress through it. But essentially, what this screen is doing is asking you where you would like to install this new role or feature. By default, each server will only have itself listed on this screen, so clicking on Next to continue is more than likely what you will be doing. But there are a couple of neat options here. First, if your Server Manager is aware of other servers in your network and has been configured to monitor them, you will have the option here to install a role or feature remotely onto one of the other servers. We will dig a little deeper into this capability shortly. Another feature on this page, which I haven’t seen many people utilize, is the ability to specify that you want to install a role or feature onto a virtual hard disk. Many of us work almost exclusively with virtual servers in this day and age, and you don’t even need your virtual server to be running in order to install a role or feature to it! As long as you have access to the .VHDX, the hard disk file, from where you are running Server Manager you can Select a virtual hard disk from this screen, which allows you to inject the new role or feature directly into that hard drive. But, as is the case 99% of the times that you will wander through this screen, we are logged directly into the server where we intend to install the role, and so we simply click on Next, as shown in Figure 2.11:

Figure 2.11: Selecting the destination server

Next we have our list of roles that are available to be installed. Clicking on each role will give you a short description of the purpose of that role if you have any questions, and we will also talk more about the core infrastructural roles throughout our next few chapters to give you even more information about what the roles do. All we need to do here to install a role onto our new server is check the box and click on Next. Since this is going to be a domain controller, I will choose the Active Directory Domain Services role, and I will multipurpose this server to also be a DNS server and a DHCP server. With these roles, there is no need to rerun through this wizard three separate times to install all of these roles; I can simply check them all here and let the wizard run the installers together. Whoops, when I clicked on my first checkbox, I got a pop-up message that the Active Directory Domain Services role requires some additional features in order to work properly. This is normal behavior, and you will notice that many of the roles that you install will require additional components or features to be installed. All you need to do is click on the Add Features button, and it will automatically add these extra pieces for you during the installation process. An example of this is shown in Figure 2.12:

Figure 2.12: Additional features

Now that we have all three of our roles checked, it’s time to click on Next. And, just to make it clear to all of you readers, I was not required to install all of these roles at the same time; they are not all dependent on each other. It is very common to see these roles all installed onto the same server, but I could split them up onto their own servers if I so desired. In a larger environment, you may have AD DS and DNS installed together, but you might choose to put the DHCP role onto its own server, and that is just fine.I am configuring this server to support a small lab environment, so for me, it makes sense to put these core infrastructure services together in the same box, as shown in Figure 2.13:

Figure 2.13: Role selection

After clicking Next, we have now landed on the page where we can install additional features to Windows Server 2025. In some cases, you may have a need to install only a particular feature, not a role at all, and in these cases, you would have bypassed the Server Roles screen altogether and gone immediately to the Features installation screen. Similar to the role installation screen, go ahead and check off any features that you would like to install, and click on Next again. For our new domain controller, we do not currently require any additional features to be specifically added, so I will simply finish out the wizard, which starts the installation of our new roles.After the installation process has been completed, you may or may not be prompted to restart the server, depending on which roles or features you installed and whether they require a restart. Once you have landed back inside Server Manager, you will notice that you are now being prompted near the top with a yellow exclamation mark, as seen in Figure 2.14. Clicking here displays messages about further configurations that may be required in order to complete the setup of your new roles and finalize their use on the server.The roles for AD DS, DNS, and DHCP are now successfully installed, but there is some additional configuration that is required for those roles to do their work. For example, to finish turning my server into a domain controller, I need to run through a “promotion” process to define my domain or to specify an existing domain that I want to join. We will work through this together in Chapter 3. There are also some loose ends that I need to tie up before putting DHCP into action. Figure 2.14 shows these remaining tasks, with quick links that can be used to click into them and complete the role installation processes:

Figure 2.14: Post-deployment Configuration

Installing a feature using PowerShell

Now that you have seen the graphical wizards for installing roles and features, you could certainly always use them to put these components into place on your servers. But Microsoft has put much effort into creating a Windows Server environment where almost anything within the operating system can be manipulated using PowerShell, and the addition of roles and features is included in those capabilities. Let’s look at the appropriate commands we can use to manipulate roles and features on our server directly from a PowerShell prompt. We will view the available list of roles and features, and we will also issue a command to install a quick feature onto our server.Open an elevated prompt that is capable of running PowerShell, most easily accomplished via the Quick Admin tasks menu, accessed by right-clicking on the Start button and choosing to launch an Admin session of Terminal. Then use the following command to view all of the available roles and features that we can install onto our server. It will also show you which ones are currently installed:

Get-WindowsFeature

Figure 2.15: A list of all the roles and features available and installed

What I would like to do on this server is install the Telnet Client feature. I use Telnet Client regularly for testing network connections, so it is helpful to have it on this machine. Unfortunately, my Terminal window currently has pages and pages of different roles and features in it, and I’m not sure what the exact name of the Telnet Client feature is in order to install it. So, let’s run Get-WindowsFeature again, but this time let’s use some additional syntax in the command to pare down the amount of information being displayed. I want to see only the features that begin with the letters TEL, as shown in the following examples:

Get-WindowsFeature -Name TEL*

Figure 2.16: A list of features beginning with the letters TEL

There it is! Okay, so now that I know the correct name of the feature, let’s run the command to install it, as shown in the following example:

Add-WindowsFeature Telnet-Client

Figure 2.17: Installing Telnet Client via PowerShell

One last thing to show you here—there is also a way to manipulate the Get-WindowsFeature cmdlet to quickly show only the roles and features currently installed on a server. Typing Get-WindowsFeature | Where Installed presents us with a list of the currently installed components. If I run that on my domain controller, you can see all the parts and pieces of my roles for AD DS, DNS, and DHCP, as well as my newly installed Telnet Client feature, as shown in Figure 2.18:

Figure 2.18: A list of currently installed roles and features

Centralized management and monitoring

Whether you are installing new roles, running backups and maintenance programs, or troubleshooting and repairing a server, it is common sense that the first thing you would do is log directly into the server that you need to work on. Long ago, this meant walking up to the server and logging on with the keyboard and mouse that were plugged directly into that hardware. Then, quite a number of years ago, this became cumbersome and technology advanced to the point where we had the Remote Desktop Protocol (RDP) available to us. We quickly transitioned over to logging into our servers remotely using RDP. Even though it’s been around for many years, RDP is still an incredibly powerful and secure protocol, giving us the ability to quickly connect to servers from the comfort of our desks. And, as long as you have proper network topology and routing in place, you can work on a server halfway around the world just as quickly as one sitting in the cubicle next to you. In fact, I recently read that mining rights were being granted in outer space. Talk about a co-location for your data center! Maybe someday, we will use RDP to connect to servers in outer space. I bet Elon has some ideas about that. While there are many tools available for remotely managing your server infrastructure, RDP is the platform of choice for 99% of us out there.Why talk about RDP? Because you probably all use it daily, and I needed to let you know that Windows Server 2025 includes some tools that make it much less necessary to our day-to-day workflow. The idea of centralized management in the server world has grown through the last few Windows Server operating system rollouts. Most of us have so many servers running that checking in with them all daily would consume way too much time. We need some tools that we can utilize to make our management and monitoring, and even configuration processes, more efficient in order to free up time for more important projects.Follow along as we discuss the toolsets Microsoft has built natively into Windows Server 2025 to be able to manage and monitor servers from the comfort of your desk. You may notice the lack of Azure Arc in this section, which is by design as I plan to take a firsthand look into Azure Arc and join a server to it in a later section of this same chapter.

Server Manager

If you have worked on Windows Server recently, you are familiar with the idea that, upon logging into any of your servers, you are always presented with a large window opening on top of the desktop. This auto-launching program is Server Manager. As the name implies, it’s here to help you manage your server. However, in my experience, the majority of server administrators do not utilize Server Manager. Instead, they close it as fast as they can and curse it under their breath because it’s been popping up and annoying them during every server login for the past 10 years.Stop doing that! It’s here to help, I promise. Figure 2.19 shows the default view of Server Manager on my new domain controller:

Figure 2.19: Server Manager on my domain controller

What I like about this opening automatically is that it gives me a quick look into what is currently installed on the server. Looking at the column on the left side shows you the list of roles installed and available for management. Clicking on each of these roles brings you to some more particular configuration and options for the role itself. I often find myself hopping back and forth between many different servers while working on a project, and leaving Server Manager open gives me a quick way of double-checking that I am working on the correct server. The ROLES AND SERVER GROUPS section at the bottom is also very interesting. You might not be able to see the colors in the picture if you are reading a printed copy of this book, but this gives you a very quick view of whether or not the services running on this server are functioning properly. Right now, both my AD DS and DHCP functions are running normally, so I have a nice green bar running through them. But, if anything was amiss with either of these roles, it would be flagged bright red, and I could click on any of the links listed under those role headings in order to track down what the trouble is.Up near the top-right corner, you can see a few menus, the most useful of which, to me, is the Tools menu. Click on that, and you will see a list of all the available Administrative Tools to launch on this server. Yes, this is essentially the same Administrative Tools folder that long ago existed as an actual folder inside the Start menu, now stored more conveniently here inside Server Manager. Server Manager is possibly the easiest way to access this myriad of tools all from a single location:

Figure 2.20: The Tools menu in Server Manager

So far, the functions inside Server Manager that we have discussed are available on any installation of Windows Server 2025, whether it is standalone or part of a domain. Everything we have done only deals with the local server that we are logged in to. Now, let’s explore what options are available to us in Server Manager for the centralization of management across multiple servers. The new mentality of managing many servers from a single server is often referred to as managing from a single pane of glass. We will use Server Manager on one of our servers in the network to make connections to additional servers, and after doing that, we should have much more information inside Server Manager that we can use to keep tabs on all of those servers.Front and center inside the Server Manager console is the section entitled Welcome to Server Manager. Under that, we have a series of steps or links that can be clicked on. The first one lets you configure settings that are specific only to this local server. We already did some work with the second step when we added a new role to our server. Now we will test out the third step, Add other servers to manage.By the way, this same function can also be called by clicking on the Manage menu at the top and then choosing Add Servers, as shown in Figure 2.21:

Figure 2.21: Adding servers to Server Manager

Most of you will be working within a domain environment where the servers are all domain-joined, which makes this next part really easy. Simply click on the Find Now button, and the machines available within your network will be displayed. From here, you can choose the servers that you want to manage and move them over to the Selected column on the right, as shown in Figure 2.22:

Figure 2.22: Select the servers you want to manage

After clicking OK, you will see that Server Manager has transformed before your very eyes, to give you more information about all of these servers and the roles that are installed on them. Now when you log in to this single server, you immediately see critical maintenance information about all of the systems that you have chosen to add here. You could even use one dedicated server to handle the management of your whole arsenal of servers. For example, I am currently logged into a brand new server called CA1. I do not have any roles installed on this server, so, by default, Server Manager looks pretty basic. As soon as I add other servers (my domain controllers) to be managed, my Server Manager on the CA1 server now contains all of the details about CA1 and my domain controllers, so I can view all facets of my infrastructure from this single pane. As you can see in Figure 2.23, I even have flags here indicating that some services are not running properly within my infrastructure:

Figure 2.23: Remote management via Server Manager

Clicking on the All Servers link or into one of the specific roles gives you even more comprehensive information collected from these remote servers. Adding multiple servers into Server Manager is not only useful for monitoring but for future configurations as well. Do you remember a few pages ago when we added a new role using the wizard? That process has suddenly evolved on this particular server to become more comprehensive since we have now tapped this server into our other servers in the network.If I now choose to add a new role from inside Server Manager that is aware of multiple servers in the network, when I get to the screen asking me where I want to install that role, I see that I can choose to install a new role or feature onto one of my other servers, even though I am not working from the console of those servers, as shown in Figure 2.24:

Figure 2.24: Selecting a server for remote installation of a new role or feature

If I wanted to install the web server role onto WEB1, a new server that I am prepping to be a web server, I would not have to log into the WEB1 server. Right here, from Server Manager running on CA1, I could run through the Add Roles wizard, define WEB1 as the server that I want to manipulate, and install the role directly from here.

Remote Server Administration Tools (RSAT)

Using Server Manager on a single server to manage and monitor all of your servers is pretty handy, but what if we could take one more step out of that process? What if I told you that you didn’t have to log in to any of your servers, but could perform all of these tasks from the computer sitting on your desk?This is possible by installing a toolset from Microsoft called the Remote Server Administration Tools (RSAT). I have a regular Windows 11 client computer online and running in our network, also domain-joined. I am now going to add an optional feature to this Windows 11 computer to give it the RSAT toolset.Open Settings on the client computer and type the word optional into the search bar. One of the options presented will be Optional features. Go ahead and click that. Once inside Optional features, click the button to View features. This will open a list of many optional features to choose from, including a lot of language options, but if you scroll down in the list, you will eventually come to a number of different entries that start with RSAT:. (or you can simply search for RSAT) If there were only a select number of the tools that you wanted to use from this Windows 11 client, you could be selective here and only install the admin consoles that you actually needed, as you can see in Figure 2.25:

Figure 2.25: Installing RSAT features on Windows 11

RSAT tools are also available for Windows 10, if you are still running that on your workstation. However, if your version of Windows 10 is older than 1809, you won’t find these options on your Settings screen. Instead, you can download and install the whole RSAT package from the following link: https://www.microsoft.com/en-us/download/details.aspx?id=45520.After walking through the process to get these tools on my Windows 11 client computer, I can’t seem to find any program that is called Remote Server Administration Tool. That would be correct. Even though the names of these features we are installing all begin with RSAT, the components that are getting installed onto your system are the actual Windows Server system tools.If you peruse your Start menu, you will now find options for both Server Manager, just like on a server, along with a folder full of Windows Tools! This makes sense, except that if you don’t realize the name discrepancy, it can take you a few minutes to figure out why you cannot find what you just installed.So, go ahead and launch Server Manager by finding it in the Start menu, by using the search bar, or even by saying Hey, Cortana, open Server Manager. Sorry, I couldn’t resist. But whatever your method, open up Server Manager on your desktop computer, and you will see that it looks and feels just like Server Manager in Windows Server 2025. And, in the same way that you work with and manipulate it within the server operating system, you can take the same steps here in order to add your servers for remote management.In Figure 2.26, you can see that I have walked through the step to Add other servers to manage and selected some of the servers that are within my test network. I now have access, right here from my Windows 11 client computer, to manage and monitor all of the servers in my lab without even having to log in to them:

Figure 2.26: Centralized management via Server Manager

Does this mean RDP is dead?

With these new and improved ways to manage the underlying components of your servers without having to log in to them directly, does this mean that our age-old friend RDP is going away? Certainly not! We will still have the need to access our servers directly sometimes, even if we go all-in with using the newer management tools. And I expect that many administrators out there will continue using RDP and full desktop-based access for all management and monitoring of their servers simply because that is what they are more comfortable with, even if newer, more efficient ways now exist to accomplish the same tasks.

Remote Desktop Connection Manager

Since most of us do still utilize RDP occasionally (or often) when bouncing around between our servers, let’s take a quick look at a tool that can at least make this task more manageable and centralized. I won’t spend a lot of time looking over individual features or capabilities of this tool since it is a client-side tool and not something that is specific to Windows Server 2025. You can use this to handle RDP connections for any and all of your servers or even all of the client computers in your network. Remote Desktop Connection Manager is an incredibly useful platform for storing all of the different RDP connections that you make within your environment. You can save connections so that you don’t have to spend time trying to remember server names, sort servers into categories, and even store credentials so that you don’t have to type passwords when connecting to servers. Though a disclaimer should come with that one—your security folks may not be happy if you choose to employ the password-storing feature.Remote Desktop Connection Manager (RDCM) has led a tumultuous life. It was available as a direct download from Microsoft for years and through many versions, until a vulnerability identified in the software caused Microsoft to shut it down and stop offering it to us. Thankfully, the Sysinternals team at Microsoft grabbed it, fixed it up, and resurrected it for continued use.You can download RDCM from the following link: https://learn.microsoft.com/en-us/sysinternals/downloads/rdcman. Once downloaded and extracted, this tool is a standalone executable that can be run on almost any Windows operating system. The beauty of so many Sysinternals tools is that they are self-explanatory. To make use of RDCM all you need to do is launch it, create a new group (saved as an RDG file), and start adding servers to it.

Figure 2.27: The RDCM tool

After saving your server RDP connections into RDCM, this tool provides you with a centralized and fast way to RDP into any of the servers that you administer. No need to remember their names or IP addresses from this point forward!

Windows Admin Center (WAC)

Now forget everything I just told you about remote server management and focus on this instead. I’m kidding… sort of. All of the tools we have already discussed are still stable, relevant, and great ways to interact with and manage Windows Server. However, there are a couple of newer offerings from Microsoft that tackle the idea of centralized server management in a whole new way. The first of these is the Windows Admin Center.WAC is a server and client management platform that is designed to help you administer your machines in a more efficient manner. This is a browser-based tool, meaning that, once installed, you access WAC from a web browser, which is great. No need to install a management tool or application onto your workstation—simply sit down and tap into it with a URL.WAC can manage your servers (all the way back to Server 2008 R2) and your server clusters and even has some special functionality for managing hyper-converged infrastructure clusters. You have the ability to manage servers hosted on-premises as well as inside Azure, and you can even manage client machines in the Windows 10 and 11 flavors.What’s the cost of such an amazing, powerful tool? FREE!WAC even has support for third-party vendors creating extensions for the WAC interface, so this tool is going to continue growing. If you have followed along with the test lab configuration in the book so far, you will recognize the words “Windows Admin Center” from a pop-up window that displays itself every time that Server Manager is opened. Microsoft wants administrators to know about WAC so badly that they are reminding you that you should start using it every time you log into a Server 2025 box, as shown in Figure 2.28:

Figure 2.28: Even Server Manager recommends using WAC

Installing Windows Admin Center

Enough talk, let’s try it out! First, we need to choose a location to install the components of WAC. True, I did say that one of the benefits was that we didn’t need to install a client software component, but what I meant was that once WAC is implemented, then tapping into it is as easy as opening up a browser. That website needs to be installed and running somewhere, right? While you could throw the whole WAC system onto a Windows 10 client, let’s take the approach that will be more commonly utilized in the field and install it onto a server in our network. I have a system running called WEB3 that is not yet hosting any roles or websites; it’s just an empty server at this point. Sounds like a good place to install the WAC components, let’s work through that together.Download WAC here: https://aka.ms/WACDownload.Once downloaded, run the installer on the host machine. There are either a few simple decisions, or many technical decisions you need to make for this installer, depending on whether you choose Express setup or Custom setup. For the environment I am building, I am going to run through Express setup and accept the default port, certificate, and authentication settings. This will provide me with a website instance of Windows Admin Center that I can log into from any other system on my network, using a self-signed SSL certificate. In a production environment, you would want to install a real SSL certificate to be used by this website and better protect it, but my lab is not even connected to the internet so I am safe continuing forward, allowing the wizard to generate a self-signed certificate for this website.

Figure 2.29: Installing WAC

The rest of the options in Express setup are very self-explanatory. Click through them to finish installing Windows Admin Center, and once finished, you will now be hosting the WAC website on this server. For my installation, that new web address is https://WEB3.contoso.local.

Launching Windows Admin Center

Now for the fun part, try logging in! To tap into WAC, you simply open a supported browser from any machine in your network and browse to the WAC URL. Once again, mine is https://WEB3.contoso.local. Microsoft recommends using Edge, but it also works with Chrome. I am logged into my Windows 10 workstation and will simply open the Edge browser and try to hit my new site, as shown in Figure 2.30:

Figure 2.30: Opening a WAC URL in Microsoft Edge

As you can see, I am dealing with a certificate warning. This is to be expected because I am using a self-signed certificate, which, once again, is a bad idea. I only justify it because I’m running in a test lab. If you want to remove the certificate warning, make sure to skip ahead to Chapter 7, Certificates, where we will cover all the necessary information to make that possible. Since I am expecting this within my lab and am okay with the risk for our purposes today, I can click the Advanced button and then click the Continue to web3.contoso.local link to proceed. I am now presented with a login prompt:

Figure 2.31: Sign in to use WAC

Even though I am logged into a Windows 10 computer that is domain-joined, and I am logged in with domain credentials, the WAC website does not automatically try to inject those credentials for its own use but rather pauses to ask who you are. If I simply input my domain credentials here, I am now presented with the WAC interface, as shown in Figure 2.32:

Figure 2.32: WAC interface

Adding more servers to WAC

Logging in to WAC is great but not very useful until you add a bunch of machines that you want to manage. To do that, simply click the + Add button that is shown onscreen. You will be presented with choices to add a new server, a new PC, a Windows Server cluster, or even an Azure VM. Make your selection and input the required information. I don’t have any clusters in my test lab, not yet anyway, so I am going to add connections to the standard servers that I have been running in the environment. If I select the option to add a Windows Server, I can type out the individual server names, import a list of server names, or even select the option to Search Active Directory. I’ll go ahead and try that search function to test how well this works.I have already set up a number of different servers in my lab and joined them to my domain (we’ll talk more about domains in the next chapter)—but how do I make WAC search for them here? When I click Search Active Directory, I still get a field asking me to type in a server name, but there is a note about wildcards being allowed. Aha! If you simply type an asterisk (*) into the search field and click the Search button, WAC polls your domain and presents a full list of machines that can be added to the console:

Figure 2.33: Search using *

Now simply select the checkboxes next to each server that you would like to administer via Windows Admin Center and click the Add button. You can see in Figure 2.34 that WAC now contains information about all of the servers in my environment:

Figure 2.34: Servers successfully imported into WAC

Managing a server with WAC

Beginning the management of a server from within WAC is as simple as clicking on the server name. As you can see in Figure 2.35, I have selected my DC1 server, as it is currently the only machine with some real roles installed and running:

Figure 2.35: DC1 server information

From this interface, I can manage many different aspects of my DC1 server’s operating system. There are power control functions, and the ability to run backups on my server, and I can even view and install certificates from here! You can monitor the performance of the server, view its event logs, manipulate the local Windows Firewall, and launch a remote PowerShell connection to the server. The goal with WAC is for it to be your one-stop shop for remotely managing your servers, and I would say it is well on its way to accomplishing that goal.I don’t yet have any Server Core instances running in my lab but rest assured that WAC can be used to manage Server Core instances just as well as servers running Desktop Experience. This makes WAC even more potent and intriguing to server administrators. When we get to Chapter 11, Server Core, we’ll make sure to wrap back to this idea and in some way manipulate a Server Core instance through this WAC console.

Changes are easy as pie

Monitoring information about your servers from a single place like WAC is great and powerful, but the coolest part about WAC is that you have some serious capabilities to manipulate your servers as well, straight from this web interface.This is yet another place where you can add roles or features to your servers, create scheduled tasks, start or stop services, or even do things like edit the registry and add Windows Firewall rules. Let’s make a quick change to our DC1 server to prove this. All of my VMs are inside a test lab that is running within Hyper-V, and so interaction with my servers to this point has been directly from Hyper-V console sessions. It is basically like I am walking up to these servers and logging in to them from the console every single time I need to interact with them. At this point, RDP has never been enabled on DC1, but I wonder if there is a way to enable that easily right from inside WAC?Within the menus along the left side of WAC, you may notice one called Remote Desktop. This sounds like it might be our starting point, but this function is actually a tool for launching an RDP connection from WAC directly into the server. While this is also very cool, it’s not what we are trying to do at the moment. Instead, you’ll want to visit Settings up near the top-left, and inside Settings look for the submenu called Remote Desktop. This is our location to make changes to the way that Remote Desktop is configured on DC1. Immediately after clicking into this section of settings, you can see options for whether or not to allow remote desktop connections to this computer, and currently this is disabled. These are the same options that you would face if you were to log directly into the DC1 server and manipulate remote desktop connectivity settings. You can see in Figure 2.36 that I have now selected the option Allow remote connections to this computer—previously, this was not enabled:

Figure 2.36: Enabling Remote Desktop connectivity to DC1

Simply changing the setting here and clicking the Save button causes Window Admin Center to reach out to DC1 and enable this Remote Desktop setting, after which I can immediately connect to it using RDP from my Windows 11 computer. I never needed to log into DC1 to enable remote logins to DC1!

Figure 2.37: RDP is now enabled

Azure integrations

You’ll notice inside WAC that there are numerous tools related to Azure. If you have an Azure environment or are thinking about getting started with one, your on-premises WAC can be used to administer both on-premises servers as well as Azure servers. WAC can also be used to bind your on-premises environment together with your Azure environment through things like Azure File Sync and Azure Backup. These tools can be a powerful way of creating a hybrid cloud configuration, where you maintain servers in both environments, and can also be used to help ease a transition from a traditional datacenter into a cloud-only mentality.

Azure Arc

Another place you may have noticed the word “Azure”, even in some of our screenshots of Windows Admin Center, are references to Azure Arc that are showing up all over the place. As we already discussed a little bit in Chapter 1, Azure Arc is another centralized administration pane that can be used to manage Azure servers, of course, but also on-premise servers and infrastructure. Azure Arc is accessed through your company’s Azure Portal, and not all companies are yet tapped into Azure so you may or may not have access to look inside this toolset.While this book is not inherently about Azure technologies, a couple of great reasons you may want to enable Azure Arc in your environment and begin tying your servers into it are pay-as-you-go licensing and Hotpatching. We also discussed both of these in Chapter 1, but as a quick refresher, new instances of Windows Server 2025 can now be licensed based on usage, via pay-as-you-go licensing. This can remove your cap-ex costs associated with spinning up new servers, and instead plug those new servers into an Azure subscription for monthly payments of Windows Server licensing.Hotpatching is a game changer for server uptime, enabling monthly Windows patches to install themselves without rebooting. Then only once per quarter, Microsoft will release a “normal” patch sequence that will restart your server. Moving from monthly to quarterly restarts of servers will save time, headaches, and money. What is the requirement to be able to use and manipulate hotpatching settings on your new servers? Having them plugged into Azure Arc, of course!Let’s join one of my servers into Azure Arc so you can experience the current process of doing so. I say “current” process because this is still a little bit clunkier than what I expect Microsoft will land on in finality, but as I write these words, the process is essentially this:

Log into Azure Arc and define the new server to be joined.

Azure creates a PowerShell script, which you can then download.

Run the script on your server, and it is now tapped into Azure Arc.

The reason I think Microsoft will update this process is because every new instance of Windows Server 2025 now has a systray tool running by default called Azure Arc and right-clicking on that systray icon displays an option to Launch Azure Arc setup. Launching that wizard does indeed walk through some steps to check prerequisites, check network connectivity, and attempt to install the Azure Connected Machine agent onto the new server, but no matter how many times I tried or from how many different new servers, the wizard fails every time to download the components that it needs. So, my hope is that in the future this wizard is an even simpler way to connect servers into Azure Arc, on an ad-hoc basis.To be able to successfully pull a server into Azure Arc, your Azure environment must first meet and be prepped with some prerequisites, which can be found here: https://learn.microsoft.com/en-us/azure/azure-arc/servers/learn/quick-enable-hybrid-vm#prerequisites.

Add a server to Azure Arc

Log into your Azure portal (portal.azure.com) and search for Azure Arc. Once here, navigate to Azure Arc resources > Machines and click the button to Add/Create. This will present you with a handful of options about what type of addition you are trying to accomplish. The first option here is typically the place to go when wanting to add a single server into Azure Arc for testing, Add a single server. Under that category, you are going to click on Generate script.

Figure 2.38: Adding a server to Azure Arc

Creation of this installation script is quite straightforward, simply choose which Subscription, Resource group, and Region that this server will be joined to. At the bottom of the wizard, you will have to define your connectivity method. Unless you have special networking configured between your on-prem and Azure environments where you could select one of the more secure options, you most likely will go with Public endpoint here. This sounds a little scary, but it just means that your on-prem server will reach into Azure with its information using the internet. That traffic is still encrypted and secured, and sent over port 443.

Figure 2.39: How will your server connect to Azure Arc?

Next, you find options to Tag your server. This applies Azure Tags to this object that is about to be created inside Azure, for the same reasons that you would tag anything inside Azure. Following this quick screen, we are finally ready to Download and run script.

Figure 2.40: Download or copy this script, and run it on your server

The only thing left to do is copy or download that script, and run it! Launch PowerShell ISE on the server to be joined (be careful not to run the x86 version), run this script, and with most things in the Azure world you will want to then let this sit and bake for 10 minutes or so. Shortly, your on-premise server will now be listed inside the Azure Arc portal, ready for you to manage it from here!If you refer back to Figure 2.38, there is a secondary installation option for Azure Arc that doesn’t involve a script at all. By clicking the “Download installer” button under Add Windows Server with installer, you can add servers into Azure Arc through a more traditional method, instead of running a script.

Quick server rollouts with Sysprep

At the beginning of this chapter, we walked through the process of installing the Windows Server 2025 operating system onto your new server. Whether this was a physical piece of hardware or a virtual machine that we were working with, the installation process was essentially the same. Plugging in the DVD or USB stick, booting to it, and letting the installer run its course is an easy enough thing to do, but what if you need to build out ten new servers instead of just one? This process would soon start to get tedious, and it would seem like you were wasting a lot of time having to do the exact same thing over and over again. You would be correct—this does waste a lot of time, and there is an easier and faster way to roll out new servers as long as you are building them all from a relatively similar hardware platform. If you are building out your servers as virtual machines, which is so often the case these days, then this process works great and can save you quite a bit of time on new server builds.Now, before I go too far down this road of describing the Sysprep process, I will also note that there are more involved technologies available within the Windows infrastructure that allow automated operating system and server rollouts, which can make the new server rollout process even easier than what I am describing here. The problem with some of the automated technologies is that the infrastructure required to make them work properly is more advanced than many folks will have access to if they are just learning the ropes with Windows Server. In other words, having a fully automated server rollout mechanism isn’t very feasible for small environments or test labs, which is where a lot of us live while we are learning about these new technologies.So, anyway, we will not focus on an automated approach to server rollouts, but rather we will do a few minutes of extra work on our very first server, which then results in saving numerous minutes of setup work on every server that we build afterward. The core of this process is the Sysprep tool, which is baked into all versions of Windows, so you can take this same process on any current Windows machine, whether it be a client or a server.Sysprep is a tool that prepares your system for duplication. Its official name is the Microsoft System Preparation Tool, and to sum up what it does in one line, Sysprep allows you to create a master image of your server that you can reuse as many times as you want in order to roll out additional servers. A key benefit to using Sysprep is that you can put customized settings onto your master server and install things such as Windows Updates prior to Sysprep, and all of these settings and patches will then exist inside your master image.Using Sysprep saves you time by not having to walk through the operating system installation process, but it saves you even more time by not having to wait for Windows Update to roll all of the current patches down onto every new system that you create.Now, some of you might be wondering why Sysprep is even necessary. If you wanted to clone your master server, you could simply use a hard disk imaging tool, or if you were dealing with virtual machines, you could simply copy and paste the .VHDX file itself in order to make a copy of your new server, right? The answer is yes, but the big problem is that the new image or hard drive that you just created would be an exact replica of the original one. The hostname would be the same, and, more importantly, some core identification information inside Windows, such as the operating system’s Security Identifier (SID) number, would be exactly the same. If you were to power on both the original master server and a new server based on this exact replica, you would cause conflicts and collisions on the network as these two servers fought for their right to be the only server with that unique name and SID. This problem exacerbates itself in domain environments, where it is even more important that each system within your network has a unique SID/GUID—their identifier within Active Directory. If you create exact copies of servers and bring them both online, let’s just say neither one is going to be happy about it, which in turn will make you very unhappy about how your servers are behaving. If you do this inside a production environment, you can wreak havoc on your network. I know from personal experience what it looks like to help someone recover their domain after a domain controller’s hard drive was simply copied, pasted, and turned on as a second server. It’s the definition of a bad day.Sysprep fixes all of these inherent problems with the system duplication process by randomizing the unique identifiers in the operating system. To prepare ourselves to roll out many servers using a master image we create with Sysprep, here is a quick-reference summary of the steps we will take:

Install Windows Server 2025 onto a new server

Configure customizations and updates onto your new server

Run Sysprep to prepare and shut down your master server (make sure it does not re-start)

Create your master image of the drive (copy it)

Build new servers using copies of the master image

And now, let’s cover these steps in a little more detail.

Installing Windows Server 2025 onto a new server

First, just like you have already done, we need to prepare our first server by getting the Windows Server 2025 operating system installed. Refrain from installing any full roles onto the server because, depending on the role and its unique configuration, the Sysprep process that we run shortly could cause problems for individual role configurations. Install the operating system and make sure device drivers are all squared away, and you’re ready for the next step.

Configuring customizations and updates onto your new server

Next, you want to configure customizations and install operating system updates onto your new server. Each setting or installation that you can do now that is universal to your batch of servers will save you from having to take that step on new servers in the future. This portion may be slightly confusing because I just told you a minute ago not to install roles onto the master server. This is because a role installation makes numerous changes to the operating system and some of the roles that you can install lock themselves down to a particular hostname running on the system. If you were to do something like that to a master server, that role would more than likely break when brought up on a new server. Customizations that you can put into place on the master server are things such as plugging in files and folders that you might want on all of your servers, such as an Admin Tools folder or something like that. You could also start or stop services that you may or may not want running on each of your servers and change settings in the registry if that is part of your normal server prep or hardening process. Whatever changes or customizations you put into place, it’s not a bad idea to run a full slew of tests against the first new server that you build from this master image, just to make sure all of your changes made it through the Sysprep process.Now is also the time to let Windows Update install and to put any patches on this new server that you want to have installed on all of your new servers in the future. There is nothing more frustrating than installing a new operating system in five minutes, only to have to sit around and wait four hours for all the current updates and patches to be installed before you can use the new server. By including these updates and patches in the master image, you save all of that download and installation time for each new server that you spin up.

Continue to save yourself time and effort by creating a new master image every few months. This way, the newest patches are always included in your master image, and it continues to save you more and more time throughout the life of Windows Server 2025.

Running Sysprep to prepare and shut down your master server

Now that our master server is prepped how we want, it is time to run the Sysprep tool itself. To do that, open an administrative Terminal or Command Prompt and browse to C:\Windows\System32\Sysprep. Now you can make use of the Sysprep.exe utility inside that folder to launch Sysprep itself.As with many executables that you run from Command Prompt, there are a variety of optional switches that you can tag onto the end of your command to make it do specific tasks. From your Command Prompt window, if you simply run the sysprep.exe command, you will see a graphical interface for Sysprep, where you can choose between the available options, as shown in Figure 2.41:

Figure 2.41: Sysprep options

Since I always use the same set of options for Sysprep, I find it easier to simply include all of my optional switches right from the command-line input, therefore bypassing the graphical screen altogether. Here is some information on the different switches that are available to use with sysprep.exe:

/quiet: This tells Sysprep to run without status messages on the screen.

/generalize: This specifies that Sysprep is to remove all of the unique system information (SID) from the Windows installation, making the final image usable on multiple machines in your network because each new one spun up from the image will get a new, unique SID.

/audit: This restarts the machine into a special audit mode, where you have the option of adding additional drivers into Windows before the final image gets taken.

/oobe: This tells the machine to launch the mini-setup wizard when Windows next boots.

/reboot: This restarts when Sysprep is finished.

/shutdown: This shuts down the system (not a restart) when Sysprep is finished. This is an important one and is one that I typically use.

/quit: This closes Sysprep after it finishes.

/unattend: There is a special answerfile that you can create which, when specified, will be used in conjunction with the Sysprep process to further configure your new servers as they come online. For example, you can specify in this answerfile that a particular installer or batch file is to be launched upon the first Windows boot following Sysprep. This can be useful for any kind of cleanup task that you might want to perform, for example, if you had a batch file on your system that you used to flush out the log files following the first boot of new servers.

The two options that are most important for our purpose of wanting to create a master image file that we can use for quick server rollouts in the future are the /generalize switch and the /shutdown switch./generalize is very important because it replaces all of the unique identification information, the SID info, in the new copies of Windows that come online. This allows your new servers to co-exist on the network with your original server and with other new servers that you bring online. The /shutdown switch is also very important because we want this master server to become sysprepped and then immediately shut down so that we can create our master image from it.

Make sure that your server does NOT boot into Windows again until after you have created your master image or taken your master copy of the .VHDX file. The first time that Windows boots, it will inject the new SID information, and you want that only to happen on new servers that you have created based on your new image.

So, rather than simply throwing all of the switches at you and letting you decide, let’s take a look at the ones that I typically use. I will make use of /generalize so that I make my new servers unique, and I also like to use /oobe so that the mini-setup wizard launches during the first boot of Windows on any of my new systems. Then, I will, of course, also use /shutdown because I need this server to be offline immediately following Sysprep so that I can take a copy of the hard drive to be used as my master image. So, my fully groomed sysprep command is shown in the following code:

sysprep.exe /generalize /oobe /shutdown

After launching this command, you will see Sysprep moving through some processes within Windows, and after a couple of minutes, your server will shut itself down, as shown in Figure 2.42:

Figure 2.42: Sysprep and shutting down

You are now ready to create your master image from this hard disk.

Creating your master image of the drive

Our master server is now shut down, and we are ready to create our master image from this server. If it is a physical server, you can use any hard disk imaging utility to create an image file from the drive. An imaging utility like those from the company Acronis will create a single file from your drive. This file contains an image of the entire disk that you can use to restore onto fresh hard drives in new servers in the future. On the other hand, most of you are probably dealing with virtual servers most often in your day-to-day work lives, and prepping new servers in the virtual world is even easier.Once our master server has been sysprepped and shut down, you simply create a copy of the .VHDX file. Log in to your Hyper-V Server, copy and paste the hard disk file, and you’re done! This new file can be renamed WS2025_Master_withUpdates.VHDX, or whatever you would like it to be named, in order to help you keep track of the current status of this image file. Save this image file or copy of the .VHDX file somewhere safe on your network, where you will be able to quickly grab copies of it whenever you need to spin up a new Windows Server 2025. Remember, you do not want to boot this actual .VHDX file, as that would then remove it’s sysprep-ed-ness (yes, I realize that is not a real word). Instead, never boot this master image but instead create copies of it whenever building out new servers.

Building new servers using copies of the master image

Now we get to the easy part. When you want to create new servers in the future, you simply copy and paste your master file into a new location for the new server, rename the drive file to something appropriate for the server you are creating, and boot your new virtual machine from it. Here is where you see the real benefit from the time that Sysprep saves, as you can now spin up many new servers all at the same time by doing a quick copy and paste of the master image file and booting all of your new servers from these new files. No need to install Windows or pull out that dusty installation DVD!As the new servers turn on for the first time and boot into Windows, they will run through the out-of-box experience, mini-setup wizard. Also, in the background, the operating system gives itself a new random and unique hostname and SID information so that you can be sure you do not have conflicts on your network with these new servers.New servers created from a sysprepped image file always receive a new hostname when they boot. This often confuses admins who might have named their master server something such as MASTER. After booting your new servers, you can expect to see randomized names on your new servers, and you will have to rename them according to their new duties in life.For example, before running Sysprep and creating my master image, the server that I was working on was named DC2 because I had originally intended to use it as a domain controller in my network. However, because I had not installed the role or configured anything domain-related on it, this server was a perfect candidate for displaying the Sysprep process, and so I used it in our text today. I sysprepped it, shut it down, made a copy of its .VHDX file (to be my master image file), and then I started DC2 back up. You can now see inside the system properties that I am back to having a randomized hostname, and so if I still want to use this server as DC2, I will have to rename it again now that it has finished booting through the mini setup, as shown in Figure 2.43:

Figure 2.43: Randomized hostname following Sysprep

Hopefully this process is helpful information that can save you time when building new servers in your own environments. Get out there and give it a try the next time you have a new server to build! You can further benefit from the Sysprep tool by keeping many different master image files. Perhaps you have a handful of different kinds of servers that you prep regularly—there is nothing stopping you from creating several different master servers and creating multiple master images from these servers.

In-place upgrading to Windows Server 2025

Before wrapping up this chapter, let’s enter into this taboo topic. As technology consumers, we are very much used to the idea of in-place upgrades. In fact, we expect them to work flawlessly, and we whine and complain when they don’t. iPhone operating systems, Android version updates, Windows feature pack installations, and even something like a Windows 7 to Windows 10 upgrade are all expected to work seamlessly after a couple of simple pushes of a button. Those of us who have worked in Windows Server administration for more than a few years do NOT have this same mindset about server upgrades. For so many years, it was normal that in-place Windows Server upgrades were almost guaranteed to tank your server, causing it to be useless in the end. Due to this, server upgrades almost always meant replacing the server rather than upgrading it. You would leave the production server running, spin up a new one in parallel, configure all of the roles and specs needed on that server, then plan an after-hours migration of data and apps to the new server so that the next morning, hopefully, everything was up and working on the new server. Then, you shut the old server down. This is normal; this is Windows Server upgrades; this is the life of a Sys Admin.Things have changed…Starting with in-place upgrades from Server 2012R2 to Server 2016, it was suddenly possible to be successful with an in-place Windows Server upgrade. Not all the time, but sometimes. Since it was still sporadic, it was not commonly attempted, and we continued to stick to old methods of replacing servers. Then, Server 2019 came out, and in-place upgrades from 2016 to 2019 were actually quite stable, and you could even get away with upgrading 2012R2 straight to 2019, but again this only worked some of the time. Windows Server 2022 and 2025 continue that trend of improvement. Windows Server operating system in-place upgrades are stable and introduce us to a much more efficient way to upgrade servers than the old rip-and-replace methods. Let’s take a minute and prove this. On my Hyper-V host, where I run test labs, I have numerous Server 2025 VMs, but I still have many Server 2022 and even 2019 VMs sitting offline from previous projects.I just finished joining one of those to my new lab network, and I will now attempt an in-place upgrade from Server 2019 directly to Server 2025.Before we get into this, let’s expand the idea of multi-version jumps. With the introduction of Windows Server 2025, Microsoft now supports what is sometimes known as N-4 updates. In other words, the ability to jump FOUR full Windows Server versions, all at once. In other, other words, this means that Microsoft supports in-place upgrades directly from Windows Server 2012R2 up to Windows Server 2025. This is quite amazing when you think about it. At this point nobody in the world should be running Server 2012R2, but don’t try to hide it from me. I know you still do.

Download and run the installer

Running the installer is pretty much all you need to do. We already downloaded the .ISO installer file earlier in this chapter, in the section Installing Windows Server 2025. Copy this file to the older Server 2019, and double-click on the file to mount it. If you’re using a virtual machine, all you need to do is visit the VM’s settings and attach the .ISO to the VM, and it now appears as if the Server 2025 installation DVD is connected to this server. Double-click on that virtual disc and the Windows Server 2025 installation wizard will launch.

Figure 2.44: Starting an in-place upgrade to Windows Server 2025

The upgrade wizards are essentially the same as when we accomplished a fresh Windows Server 2025 install earlier in this chapter. Walk through those wizards, choosing your licensing options and which version of Server 2025 you want to put into place, and you’ll be on your way to an upgraded server! One extra decision for the upgrade versus installing fresh is that you get to decide whether you want to Keep files, settings, and apps or not. I don’t know why you would ever want to ditch your settings and apps when upgrading a production server to a new OS, but the option exists regardless.

Figure 2.45: In-place upgrade from 2019 to 2025

That’s it! Once those options have been decided upon, the installation process kicks off, and after a little bit of time and a few automated restarts of the server, you should find yourself back at a login screen of the same server with the same roles and files present, but now running the Windows Server 2025 operating system.

Upgrading from Settings

Wait a minute, there is one more option for in-place upgrade methodology! You may have already noticed this option on some of your existing servers and wondered what in the world was going on. It is normal to expect a Windows 11 upgrade button when visiting the Windows Update settings inside a Windows 10 computer, but to have the same OS upgrade method available in the server world is kind of mind blowing. Microsoft has now introduced the ability for the internal Windows Update engine to be able to self-upgrade Windows Server 2022 to Windows Server 2025.While not yet existing on all servers out in the wild, visiting Settings > Windows Update may provide you with a new option to launch the Windows Server 2025 upgrade process right from here, without needing to first acquire installation media, as shown in Figure 2.46:

Figure 2.46: In-place 2025 upgrade from Windows Settings???

Two special notes about this new capability. First, Microsoft says they will never allow the Server 2025 upgrade process to run all on its own. This new option is currently creating some fear among sys admins that they may have servers self-update and cause issues. Again, per Microsoft’s own words, they will always wait for you to click this button and choose to upgrade.Second, if you are in-place upgrading multiple versions, such as N-4 bringing a server from 2012R2 to 2025 directly, this will always require using the Windows Server 2025 installation media and running the installer manually.

Summary

Anyone interested in being a Windows Server administrator needs to be comfortable with installing and managing servers, and covering those topics establishes an important baseline for moving forward. It is quite common in today’s IT world for new operating system releases to be thoroughly tested by companies before deploying them, both because server hardware resources are so easily available to us through virtualization technologies and because most business systems are now being designed for 100% uptime. This kind of reliability requires very thorough testing of any platform changes, and to accomplish such testing of the Windows Server 2025 operating system in your environment, you will burn quite a bit of time spinning through the basic installation processes numerous times. I hope that you can put the suggestions provided in this chapter to good use in saving you precious extra minutes when dealing with these tasks in your Windows Server world.Years ago, quite a bit of effort was regularly put into figuring out which roles and services could co-exist because the number of servers available to us was limited. With the virtualization and cloud paradigm shift, many companies have a virtually unlimited number of servers that can be running, and this means we are running much larger quantities of servers to perform the same jobs and functions. The management and administration of these servers then become an IT burden, and adopting the centralized administration tools and ideas available within Windows Server 2025 will also save you considerable time and effort in your daily workload. In the next chapter, we will start to dive into some of the most commonly used roles and tools in a Windows Server environment and the core infrastructure technologies surrounding Active Directory.

Questions

What is the name of the web-based, centralized server management tool from Microsoft (fun fact, this toolset was originally known as Project Honolulu)?

True or false—Windows Server 2025 needs to be installed onto rack-mount server hardware.

True or false—By choosing the default installation option for Windows Server 2025, you will end up with a user interface that looks quite like Windows 11.

What is the PowerShell cmdlet that displays currently installed roles and features in Windows Server 2025?

True or false—Server Manager can be used to manage many different servers at the same time.

What is the name of the toolset that can be installed onto a Windows 11 computer in order to run Server Manager on that client workstation?

Which built-in tool is used to prepare the Windows operating systems for imaging or replication?

What is the oldest version of Windows Server that can be in-place upgraded to Windows Server 2025?

3 Active Directory

Join our book community on Discord

https://packt.link/zYovfWorking on computers and working in IT can be two very different things. Throughout my career, I have interviewed hundreds of people seeking to land an IT role. When talking to any engineer who already has some experience working within a corporate IT environment, the topic of Active Directory is old hat. They are familiar with what it is, what it does, and with at least some of the toolsets provided to manipulate it. Hiring for entry level engineering positions takes an entirely different twist, as these interviews often include people who have worked with computers for years, and are very  good at it, but who literally have no idea what Active Directory is or does. If your experience with computers is building them, repairing them, and working within the operating system, you probably have had zero reasons to understand this technology called Active Directory, even though it is the one central thing that underpins almost every corporate network across the globe.Each of you reading this book will have a different acquired skillset and level of experience with the Windows Server environment. As I mentioned previously, building a server and working through installation of the operating system is great progress, and a very important first step for doing real work in your environment. But until you know and understand the purposes behind the main roles available in Windows Server 2025, the only thing your new server does is consume electricity.A server is intended to serve data. The kind of data that it serves and to what purpose depends entirely on what roles you determine the server must ... well ... serve. Appropriately, you must install roles within Windows Server 2025 to make it do something. We already know how to get roles installed onto our server but have not talked about any of the purposes behind these roles. Over the next few chapters, we will start looking into what I commonly refer to as the core infrastructural roles available within Windows Server. This involves discussing the role’s general purpose, as well as working through specific tasks that pertain to those roles. These are the things you will be responsible for doing in your daily tasks as a server administrator.We begin with the single most important role in all of the on-premise Microsoft world, Active Directory (AD). AD, as it is commonly referred to, is a directory service that serves as a kind of database, storing and centralizing various types of information about your organization. User accounts, computer accounts, certificates, policies, DNS, and even file replication are all things that you can find hooked into AD.As we look over the parts and pieces of AD, it will become clearer what information is stored within and why it is so important. If you are new to IT and do not yet have a good grasp of AD, make sure to learn this technology! AD is the hinge upon which almost everything in a Windows Server world revolves. Is it possible to utilize Windows servers without them being connected and joined to Active Directory? Yes. Is it likely you will ever find this scenario at play in the real world? No.During many Windows Server operating system releases, the number of new or improved features inside Active Directory is low. Windows Server 2025 bulks that trend, and we have already mentioned the Active Directory improvements in Chapter 1. If you glazed over that section because you were, at the time, unfamiliar with AD’s purpose and thought it didn’t pertain to you, you are welcome to re-read those updates. Ultimately, while many protocols and security features used by Active Directory were improved for this 2025 release, these changes are largely “under the hood”. In other words, we don’t have a bunch of new buttons and screens to interact with due to these changes, but everything that you do inside Active Directory is enhanced simply by using Windows Server 2025 to run it, as opposed to any older version of the Windows Server operating system. In this chapter, we will learn the following:

What is a domain controller?

Creating your first domain

Multiple domain controllers for redundancy

Active Directory Users and Computers

Active Directory Domains and Trusts

Active Directory Sites and Services

Active Directory Administrative Center

Read-only domain controllers

FSMO Roles

Demoting an old domain controller

Intro to Group Policy

Microsoft Entra ID

Let’s get started!

What is a domain controller?

If we are going to discuss the core infrastructure services that you need to piece together your Microsoft-driven network, there is no better place to start than with the domain controller. A Domain  Controller, commonly referred to as a DC, is simply a server that hosts Active Directory. It is a central point of contact, a central “hub” so to speak, that is accessed prior to almost any communication that takes place between a client and server in your network. Perhaps the easiest way to describe it is as a storage container for all identification that happens on the network. Usernames, passwords, computer accounts, groups of computers, servers, groups and collections of servers, security policies, file replication services, and many more things are stored within and managed by DCs. If you are not planning to have a DC be one of the first servers in your Microsoft-centric network, you might as well not even start building that network. DCs are essential to the way that our computers and devices communicate with each other and with the server infrastructure inside our companies.

Active Directory Domain Services

If you’ve stopped reading at this point to go install the Domain Controller role onto your server, welcome back! There is no role called Domain Controller. The role that provides all these capabilities is called Active Directory Domain Services, or AD DS. This is the role that you need to install on a server. By installing that role, you will have turned your server into a domain controller. The purpose of running a DC, really, is to create a directory, or database, of objects in your network. This database is known as Active Directory, and is a platform inside which you build a hierarchical structure to store objects, such as usernames, passwords, and computer accounts. You might be thinking, “didn’t we just say these same words in a slightly different way?” and you’re not wrong. AD is important, and I want to make sure you understand it. A career in IT guarantees that you will in some way interface with AD in your work.Most of the time when you hear anyone talking about “Active Directory” it is likely that what they really mean is a single domain within the directory. There is a whole hierarchy within an Active Directory schema, comprising forests, trees, domains, and organizational units. We will discuss each of these organizational levels of Active Directory as we navigate through the tools that you will be utilizing to interact with AD further along in this chapter.Once you have created a domain in which you can store accounts, objects, and devices, you can then create user accounts and passwords for your employees to utilize for authentication. You can then also join your other servers and computers to this domain so that they can accept and benefit from those user credentials. Creating and joining a domain is the secret sauce that allows you to walk from computer to computer within your company and log on to each of them with your own username and password, even when you have never logged in to that computer before. Even more powerful is the fact that it enables directory-capable applications to authenticate directly against Active Directory when they need authentication information. For example, when I, as a domain user, log in to my computer at work with my username and password, the Windows operating system running on my computer reaches out to a domain controller server and verifies that my password is correct.Once it confirms that I really am who I say I am, AD issues an authentication token back to my computer and I can log into Windows. Then, once I am on my desktop I am able to launch applications. For example, I might open File Explorer and navigate to one of my drive letters to open a document that is housed on my file server. The file server is only going to allow certain people or groups to have access to this file, how does the file server understand who I am? How does it ascertain my user identity? Did I need to re-enter my username and password to be able to open this file? No. And the reason I do no not have to re-authenticate myself over and over again as I open more applications is that these servers are all part of the same domain, and have the same universal understanding of that authentication token Active Directory gave me during login. My user account and these machines I am interacting with are all part of the same domain.When this is true, and it is for most business networks, my authentication token can be shared among many programs. So, once I log in to the computer itself, my applications can launch and open, and pass my credentials through to the application server, without any further input from me as a user. It would be quite a frustrating experience indeed if we required our users to enter passwords all day, every day as they opened the programs that they need in order to do their work.Active Directory itself is a broad enough topic to warrant its own book, and indeed there have been many written on the topic. Now that we have a basic understanding of what it is and why it’s critical to have in our Windows Server environment, let’s get our hands dirty using some of the tools that get installed onto your domain controller during the AD DS role installation process.

Creating your first domain

I must admit that I have cheated a little bit and have already been working from within a domain for the purpose of taking screenshots for the book up to this point. My test lab already has a DC1 server up and running, and on it I have configured a domain called contoso.local. However, saying “domains are important” and not showing you how to create one would not be helpful to you, the reader, and so we are going to build a brand-new domain now, on a brand-new server.You probably recognize “Contoso” if you’ve ever read over Microsoft tutorials or example configuration documentation, because it is one of several fake business names Microsoft uses often in documentation or for the purpose of showing example scenarios. I am using it here as well, but you could name your domain anything you want to. For setting up our second domain, I am going to pull another company name from the Microsoft hat, Fabrikam.One of the first things that needs to be decided before you can build a domain is the name of the domain. We don’t want to discuss DNS in depth here because there’s another whole chapter for that, but everyone uses DNS every day whether they realize it or not. Every time that you type any website name – microsoft.com, google.com, bing.com, and so on – you are inputting a name, which DNS is then going to turn into an IP address. You also know that the ending of website names can take on many forms. Most common is .com, but you may visit websites that also end with .org, .biz, .info, .tech, .edu, .mil, and many more.Let’s take microsoft.com as an example. If you simply visit microsoft.com, you’ll see the main website for the company. If you visit learn.microsoft.com, you will land on their documentation and learning platform page. Visiting portal.microsoft.com takes you to an Microsoft 365 sign-in page, and if you have an Microsoft 365 account you can sign in here and perform many functions. The different addresses you are typing into the web browser are taking you to vastly different web pages and systems, yet the domain names being called for in the browser all end with the same microsoft.com. This means that microsoft.com is the primary domain name for all of these things, also known as a domain suffix or a top-level domain.Why am I running down this rabbit hole? Because this is important information to understand when you decide on your internal domain name. Just like a domain suffix on the internet, when you build your internal domain and then later join computers and servers to that domain, each of those devices is going to have a true, full name of computername.domainname.something. In my current domain, contoso.local, a full server name that exists right now is DC1.contoso.local.Most internal domains that I have encountered in the world end with .local. Is it possible to name your internal domain something that ends in one of these internet-based suffixes, like Contoso.com? Yes! You can name your internal domain whatever you want, and in fact if you have plans to host email in Office 365, using an internal domain that matches your public domain name used for email carries some advantages. Some of you may be thinking at this point, “I already own contoso.com (insert your own business website name here), so wouldn’t it be less confusing overall if I also name my internal domain the same thing? contoso.com?” The answer is yes and no. For certain scenarios that involve cloud resources, like Office 365 and Azure, yes, using a .com internal domain can make a more seamless transition to the cloud. However, prior to these cloud technologies it was always Microsoft’s recommendation to end your internal domain with .local. We will talk more about why this is the case in Chapter 4, DNS and DHCP, when we discuss something called split-brain DNS.

Prep your domain controller

Okay, I have decided to use fabrikam.local as my internal domain name. Now, how do I make that a reality? We only need one server to build a domain, the server that you want to be your domain controller. I have a new Windows Server 2025 VM running and plugged into a network, but so far I have not configured anything at all on the server. There are three simple things that need to happen on any server that you plan to turn into a domain controller:

Set a static IP address – Head into your NIC properties and define a static IP address for this server. Even if you already have a DHCP server running in your network to hand out IP addresses, you do not want domain controller servers to ever change IPs. It is possible to do so, but quite challenging. So best practice dictates that whatever IP address you define for your DC, plan on that being its IP address forever.

Set a good hostname – Similar to IP addressing on a domain controller, it is not recommended to ever change the name of a DC server. In fact, this is quite a bit more complicated than IP addressing, and you should definitely plan that whatever name you give your server today will forever be its name on your network until the day you decommission this server entirely.

Set the DNS server address – Head back into your NIC properties and configure the DNS server address that your domain controller is looking for, to be itself. What? Itself? It’s not a DNS server! Not yet, but other than rare circumstances, almost every domain controller will also become a DNS server. DNS integrates with Active Directory and there is a lot of benefit to hosting these services together, so most Microsoft environments you encounter will have AD DS and DNS installed together on domain controller servers. Generally, when setting up your first DC, you will always start by pointing the NIC’s DNS settings to the server’s own IP address.

You can see in Figure 3.1 that I have now named my new server FAB-DC1, configured a static IP, and pointed DNS to itself:

Figure 3.1: Prepping a server to become a DC

Install the AD DS role

Now that the server is prepped to be a domain controller, we install the role! Since you are already familiar with the process of adding roles to servers, we won’t step through the whole thing again. Simply utilize Server Manager or PowerShell to install the following components onto your new server:

Figure 3.2: Installing AD DS and DNS Server roles

As mentioned, I am going to install AD DS for Active Directory, and DNS Server so that this domain controller can also serve as a true DNS server for our new business. As you progress through the role installation wizard, you will encounter some informational text that is useful to read over, but there should be no further options that you need to select in order to get both of these roles installed onto your server.

Configure the domain

Following the installation of the roles, you will notice a yellow exclamation mark near the top of Server Manager. Clicking on that icon, you can see text indicating that some configuration is required for the Active Directory Domain Services role:

Figure 3.3: Additional configuration is required for the Active Directory Domain Services role

Click on the link that says Promote this server to a domain controller. This link will invoke the configuration wizard that is going to walk us through turning the server into a true DC.

Trees, forests, and…domains?

Wait a minute, the first screen we encounter in this promotion wizard where we need to make a decision is talking about shrubbery. I enjoy gardening, but what in the world are we talking about here?? You already know that a domain is like a database, containing information about many kinds of objects, but primarily user accounts and computer accounts that are part of that domain. What we have not really discussed yet is that a domain is not the top tier of its existence, rather a domain resides within a forest. These are the two technical terms you will run across when working within Active Directory, domain and forest, and references to a tree are more metaphorical, related to the layout of a forest with domains underneath the forest, with possible child domains listed beneath the domains. The whole schema when mapped out on paper may resemble the many branches of a tree, thus the term tree.A forest is the top tier in Active Directory, and you could potentially have many different domains inside the same forest. Why would you want to do that? Most companies don’t, and most of the time you will find that any given company has exactly one internal domain, residing within one forest, and that’s it.One reason you may find multiple domains inside the same forest would be if the company had different divisions or business units that needed their authentication and systems to be separated from each other. In a single domain, remember that oftentimes any domain user can authenticate and log in to any domain computer, and perhaps you wanted to ensure that nobody in DivisionA was able to log in to computers that were owned by DivisionB. Creating multiple domains would be one way to accomplish that scenario.As you walk through the domain configuration wizard that we have just launched on our new server, you will see many different options for what kind of domain controller this server may become. You may be adding a DC to an existing domain, adding a new domain to an existing forest, or creating a new forest altogether. Selecting each of these options in the wizard will present you with different sub-options related to that selection. If you click on Add a new domain to an existing forest, you will find that you then have options for creating a new child domain, or a tree domain. A child domain would be a new domain that exists under an existing domain in the hierarchical AD tree, while a tree domain would be a new domain that resides directly under the forest itself and would sit alongside any existing domains. Still under the same forest but separated from any existing domains.Today, we have nothing in this Fabrikam network. No forest, no domains, no child domains. So we are going to choose the third option, Add a new forest. All that needs to be decided on this screen is the Root domain name, which is where I will enter fabrikam.local, which we decided on earlier:

Figure 3.4: Creating a new forest

The remaining screens in this configuration wizard contain a number of options, but not many of them need to be populated if you are unsure of the answers. Especially if you are building out a test lab, the default options are generally sufficient. We’ll do a quick summary here of each screen to point out options and what they mean.

Domain controller options

Now that you understand that there are at least two tiers to every Active Directory, at minimum one forest and one domain, it is important to understand that each of those things has its own functional level. Forest and domain functional levels are classified by different versions of Windows Server operating system releases. Windows Server 2016 functional level has more features and accessories baked into it than Server 2012 R2 does, for example, and on and on. Something interesting to note is that Windows Server 2019 and 2022 did not introduce their own functional levels, which was a strange thing in the world of Windows Server releases. As you work through this wizard, you’ll discover a large gap in the list of available levels. Windows Server 2025 is the default, of course, but the next newest option in the drop-down list lands on Windows Server 2016.Why does the wizard even ask? Wouldn’t it make sense that you would always want to select the newest from this list? In almost all cases, the answer is yes. One reason you may need to select an older functional level for either your forest or domain is if some technology you are planning to implement or some version of device you plan to join to that domain requires an older functional level version. This brings to light another valid scenario that might require a company to build a secondary domain under an existing forest, if a technology that you wanted to implement for the business carried some specific requirements that locked you into a certain version of functional level, but your primary production domain could not meet those requirements for whatever reason.For our purposes today, we simply leave both forest and domain functional levels selected on the default Windows Server 2025.On this screen of the wizard, you also have options to choose whether or not this domain controller will also be a DNS server (usually yes), whether it will be a Global Catalog server (also usually yes), or a Read-only domain controller, which we will discuss later in this chapter.The third option, and the only one that absolutely requires your attention, is to define a Directory Services Restore Mode password. I sincerely hope that you never have to enter Active Directory recovery mode in order to restore information or your directory, but if you do – this password is going to be very important to that process:

Figure 3.5: Domain Controller Options

DNS Options

If you were creating a new Domain Controller/DNS Server that was going to live inside an existing tree and particularly if your new server is going to play a child role, then you typically want to ensure that the parent’s DNS zones have a delegation for this new DNS server you are creating, to ensure that names in your domain can be successfully resolved in the parent domain as well. The creation of that DNS delegation is the only option on this screen, and in cases where we are creating a brand-new forest and domain, there is no existing authoritative parent zone so there is an expected warning message on-screen:

Figure 3.6: Expected warning message regarding no authoritative parent zone

Since we are building a new forest, there is nothing we need to do with this warning message and we simply click Next to proceed.

Additional Options

The NetBIOS domain name should self-populate in the wizard and will be the first portion of your domain name. In my example, it has inserted the word FABRIKAM into this field. Many people seem to think that NetBIOS is obsolete, but it is still used by applications to pass traffic around in some cases, so the options for configuring it here are still important. You don’t need to do anything on this screen other than to ensure a NetBIOS name populates in the wizard and continue on.

Paths

Active Directory stores quite a bit of very important information on your domain controller server. If desired, here you can specify paths for storing this data if you wanted it to reside in a special location, such as on a dedicated hard drive. The default options are all within the C:\Windows folder, which is generally where everyone leaves it.

Review Options, Prerequisites Check, Installation

That’s it! You have now populated all the available options, and you are presented with a screen that allows you to review the selections you have made. Once satisfied that everything looks good on this screen, the wizard will run through a prerequisites check on your server to ensure it is ready to become a domain controller. This is the point where, if you forgot to assign a static IP or to set a DNS server in the NIC properties, the wizard will fail the prereq check and flag you with some warnings. In fact, you will likely see at least one or two warnings even if you have done everything perfectly: one regarding that DNS delegation that we already talked about and another warning about cryptography algorithms. This is normal behavior for configuring a brand new forest/domain on Windows Server 2025.Assuming you have everything in order, the wizard will continue on to installation, at the end of which your server will reboot, and is now officially a domain controller for your network.During the first login to your server, which is now a domain controller, you will notice at the login screen that you are now signing in with a domain account, no longer a local account on this server. Domain controllers don’t actually have local user accounts anymore; if you were using the built-in administrator account to sign in to your server before, like I was, that account and password have now been converted into the domain administrator account. This account can now be used to log in to any computer or server that is later joined to your domain and will automatically receive administrative rights on that device. Make sure you’re using a good domain administrator password, and don’t share it with anybody! To further strengthen security around these ultra-important passwords, consider storing them inside a trackable password vault. There are various available, but using a password vault enables you to store your passwords in a secure location, accessible only to those who actually need them (your IT staff), and will allow you to track and audit which of your employees has accessed these passwords.

Multiple domain controllers for redundancy

Now having configured our first domain controller, we should jump in and start setting up objects inside Active Directory, right? Not yet! I’m being a little dramatic here, of course you can jump ahead and start using the tools that interface with AD, which we will discuss immediately following this section of our chapter. There are many businesses that have run or are still running a single domain controller successfully, without ever considering redundancy for this critically important role in your environment. If you think I’m being dense, and that nobody in their right minds would ever run a production server environment today with a single DC, I’ll have you know that I literally encountered such an environment only yesterday. What was the issue that I was tasked with investigating? Wouldn’t you know it, a problem on the domain controller…Is it possible to run a business with one DC? Yes, until something happens to it. Those of us on the side of common sense understand that this scenario is literally begging for disaster. Whenever setting up a real environment and not just monkeying around in a test lab, it is going to be super critical that you establish redundancy for your domain.Adding a second domain controller is even easier than spinning up the first one. Simply take the same steps that you did last time, with one exception to the way that the NIC is configured:

Spin up a new server.

Set a static IP.

Configure a good permanent hostname.

Deviation from before: Instead of configuring your NIC’s DNS server settings to point at the new server itself, point your primary DNS to the existing domain controller’s IP address.

Now when you add the AD DS and DNS server roles and walk through the same configuration wizard that we just witnessed a few minutes ago, this time you are going to choose the option Add a domain controller to an existing domain. Then all you have to do is select or type the name of the domain and provide administrative credentials on that domain:

Figure 3.7: Adding a new DC to an existing domain

The rest of the wizard is pretty straightforward, but you’ll notice that you have a new drop-down menu on the Domain Controller Options screen that allows you to select a site name. If you had multiple AD sites, you would select here which site this new DC is being installed into. We will discuss more about Active Directory Sites and Services in a later section of this chapter. You will also notice that you have to once again create a password for Directory Services Restore Mode. This password is configured per domain controller, so it could potentially be different for each of your DC servers.If you remember everything we have done so far, you will realize that right now both of our domain controller servers are pointing to FAB-DC1 as their primary DNS server, as defined inside the NIC properties. As long as each DC can contact a DNS server, your domain is going to function properly, but now that we have two DCs (which are also DNS servers) created for the purpose of redundancy, your overall solution will be made even better if you ensure that both domain controllers are aware of each other from a DNS perspective.There are two different ways to go about this, both are considered to be good practice:

Configure each domain controller to have a primary DNS server address of itself, and the secondary DNS server address to be the other DC. This causes DNS lookups on those servers to happen slightly faster but has the potential drawback that you might have to wait on Active Directory replication to happen between the two servers before newly created DNS records are available on both servers.

Configure both (or all) of your domain controllers to use a single DNS server as the primary DNS server on your network, with themselves as the secondary DNS server. If all of your DCs are looking to a centralized DNS server, then any updates or additions you make to that DNS server are immediately available on all DCs. However, if that central DNS server goes offline, it will cause all other DCs some grief and delays as they take a second to realize that they now need to fail over to themselves for name resolution.

Whoops, I said there were two ways to do this, and generally you’ll find that either option #1 or option #2 above are the way that DNS is configured in most environments. But there is a third possibility here that is sort of a mix between the two. You could configure each domain controller’s NIC settings so that the primary DNS server is any different DNS server in your environment and then make the secondary DNS server point back at itself. This causes DNS lookups to always happen across the network, which generates more traffic than the other options but also ensures that each DC can stand on its own accord if the other one fails. In this third scenario, if there were two DCs in the network, you are basically just pointing them at each other, while using themselves as a backup.I can’t tell you what is best for your own environment, but what I do most of the time is configure each DC to declare itself as the primary DNS server, and just remember that whenever I create new DNS records it might take a few minutes for them to replicate between the DCs. One additional advantage to going with Option #1 where each DC points at itself primarily is that it simplifies troubleshooting, especially in situations where you may have multiple domain controllers spread across different network segments or geographical regions.

When you configure a domain controller to point itself to itself for primary DNS, it is generally recommended to utilize the localhost IP address 127.0.0.1, rather than the DC’s actual IPv4 address.

One more important note on the topic of populating DNS server information into the NIC properties of your domain controller servers. NEVER CONFIGURE DCs TO POINT AT PUBLIC DNS SERVERS. Plugging 8.8.8.8 or something similar into a NIC’s DNS settings is a common thing to do for internet-connected home computers. Not for servers. Do not carry this mentality into your business. Your domain controllers must register special records within Active Directory, and pointing a DC’s NIC at a public DNS server will cause that process to fail.I have actually had to clean up this mess, caused by that exact scenario – a company was having some internet connectivity troubles, and as part of troubleshooting, an IT person decided to replace the actual DNS server information inside the NIC properties of every server in the network with 8.8.8.8. Let’s just say that didn’t work out very well…

Active Directory Users and Computers

There is not a single tool that is used to manage all facets of Active Directory. Since it is such an expansive technology, our configuration of the directory is spread across a number of different management consoles. Let’s look at each of them, and at some of the most common tasks that you will be performing inside these tools. Any of these management consoles can be launched from any of your domain controller servers, and just as we saw in a previous chapter, the easiest way to launch these consoles is right from the Tools menu in the upper-right corner of Server Manager.I’ll start with the tool that is alphabetically last in the list of our Active Directory tools, because this is by far the one that the everyday server administrator will use most often. Active Directory Users and Computers is the console from which all of the user accounts and computer accounts are created and managed. Open it up, and you will see the name of your domain listed in the left-hand column. Expand your domain name, and you will see several folders listed here. If you are opening this on an existing domain controller in a well-grown network, you may have pages and pages of folders listed here. If this is a new environment, there are only a handful. The most important pieces to point out here are Computers and Users. As common sense would dictate, these are the default containers in which new computer accounts and user accounts that join the domain will be located.While this window looks quite a bit like File Explorer with a tree of folders, these folders really aren’t folders at all. Most of the manila-colored folder icons that you see here are known as Organizational Units (OUs). I say most of because there are a few containers that exist out of the box that are legitimate storage containers for holding objects, but they are not officially called OUs. The ones we pointed out earlier, Users and Computers, are actually these generic storage containers and are not traditional organizational units. However, any new folders that you create for yourself inside AD are going to be OUs. The difference is depicted in the manila folder icon. You can see in the upcoming screenshots that some of the manila folders have an extra little graphic on top of the folder itself. Only those folders that have the extra little yellow thing are real OUs.OUs are the structural containers that we use inside Active Directory in order to organize our objects and keep them all in useful places. Just like with folders on a file server, you can create your own hierarchy of organizational units here, in order to sort and manipulate the location inside Active Directory of all your domain-joined network objects and devices. In the following screenshot, you can see that instead of having just a plain Users and Computers folder, I have created some new OUs including sub-OUs (more officially known as nested OUs) so that as I grow my environment, I will have a more structured and organized directory:

Figure 3.8: Active Directory structure

User accounts

Now that we have some OUs ready to contain our objects, let’s create a new user. Say we have a new server administrator coming onboard, and we need to get him an Active Directory login so that he can start his job. Simply find the appropriate OU for his account to reside within, right-click on the OU, and navigate to New | User. We are then presented with an information-gathering screen about all the things that AD needs in order to create this new account. Most of the information here is self-explanatory, but if you are new to Active Directory, the one field I will point out is User logon name. Whatever information is put in this field is the user’s official username on the network. Whenever they log in to a computer or server, this is the name they will input as their login.

Figure 3.9: Creating a new Active Directory user

When finished, our new admin can utilize the new username and password to log in to computers and servers on the network, within the security boundaries we have established on those machines, of course. But that is another topic for another chapter.

Security groups

Another useful unit of organization inside Active Directory is security groups. We can do quite a bit to distinguish between different types and kinds of users and computer accounts using organizational units, but what about when we need a little cross-contamination in this structure? Perhaps we have an employee that handles some HR and some accounting responsibilities. File and folder permissions on our file servers are typically managed by individualized or group-based access to read and write into particular folders. Susie from HR needs to have access to the payroll folder, but Jim from HR does not.Both Susie and Jim reside inside the same OU, so at that level, they will have the same permissions and capabilities, but we clearly need a different way to distinguish between them so that only Susie gets access to payroll information. By creating security groups inside Active Directory, we grant ourselves the ability to add and remove specific user accounts, computer accounts, or even other groups so that we can granularly define access to our resources. You create new groups in the same way that you create user accounts, by choosing the OU where you want the new group to reside, and then right-clicking on that OU and navigating to New | Group. Once your group has been created, right-click on it and head into Properties. You can then click on the Members tab; this is where you add in all the users that you want to be a part of this new group:

Figure 3.10: Creating a new group

Prestaging computer accounts

It is very common to utilize Active Directory Users and Computers for creating new user accounts because without the manual creation of a user account, that new person is going to be completely unable to log in on your network. It is far less common, however, to think about opening this tool when joining new computers to your domain. This is because most domains are configured so that new computers are allowed to join the domain by actions performed on the computer itself, without any work being done inside Active Directory beforehand. In other words, as long as someone knows a username and password that has administrative rights within the domain, they can sit down at any computer connected to the network and walk through the domain-join process on that local computer. In fact, in many domains you don’t even need administrative rights to join a machine to a domain.By taking a few steps on the computer, you can easily join it to the domain, and Active Directory will create a new computer object for it automatically. These autogenerating computer objects place themselves inside the default Computers container, so in many networks, if you click on that Computers folder, you will see a number of different machines listed, and they might even be a mix of both desktop computers and servers that were recently joined to the domain and haven’t been moved to an appropriate, more specific OU yet. In my growing lab environment, I recently joined several machines to the domain. I did this without ever opening Active Directory Users and Computers, and you can see that my new computer objects are still sitting inside that default Computers container:

Figure 3.11: Active Directory’s default Computers container

You may even notice that my Fabrikam servers do not show up in this list. Great observation! My primary server base for this test lab is all focused around Contoso.local. I established Fabrikam.local as a completely separate domain for some later purposes, but those two domain environments are not tied together in any way, and are unaware of each other for now.Allowing new computer accounts to place themselves inside the default Computers container is generally not a big problem for client systems, but if you allow servers to be autogenerated in that folder, it can cause you huge issues. Many companies have security policies in place across the network, and these policies are often created in a way that they will be automatically applied to any computer account residing in one of the generalized OUs. Using security policies can be a great way to lock down parts of client machines that the user doesn’t need to access or utilize, but if you inadvertently cause these lockdown policies to apply to your new servers as soon as they join the domain, you can effectively break the server before you even start configuring it. Trust me, I’ve done it. And unfortunately, your new server objects that get added to Active Directory will be identified and categorized the same as any client workstation that is added to the domain, you cannot specify a different default container for servers simply because they are a server and not a regular workstation.So, what can be done to alleviate this potential problem? The answer is to prestage the domain accounts for your new servers. You can even prestage all new computer accounts as a matter of principle, but I typically only see that requirement in large enterprises. Prestaging a computer account is very much like creating a new user account. Prior to joining the computer to the domain, you create the object for it inside Active Directory. By accomplishing the creation of the object before the domain-join process, you get to choose which OU the computer will reside in when it joins the domain. You can then ensure that this is an OU that will or will not receive the security settings and policies that you intend to have in place on this new computer or server. I highly recommend prestaging all computer accounts in Active Directory for any new servers that you bring online. If you make it a practice, even if it’s not absolutely required all the time, you will create a good habit that may someday save you from having to rebuild a server that you broke simply by joining it to your domain.Prestaging a computer object is extremely fast and simple; let’s do one together. In the future, I plan to build a Windows Server that hosts the Remote Access role to connect my roaming users into the network from their homes, coffee shops, and so on. Some components in the Remote Access role are finicky when it comes to network security policies, and so I would rather ensure that my new RA1 server will not receive a whole bunch of lockdown settings as soon as I join it to the domain. I have created an OU called Remote Access Servers, and I will now prestage a computer object inside that OU for my RA1 server.Right-click on the Remote Access Servers OU and choose New | Computer. Then simply populate the Computer name field with the name of your server. Even though I have not built this server yet, I plan to name it RA1, so I simply type that into the field:

Figure 3.12: Prestaging a computer in the domain

That’s it! With a couple of simple mouse clicks and typing in one server name, I have now prestaged (pre-created) my computer object for the RA1 server. If you look closely at the previous screenshot, you will notice that you could also adjust which users or groups are allowed to join this particular computer to the domain. If you plan to build a new server and want to make sure that you are the only person allowed to join it to the domain, this field is easily updated to accommodate that requirement.Once I actually get around to building that server, and I go ahead and walk through the steps of joining it to my domain, Active Directory will realize that the name of my new server matches an object already in Active Directory, and will associate my new server with this prestaged RA1 object instead of creating a brand new object inside the generic Computers container:

Figure 3.13: RA1’s AD object is prestaged

Now let’s venture into another important component of the Active Directory toolbox, especially useful in larger environments...

Active Directory Domains and Trusts

This tool is generally only used in larger environments that have more than one domain within the same network. As we discussed earlier, a company may utilize multiple domain names to segregate resources or services, or for a more comprehensive organizational structure of their servers and namespaces within the company. You already know the differences between a domain and a forest and how the domain resides within the forest. Another way to think of the forest is as the boundary of your AD structure. If you have multiple domains beneath a single forest, it does not necessarily mean that those domains trust each other. So, users from one domain may or may not have permission to access resources on one of the other domains, based on the level of trust that exists between those domains. When you have a domain and are adding child domains under it, there are trusts placed automatically between those domains, but if you need to merge some domains together in a way other than the default permissions, Active Directory Domains and Trusts is the management tool you use to establish and modify those trust relationships.Growing organizations often find themselves in a position where they need to regularly manage domain trusts as a result of business acquisitions. If Contoso acquires Fabrikam, and both companies have fully functional domain environments, it is often advantageous to work through an extended migration process to bring the Fabrikam employees over to Contoso’s Active Directory, rather than suffer all the loss associated with simply turning off Fabrikam’s network. So, for a certain period of time, you would want to run both domains simultaneously and could establish a trust relationship between those domains in order to make that possible.

Building a trust

Earlier I mentioned that I already had domain controllers and a whole test lab network built out for contoso.local, and in this chapter, we established a new fabrikam.local domain. These domains are not associated with each other in any way, they are completely separated forests. As such, a user account in one domain would absolutely not be able to log in to any machine that is joined to the other domain.Let’s change that. We are going to use Active Directory Domains and Trusts to establish a two-way trust relationship between these domains, which will enable exactly that scenario – users from contoso. local will be able to log in to computers joined to fabrikam.local, and vice versa. It is possible to establish either one-way or two-way trusts. Most commonly in the wild I see two-way trusts because they enable more information to flow between the two domains, and in the case of an acquisition, that is most often what we are looking to accomplish. If there was a need for this trust to only flow in one direction, for example allowing contoso.local accounts to log in to fabrikam.local machines but not allow Fabrikam employees to sign in to Contoso equipment, that would be possible with a one-way trust.There are three components to building a successful trust relationship:

Network connectivity

Conditional DNS forwarding

Configuring the trust

Let’s go over them briefly.

Network connectivity

The first one is common sense, those domains need to be able to talk to each other! If you have acquired a company and their servers are in a different physical location, you will likely need to build out some form of site-to-site VPN connectivity between the two physical sites and establish routing so that the domain controllers can communicate with one another.In my test lab, I do have Contoso and Fabrikam servers IP addressed into separate subnets, but they are all part of one test lab network, so they already can communicate with each other at a TCP/IP level.Make sure that you can get packets back and forth between the domain controllers, in both directions, before proceeding with the remaining steps of the trust build.

Conditional DNS forwarding

We haven’t done anything in the DNS management console to this point, but it is installed on all of our DCs. Our next chapter is going to cover many more items related to the management of DNS itself, but for now we will need to utilize DNS management and make a change inside each domain. Currently, if I were to log in to a Contoso workstation and ping fabrikam.local, or if I signed in to a Fabrikam computer and tried ping contoso.local – either of these functions would fail completely, because the two domains have no idea that those DNS namespaces are supposed to resolve to DNS servers in those domains.To bring name resolution full circle between the two domains, I need to set up conditional forwarding inside each domain.I log in to DC1, one of my domain controllers for contoso.local, and launch the DNS Manager tool from Server Manager’s Tools menu. Once inside, beneath my server name there is a folder called Conditional Forwarders. If I right-click on that folder, I can then select the option to create a New Conditional Forwarder…:

Figure 3.14: Creating a new conditional forwarder

Next, enter the remote domain name that you are trying to contact into the DNS Domain field. Then populate the IP addresses of the DNS servers within that other domain. The screen should be able to take your IP address and query the remote server to discover the server FQDN of that server. I also generally select the checkbox to Store this conditional forwarder in Active Directory, so that all of my AD-enabled DNS servers can perform this forwarding. Here are the selections I have made within my contoso.local DNS server, which then tells it how to reach out and talk to fabrikam.local:

Figure 3.15: Configuring the conditional forwarder

You should now see the new conditional forwarder populate inside DNS Manager, and if you pull up Terminal and try to ping the remote domain, fabrikam.local in my case, you can see that name resolution for that remote domain is now successful, where it would have failed prior to our conditional forwarder being created:

Figure 3.16: Successfully pinging fabrikam.local from a contoso.local server

Do it again!

We have now created a conditional forwarder from contoso.local toward fabrikam.local, but remember that we want to establish a two-way trust, and so we now must configure the same type of forwarder inside the fabrikam.local domain, pointing back at contoso.local's domain controllers. Follow the same steps above to create the second conditional forwarder. Once I complete that step, name resolution is successfully working cross-domain, and I am now ready to configure the trust.

Configuring the trust

VPN or other forms of connectivity between the two domains: Check Conditional forwarding set up between the two domains: CheckTime to create a trust!Log in to one of your domain controllers, I am going to use DC1.contoso.local, and launch Active Directory Domains and Trusts. Once inside, you should see the name of your domain listed in the left window pane. Right-click on the name of your domain and select Properties. Inside Properties for your domain, you will see the second tab is called Trusts. Go ahead and choose this tab, and at the bottom there is a button to create a New Trust…. You can see this screen and button in Figure 3.17.There are a few options for naming your trust, but when creating a trust between two forests, as we are today, you want to specify the full DNS name of the remote forest to which you are connecting. In my example, I am creating this trust from inside the contoso.local domain, so I am going to specify fabrikam.local on this screen, as seen here:

Figure 3.17: Creating a new trust

Now you will encounter a few screens that present various options about how this new trust is to be established. You can create a trust based on domains or forests (External trust or Forest trust), you can create this as a two-way trust or a one-way trust in either direction, and you can decide to allow authentication to happen forest-wide or to be more selective. There are good descriptions of what each of these options means right inside the wizard interface as you progress, but what I am interested in establishing today is a total two-way transitive trust between contoso.local and fabrikam.local, so I am selecting the following options:

Forest trust

Two-way

This domain only

Forest-wide authentication

A trust password – you can specify anything you want as the trust password; the important part is that you remember it because you will have to enter the same trust password again when you move over to your second forest or domain, and walk through these steps again to create the other side of the trust.Figure 3.18 summarizes the selected settings:

Figure 3.18: Summary of trust settings

The last step of the wizard is whether or not you want to confirm the outgoing trust. Since at this point we have only created one side of the trust, remember we still need to visit fabrikam.local's domain controller and set up the other side of the trust; at this point we do not want to confirm the outgoing trust because the trust setup is not yet complete.Now that one side of the trust is established in contoso.local, log in to a domain controller in fabrikam.local and walk through the same setup process. You may have noticed earlier that I had an option when establishing my Contoso side of the trust to create the trust for Both this domain and the specified domain. The idea behind this option is that you can create both ends of the trust all at once, via the same wizard and from only one domain controller, but my experience is that this function doesn’t work very well. Therefore, I always take the approach of establishing each side of the trust one at a time, from within each domain. Once complete, you now have an established two-way transitive trust between your two forests:

Figure 3.19: Two-way trust completed

Test it out!

We have a trust. Great! Now, what can we do with it? Remember that trusts are all about allowing cross-authentication to happen between domains. You should now be able to hop onto a computer in either domain and log in to it with a user account from the other domain (assuming there is nothing in your network that is restricting logins such as this). Another quick and easy test is to try setting up a file share, which is a very common thing to share back and forth across multiple domains. Set up a folder on any server in one domain and share it as you would with any folder. Now visit the Security tab to set some NTFS permissions on this folder.When you click the Add… button to include more permissions on this screen, it of course defaults to the domain that this server is joined to. However, if you click on the Locations… button you now have the ability, only because the trust exists, to specify your remote domain as the location you are searching, and you are then able to add user accounts or groups to your folder share permissions from that remote domain, granting those users access to your shared folder. You can see in Figure 3.20 that my Share1 folder is now allowing permissions for groups in both the CONTOSO domain and the FABRIKAM domain:

Figure 3.20: Share1 folder permissions reflect both domains

Active Directory Sites and Services

Sites and Services is another tool that is generally only employed by companies with larger Active Directory infrastructures. As is the case with any server, if having one domain controller is good, then having two domain controllers is even better. As your company grows larger, so does your Active Directory infrastructure. Before you know it, you will be looking into setting up servers in a second location, then a third, and so on. In a domain-centric network, having domain controller servers in each significant site is a general practice, and you could soon be looking at dozens of domain controller servers running in your network.Turning on new domain controllers and joining them to your existing domain so that they start servicing users and computers is pretty easy. The harder part is keeping all of the traffic organized and flowing where you want it to. If you have a primary datacenter where the majority of your servers are located, you probably have multiple DCs onsite in that datacenter. In fact, to make your AD highly available, it is essential that you have at least two domain controllers. But let’s pretend you then build a new office that is quite large, where it makes sense to install a local DC server in that office so that the computers in that office aren’t reaching over the Wide Area Network (WAN) to authenticate all the time. If you were to spin up a server in the new office and turn it into a domain controller for your network, it would immediately start working. The problem is that the client computers aren’t always smart enough to know which DC they need to talk to. You may now have computers in the remote office that are still authenticating back to the main datacenter’s DCs. Even worse, you probably also have computers in the main office that are now reaching over the WAN to authenticate with the new DC that is in the remote office, even though there are DCs right on the local network with them!This is the situation where Active Directory Sites and Services become essential. In here, you build out your different physical sites and assign the domain controllers to these sites. Domain-joined users and computers within this network follow the rules that you have put into place via Sites and Services, so that they are always talking to and authenticating from their local domain controller servers. This saves time, as the connections are faster and more efficient, and it also saves unnecessary bandwidth and data consumption on the WAN, which often saves you dollars.The next page gives us a look into Active Directory Sites and Services. As you can see, there are multiple sites listed here, and they correspond to network subnet information. This is the way that AD Sites and Services tracks which site is which. When a client computer comes online, it obviously knows what subnet it is part of, based on the IP address it is using. AD Sites and Services then knows, based on that IP address, which site the client now resides in.That site identification then helps Active Directory to steer authentication requests to the proper domain controllers, and also helps things like Group Policy (which we will talk about shortly) to be able to process site-specific information. There is a good chance you will have to make use of this tool someday if you are part of a growing organization. Adding new objects into AD Sites and Services is about as easy as it gets. Configure all of your sites by simply right-clicking on the Sites folder and then choosing New Site. You can name your sites anything you like.Once all sites are placed inside AD Sites and Services, you add your subnets in a similar fashion, by right-clicking on the Subnets folder and choosing New Subnet. When you create a new subnet, you plug in the identifying network information about that subnet, and the bottom of the screen allows you to select which site the subnet resides within. You can see that process in Figure 3.21, as well as a look into my sample AD Sites and Services that is now populated with multiple sites and multiple subnets:

Figure 3.21: Defining subnets in AD Sites and Services

Active Directory Administrative Center

While it is critical to understand and be familiar with the tools we have looked at so far that help us manage Active Directory, you can tell that their aesthetics are a bit dated. The Active Directory Administrative Center (ADAC), on the other hand, has a much more streamlined interface that looks and feels like the newer Server Manager that we are all used to working with every day. Many of the functions available within the ADAC accomplish the same things that we can do through AD Users and Computers, Domains and Trusts, and Sites and Services, but it pulls these functions into a more structured interface that brings some of the most utilized functions up to the surface and makes them easier to run.One great example is right on the landing page of ADAC. A common helpdesk task in any network is the resetting of passwords for user accounts. Whether the user forgot their password, changed it recently and mistyped it, or you are resetting a password during some other sort of troubleshooting, resetting a password for a user account typically involves numerous mouse clicks inside AD Users and Computers to get the job done. Now, there is a quick link called RESET PASSWORD, shown right there on the main page of the ADAC. Also useful is the GLOBAL SEARCH feature right next to it, where you can type anything into the search field, and it will scour your entire directory for results relating to your search. This is another common task in AD that previously required multiple clicks to accomplish:

Figure 3.22: Useful tools inside ADAC

If you click on the name of your domain in the left navigational tree, you will dive a little deeper into the capabilities of ADAC. As you can see, the information listed here is being pulled from Active Directory and looks like the same information you would see in AD Users and Computers. That is correct, except instead of having to right-click for every function, such as new user creations or searches, you now have some quick Tasks available on the right that can quickly launch you into accomplishing these functions. Also interesting are the links for raising the forest or domain functional level on this screen.

Figure 3.23: ADAC user interface

In order to raise a functional level from inside our classic tools, I watch most admins accomplish this by launching AD Domains and Trusts. So, one of the big benefits of the newer ADAC tool is that it gives you a centralized management window from which you can accomplish tasks that would normally have taken multiple windows and management consoles.

Dynamic Access Control

In addition to teaching old dogs new tricks, ADAC also brings some functionality to the table that is not available anywhere in the classic tools. If you once again take a look at the tree to the left, you will see that the next section in the list is Dynamic Access Control (DAC). This is a technology that is all about the security and governance of your files and the company data that you need to hold onto tightly, making sure it doesn’t fall into the wrong hands. DAC gives you the ability to tag files, thereby classifying them for particular groups or uses. Then you can create access control policies that define who has access to these tagged files. Another powerful feature of DAC is reporting functionality. Once DAC is established and running in your environment, you can do reporting and forensics on your files, such as finding a list of the people who have recently accessed a classified document.DAC can also be used to modify users’ permissions based on what kind of device they are currently using. If our user Susie logs in with her company desktop on the network, she should have access to those sensitive HR files. On the other hand, if she brings her personal laptop into the office and connects it to the network, we might not want to allow access to these same files, even when providing her domain user credentials, simply because we do not control the security on that laptop. These kinds of distinctions can be made using DAC policies.

Fine-Grained Password Policy

Just about anyone who has ever had to use a Windows computer as part of employment at a business is familiar with the requirement to “reset your password every x number of days.” In a Microsoft Active Directory environment, there are a few different ways to enforce password policies that require a certain password length, set complexity requirements on that password, and define maximum ages for passwords, which result in users needing to reset their passwords every so often. It is a common requirement for companies to require users to change passwords every 30 days or so.The most common and certainly easiest place to define a password policy is by using Group Policy. We will cover this in more detail as we talk about the Default Domain Policy in Chapter 5, Group Policy, but that policy is going to apply one set of password requirements settings to all of the users in your domain, bar none. What if your needs are slightly more complex? For example, maybe you require a complex password that needs to be changed every 30 days for all your office staff, but you manage IT for a manufacturing company that also has some shared computers out on the shop floor. These computers log in with domain accounts so that you can effectively push policies to them and grant permissions at the domain level, but you don’t need these shop floor logins to have the same complexity on their passwords, nor do you care about those passwords changing since they are only ever used inside the network.Enter the Fine-Grained Password Policy. Such a policy meets those expanded needs to a “T” by allowing you to configure differing password policies for different groups of people inside Active Directory. We are actually going to build a fine-grained password policy in Chapter 10, Hardening and Security, so we’ll have to wait on the details until then. The reason I mention it here is that the creation of a fine-grained password policy requires the use of Active Directory Administrative Center, so we will be working within this newer console to create the policy.

Active Directory Recycle Bin

Speaking of technologies that are configured from inside Active Directory Administrative Center, and in this case one that can save you a lot of heartburn, let’s discuss the Active Directory Recycle Bin. As the name implies, this is a container into which objects that are deleted from Active Directory move before they are permanently deleted. Anyone who has worked on a helpdesk knows about user termination tickets, those often-mundane tasks that need to be accomplished on a regular basis. In many cases, those former employee user accounts are deleted from Active Directory to keep things clean. However, many of you who have worked on a helpdesk for a considerable amount of time also know that companies tend to hire the same people back, sometimes within mere days of their departure. Depending on the infrastructure of the business you are supporting, perhaps re-creating the user account from scratch is no big deal, but it is becoming more and more problematic with things like Entra Directory synchronization and immutable IDs. In these cases, boy would it be nice if we had an “oops” button we could click to bring the formerly deleted user account back to life.Enter the AD Recycle Bin. That is exactly the capability provided by this tool. The only trouble? It’s not enabled by default. Let’s go ahead and enable it together, and test it out.Open ADAC and click on the name of your domain in the left-hand list. Then glance over at the right side of your screen, and sitting right there is a button to Enable Recycle Bin….

Figure 3.24: Enabling the AD Recycle Bin

Click this task, and you are presented with a simple selection. You should encounter a dialog box that states “Are you sure you want to perform this action? Once Recycle Bin has been enabled, it cannot be disabled.” Seems pretty straightforward, if you are ready to make this move in your environment, go ahead and click on the OK button. When you do this, Active Directory is updated to reflect the change, and it may take a few minutes for this to activate on all your Domain Controller servers. After letting it sit and bake for a while, close and re-launch your ADAC window, and click on the name of your domain again. If you look closely, you will now find a new folder listed in the middle pane called Deleted Objects.This did not exist before you enabled the AD Recycle Bin. My Deleted Objects folder is currently empty, but I will go ahead and delete our test account for Susie, and then check inside. After deleting Susie’s account, and then double-clicking on that folder called Deleted Objects, I can easily find my deleted account for Susie, and from here simply right-click on it and choose to Restore.

Figure 3.25: Restoring a user account from AD Recycle Bin

By taking this simple action, my user account for Susie is restored directly into the same HR Users OU that she was part of before, with preexisting user account configuration intact. This is so much faster than re-creating a new account and trying to make sure it has all of the original configuration!

Read-only domain controllers

The first domain controller you set up in your network will be a fully writable one, able to accept data from the domain-joined users and computers working within your network. In fact, most DCs in your network will likely be fully functional and writeable. However, it’s worth taking a quick minute to point out a limited-scope DC that can be installed called a Read-Only Domain Controller (RODC). Just like the name implies, an RODC can only have its directory data read from it. Writes that might try to be accomplished to the domain from a user’s computer, such as a password change or new user account creation, are impossible with an RODC. Instead, RODCs receive their directory data from other more traditional domain controllers and then utilize that data to verify authentication requests from users and computers. Where would a limited-access domain controller like this be beneficial? Many companies are installing them in smaller branch offices or less secure sites so that the local computers onsite in those smaller offices have quick and easy access to read from and authenticate to the domain without the potential security risk of an unauthorized user gaining access to the physical server and manipulating the entire domain in bad ways. Another valid use-case for an RODC is within a DMZ, a protected network where you would typically never dream of installing a full domain controller because a DMZ network is all about access restriction and keeping internal network information safe.Configuration of a read-only domain controller is not a totally disparate process, consisting of yet another role or feature, but simply a different option to select when running through the standard installation process of the AD DS role, which we have already worked with a number of times throughout this chapter. In fact, let’s set one up right now. I just created a new VM in my environment (RODC1) and have given it an IP address and hostname. After installing the AD DS role as I have done with other domain controllers in my environment already, I am now going to run the configuration wizard that helps me promote this server to be a domain controller.Since I am adding another DC to an existing domain, the first selection is pretty straightforward. It is when we come to the Domain Controller Options screen where we make a deviation from the way we have run through this wizard in the past. You see that little checkbox that says Read only domain controller (RODC)? Go ahead and check that box:

Figure 3.26: Defining a new DC as an RODC

After clicking Next on this screen, you are now presented with new options, which we have never seen before, on a screen entitled RODC Options. Most interestingly here is the field where we can define which user accounts, or groups of user accounts, are allowed or denied permission to replicate their passwords to RODCs. There are pre-defined objects in these fields. Take note of two Active Directory groups called Allowed RODC Password Replication Group and Denied RODC Password Replication Group. Are these brand-new groups that are going to be added into AD when I finish this wizard? No! While there is a good chance you have never taken notice of these groups before, they already exist inside Active Directory, but are simply unused if you never roll out an RODC in your environment:

Figure 3.27: Built-in groups related to RODC

The choice is yours on whether to utilize these built-in groups or specify your own groups that are either allowed to replicate passwords to this RODC or denied from being able to do so. RODCs are all about keeping security as tight as possible, so you generally don’t want any passwords getting cached on an RODC that won’t actually be needed for that local office’s authentication. Physical security is yet another advantage of using an RODC instead of a full domain controller. What if someone breaks into your branch office and steals the physical server? If bad guys were to get their hands on a full DC, all usernames and passwords in your domain would be stored on that hard drive. With an RODC, only the accounts that have been allowed to cache are contained on the stolen server.Each RODC has its own definition of allowances and denials. By default, every RODC that you add into your domain will follow through these same wizard steps, and if you leave all default options in place then all RODCs in your environment will treat those built-in allowed and denied RODC groups as their definitions, meaning that all RODCs in your environment will be caching the same passwords because they all pay attention to the same groups. However, each RODC maintains its own set of users and groups that are allowed or denied caching. This RODC Options screen can be configured differently for every RODC that you establish.What if you want to make changes to these definitions in the future? Easy enough, you simply need to know where to look for this information to be able to change it. The list of accounts that are allowed or denied caching is generally called the Password Replication Policy (PRP) for each RODC. To find an RODC’s PRP, simply open up AD Users and Computers and find the object for your read-only domain controller, right-click on that computer object, and visit Properties. Inside the properties of your RODC, navigate to the tab called Password Replication Policy. Here, you can view and manipulate the password caching policy for each RODC individually:

Figure 3.28: Password Replication Policy settings

Denials always win! In the Microsoft world, a permission denial always takes priority over a permission allowance. The same is true for RODC caching. If a user account is a member of groups that fall inside both the allow RODC caching and deny RODC caching categories, it will be denied caching for that account.

FSMO Roles

Active Directory is like a database, a potentially huge database, sync’d across a potentially huge number of different Domain Controller servers in your environment. In an environment with lots of DCs spread across numerous sites, the potential for change-based conflict is huge. What if DC1 in Redmond receives a change and needs to sync it around the entire domain, and at the same time DC22 in London receives instruction to sync a change that conflicts with the change of DC1. What now? Who wins? In the early days of Active Directory, there was one single master domain controller server, known as the Primary Domain Controller (PDC), that was responsible for making all changes like this. Technically, the PDC role no longer exists, but some of the same protections are still in place under the hood using Flexible Single Master Operation (FSMO) roles. Every instance of Active Directory has FSMO roles, and FSMO role holders. In a lot of cases, the same Domain Controller holds all five of the FSMO roles, but they could technically be managed by different domain controller servers. Here are the five FSMO roles:

Schema master

Domain naming master

RID master

PDC emulator

Infrastructure master

We aren’t going to discuss each of these in-depth for the purposes of our chapter, because the typical IT admin doesn’t need to know that level of detail. What you do need to understand, however, is that they exist and that at least one of your domain controllers is hosting these roles. This knowledge becomes critically important if you remove or replace a domain controller that was hosting one of these roles, or that server dies, and you now have chaos inside your directory. Thankfully, it is quite easy to find out what server or servers are hosting these roles, and also now easy to transfer the FSMO roles to a different domain controller in your environment, should the need arise. The key things to remember are that you have FSMO roles, they are extremely important to the workability and health of Active Directory, and that if their server disappears, you need to move them to another server asap.

Viewing current FSMO role holders

To find FSMO role holders via graphical interface, you’re going to have to check three different administrative tools. This is because some FSMO roles are forest-wide, and some are domain-wide. Therefore, it is possible to have many more than five FSMO roles within a forest, and their technical homes are inside different admin consoles. Let’s first list out where you could find this information via the GUI.

RID, PDC, and Infrastructure master

Open Active Directory Users and Computers, right-click on the name of your domain, and click Operations Masters…. The three tabs here will indicate which DC is hosting the corresponding roles.

Schema master

Right-click the Start button, and click Run. Then type regsvr32 schmmgmt.dll and click OK. This process enables something called Active Directory Schema to be available from inside the MMC console, which you can then open by…Right-clicking the Start button, click Run, type MMC and click OK. Now navigate to File > Add/Remove Snap-in… and add the Active Directory Schema to your MMC console. Once added, right-click Active Directory Schema and look inside Operations Master to find the schema master server.

Domain naming master

Open Active Directory Domains and Trusts, right-click on the words Active Directory Domains and Trusts, and click on Operations Master… to view the Domain naming master server.

View them all in one place

While the graphical interfaces are good to know about and useful for finding individual FSMO role holders, most of the time you would rather just see them all listed out together, right? Thankfully we have some very old tools still hanging around even in Windows Server 2025 that can do exactly this.Open an administrative Terminal on one of your Domain Controller servers, and simply run the following command: netdom query fsmoThis single command lists out all five FSMO roles and their current master servers, as seen in the following screenshot.

Figure 3.29: Viewing FSMO role holders via Terminal

FSMO role visibility through PowerShell

And of course we can also see these through PowerShell, though surprisingly it requires two separate commands to do so. Given this, I prefer good ole netdom via Command Prompt or Terminal if I am manually looking for FSMO role ownership information, but there are certainly use cases where pulling this information from PowerShell would be beneficial for scripting or other purposes, so here are the commands to find the same information using PowerShell.

Find domain-level FSMO roles

Get-ADDomain | select InfrastructureMaster, PDCEmulator, RIDMaster

Find forest-level FSMO roles

Get-ADForest | select DomainNamingMaster, SchemaMaster

Transferring FSMO roles

Now for the fun part, transferring these FSMO roles to new servers. Pulling the trigger on changes like this can be very intimidating if you haven’t done it before. I mean, you’re yanking a significant underpinning of Active Directory and moving it to a new place, what could go wrong? No reason to fret, moving these roles around is quite easy and you’ll be surprised to find that it happens almost immediately after you click the button or press that Enter key. If you are moving FSMO roles one at a time, each of the graphical interface methods for viewing the master also includes a Change button that can be used to quickly and easily shift individual FSMO roles from one server to another. The key to doing this is that you must connect to the domain using the new destination server to whom you are planning to transfer your role. As you have seen, all FSMO roles in my test lab are held by DC1, which makes sense because it was my first domain controller. I now want to move only the PDC role to my DC2 server. To accomplish this transfer of power, I log into my newer DC2. Remember, there are three different places you may need to visit to move FSMO roles, depending on which roles you are working with, but for the PDC role I need to perform the following: Active Directory Users and Computers > Right-click the domain name > Operations Masters > PDC > Change. Uh oh, when I clicked that Change button, I was presented with the error below. What gives?

Figure 3.30: Attempting to transfer the PDC role

If you look closely at the previous screenshot, you’ll notice that DC1 is displayed in a couple of different places, most primarily near the top of my AD Users and Computers window. I told you that I would need to log into my DC2 server to change this role, and simply wanted to prove that this process will not work if you are logged into the domain controller who already holds the FSMO role. If I right-click on Active Directory Users and Computers [DC1.contoso.local] and choose the option to Change Domain Controller… I will be able to connect to the domain through DC2 instead. Once I accomplish that, I can now successfully migrate the PDC role to DC2. Alternatively, I could log out of DC1 completely and log into DC2 instead, ensuring that DC2 is indeed the server listed inside my AD Users and Computers window, like in Figure 3.31, and you’ll find that transferring this PDC FSMO role is now a simple matter of clicking that Change button.

Figure 3.31: PDC role has been moved to DC2

Transferring FSMO roles via PowerShell

As with everything inside Windows Server, if you can accomplish it via graphical interface, you can almost certainly find a way to do the same thing with PowerShell. While viewing FSMO role ownership was slightly easier via an old Command Prompt command, transferring the roles between Domain Controllers is definitively easiest to accomplish by using PowerShell. To transfer roles, simply log into the server to whom you are going to transfer the roles, and run as few or as many commands as you need. There is a separate command to run for each FSMO role, and by running all five, we have now quickly and smoothly transferred all FSMO roles onto my DC2 server.Pro tip: You can even move multiple roles at the same time, by following any one of the following commands and simply comma-separating the different roles to transfer, as you can see in Figure 3.32:

Transfer RID Master

Move-ADDirectoryServerOperationMasterRole -Identity "DC2" RIDMaster

Transfer PDC Emulator

Move-ADDirectoryServerOperationMasterRole -Identity "DC2" PDCEmulator

Transfer Infrastructure Master

Move-ADDirectoryServerOperationMasterRole -Identity "DC2" InfrastructureMaster

Transfer Schema Master

Move-ADDirectoryServerOperationMasterRole -Identity "DC2" SchemaMaster

Transfer Domain Naming Master

Move-ADDirectoryServerOperationMasterRole -Identity "DC2" DomainNamingMaster

Figure 3.32: All FSMO roles have been transferred to DC2

Demoting an old domain controller

Creating new servers and turning them into Domain Controllers is technically known as promoting those servers to become Domain Controllers. This process is fairly straightforward, and easy to accomplish in a fresh environment without any history of changes or issues, such as inside a test lab. Now let’s cover one of the messier things that you may encounter as a server administrator, removing an old Domain Controller server. The process of removing a DC from your environment is known as demoting. Demoting a Domain Controller can be straightforward if the old server is online, or it can be a little convoluted if the old server has died, and you are now trying to remove all traces of it from the domain without being able to take the standard removal steps.

Demoting while the old server is still online

If you are removing an old Domain Controller and it is still online, the process is fairly painless. Log into that server, and accomplish the following steps:

Open Server Manager

Manage > Remove Roles and Features

Make sure your old server is selected

Uncheck Active Directory Domain Services

If this server is also a DNS server, it is easiest if you remove the DNS Server role before accomplishing the AD DS removal

You will receive a pop-up with Validation Results. On this screen, click the link to Demote this domain controller

Figure 3.33: Demoting a Domain Controller via Server Manager

You will also be asked if you want to Force the removal of this domain controller – it is generally recommended NOT to check this box unless you are removing the very last Domain Controller from your domain.A few more Next boxes and specifying a new local Administrator password (remember, this server will no longer be a DC, so the wizard will be creating a new local Administrator account), and you’re off to the races. The server is demoted and removed from Active Directory, and when it finishes restarting, there will be a plain-jane Windows Server sitting on your network.

Clean up AD Sites and Services

The DC demotion process via Server Manager cleans up almost everything, but if you open Active Directory Sites and Services, you will still find reference to the old Domain Controller name, listed under the Servers folder under whichever site that server resided. Simply right-click on the old server name and delete it, and you’re all set.

Demoting when the old server is gone

Here is a scenario that most tenured Active Directory administrators have encountered at least once. The reason we have redundant DCs is in case one of them dies, right? Well…what happens when that happens?Running to Server Manager and attempting to cleanup or remove the old DC will get you nowhere. Without being able to contact the server that is now offline, Server Manager is not going to know what to do to remove that server from all of the places it is plugged and referenced inside Active Directory. Instead, you must manually clean up references to the old server, which is surprisingly easier than you might think.

Move FSMO roles

First, as we just finished describing, you’ll want to ensure that you get your FSMO roles moved to a working DC in your environment. Thankfully the old server does not need to be online for this to happen.

Delete it

Open Active Directory Users and Computers, and navigate to the OU called Domain Controllers. Inside this OU you should find the computer object for every DC in your environment, including the dead one. Simply right-click on this object and Delete, and you are presented with a warning message regarding the fact that you are attempting to delete a Domain Controller without performing a proper demotion. If your DC is really gone and not coming back, simply check the box to Delete this Domain Controller anyway and delete it.

Figure 3.34: Manually removing a Domain Controller from Active Directory

Clean up Sites and Services and DNS

Following either removal method, make sure to visit Active Directory Sites and Services to clean up any traces or pointers that still reference the old Domain Controller, DC2 in my case. In addition to Sites and Services, when you forcibly remove a DC from Active Directory, it often leaves behind traces of the old DC inside DNS. We have not talked in-depth about DNS at this point, but if you open the DNS Manager console and expand the available folders, looking inside each one, you will almost certainly find traces of the former DC.

Figure 3.35: Cleaning up DNS following a manual DC deletion

These records are no longer needed and could cause problems or delays in DNS, so they should all be removed.

Intro to Group Policy

In a network that is based upon Windows Server and Active Directory, it is almost always the case that the primary set of client computers is also based upon the Microsoft Windows operating systems, and that these machines are all domain-joined. Setting everything up this way not only makes sense from an organizational perspective inside Active Directory, but also allows centralized authentication across devices and applications, as we have already talked about. I know that a couple of the examples I gave earlier in the book went something like, What about when a company has a security policy in place that... or Make sure your servers don’t get those existing security policies because... So what are these magical security policies anyway, and how do I set one up?This is the power of Group Policy. It enables you to create Group Policy Objects (GPOs) that contain settings and configurations that you want to apply to either computers or users in your Active Directory domain. Once you have created and built out a GPO with a variety of settings, you then have the option to steer that GPO in whatever direction you choose. If you have a policy that you want to apply to all desktop systems, you can point it at the appropriate OU or security group in Active Directory that houses all of your domain-joined desktop computers. Or maybe you created a GPO that only applies to your Windows 10 computers in a particular site; you can filter it appropriately so that only those systems are receiving the policy. And the real magic is that the issuance of these settings happens automatically, simply by those computers being joined to your domain. You don’t have to touch the client systems at all in order to push settings to them via a GPO. You can tweak or lock down almost anything within the Windows operating system by using Group Policy.Once again, I’m looking in the list of available roles on my Windows Server 2025, and I am just not seeing one called Group Policy. Correct again: there isn’t one! In fact, if you have been following along with the lab setup in this book, you already have Group Policy fully functional in your network. Everything that Group Policy needs to work is part of Active Directory Domain Services. So, if you have a domain controller in your network, then you also have Group Policy on that same server, because all of the information Group Policy uses is stored inside the directory. Since the installation of the AD DS role is all we need to use Group Policy, and we have already done that on our domain controller, we are already prepared to start using Group Policy to send policies and preferences to our computers and users within the domain.But wait! Group Policy is a large enough topic that it really needs its own chapter, which is exactly what I have decided to do. If you’re interested in centralizing administration and policy with this fascinating tool, which you should be, continue reading and we will dive deeper into all things GPO in Chapter 5, Group Policy.

Microsoft Entra ID

I’ve said it before and I will probably say it again, this book’s primary focus is Windows Server capabilities inside your network. Even so, many of these concepts and tools will carry directly over to your cloud journey inside Azure, as a lot of cloud administration work is still really Windows Server administration work, but with your Windows Servers running inside Azure.The topic of Active Directory in the cloud is…cloudy.Active Directory is all about authentication and identification. It is the source of truth for who your user accounts are, and what computer accounts are owned by your business. As many companies prepare or are moving into the cloud, we of course seek similar functionality in a cloud resource. From Microsoft’s cloud toolset, what is our answer to authentication and identification?Microsoft EntraThe reason I called Microsoft Entra cloudy is not only to be punny, but because this topic can be confusing if you haven’t heard about it before. There are actually three different ways that you can authenticate and identify computers and users inside Microsoft’s cloud, and I thought it would be a helpful addition to this chapter to describe each of them.

Entra ID

The first step into Microsoft cloud authentication for most companies is Entra ID. This is the SaaS-based identity engine that underpins Microsoft 365. If you are using Microsoft 365 for email hosting, or even if you are simply using Microsoft 365 applications on your computers and utilize M365 user accounts to log into those apps, all of those user accounts are stored, maintained, and administered inside Microsoft Entra ID. Management of accounts and objects inside Entra ID happens most often through a web browser, by simply logging into your Microsoft Admin Portal and driving around from there.

Active Directory on an Azure VM

Another completely separate way to manage authentication inside Microsoft Azure is to create a virtual server in Azure, and promote it to be a Domain Controller, exactly as we have done within this chapter. For many companies, Azure is really treated like a large Hyper-V server, granting you the ability to host unlimited numbers of VMs. Moving your resources into Azure may involve a combination of full Azure servers as well as SaaS services like Entra ID, but the point of this section is to make sure you know that you can absolutely run a traditional domain controller server inside Azure. In fact, most customers that I work with who are interested in putting any server resources in Azure begin this journey with a single domain controller in Azure. Spinning up a DC here and creating a site-to-site link between Azure and your local datacenter opens a world of possibilities. You are essentially just extending your domain into your private Azure space, and in Active Directory’s eyes, Azure is simply another Site just like Dallas, London, or Redmond in our examples today. Once your existing domain is extended into Azure, you can now quite easily slide your existing servers into Azure also, where they can happily run while you take steps to power down and recycle that old physical server hardware.

Microsoft Entra Domain Services

The most confusing iteration of cloud-based Active Directory is something called Microsoft Entra Domain Services, which was formerly known as Azure Active Directory Domain Services, or AADDS for short. It’s not often that we come across five-letter acronyms, so I suppose it’s no surprise that something with such a significant name would require significant learning to make use of it.Entra Domain Services is different than Entra ID because it is a more classic Active Directory environment. When running Entra Domain Services, you can take Azure VMs and join them to this instance of AD, just like you would with on-premise servers joining on-premise Active Directory. The big difference with Entra Domain Services compared to our previous scenario of AD on an Azure VM is that Entra Domain Services has no server attached to it. You do not have to pay for the compute resources in Azure to be running a Windows Server instance that happens to be a domain controller. Instead, Active Directory is offered up as a sort of PaaS, where you can tap into AD and make use of its authentication mechanisms, even NTLM and Kerberos, without having to log into or maintain an actual server. As you can see, this often creates confusion for those tasked with building it, but in the end it can be quite beneficial in that you don’t have to maintain a server, and Entra Domain Services even integrates with Entra ID, which creates a more uniform authentication experience across your cloud infrastructure.

Entra Connect

All these Azure/Entra based authentication methods sound great, but if I already have servers in my datacenter and now want to slowly open the valve to begin creating cloud resources and migrating some of my workloads into that cloud, does that mean I need to maintain two separate authentication methods during this hybrid period? Not at all!Almost every company who goes through cloud migration begins by creating a hybrid environment, where resources exist both in-cloud and on-premise. Indeed, some companies plan to remain in hybrid mode indefinitely. In any hybrid scenario, which you will almost certainly encounter during your time working in IT, a tool called Entra Connect is the magic glue that holds these things together. Entra Connect is a piece of software that is installed on one of your local servers, most usually on a domain controller but not necessarily so. Once installed, a simple configuration wizard walks through the process of defining what this tool needs to accomplish. Its purpose is to take information that exists inside your local Active Directory, and sync that data upward into Entra ID. Most notably, it syncs user accounts, their accompanying passwords, and various attributes of the AD object. This means that users will have the same identity, username and password, for their M365 and Azure resources as they do for their normal workstations in the office. The same password for local network drives on a file server will work for M365 email, and anytime their password changes in AD, it syncs automatically to Entra.Entra Connect is also an important piece to the puzzle for some information that you may want to sync back downstream, in the opposite direction. Passwords are the prime example. A common helpdesk ticket is helping someone to reset their password, but these tickets are always high-alert because they come with a sense of urgency (the user cannot work until you help them), but you need certain guarantees from the user that they really are who they say they are, or you may be helping a malicious actor to gain entry to this account. In the Microsoft 365 world, there is a web service called Self-Service Password Reset, where you can simply steer users to the website and they are able to self-reset their M365 password from this interface, using a combination of variables they need to answer, most notably the MFA that is on their own device. This makes helpdesk involvement in password resets very easy and safe, and leaves the power of password change in the user’s own hands. But…in a hybrid scenario, where your AD passwords are the source of truth and sync into Entra, you are now attempting to take a backwards approach to changing that password. Not to fear, this scenario, the backwards syncing of passwords from Entra to AD, is another thing that Entra Connect helps with.Entra Connect was formerly known as Azure AD Connect, and a lot of documentation still references “AD Connect” or “AAD Connect”. This is good to know in case you are searching for something and unable to find it listed under Entra Connect.

Summary

Anyone who has been around Windows Server before knows that Active Directory is nothing new and certainly not a breathtakingly hot topic that is specific to the release of Windows Server 2025. AD has been the authentication underpinning of any Microsoft-centric environment for a very long time and will continue to be far into the future for anyone who hosts an on-premise datacenter. As we have just finished discussing, AD is no longer relevant only inside your physical walls, but flows throughout the Azure world also. Knowing and understanding AD is entirely critical for the mastery of Windows Server 2025, because without this knowledge your career in server administration won’t even make it off the ground.Some hints were dropped in this chapter about another core infrastructure technology that almost always runs alongside Active Directory on all of your domain controller servers, DNS. To effectively manage a Microsoft infrastructure, in my opinion there are three in-the-box server technologies that any admin must be able to work with fluently: Active Directory, DNS, and DHCP. Follow along to Chapter 4, DNS and DHCP, as we cover the latter.

Questions

Inside Active Directory, a container (folder) that holds computer and user accounts is called a(n)…?

What is the term for creating a computer account inside Active Directory prior to that computer being joined to your domain?

Which management tool is used to specify that certain physical locations in your network are bound to particular IP subnets?

What is the name of a special domain controller that cannot accept new information, only synchronize from an existing domain controller?

What tool is needed to create a fine-grained password policy?

What must be configured inside DNS prior to establishing a forest trust?

What is the command-line command that shows you all FSMO role holders at once?

True or False? It is faster to manually remove a Domain Controller from the domain than it is to follow the Server Manager role removal wizard.

What identity and authentication service underpins Microsoft 365?

4 DNS and DHCP

Join our book community on Discord

https://packt.link/zYovfWithout a doubt, I consider Active Directory Domain Services (AD DS) to be the most common and central role inside any Microsoft-centric network, with DNS and DHCP sliding in at #2 and #3 in order of importance. I am yet to meet an admin who has chosen to deploy a new domain without deploying DNS at the same time, and every network has a need for DHCP whether or not that service is provided by a Windows server. Either of these roles could be served by something other than a traditional server. There are other companies and even dedicated appliances that exist to provide DNS within a corporate network, which have some advantages and some disadvantages. Regarding DHCP, there are plenty of options for providing that service outside of the Windows world, as most firewalls and even switches are capable of also being DHCP “servers” in a network. Indeed, if you are sitting at home reading this text, it is most likely that your computer is connected to a DHCP server built into your home router. Although the preceding sentences are true, the majority of internal DNS and DHCP services for businesses around the world are provided by Windows servers, and these two roles are very commonly located alongside AD DS on at least some of the Domain Controller (DC) servers in any given network.In this chapter, we will cover both DNS and DHCP provided by Windows Server 2025, getting to know their purposes and walking through some common terminology and tasks related to these roles. In this chapter, we will be covering the following:

The purpose of DNS

Types of DNS records

Split-brain DNS

Types of DNS zones

DNS-over-HTTPS

IP addressing with DHCP

Creating a DHCP scope

DHCP reservations

DHCP failover

IPAM

Let’s get started!

The purpose of DNS

Domain Name System (DNS) is similar to Active Directory in that it is a structured database that is often stored on domain controller servers and distributed automatically around your network to other domain controller/DNS servers. Where an AD database contains information about your domain objects, DNS is responsible for storing and resolving all of the names on your network. What do I mean by names? Whenever a user or computer tries to contact any resource by calling for a name, DNS is the platform responsible for turning that name into something else in order to get the traffic to the correct destination. You see, the way that traffic gets from the client to the server is via networking, and typically via the TCP/IP stack, using an IP address to get to its destination.When I open an application on my computer to access some data that resides on a server, I could configure the application so that it communicates directly to my server by using the server’s IP address on the network. If an application on my computer needed to communicate with a server called APP01, and that server was using an IP address of 10.10.10.15 on the network, I could plug 10.10.10.15 into my application configuration, and it would open successfully. If I set up hundreds of different computers this way, all pointing to IP addresses, it would work fine for a while. But the day will come when, for whatever reason, that IP address might need to change. Or perhaps I add a second server to share the load and handle my increased user traffic. What to do now? Re-visit every client computer and update the IP address being used? Point half of the computers at one server and half at the other? Certainly not.This is one of the reasons that DNS is critical to the way that we design and manage our infrastructures. By using DNS, we can employ names instead of IP addresses. With DNS, my application can be configured to talk to APP01 or whatever my server name is, and if I need to change the IP address later, I simply change it inside the DNS console to the updated IP address and immediately all of my client computers will start resolving the APP01 name to the new IP address. Or I can even use a more generic name, such as intranet, and have it resolve across multiple different servers. We will discuss more about that shortly.Any time that a computer makes a call to a server, service, or website, it is using DNS to resolve that name to a more useful piece of information to make the network connection happen successfully. The same is true both inside and outside of corporate networks. On my personal laptop right now, if I open Edge and browse to https://www.bing.com/, my internet provider’s DNS server is resolving bing.com to an IP address on the internet, which is the address that my laptop communicates with and so that page opens successfully. When we are working inside our own corporate networks, we don’t want to rely on or trust a public provider with our internal server name information, and so we build our own DNS servers inside the network. Since DNS records inside a domain network are almost always resolving names to objects that reside inside Active Directory, it makes sense then that DNS and AD DS would be tightly integrated. That rings true in the majority of Microsoft networks, where it is a very common practice to install both the AD DS role, plus the DNS role, on your domain controller servers. If you remember back to our previous chapter, that is exactly what we did when we built DC1 and DC2.

Types of DNS records

Having installed our DNS role on a server in the network, we can start using it to create DNS records, which resolve names to their corresponding IP addresses, or other pieces of information needed in order to route our traffic around the network.Assuming that you are working in a domain network, you may be pleasantly surprised to discover that a number of records already exist inside DNS, even though you haven’t created any of them. When you are running Active Directory and DNS together, the domain-join process that you take with your computers and servers self-registers a DNS record during that process, which means creating a DNS record for each new server or computer is not something that you need to remember to accomplish.I have not yet created any DNS records in my new lab environment, not purposefully anyway, and yet when I open the DNS Manager console from inside the Tools menu of Server Manager, I see numerous records already existing. When I joined each of these machines to the domain, it automatically registered these records for me so that the new servers and workstations were immediately resolvable within our domain:

Figure 4.1: DNS Manager

Host record (A or AAAA)

The first kind of DNS record we are looking at is the most common type that you will work with. A host record is the one that resolves a particular name to a particular IP address. It’s pretty simple, and for most of the devices on your network this will be the only kind of record that exists for them inside DNS. There are two different classes of host records that you should be aware of, even though you will likely only be using one of them for at least a few more years. The two different kinds of host records are called an A record and an AAAA record, which is pronounced “Quad A”.The difference between the two? A records are for IPv4 addresses and will be used in most companies for years to come. AAAA records serve the exact same purpose of resolving a name to an IP address, but are only for IPv6 addresses, and will only be useful if you use IPv6 in your network.In Figure 4.1, you can see some Host (A) records that were self-created when those machines joined our domain. I also have another server running on my network that has not yet been domain joined, and so it has not self-registered into DNS. This server is called RA1, you may remember that we already pre-staged an AD object for this server, but since it is not yet joined to the domain it has not self-registered a DNS record. If I log in to any other system on my network at this moment, I fail to contact my RA1 server by name, since that name is not yet plugged into DNS:

Figure 4.2: RA1 server does not resolve

For now, I am going to choose not to join this server to the domain, so that we can manually create a DNS record for it and make sure that I am able to resolve the name properly after doing that. Back inside DNS Manager on your DNS server, right-click on the name of your domain listed under the Forward Lookup Zones folder, and then choose New Host (A or AAAA)... Inside the screen to create a new host record, simply enter the name of your server, and the IP address that is configured on its network interface:

Figure 4.3: Adding a new host record

Now that we have created this new host record, we should immediately be able to start resolving this name inside our domain network. Moving back to the client machine from which I was trying to ping RA1 earlier, I’ll try the same command again, and this time it does resolve and reply successfully, even though RA1 is not yet joined to our domain. If I had instead worked through the process of joining RA1 to the domain, I never would have needed to manually create this A record, but I wanted to show you the process:

Figure 4.4: Successfully pinging RA1

Alias record – CNAME

Another useful type of DNS record is CNAME (canonical name), which more commonly these days is called an alias record. This is a record that that takes a name and points it at another name. You can almost think of a CNAME as a nickname. It sounds a little silly at first glance, because, in the end, you are still going to have to resolve your final name to an IP address by using a host record in order to get the traffic where it needs to go, but the purposes of an alias record can be vast. A good example to portray the usefulness of an alias record is when you are running a web server that is serving up websites within your network. Rather than force all of your users to remember a URL like http://web1.contoso.local to access a website, we could create an alias record called intranet, and point it at WEB1. This way, the more generalized intranet record can always be utilized by client computers, which is a much friendlier name for your users to remember.In addition to creating a happier user experience with this new DNS record, you have at the same time created additional administrative flexibility because you can easily change the server components that are running beneath that record, without having to adjust any settings on the client machines or retrain employees on how to access the page. Need to replace a web server? No problem, just prep the new server alongside the old one and then point the alias record at the new server. Need to add another web server? That’s easy too, as we can create multiple alias records, all with the same intranet name, and point them at the different web servers that are in play within the environment. This creates a very simple form of load balancing, as DNS will start to round-robin the traffic among the different web servers, based on that intranet CNAME record.In fact, rather than continue to talk about this, let’s give it a try. I have a website running on exactly that URL in my environment, but currently I can only access it by typing in http://web1.contoso.local. Inside DNS, I am going to create an alias record that redirects intranet to WEB1:

Figure 4.5: Creating a new alias record

Now when I ping intranet, you can see that it resolves to my WEB1 server. And when accessing the web page, I can simply type the word intranet into my address bar inside a web browser to launch my page. The website itself is not aware of the name change being made, so I didn’t have to make any modifications to the website, only within DNS:

Figure 4.6: Visiting WEB1’s site using the new Intranet alias

Mail Exchanger (MX) record

A third type of DNS record is called a Mail Exchanger (MX) record. In your everyday duties, you will not have to encounter or configure MX records nearly as often as A or CNAME records, but they are important to understand nonetheless. An MX record is all about email services and delivery. Whatever domain name follows the @ in your email address, the DNS servers that are handling that domain name must contain an MX record telling the domain where to point for its mail services. MX records are most commonly used within public DNS, for name resolutions happening over the internet. For companies hosting their own email on local Exchange servers, your public DNS servers will contain an MX record that steers email at your Exchange environment. For companies hosting their email in a cloud service like Office 365, your public DNS records would need to contain an MX record that directs email traffic toward the cloud provider that is hosting your mailboxes.Whenever an email is sent outbound, the internet needs to determine how to deliver that email. Public internet DNS is checked for whichever domain the email is destined for, and the MX record contained within that DNS configuration defines where the email is sent. If you don’t have an MX record, or if it disappears for some reason, you will receive zero emails to your domain. This is important to understand for email delivery troubleshooting purposes. How would an MX record possibly disappear? Usually during website changes. When a business decides to migrate over to a new website, it is typically the website developer making those changes. As part of those changes, they need access to DNS to be able to point your company website name at whatever new IP address is being used to host the website, and if the wrong options are selected during migration, your MX record could become null in the process. If you encounter any email delivery problems following changes in DNS, it is most likely that something is wrong with your MX record.

Microsoft 365 MX records

Now that so many businesses host their email in Microsoft’s Office 365 platform, let’s take a firsthand look at an MX record that points to this system. Even though millions of mailboxes across thousands of companies now host their email in the same Microsoft 365, every company will have a unique MX record associated with their M365 environment. Finding your specific MX record criteria is pretty simple (but very critical to get it correct), you just need to know where to look.Log into your Microsoft 365 admin portal, and navigate to Settings > Domains. Here, you will see all of the domain names that you have configured inside the portal. Click on the name of the domain in question, and then click on DNS records. Here, you will see all DNS records that need to be present in your company’s public DNS provider that are required for Microsoft 365 services to work successfully. The most important for email delivery is the MX record, listed right on top, but all three of the records under the Microsoft Exchange heading are very important.

0 contoso-com.mail.protection.outlook.com

Once you ensure this MX record is successfully created in your domain’s public DNS records, the internet now knows that any email destined for an address ending in @contoso.com needs to be delivered to Microsoft 365 hosting services, and Microsoft takes it and delivers it to your appropriate company and mailbox from there.

TXT record

TXT is simply short for text record. TXT records are used within DNS for various purposes, and they can contain just about any kind of information. Sometimes TXT records are placed for actual human reading of some type of info, but more likely you will be asked to create a TXT record at some point as a form of validation.For example, most websites are protected by SSL certificates, and the process of purchasing an SSL certificate is straightforward. However, you certainly wouldn’t want any yahoo with a laptop and internet access to be able to purchase a certificate that can protect a website name that ends in a domain name that your business owns, right? So, certification authorities (CAs) (the places where you purchase SSL certificates) will require some sort of validation process before allowing you to purchase a certificate for your domain name.Sometimes that validation process is simply allowing the CA to send an email to an address associated with that domain name where you can then manually validate by clicking on a link in that email, or sometimes you will be asked to create a TXT record with a very exact set of characters in your public DNS records. The implication and validation, of course, is that if you really do own that domain name, you will have access to receive email or to create DNS records within that domain. When the CA sees your newly created TXT record that contains the data they asked you to input, they know you really do own that domain, and they will then issue your new certificate. An attacker trying to spoof your website and acquire an SSL certificate maliciously would not have such access into your domain’s DNS settings.

SPF record

There are a few special kinds of TXT records, a common one being Sender Policy Framework (SPF) records. This record pertains to the delivery of emails, but while an MX record identifies which servers email should flow toward, an SPF record identifies which locations email is coming from. SPF records are part of spam and spoofing calculations, used to identify the locations on the internet from which email from your domain is expected to be flowing. Let’s take a look at a couple of example SPF records, which will help you to understand how they are formatted, and also assist in describing why they are necessary:

v=spf1 [IP address 1] [IP address 2] [include:<domain>] -<enforcement rule>

The preceding is standard formatting for an SPF TXT record. For simple email systems where all email flows from one public IP address on the internet, or from one hosted email system, your record will be nice and short. A great example is email coming from Microsoft 365. Everyone who hosts email in M365 should have an SPF record with (at minimum) the following information inside:

v=spf1 include:spf.protection.outlook.com -all

SPF record information is used by receiving email servers to validate the mail coming inbound. That mail server will receive the email, discover which domain it came from, and reach back out over the internet to that domain’s DNS servers to check for the existence of an SPF record. If it doesn’t find such a record, your email has a much higher chance of being flagged as spam. If it does find an SPF record, the mail server then checks the entries in that record, which identifies the safe places that we expect mail to be flowing from, and confirms that the email did, in fact, originate from one of those places. In our preceding Microsoft 365 SPF record, we included the domain spf.protection.outlook.com. All email that flows from Office 365 servers will match this origination, so this simple record is the only thing needed to be in place for safe delivery of email from your Microsoft 365 tenant.

Note:

You may have noticed that I keep interchanging Microsoft 365, Office 365, and M365. These are all commonly used nomenclatures to refer to the same thing, email that is hosted on Microsoft’s servers.

Now pretend that your SPF record is already in place and working with your hosted email, but that you set up an on-premise SMTP relay server so that your copiers on the network have the ability to scan to email. This is a common request by businesses, and something that I find in the wild on a very regular basis. The nature of your SMTP server doesn’t really matter; there are various ways to accomplish that. What you’ll usually find, though, is that when you send email from your copier, that email may start getting flagged as spam. Sometimes it lands in the recipient’s junk mail folder, sometimes it is captured and not delivered to them at all. Why is this? If you have an onsite SMTP relay where the email is coming from, remember the copier just hands email over to the SMTP relay, and that relay is the guy who is shuttling the email over the internet.That relayed email is not coming from spf.protection.outlook.com, but rather email sent from your on-premise SMTP server is coming from your ISP’s outbound public IP address. Your SPF record needs to be adjusted to include this additional safe sender, so that recipients of your email will know that emails coming from your physical building are legit. Let’s build out an SPF record that includes a single IP address:

v=spf1 ip4:8.8.8.8 include:spf.protection.outlook.com -all

That’s it! By simply updating your SPF record to include the public IP address that the copier scans are coming from, your recipient email servers will better trust that incoming mail.I’m obviously using 8.8.8.8 as an example in the preceding text; don’t plug this into your own SPF records! You will want to identify your actual outbound IP address and use that information instead.It is also easy to add multiple IP addresses, for example, if your business owns multiple buildings, each with their own ISP connections, and want email traffic to be able to flow from devices (such as copiers) in each location:

v=spf1 ip4:8.8.8.8 ip4:4.4.2.2 include:spf.protection.outlook.com -all

Enforcement rule -all

What is that -all at the end of an SPF record, anyway? I’m glad you asked! The declaration at the end of an SPF is telling the receiving mail server how strictly it should enforce these SPF rules. There are three different ways that you could configure that enforcement rule:

-all: This is generally the way you always want to set up SPF records. -all means “hard fail.” It sets the SPF rules as firm, so recipient mail servers will follow these rules.

~all: Use this alternative if you are unsure that you have all IP addresses listed in your SPF record, for a soft fail scenario. I would only use this as a temporary measure, and honestly I don’t know that I have ever encountered an SPF record in a production environment that is configured as such.

?all: The last option here is neutral. Use it only for testing SPF records, as it will not help mail delivery until you later change it over to -all.

DKIM signatures

Another increasingly common type of DNS “record” related to email delivery is DomainKeys Identified Mail (DKIM). In the far past, no special DNS records were required on the internet to be able to deliver email successfully, because stupid spammers and attackers weren’t yet holed up in their basements with nothing better to do. Once these things started becoming prevalent, SPF became commonplace to combat it and prove identity for real email delivery. Email attacks continue to escalate, and now it’s the norm to establish both SPF and DKIM in public DNS, to further prove reliable identity of your real email.DKIM is not actually its own “type” of DNS record, but a series of tools that work together to help verify the authenticity of email. Once you work toward enabling DKIM in your environment, you will find that the DNS records to be created in your public DNS are actually CNAME records, which we already discussed.Since Microsoft 365 is so popular, let’s log into the M365 administrative portal and discover what exactly is needed to enable DKIM in our environment. Log into portal.office.com, and navigate to the following, or simply search for “DKIM” in the search field of the Admin portal:Admin | Security | Policies & Rules | Threat Policies | Email authentication settings | DKIMYou know what, just go ahead and visit the admin center and then search for DKIM. Microsoft changes the placement of things in the Security portal so often, it is most likely that it will be changed again before this book is in print. Oh, Microsoft.Hopefully you are now looking at a heading which says DomainKeys Identified Mail (DKIM) and a listing of all domains that are plugged into your 365 environment. You will see a status next to each domain, and a simple Disabled/Enabled toggle switch. Flipping this switch to Enabled is literally all you must do on the M365 side to enable DKIM on your email domain, but if you try it, you’ll receive a rather nasty-looking error on-screen:

Figure 4.7: Read closely to find your needed CNAME records

If you read over the messy text very carefully, you will find that this Client Error screen is telling you exactly what you need to create inside your public DNS, in order to have the proper CNAME records that DKIM is looking for. Using this information, which I of course obfuscated in my earlier screenshot, head over to your public DNS provider and add the specified CNAME records. After waiting for those DNS records to become live on the internet, which could take a few minutes or a few days depending on your DHS hoster, you will now be able to re-visit the DKIM screen inside M365’s Security portal, and successfully flip the toggle to enable DKIM on that email domain. That’s it!

Name Server (NS) record

Here is another type of DNS record that you don’t have to deal with on a day-to-day basis, but you should still know what it’s there for. An NS record is an identifier within a DNS zone that tells it which name servers (your DNS servers) to use as the authorities for that zone. If you look at the NS records listed in your internal DNS right now, you will recognize that it is calling out the names of your DNS servers on the network. When you add a new DC/DNS server to your domain, a new NS record for this server will be automatically added into your DNS zone:

Figure 4.8: Viewing NS records in your zone

Public name server records

NS records are critical to understanding when working with public/internet DNS records. I can’t tell you how many times I have assisted admins who were trying to create new DNS records for their zone and struggling because it seemed like no matter what they plugged into the DNS settings, their new records would never show up and work on the internet. After a quick look, we discover that their Name Server record for the domain was pointing at a different DNS server or service altogether, which they didn’t even realize was part of their company’s DNS equation. Here’s an example scenario that helps explain:You inherit an already established infrastructure as you take over server administration for a company. The previous admin has all passwords documented; things are looking good so far. The director of marketing for the company has their own company credit card, and comes to you on day two to let you know that rather than navigate the proper IT purchasing channels, they just signed up for xyz marketing service that is going to help send out blasts of emails. This marketing company requires things called CNAME records to be created in your public DNS so that your email and their systems can work together. Now it’s up to you to put those CNAME records into place.No big deal, right? You reference the password document and find a record labeled DNS that has login credentials for GoDaddy. Sounds like the jackpot, and makes sense as GoDaddy is a pretty common platform on the internet for managing DNS zones. You log in to GoDaddy, edit the DNS zone for your domain, and add your new CNAME records. The CNAME records aren’t resolving yet, but you know that DNS propagation takes a while to roll around the internet, so you inform Mr. Marketing that his new service should be up and running within 24 hours. You’re a hero!Except…24 hours roll around, and it’s still not working. Mr. M is starting to push back, and you’re realizing that that quarterly bonus may not be so sure a bet. Unfortunately, you have forgotten one critical piece of the puzzle. Even though you have a GoDaddy account, and it is labeled DNS, and you were able to create new DNS records within that account, it is entirely possible that the registrar for your domain is actually pointing Name Server records at a different DNS service entirely! A useful tool in this scenario is the DNS Lookup tool from MXToolbox.com. A quick search for that on the internet will find you the current link, you simply type in your domain name to the DNS Lookup tool, and it will spit back at you which Name Servers are in place, and which service is hosting your DNS records on the internet.Following the previous procedure, you discover that the Name Server records for your domain are, in fact, pointing to Network Solutions, not GoDaddy at all! As it turns out, your IT predecessor wasn’t entirely sure how to do a domain transfer, and they got it part-way there but never finished out the process, so while you have GoDaddy available and your domain is even listed inside the GoDaddy console, when any computer on the internet tries to look up DNS info for your domain, the Name Server records are telling that computer to head toward Network Solutions for the domain’s DNS servers, not GoDaddy at all. You now have two choices. You can either log in to Network Solutions and add your CNAME records there, and they will work because Network Solutions is currently the service that is doing DNS resolution for your domain, or you can finish out that migration and update your Name Server records so that they point at GoDaddy’s DNS servers, instead of Network Solutions.In summary, this is the flow that happens with a DNS lookup:

Client/server makes a call for DNS

Name Server records identify which DNS servers are authoritative for the domain you are calling for

DNS lookups are steered at those name servers

DNS resolution happens

ipconfig /flushdns

Just one final note to finish out this section. I have been saying things like Now when I do this... or Immediately following this change... and if you are creating some of your own records, you may have noticed that it sometimes takes a while for your client computers to recognize these new DNS records. That is normal behavior, and the time that it takes before your change rolls around to the whole network will depend entirely on how large your network is and how Active Directory replication is configured. When you create a new DNS record on one domain controller, your new record needs to replicate itself around to all of the other DCs in your network. This process alone can take upward of a couple of hours if AD is not configured for faster replication. Typically, it only takes a few minutes. And then, once the new record exists on all of your DC servers, your clients may still take a little bit of time to utilize the new record, because client computers in a domain network hold onto a cache of DNS data. This way, they don’t have to reach out to the DNS server for every single name resolution request. They can more quickly refer to their local cache in order to see what the information was from the last time they checked in with the DNS server. If you are trying to immediately test out a new DNS record that you just created and it’s not working, you may want to try to run the ci command on your client computer. This forces the client to dump its locally cached copies of DNS resolver records and go grab new information from the DNS server. After flushing your cache, the new record should resolve properly.

Split-brain DNS

In all of our lab configurations, screenshots, and examples you will notice that domains we create on the internal network always end with .local. This is purposeful and is generally considered best practice. Public DNS zones, as you well know, can end in a myriad of ways.Websites or services that live on the internet may end with .com, .org, .edu, .biz, .info, .tech, .construction—the list goes on and on. These are known as top-level domains, and the creative use of such DNS suffixes should remain on the internet and away from our internal DNS zones.Now, many of you may already work in corporate environments where your internal DNS is configured as something other than a .local, and so you already realize that internal domains can certainly be configured as one of these other suffixes. For example, Microsoft.com is obviously one of the public domains that Microsoft owns, and they could very well also have used Microsoft.com as an internal DNS zone. In fact, it could even be their primary domain name inside Active Directory right now, and this wouldn’t necessarily cause any problems, but it certainly increases the potential for problems, or at least creates a more complex DNS environment in general.Whenever a company configures their internal DNS to match their external DNS, this is commonly referred to as split-brain DNS. Years ago, there were articles published on the internet by Microsoft warning administrators against doing this, as it caused confusion and problems with some Microsoft roles and technologies that companies would try to deploy in their environments. As time went on, many people either didn’t know or simply ignored this recommendation, and so the world is now awash with networks where split-brain DNS exists. Many of these environments are so populated and complex that they will never be changed at this point, and so Microsoft and the world had no choice but to adapt. Thankfully in today’s world, most roles or services that you deploy are written in a way that they accommodate for possible split-brain DNS out of the box, but some still require special considerations.One example is Microsoft DirectAccess, which we will cover in Chapter 9, Remote Access. When deploying DirectAccess, there is a critical piece of client-side technology called the Name Resolution Policy Table that must be populated based on your internal DNS architecture. For companies using a .local domain internally, this configuration is a piece of cake and no special considerations are needed. For anyone with split-brain DNS, this sometimes turns into a convoluted mess and for anyone not well-versed in the intricacies of DirectAccess, simply having split-brain DNS in your environment could very well mean that you are never able to get DirectAccess working in your environment. It’s possible, but more challenging.At first glance, you would think that administration would be made easier if internal DNS zones matched public DNS zones, but this simply isn’t true. The opposite, in fact, is what you will find. Whenever you publish any external service, you will then have to make special considerations with your internal DNS to make that service work as intended from inside the network, because internal DNS zones will typically trump external. Split-brain DNS ends up being more work on a daily basis.Over the past few years I have seen a couple of Microsoft documents related to Office 365 that recommend administrators who are setting up new internal domains to do so by intentionally using split-brain DNS, configuring their internal DNS zones to match their public DNS. For example, they might recommend that if your public domain is contoso.com, that your internal domain should also be setup for contoso.com instead of contoso.local. After reading over these articles, and based on my own experiences, I don’t agree. Setting up split-brain DNS makes some aspects of Office 365 administration and integration easier, but if you step back and look at the whole IT picture, it’s still more complicated overall. Configuring your on-prem internal DNS to be split-brain creates extra complexities with Entra Domain Services rollouts as well.As the saying goes, you can lead a horse to water but can’t make him drink. You have now been informed that utilizing the same DNS zone inside your network as what you use on the internet could cause you some headaches. What you decide to do with this information in the future, well that’s up to you…

Types of DNS zones

You are now familiar with creating different types of DNS records, but that information is only going to enable you to create new records inside of an already existing DNS zone. At present in our test lab, we have only one DNS zone available to us, contoso.local, which was created automatically when we built the contoso.local domain. As of right now, computers who are using one of my contoso.local domain controllers as their DNS server are only able to look up DNS records that I have plugged into my DNS zone.With DNS Server provided by Windows Server 2025, you can certainly build out many different DNS zones, to increase name resolution capabilities in your network. There are plenty of different reasons why you might want to create additional DNS zones, and you should understand what types of zones are available to implement. Let’s take a minute and discuss the different types of zones available to us.

Active Directory Integrated Zones

This is not a zone type, per se, but rather an option that can be selected when you create some types of DNS zones. When creating that new zone, you will find a checkbox that states Store the zone in Active Directory. When selected, this means that the new zone you are creating is going to be stored inside Active Directory, rather than being stand-alone on the DNS server from which you are creating the zone. Being stored inside AD means that this new zone is capable of being replicated automatically to all domain controller servers in your domain, which means that your DNS zone is highly available and more quickly accessible across your entire network. In general, if the type of zone you are creating allows storage inside Active Directory, do it.After opening up the DNS Manager tool on your domain controller, you’ll notice that any current DNS zones are listed beneath folders entitled Forward Lookup Zones and Reverse Lookup Zones. What’s the difference?

Forward Lookup Zones

Zones configured inside Forward Lookup Zones are your traditional DNS zones. Their purpose is to take an incoming DNS request, such as from a client computer, and turn that DNS name request into an IP address that is handed back to the client computer. Forward Lookup Zones are almost always where DNS administrators will be working.

Reverse Lookup Zones

If “reverse” is the opposite of “forward,” then the same must be true within a DNS context. Reverse Lookup Zones are responsible for mapping IP addresses backward into names. You may not even realize that these happen in your environment, but you can easily test it out anytime. You likely all know how to use the ping command, which is relying on DNS to turn a name into an IP address. That, of course, is being handled by a Forward Lookup Zone, like we see here:

Figure 4.9: Resolving a name to an IP address

Did you know you can also use the ping command to perform the opposite? What if you want to query DNS to find out what hostname the 10.10.10.11 IP address maps back to?

ping -a 10.10.10.11

Figure 4.10: Querying DNS to find a hostname from an IP address

This reverse lookup, converting IP addresses back to names, has shown us that the IP address 10.10.10.11 has a reverse pointer record (PTR) mapping back to our DC2 server. This type of lookup is handled by a Reverse Lookup Zone inside DNS. Reverse Lookup Zone creation is handled in the same way Forward Lookup Zone creation is handled, and we will work through creating a new DNS zone in just a few minutes. What is important to understand is that reverse zones are not automatically generated, you will need to intentionally create a reverse lookup zone if you have a reason for this functionality to exist in your environment. Now that we understand the difference between Forward and Reverse Lookup Zones, right-clicking on Forward Lookup Zones and selecting New Zone… lands us with three choices on which type of zone we would like to create:

Figure 4.11: DNS zone types

Primary Zone

The majority of DNS zones within internal networks are primary zones. This indicates that it is the “parent,” so to speak. The master copy of any particular DNS zone is going to be the primary zone for that domain. When changes and updates are made to DNS records, it always happens within the primary zone. We will create a new primary zone together in just a few minutes. You can choose for primary zones to be stored in Active Directory, or not.

Secondary Zone

Based on their names, it would seem secondary zones might be less important than primary zones, and that is generally true. A secondary zone is simply a read-only copy of a primary zone. Because it is read-only, no updates can be made within a secondary zone, it is always syncing from the primary zone. Secondary zones can be used to spread the DNS computing power among multiple servers, taking the load off of the primary zones, but it is important to know that secondary zones are not Active Directory-integrated. When you try selecting the option to create a new secondary zone, you will notice that the AD checkbox grays out.Inside most networks I have worked with that are based on Microsoft infrastructure, your primary zones all get set up to be Active Directory-integrated, which means they are syncing around to all of your domain controller-based DNS servers anyway. In this case, secondary zones are less likely to be needed. If you deviate from that mentality and create DNS servers that are not also domain controllers (which you can absolutely do)—then you may want to take care that you understand the use cases of secondary zones because it is more likely in this scenario that you would utilize them.

Stub Zone

The third selection on your new zone screen is Stub Zone. Like secondary zones, stub zones are copies of primary zones but only contain certain pieces of information. Namely, stub zones contain resource records that help clients to identify and more quickly get to the full DNS servers for whatever zone they are calling. Stub zones can be AD-integrated if required.Stub zones are enabling your DNS servers to know how to direct traffic to resolve records inside another domain. Sounds just like a conditional forwarder that we learned about in the previous chapter, right? Similar, yes, but as you know we pointed our conditional forwarder at a specific IP address, telling DNS that requests for the remote domain should always point at a particular server or servers. Stub zones contain NS records for the remote domain, so even if that remote domain makes some internal adjustments and its DNS servers change or are updated, stub zones can more accurately deal with those scenarios.AD-integrated DNS zones replicate among domain controllers using domain replication, but non-AD-integrated DNS zones have to sync using their own process, known as zone transfers. Stub zones can be used to help make the zone transfer process more efficient and create faster name resolution for client computers.

Creating a new Forward Lookup Zone

We will finish out this section with a quick walk-through on creating a new DNS zone. The process is straightforward, but there are a few options to consider along the way. In most cases when creating new DNS zones, you will be doing so in order to enable internal client computers to resolve names for a new internal namespace (another .local, for example), so that you can utilize that internal naming scheme for accessing servers and resources inside the network.For our example, let’s create a new primary zone just like we would for any internal namespace, but we are going to configure the DNS zone with a name that conflicts with a well-known internet namespace. This walk-through will not only portray the options available as we configure a DNS zone, but also give a glimpse into what kind of challenges can present in a split-brain DNS scenario. It also portrays the fact that when clients are inside the network, their internal DNS servers have priority over internet DNS servers.Inside DNS Manager, right-click on Forward Lookup Zones and select New Zone…. Now select the options to create a new Primary Zone, and I am going to choose to store mine in Active Directory. Refer to Figure 4.11 if you need a reference point on these options.We now encounter a screen titled Active Directory Zone Replication Scope. This screen and options only present themselves when the Store inside AD option is checked, otherwise the wizard would have bypassed this screen. Here you have options for how extensively you would like this new DNS zone to replicate among your domain controllers. You can replicate to all DCs inside the domain, or even the whole forest.Next, name the zone. The name that you provide the zone here is the namespace for which the zone is going to contain records. The possibilities here are endless, I could even type in Jordan.local as my DNS zone, or Jordan.com. This is actually a legitimate website that wraps over to Nike.com, which I suppose is fair because Michael Jordan is a little bit more popular than I am.Now, I typed Jordan.com just to be silly, but it will portray exactly what I was going to show you, so let’s stick with it. This is possibly the weirdest thing I’ve ever done inside DNS Manager.To prove out what is happening here, first from a client computer in my network I have pulled up a web browser and verified that I can successfully get to Jordan.com. If I ping that name, you can see that it resolves to a public IP address, which is expected. This is the public, internet-routable IP address of the web server upon which Jordan.com is hosted:

Figure 4.12: Resolving a public DNS zone

This is completely normal behavior, right? Type in a website URL, which is a DNS name; DNS resolves it to the IP address that hosts the website, and your browser takes you there. Next, finish out the creation of our new Jordan.com internal DNS zone, on our internal DNS server.Walking through the zone creation wizard, I have typed in a zone name of Jordan.com, and the next screen that I must answer is regarding Dynamic Update. Server administrators always have the ability to manually create DNS records inside DNS zones, but if you have hundreds of client computers in your environment, do you really want the creation of DNS records to be a full-time job? Thankfully there is no need to do this, as client computers that are joined to your domain will automatically attempt to register their own hostname and IP address into DNS servers whenever they connect to the network. This process is known as dynamic update, and the settings on this screen show you options regarding these updates. You can allow or disallow dynamic updates for each zone and set some requirements around how secure that updating process needs to be. In most domain environments, configuring the top option is what you will do, only allowing secure updates in your zone. If you have legacy equipment or non-Microsoft products abundant in your network, you may need to select the second option to allow both secure and nonsecure updates:

Figure 4.13: Security options for DNS dynamic updates

That’s it! The final screen of the wizard is simply a settings review, and after clicking Finish, your new DNS zone is immediately available and working to resolve names in the new Jordan.com namespace, for any client computers who are using this server as their DNS server. As you can see in Figure 4.14, the Jordan.com zone is now listed in DNS Manager, and I went ahead and created a couple of A records so that any requests for Jordan.com or www.Jordan.com return an IP address of 10.10.10.23. (See what I did there? Number 23?):

Figure 4.14: Creating an internal Jordan.com DNS zone

Now that our new zone is created inside the network, what has that changed? Let’s move back to that client computer in my test network, and try both browsing and pinging Jordan.com again:

Figure 4.15: Pinging Jordan.com again

Prior to creating this new zone, my client request for Jordan.com was simply forwarded to public internet DNS servers, because my internal DNS servers did not have any of their own definitions for what to do with Jordan.com lookups. After creating an internal DNS zone for Jordan.com, we have now interrupted access to the website, because our own DNS server now has its own ruleset for what to do with these name requests! If I were to build out my own website on a web server and give that server an IP address of 10.10.10.23, my client computer would have successfully loaded my custom website when typing Jordan.com into their browser.This example serves two purposes. First, to walk through the creation of a new DNS zone to review the options available, and to show how easy it is. Second, to make sure you understand that your internal corporate DNS servers have priority over public internet DNS servers. This means you need to take care when creating DNS zones, and when deciding whether or not you want to pursue split-brain DNS by hosting your public namespace inside your network as well, because your internal DNS servers are going to be the primary resolvers for those zones. Split-brain DNS requires more attention and maintenance on a regular basis.

Creating a new Reverse Lookup Zone

While not necessary in many environments, we talked about Reverse Lookup Zones and what the PTR records contained within can do in your environment, but have not yet looked at one together. Similar to the process of creating a new Forward Lookup Zone, right-click on Reverse Lookup Zones inside DNS Manager, and select the option to add a new zone. Options for this new zone are almost exactly the same as a forward lookup zone, but you will find that instead of specifying a namespace for this new zone, you are instead going to select whether you want this Reverse Lookup Zone to be for the purpose of IPv4 or IPv6, and then find a requirement to specify a Network ID that this zone is going to manage. My internal lab network is 10.10.10.x, so I will specify this reverse zone to operate as such:

Figure 4.16: Creating a Reverse Lookup Zone

If you enable this zone for Secure Dynamic updates, and if you have both DNS and DHCP running on servers in this environment, then from this point forward when you join new computers or servers to the domain they will automatically create both forward zone Host (A) records in DNS, as well as PTR records inside this new reverse zone. Reverse Lookup Zones are, therefore, usually hands-off. For our purposes today, I also wanted to show you what it looks like to manually create a new record inside our new Reverse Lookup Zone. Right-click on the new zone, and select the option to create a New Pointer (PTR)...

Figure 4.17: Creating a PTR record inside our Reverse Lookup Zone

Simply enter the IP address and hostname of the server or computer that this PTR record points to, very similar to creating new Host records inside a Forward Lookup Zone. Once your PTR records are populated, you can reverse lookup machines in the environment all day long!

DNS-over-HTTPS

Hold your horses! For any of you who already know what DNS-over-HTTPS is, you may have jumped to the conclusion that seeing these words here in this book means that you can now host DoH within Windows Server DNS, but unfortunately we are not there quite yet. We are discussing DNS-over-HTTPS here because it is a relevant technology, it is the future of DNS, and Microsoft has made the statement that DNS-over-HTTPS support is coming to Windows DNS Server in the future.I wish that future were today, but alas…or should I say “doh”?DoH (yes, this acronym makes me LOL) is becoming more and more important as we see increased sophistication in attacks on our network traffic. You are almost certainly already familiar with the concept of HTTPS and would never dream of visiting a sensitive location on the internet without seeing that familiar nomenclature in your browser’s address bar. HTTPS means that all traffic flowing back and forth between your computer and a website is encrypted, but you now know that your computer doesn’t even understand how to get to myfavoritebankingsite.com without first reaching out to ask the internet’s DNS servers, how do I get to this name? The process of DNS doing its job and looking up a name and then submitting it back to your computer is NOT encrypted. So attackers may not gain access to your financials, thank goodness, but they could certainly find out what bank you use because the fact that you are visiting myfavoritebankingsite.com (this is not real, FYI), Google, Bing, Microsoft, or any other site that you frequent…well, those website names are information that would be interesting to an attacker and would not be very difficult for them to capture.Enter the idea of DNS-over-HTTPS. DoH fills the gap, and when enabled means that even your initial DNS lookups are encrypted, as well as your web traffic afterward, of course. To successfully make use of DoH, you simply need to enable a client computer to point their DNS traffic at a DoH-enabled DNS server.Currently, DoH is primarily focused on Internet traffic, not so much our internal networks. For any client computer that is connected to the internet, all you need to do is edit the IP address properties of your network card, and point the DNS server definition at a DoH-capable endpoint. Some of the big-name companies providing DoH services available to the public internet are Google and Cloudflare.

Finding a DoH provider

Microsoft does recognize that DNS is heading this direction, and already includes a very useful PowerShell cmdlet that spits out a listing of public DoH providers. To find one, simply open PowerShell or Windows Terminal, and run the following:

Get-DNSClientDohServerAddress

(once again, I just love that “Doh” is the official language here)

Figure 4.18: Seeking out DNS-over-HTTPS servers on the internet

You are now equipped with IP addresses, from that ServerAddress column, that can be used to steer a workstation at a public DoH service.

Enabling DoH on a workstation

This part is easy for anyone already familiar with editing NIC properties. Simply open your TCP/IPv4 properties, find an appropriate DNS-over-HTTPS option in the drop-down menus, and point your DNS server address at one of the DoH servers on the internet.Start | Settings | Network & internet | EthernetFrom this screen, find your network card and click Edit from the DNS server assignment section.Click that drop-down menu, and change your DNS settings from Automatic to Manual. Then click the toggle to enable IPv4.You will now find the expected option to define your own DNS server, with another drop-down menu to select whether or not you want to use DNS over HTTPS. Specifying one of the IP addresses of a public DoH provider is the most important component here. In our previous screenshot, you may have noticed DohTemplate information. This info is automatically pulled into your NIC configuration if you select to use automatic template settings, or you can choose to manually enter this information. With a workstation on the public internet, it is easiest to simply allow automatic configuration to happen, but in the future once we have options to implement DoH on an internal DNS server, we may find ourselves making use of more manual configurations of these settings.The last option to select on this screen is whether or not you want to allow Fallback to plaintext. This is fairly self-explanatory, if the DoH services are not behaving properly or if you try to visit a website that it cannot look up securely for some reason, your computer will fall back on traditional (non-encrypted) DNS lookups to get the job done. If you leave this slider set to Off, as I have done in my upcoming screenshot, you are going all-in on DoH and if it has any trouble with name resolution, you simply won’t get to your website.

Figure 4.19: Using Google’s public DoH service

Now, the astute among you have realized that DoH is a great idea, and that your DNS lookups are now hidden from the majority of the internet, but that you are still handing this listing of website lookups over to your DoH provider. Yes, you are exactly right. Without DoH being enabled, a company like Google already knows what websites you search for and visit, if you search for them via Google.com. But if you point your computer to Google’s DoH presence for secure DNS-over-HTTPS lookups, you are increasing security of your internet browsing, but you are also now telling Google every website that you visit from your computer.Sidenote: Please do not walk around and configure all of your business computers to make use of a public service DNS-over-HTTPS provider! I wanted to walk through this example today to help readers understand what DoH is, and how to enable it. Inside your corporate domain environment, you will want your domain-joined workstations to continue throwing DNS requests against your internal, corporate DNS servers. If you suddenly usurp that and point all workstations at public DNS, you will absolutely cause problems for your users whenever they attempt to access company-owned resources, like internal servers. To bind internal name resolution together with DNS-over-HTTPS, we would need….

DNS-over-HTTPS on Windows DNS Server

I really wish I could outline for you exactly how you can turn your Windows DNS Server into a Windows DNS Server that is enabled for DNS-over-HTTPS, but it simply isn’t possible as of this writing. Microsoft is working on it, and once released I expect this will quickly become a commonplace security enhancement that most businesses, any that have good IT admins like yourself, will implement.

IP addressing with DHCP

IP addresses on your network are sort of like home addresses on your street. When you want to send a package to someone, you write their address on the front of the package and set it in the mailbox. In the same way, when your computer wants to send data to a server or another device on a network, each of those devices has an IP address that is used for the delivery of those packets. We know that DNS is responsible for telling the machines which name resolves to which IP address, but how do those IP addresses get put into place on the servers and computers in the first place?Static addressing is simply the process of configuring IP addresses on your system manually, using your own hands as the configuration tool to plug all of your IP address information into the NIC settings on that device. While this is a quick and easy way to get network traffic flowing between a few endpoints, by giving them each a static IP address, it is not scalable. We do often statically address our servers as a way of making sure that those IP addresses are not subject to change, but what about on the client and device side? Even in a small company with 10 employees, each person may have a desktop and a laptop, there are likely going to be printers on the network also needing IP addresses, and you may have a wireless network where employees or even guests can connect phones and other devices in order to gain internet access. Are you going to assign IP addresses by hand to all these devices? Certainly not.Our answer to this problem is the Dynamic Host Configuration Protocol (DHCP). This is a protocol that is designed to solve our exact problem by providing the ability for machines and devices to be plugged into your network and automatically obtain IP addressing information. Almost any user on any device in the entire world uses DHCP every day without even realizing it. When you connect your laptop or smartphone to a Wi-Fi router to gain internet access, a DHCP server has given you the ability to route traffic on that Wi-Fi network by assigning you IP addressing information. Often, in the case of public Wi-Fi or a simple home internet setup, your DHCP “server” is a service running on the wireless router itself. DHCP servers come in many flavors and on many types of equipment. Most firewalls are also capable of being DHCP servers for any or all of the subnets they manage. In our businesses where Windows Server rules the datacenter, our DHCP services are most often hosted on one or more Windows Servers across the network.

Creating a DHCP scope

So far in the new Windows Server 2025 lab environment I have been building, I have been statically assigning IP addresses to all of the servers that are being built. This is starting to get old and is hard to keep track of. When the first domain controller was configured, I installed the DHCP role onto it but haven’t told it to start doing anything yet. What does a DHCP server need to start handing out IP addresses? It needs to know what IP addresses, subnet mask, default gateway, and DNS server addresses are within your network so that it can package that up and start handing the information out to the computers who request it. This package of information inside the DHCP server is called a DHCP scope. Once we define our scope, the DHCP server will start handing out IP addresses from that scope to our new servers and computers that do not already have static addresses defined.Once again, we need to launch a management tool on our Windows Server 2025, and once again, the easiest way to launch that is by using the Tools menu inside Server Manager. On the server where the DHCP role is installed, go ahead and launch the DHCP console. Inside, you will see the name of your server where the DHCP server is running. Expand that, and you have options for both IPv4 and IPv6. Yes, this means that you can use this DHCP server to hand out both IPv4 addresses as well as IPv6 addresses for those of you who are testing out IPv6, or have plans to in the future. For now, we are sticking with good old IPv4, and so I can right-click on IPv4 and choose to create a New Scope. This launches a New Scope Wizard that walks you through the few pieces of information that the DHCP server needs in order to create a scope that is ready to start handing out IP addresses inside your network. I am setting my new scope to hand out IP addresses from 10.10.10.110 through 10.10.10.170:

Figure 4.20 Creating a new DHCP scope

During this DHCP scope setup wizard you will encounter a few additional options. Most have self-explanatory text on the screens, but let’s take a moment to review the options you will uncover:

Subnet mask and length: Define the size of the subnet that you are asking DHCP to assign IP addresses within. If this is unfamiliar territory, make sure to visit Chapter 8 at some point in your journey through this book.

Exclusions: If there are any IP addresses within your defined scope which you would like DHCP to refrain from handing out, specify them here. An example of this would be an IP address for a server which is already statically assigned, and falls within the DHCP range that you declared earlier. DHCP will not know about any static IP addresses on your network, and so DHCP could still hand out that address and create a conflict on the network if you don’t specify static addresses as exclusions. I can’t tell you how many times I have watched IT admins do the “ping test” to find an available IP address, without even thinking about DHCP scopes. What if I was looking for an available IP address to place a new printer, and I did a simple “ping 10.10.10.151”. If no other devices had yet grabbed 10.10.10.151 from DHCP, this address would be free, and maybe I go ahead and assign it to my printer. Then tomorrow, a new computer joins wireless and DHCP could easily hand it 10.10.10.151, because it has no way of knowing that you inserted your printer’s static IP right in the middle of its DHCP scope. Anytime you are assigning an IP address to any device for any reason, make sure to keep DHCP in mind.

Lease Duration: When a computer or device grabs an IP address from a DHCP server, that address is always “leased” out to the computer, and only for a specific amount of time. When this time expires, the client or device will reach back to DHCP to get another IP address. Perhaps the same one will be issued, perhaps a different IP address. Lease Duration is where you define the amount of time DHCP clients can retain their IP addresses before asking for a new one.

Configure DHCP Options: There are many additional options that you can include with a DHCP-issued IP address. This is the place where you would define what information a client receives in addition to their IP address. You can declare your network’s Default Gateway, the DNS Servers present within your network, and even specify special options such as provisioning information for VOIP phones. The two most common pieces of information to define here are Default Gateway (router), and DNS Servers. By doing so, anytime that DHCP hands out an IP address to a workstation, it also gives that workstation the correct DNS servers and Default Gateway, which are both critical pieces of information for proper routing of traffic on your network.

The last option you encounter is whether you want to activate your scope now. Typically, yes you would want to do this. Activating the scope means that the DHCP server is now ready to issue IP addresses based on this scope to any computer who asks for one. However, there is one important thing we have not accomplished yet, as this is the first time that we have touched this new DHCP role on our DC1 server.

Authorize the DHCP server

If the DHCP server you are working with has never been authorized within the network, you must do so before it can perform any work. To do this, from inside the DHCP management console, simply right-click on the name of your server and then select the option to Authorize.

Figure 4.21 Authorizing a DHCP server

As soon as your DHCP server is authorized and your scope is activated, it is immediately active and any computer in your network whose NIC is configured to grab an address automatically from a DHCP server will start doing so against this new DHCP server. You can witness proper authorization of a DHCP server by watching those red arrows in Figure 4.21change into green checkmarks, the little icons on the IPv4 and IPv6 headings. Green checkmarks indicate a successfully authorized DHCP server.Now that our new scope has been created, you can expand the scope inside the DHCP console and see some additional information about this scope. By clicking on the Address Leases folder, you can see all the DHCP addresses that have been handed out by this DHCP server.As you can see in Figure 4.22, I have a Windows 10 client computer on the network, which does not have a static address, and so it has grabbed a DHCP address from my DHCP server. It has been given the first IP address that I defined in my scope, 10.10.10.110. The next machine that reaches in to grab an IP address from this DHCP server will receive 10.10.10.111, and so on from there:

Figure 4.22: IP addresses assigned by DHCP

Scope Options

DHCP scopes can be configured to hand out a very small set of information, like we have configured so far, or when needed DHCP is capable of handing out a lot more. When a client reaches into DHCP to grab information, we are currently handing out an IP address and subnet mask, because these two pieces of information are critical to making traffic flow on our networks. Most networks, however, are going to require at least a couple of additional pieces of information to be given to DHCP clients, for those devices to really be usable in a traditional corporate network. We very briefly discussed additional scope options that can be passed to client machines during IP address assignment, now let’s take a look at how to get back into those options from within an existing DHCP scope and tweak them to our liking.Listed under the new scope we just created, you will see a folder titled Scope Options. Right-click on Scope Options, and then select Configure Options….Here you will find many, many different checkboxes, all of which are available DHCP scope options. By selecting a checkbox and populating the necessary information for that particular scope option, you are then configuring this DHCP scope to give not only simple IP address and subnet mask information to all clients reaching in, but this additional information as well. Two very common ones are 003 Router and 006 DNS Servers. The 003 Router designation is essentially your default gateway setting on the client NIC. Almost all networks will have a default gateway, typically a firewall or a router, and by selecting this option you can define the default gateway address to be assigned to your DHCP clients.In Figure 4.23, you can see that I have selected 006 DNS Servers, and configured the IP addresses of the DNS servers in my lab. Now when my client computers pull IP addresses via DHCP, their NICs will also be automatically configured with these two DNS server addresses, which will cause them to be able to resolve DNS names in my environment:

Figure 4.23: Using DHCP options

Another useful DHCP scope option is option 66. If you have a VoIP phone system and want to set up some automatic provisioning of your physical phones, it is easy to create a DHCP scope just for the phones, and use option 66 to point at your phone system’s provisioning link. When phones grab an IP address from the DHCP server, they will be automatically provisioned in the phone system as well!

DHCP reservations

Assigning IP addresses from a large pool is great, but these address leases are subject to expiry and change. This means that a computer that has 10.10.10.110 today might receive 10.10.10.125 tomorrow. Typically, this is fine from a desktop computer perspective, as they don’t generally care what IP address they have. Client computers are usually reaching outward on the network, and other devices are rarely trying to find and contact them. What if you have a more permanent fixture in your network, like a Windows server, but you don’t want to have to deal with statically addressing this server? Another great example of such a device is a printer that is connected to your network. Some printers don’t even have an interface from which you could assign a static IP address, and once your printer gets a DHCP address you typically want that address to remain the same throughout the printer’s life, because you’ll be configuring computers to send their print jobs to that IP address. This is where DHCP reservations come into play. A reservation is the act of taking a single IP address within your DHCP scope and reserving it to a particular device. This device will receive the same IP address every time it connects through the DHCP server, and this particular IP address will not be handed out to any other device on your network. By using reservations inside DHCP, you can allow the DHCP server to handle the assigning of IP addresses even to your permanent servers, so that you do not have to manually configure the NICs of those servers, yet still maintain permanent IP addresses on those machines.As a quick aside, while I am using it as an example today, I want to make sure it is clear that I am not recommending for you to allow DHCP to manage IP addressing of Windows Servers in your production network. Even with DHCP reservations in play, you would be putting a lot of unnecessary reliance on the DHCP server. With all of your servers being IP addressed by DHCP, if that DHCP server goes offline or has some kind of issue, it could mean that all of your servers go offline, because they cannot figure out what IP address they are supposed to use. If DHCP goes down in an environment where servers have static IP addresses, you will certainly have client-side problems until you get things fixed, but your other servers will remain running and connected the entire time.You can see the folder called Reservations in the DHCP console. Currently, there is nothing listed here, but by right-clicking on Reservations and choosing New Reservation..., we will create one for ourselves. Let’s work once again with that WEB1 server. Right now, I have a static IP address assigned to WEB1, but I will instead create a reservation for it on the IP address 10.10.10.150:

Figure 4.24: Setting up a reservation

Whoa, whoa, whoa ... back the train up. Most of the information on this screen makes sense—a quick description of the server name and the IP address itself—but how did I come up with that MAC address? A MAC address is a network card’s physical address on the network. When your networking equipment tries to send information to a certain IP address, or, in this case, when the DHCP server needs to hand a certain IP address to a particular NIC on a server, it needs a physical identifier for that network card. So, this MAC address is something that is unique to the NIC on my WEB1 server. Every network card on your network has a unique MAC address. By logging in to my WEB1 server, I can run ipconfig /all and see the MAC address listed for my NIC right in that output, that goofy-looking combination of letters and numbers shown as Physical Address. That is where I got this information. This is how DHCP decides when to invoke reservations. If a network interface asks DHCP for an IP address, and that device’s MAC address is listed here in the reservation list, then the DHCP server will hand the reserved address back to the device every time, rather than one from the general pool:

Figure 4.25: Finding the MAC address with ipconfig /all

Now that our DHCP reservation has been created, I will head into the NIC settings on my WEB1 server, and get rid of all the static IP addressing information by choosing the option to Obtain an IP address automatically. I’ll go ahead and select the same option for DNS servers, to prove that DHCP is able to hand me both an IP address as well as DNS server info:

Figure 4.26: Removing the static IP address information

After doing that, WEB1 will reach over to the DHCP server and ask for an address, and you can see that I have now been assigned the reserved address of 10.10.10.150:

Figure 4.27: Reserving 10.10.10.150 for WEB1

This will always be the IP address of the WEB1 server from this point forward, unless I change my DHCP reservation or somehow change the MAC address of WEB1. This could possibly happen if I were to install a new NIC into WEB1.You can also create DHCP reservations for objects other than Windows devices in your network. Since all you need is the MAC address of the device (and every device with a network adapter has a MAC address), it is easy to create reservations for devices such as print servers, copy machines, security alarm systems, cameras, wireless access points, and more.

DHCP failover

There is some truth to the phrase “never too much of a good thing” in the Windows Server world. When building a production infrastructure, you want to implement redundancy everywhere that you can. With DHCP servers, you want to take great care when doing so. As we already discussed, DHCP “servers” come in many flavors. Maybe a Windows Server, maybe a firewall, maybe a wireless access point, maybe even a Raspberry Pi that an employee has been tinkering with at home and suddenly decided it would be a good idea to bring it into the office and connect it to one of your RJ45 jacks under his desk. These devices are all capable of being DHCP servers and handing out IP addresses. You will quickly discover that any device looking for an IP address, which is likely every single client computer on your network, will simply grab an IP address from whichever DHCP server it can communicate with first. Your DHCP environment must be carefully crafted, and the introduction of any DHCP server into that environment which is unplanned or unexpected is referred to as a Rogue DHCP server. These are bad news, you need to seek out and destroy them. Or maybe just find and disable them, but that sounds far less dramatic and fun.This scenario plays out in the wild all the time, where a sudden introduction of a new piece of technology wreaks havoc on your IP addressing. I saw it just a few weeks ago, where a phone vendor installed a new phone system, and the entire network went sideways. This happened because the phone system was configured out of the box to run a DHCP server, so that VoIP phones can use the phone system to find an appropriate IP address for communication. What the phone vendor failed to realize was that almost every network in the world already has DHCP running, and if their phone system suddenly starts giving IP addresses of its own choosing to any device who asks, those devices are going to be unable to communicate with anything in their normal networks. Or possibly worse, if your intentional DHCP and this rogue DHCP are both handing out IP addresses within the same scope, for example 192.168.1.x, you will be awash in IP addressing conflicts across your network.Okay, enough doom and gloom. The moral of that example is to make sure you keep a close eye on what DHCP servers are running. Make sure they are intentional, and second-guess any device that a vendor wants to plug into your network. This is always good advice for a myriad of reasons. Moving back to the topic of good and planned redundancy…Just like the creation of multiple domain controller servers creates good redundancy for Active Directory, the DHCP servers in your network can be tied together into a failover pair to create their own form of high availability. While it is true that the DHCP server role often happens to co-exist alongside the AD DS and DNS roles, this is not a requirement. You already know that it is easy to store DNS zones right inside Active Directory so there is automatic replication of zone information, but this mentality is not true of DHCP scopes.DHCP is a useful tool inside domain environments, or outside of domain environments. As such, it is not as tightly integrated a role as DNS. So when we create DHCP failover, we need to take a more manual approach, and whether or not the DHCP role happens to be hosted on top of a domain controller makes no difference.

Two DHCP servers

In a DHCP server failover environment, two DHCP servers can be configured and pointed at each other, and they will then replicate DHCP lease information between themselves, always keeping this information up to date. That way, if one DHCP server goes offline, the other can pick up the slack and continue issuing IPs and renewing the leases of those IPs.I said “two” DHCP servers above, and this is an important point of clarification. With Windows Server DHCP failover, you can only connect two DHCP servers together. No more. It is also important to note, as we progress into the world of IPv6, that DHCP failover is only intended for use with IPv4 scopes. The failover of DHCP servers would be unnecessary in the IPv6 world anyhow, as most IPv6 implementations are stateless, and the only information that DHCP needs to give to IPv6 clients are the options, which could simply be configured on multiple DHCP servers, and the clients care not from which server they pull that option information.

Hot standby mode

There are two different modes of operation that can be employed by DHCP failover: hot standby mode or load sharing mode. Hot standby, as the name indicates, is more of a primary/failover mentality. One DHCP server is primary and is always responsible for an IPv4 scope, unless it becomes unavailable. In that case, the failover DHCP server takes over until the primary can be restored.Hot standby mode is useful for branch offices that are connected back to the primary network via a WAN of some sort. The local branch offices could have their own local DHCP server that handles DHCP primarily, but if that DHCP server were to go offline, DHCP requests would reach over the WAN link and grab a lease from the standby DHCP server sitting in your main site. In this kind of deployment, you could easily configure one single DHCP server in the main site to be the hot standby for multiple branch offices, as it is easy to configure multiple scopes on a DHCP server.

Load sharing mode

Alternatively, indeed much more common, is load sharing mode. This is the default mode of operation for DHCP failover. In load sharing mode, two DHCP servers are configured with the same scope of information and then both service incoming clients. In doing so, they share the load between servers, both responding and also replicating information between themselves, so both are always aware of which IP addresses have been handed out to clients.In load sharing mode, you want both DHCP servers to be located in the same physical site. They need to have very fast communication between them to keep replication data straight. I have seen DHCP failover configured across sites before, and can tell you definitively that it causes IP conflicts and similar issues. Keep them in the same site.

Configuring DHCP failover

Now we know about DHCP failover, how do we set it up? You already know that I have DC1 and DC2 in my test lab environment. Both servers are already domain controllers and DNS servers, though those facts have no bearing on DHCP configuration. These could be domain controllers, or simply domain-joined servers, or even non-domain-joined servers, and DHCP would have all of the same options for failover. Since I already have these two servers available to me, I am going to use them to create a DHCP scope that is replicated between both. This is an important point to clarify, that DHCP failover is configured on a per-scope basis. You don’t necessarily tie DC1 and DC2 together, but rather inside the DHCP scope properties you establish failover between DC1 and DC2 for a particular scope (or scopes). This implies, then, that you have the ability to create DHCP scopes that are running in failover mode, and additionally create DHCP scopes on those same servers that are not doing any form of failover.

Make sure the clocks are in sync! If your DHCP servers are domain-joined, their clocks should always be kept in sync automatically by Active Directory. If your DHCP servers are not domain-joined, you will want to ensure that the system clocks on both servers are using the same time source to always retain continuity.

DC1 already has the DHCP role installed, and we created a scope on it together, so that my Win10 client computer could grab a DHCP address and communicate with the rest of my network. DC2, however, does not yet have the DHCP role installed, so the first step is to go ahead and add that role.Whenever creating new DHCP servers in a network, the role must be installed of course, but there is a second critical piece of the puzzle to enable them to be recognized as DHCP servers. It is fairly obvious, but after installing the DHCP role onto a server, Server Manager will prompt you to Complete DHCP configuration. This pulls up a small wizard with basically just one step to accomplish—Authorize your new DHCP server. This mini-wizard can be called via Server Manager immediately following role installation, or if you missed the prompt there and opened up right into the DHCP management tool, you can alternatively authorize a DHCP server by right-clicking on the server name inside the DHCP management tool, and then selecting Authorize. One way is not better than the other, the point is that each of your DHCP servers must be authorized before they can do anything.OK, we now have two authorized DHCP servers in our environment, and a scope is already present on DC1. This scope is servicing clients already, handing out IP addresses in our network. Creating failover for this scope is quite easy. Open up DHCP management on DC1, and navigate to find your IPv4 scope. Right-click on the scope itself, and select Configure Failover…:

Figure 4.28: Configuring DHCP failover

Next, select which scopes you want to configure in failover. As I mentioned before, DHCP failover con- figuration is individual per DHCP scope. If your DHCP server has multiple scopes already established, you can select to configure failover on any or all of them. Then on the second screen, we need to define the failover DHCP server. You can type out the name of the server on this screen, but what I like to do is click that Add Server button, which then displays any servers in your environment that are recognized as authorized DHCP servers. By using the button and then selecting the second DHCP server from the list, it gives you one more validation that you have properly authorized the second server, DC2 in my case, in your network. You can see this in Figure 4.29:

Figure 4.29: Selecting DC2 for DHCP failover

On the following screen of this wizard, we define all of the relationship parameters between the two DHCP servers. As you can see in our next screenshot, this is the screen where you define simple things that don’t have too much impact such as Relationship Name and creating a Shared Secret that the two DHCP servers will use to interact with each other, but this screen is also where you create the definition of which type of failover is happening for this scope. We have already talked about Load balance mode and Hot standby mode, and here is where you would additionally define, in Load balance mode, what weights to assign the two servers for establishing that load balancing.Unless you have a particular reason to deviate, the default settings are generally what you want. Make sure that Maximum Client Lead Time remains configured at one hour or more. You may bump that number down smaller for testing failover in your network, but in a production environment one hour is the general recommendation:

Figure 4.30: Configuring failover relationship settings

That’s it! Click Next a couple more times, and your DHCP failover configuration will be pushed out to the second DHCP server. Now, if one of these servers were to go offline or have some kind of issue, DHCP clients coming in fresh or whose DHCP leases are expiring will be able to acquire a lease from either DHCP server.Now that DHCP failover has been established, you would sort of expect something inside the DHCP management console to have changed to visually indicate to us that there is failover configured on the scope, but that is not really the case. Everything in here looks exactly the same as before failover creation. I point this out to let you know that during future visits to this console, or if you are a new admin to an existing infrastructure and want to quickly identify whether or not DHCP failover is established in your environment, you can find this information by right-clicking on each scope. In the menu list that is displayed with that right-click, you will now find an option to Deconfigure Failover, which implies that failover is currently configured for this scope. Additionally, if you head into the properties of that scope, you will find a Failover tab that displays all pertinent information about DHCP failover:

Figure 4.31: Deconfiguring failover

One last verification, let’s log into DC2 and see what the DHCP management console looks like now! Remember that previously the only thing I have done on DC2 is to install the DHCP role and to authorize this server. I have never even opened the DHCP management console on this second server. If I do so now, you can see that my 10.10.10.0 scope has been replicated over to this server, including the current address lease information!

Figure 4.32: The 10.10.10.0 scope is now replicated to DC2

IPAM

The IP Address Management (IPAM) feature built into Windows Server 2025 is overlooked by many server administrators because it is a feature and not a full-blown role inside Windows. IPAM is a technology that allows centralized monitoring and management of DHCP and DNS in your environment. If all of your infrastructure is sitting inside one building, it is easy enough to simply use the DNS and DHCP management tools from any server or workstation in your network and have full control over both of those technologies. But how about larger and enterprise-class networks that span many locations, each with its own sets of DNS and DHCP servers? IPAM is useful for gathering up all those differing namespaces and scopes and providing access to them from one interface.Let’s install the IPAM feature in my lab so you have an idea of where to start, should you choose to explore or employ this feature. Begin by choosing a server upon which you want to install IPAM, and simply walk through the Add Roles and Features Wizard to add the feature called IP Address Management (IPAM) Server.

It is not recommended to install IPAM onto a domain controller, or onto a DHCP server as that will hinder its ability to acquire information from these systems.

Now that the feature is installed, launching Server Manager will display a new section in the left window pane called IPAM. Go ahead and click on IPAM, and you are presented with a series of six tasks that need to be accomplished in order to use IPAM:

Figure 4.33: IPAM server tasks

The first step is already finished, we are connected to the IPAM server. In my lab, I installed IPAM on my WEB1 server, but not for any particular reason. You could dedicate a server to this task or install the feature onto an existing server.Moving on to step 2, Provision the IPAM server, you will have a chance to read over some good descriptive text about how IPAM plans to interact with your servers. You have the option of manually configuring each server (who’s going to do that?) but clearly the way Microsoft expects most of us to centrally roll this out is through the use of Group Policy. We discuss Group Policy in the next chapter of this book, but for the purpose of setting up IPAM we can pretty much just flow through these configuration wizards, selecting the default settings, and understand that under the hood this console is establishing GPOs for us, which will then be pushed down to the servers in our network to configure them for reporting into IPAM.The only selections that need to be made inside step 2 are what database for IPAM to utilize, and which provisioning method should be used to send IPAM settings out to your servers. For the database, if you have a SQL server you may certainly use it to store IPAM information, but the default selection is Windows Internal Database (WID), which is a built-in database platform used by many of the Windows Server roles and features. We will utilize WID for this new IPAM server, and as we already mentioned, the rolling out of IPAM settings to other servers in your environment is easily accomplished via Group Policy.As a sidenote on WID itself, the Windows Internal Database has recently been added to Microsoft’s “no longer developing” list. This means that WID is still 100% a valid technology inside Windows Server 2025, and they even declare that it is used by roles such as ADFS, ADRMS, IPAM, RD Broker, and WSUS. However, at some point in the future WID will likely be removed from Windows Server, and at that point in time if you were facing the decision to install something like IPAM, you would either need to choose a then-older platform (like Server 2025) to run it, or change gears on database selection. Rather than using the internal WID you could, instead, install the free version of SQL to serve this need. On the screen where you select Group Policy Based as the provisioning method, you will also need to define a GPO name prefix. When this console reaches into Active Directory and creates the GPOs needed for IPAM to work, it will define names for the GPOs and those names cannot be altered, but what Microsoft allows here is for you to assign a prefix to those GPO names, so that when you later look inside the Group Policy management tool, all of the GPO configurations related to IPAM will be listed together, all having the same prefix that you define on this screen:

Figure 4.34: Using GPOs to implement IPAM

You’ll notice a little informational text in Figure 4.34, as well as on the summary screen when you finish step 2, regarding a PowerShell cmdlet called Invoke-IpamGpoProvisioning. Common sense would tell us that after step 2 in the IPAM implementation, you would move on to step 3, right? Actually not in this case. Configuring server discovery (step 3) is a step that we need to take soon, but at this point the IPAM console is waiting for those GPOs to be created so that they can be used and referenced during the rest of the setup process.Pause on your work inside the IPAM steps, and open an administrative PowerShell or Terminal prompt, making sure that you are logged in to your server with a domain admin account. Then simply run Invoke-IpamGpoProvisioning. This will ask you to key in the name of your domain, as well as that GPOPrefixName you specified during the wizard; be sure to type it in exactly the same!

Figure 4.35: Running Invoke-IpamGpoProvisioning

You will be required to enter Y and press Enter three times to finish through this command. In reading the warning text that is being displayed, the same text three times in a row, this is asking you for confirmation simply because when these three GPOs are being created, their security filtering settings are being modified away from default GPO security filtering behavior. We will explain GPO security filtering soon, but for IPAM’s purposes, simply type Y and continue through these prompts. Now that Invoke-IpamGpoProvisioning has done its work, if we sneak a quick peek into the Group Policy Management console, you can see that there are three new GPOs that did not exist a minute ago:

Figure 4.36: Invoke-IpamGpoProvisioning has created three new GPOs

Now back inside IPAM configuration on WEB1, we will go ahead and click on step 3, Configure Server Discovery. Inside, use the Get forests and Add buttons to query your domain for infrastructure services that can be monitored by IPAM. Your domain should be listed, with checkboxes selected on the components that the wizard was able to discover about your domain. In my case, I have discovered all three—Domain controller, DHCP server, and DNS server. I will leave all three checked so that IPAM can pull data about these roles and click OK:

Figure 4.37: Configuring server discovery

Move on to step 4, Start server discovery. This launches a scheduled task in the background that is reaching out and discovering additional information about your infrastructure. Once finished, click on step 5, Select or add servers to manage and verify IPAM access. Here you should see the servers listed that are hosting your AD DS, DNS, and DHCP roles. Right-click on each server that you want to manage, and then select Edit Server…. Inside this screen, for each server, change the server’s Manageability status field to Managed:

Figure 4.38: Setting IPAM to manage these servers

Finally, click on step 6, Retrieve data from managed servers, which will set the GPOs into action and start pulling information from those servers into the IPAM database. When finished, you will now have a centralized interface from which you can view information about Active Directory, DNS, and DHCP scopes, as you can see in Figure 4.39:

Figure 4.39: IPAM’s centralized interface

Management of DHCP from within IPAM is particularly useful, as classic administration of DHCP from within its own management console can get pretty messy in an environment with many different DHCP scopes. IPAM provides an interface from which you can quickly and easily see information about all scopes together, and even run some fun PowerShell cmdlets to quickly gather data that would have otherwise taken manual poking and prodding to discover in the past:

Find-IpamFreeSubnet

Add-IpamSubnet

Find-IpamFreeRange (this one is nice because it helps you to quickly discover a range of avail- able IP addresses)

Add-IpamRange

Summary

The Microsoft core stack of infrastructure technologies generally consists of Active Directory, DNS, and DHCP—and often you will find all three of these housed on the same servers. Understanding these technologies and knowing how to utilize their associated toolsets is an essential part of any server administrator’s life. A Microsoft centric network running Windows Servers almost guarantees that this network is built upon Active Directory and DNS. As a manager in an IT company, I will tell you with surety that having a grasp on these concepts and tools will greatly improve your chances of landing that sysadmin role you’ve been seeking.I hope these last two chapters have been beneficial to your overall understanding of the ways that companies make use of Windows Server technology and have given you something to help prepare for IT life in a business setting. Next, we turn to another baked-in component of any Active Directory-focused environment, but one that is often underutilized. Group Policy is an amazingly powerful tool that can be used to enhance security and create automation inside any domain.

Questions

Which kind of DNS record directs email flow?

Which type of DNS record resolves a name to an IPv6 address?

Which DNS zone type resolves IP addresses backward into hostnames?

Which DHCP option is often used for VoIP phone provisioning?

Which mode of DHCP failover is often used between branch offices and a primary site?

What is the standard recommendation and default setting for Maximum Client Lead Time when configuring load balanced DHCP failover?

Which Windows Server roles can IPAM tap into?

What does the ingenious acronym “DoH” stand for?

5 Group Policy

Join our book community on Discord

https://packt.link/zYovfIf you find yourself reading this book from front to back, indeed a good and not at all weird way to read a book, you already have a general idea of what Group Policy is and does (because we talked about it in Chapter 3, Active Directory). However, I’ve been around IT folks long enough to know that reading a book from cover to cover is rare, and attention spans rarely accommodate such a quest. Therefore, any of you hitting up this chapter in a random fashion because the words “Group Policy” drew your attention or you have a specific need that you are hoping to be answered in this chapter, fear not! Let’s again summarize the great and glorious power of Group Policy.It’s easy to understand the general use of the word “policy,” meaning some kind of ruleset, structure, or standard to which you need something to adhere. In our case, we’re talking about Microsoft Windows-based computers (and servers). Applying policies to computers, such as security policies, application policies, or printer policies, sounds like a great idea. If applying policies to a computer is great, applying policies to a group of computers must be even better, hence the term “Group Policy.” In a nutshell, Group Policy is a centralized way to issue policies to groups of users or computers inside your domain network. “Domain” is a key word here, as Group Policy can only identify and manipulate users or computers if they are part of your Active Directory domain. Here’s a quick list of the topics we plan to cover together:

Group Policy Objects

Building a GPO (a few, actually!)

Scoping a GPO

Computer settings and user settings

Policy versus preference

Default Domain Policy

Administrative Templates

The Central Store

Group Policy Objects

The overlying technology we are talking about here is called Group Policy, and an individual instance of a Group Policy is known as a Group Policy Object, commonly referred to as a GPO.A GPO is a single package that contains one or many policy settings and applies to a domain computer, a domain user, or sometimes many computers and users all at the same time.GPOs are stored inside Active Directory and are replicated among your domain controller servers. Every time a domain user logs into a domain-joined computer that is connected to your network, the computer reaches out to Active Directory and asks, “Hey, got any GPO settings for me?” Then a whole slew of activity commences as a domain controller hands over all of the GPO settings that it contains that apply to the computer and/or user logging in. This is a key piece of information. GPOs are scoped upon creation, giving you the power to define to whom each policy is applied. Extremely powerful stuff. These policy settings then plug themselves into place on your computer, forcing certain things to happen (or not happen) at the discretion of your IT department. You can lock down settings, force settings into place, or even configure default settings while still allowing users to override them. You can throw certain settings at some computers and completely opposite settings at others. You could even apply conflicting GPOs to the same computers and sit back and watch them fight to see who comes out as the winner in the end. If you don’t understand how Group Policy works, it is very easy to cause huge problems in your network, as it is very, very easy to apply settings to every machine in the domain. A single GPO has the potential to bring your entire network to its knees if misused.So… that’s reassuring, right? Trust me, while Group Policy comes with a warning label and “with great power comes great responsibility” and all that, you will want to use GPOs more than you are now after seeing all that they can do.

Group Policy background refresh cycle

I mentioned that Group Policy processes through its list of rules and settings on your domain-joined computers every time a user logs in, and that is true. What is also true is that Group Policy reprocesses itself at intervals throughout the day, even while the user remains logged in. By default, and almost nobody changes it, something called a background refresh happens every 90 minutes. This means that implementing new GPOs during the day generally works fine because those settings will roll into place even without users needing to log off or restart their computers. There are exceptions to this, though, as some GPO settings are unable to process as background cycles and can only take effect during the login process. Some examples of such GPOs are a login script (which can only run during logon or logoff of a computer) or even something like a mapped network drive. Some GPOs will only push themselves into place during the user login process.Many times I find myself testing GPO settings as I make changes to them, and it would make for a very inefficient workday if I had to wait 90 minutes or restart my test computer after every little tweak or change to a GPO. Thankfully, we have a quick and easy command-line tool that can be used to force Group Policy to reach out and do its thing, any time of any day!

gpupdate /force

Running this command inside Command Prompt or PowerShell on a domain-joined client computer will cause it to immediately reach out and grab updated GPO settings. Keep in mind, your computer does need to be able to contact a domain controller for Group Policy to process, so this isn’t going to work if your work laptop is sitting in your house and not connected via VPN.But for any computers inside the office or in some way connected to your corporate network, you can run gpupdate all the live-long day and continually roll new policies and changes into place.

Building a GPO

There’s nothing quite as satisfying as jumping in and getting your hands dirty, so let’s get down to business and build a new GPO. Don’t worry, we will be careful not to apply this GPO to anything yet and save that for the next section. As with most Microsoft technologies, there is a special management console in Windows Server, solely for the purpose of interacting with Group Policy, appropriately named the Group Policy Management Console (GPMC). Logging into any of your domain controller servers, you can launch the GPMC from inside Administrative Tools, inside the Tools menu of Server Manager, or by launching GPMC.MSC from Start | Run, Command Prompt, Terminal or PowerShell:

Figure 5.1: GPMC

You’ll notice in Figure 5.1 that there are already some GPOs listed here. They are a combination of default GPOs that always exist when you install Active Directory (we’ll talk about the Default Domain Policy a little later in this chapter) and the IPAM GPOs that the IPAM configuration process put into place for us in Chapter 4, DNS and DHCP. To create a new GPO in a way that does not yet apply to any workstations or users, right-click on the Group Policy Objects folder and select New. Create a name for your new GPO, click OK, and you have created a Group Policy Object! So far, your new GPO is void of any settings or configurations, and it does not apply to anything or anybody, so it is precisely pointless. We will soon change that…

Adding Trusted Sites

I named my first GPO Trusted Sites because I am going to use this new GPO to cause some URLs to be recognized as trusted sites inside Windows on my Windows 10 and 11 computers. Anyone who recognizes the term “Trusted Sites” might wonder whether, in the year 2025, I am actually going to travel the road of pushing configurations into Internet Explorer properties. Yes, indeed! Even though Internet Explorer itself is effectively dead and has been replaced by Edge for web browsing purposes, IE was so tightly integrated into Windows code that there are still many occasions where manipulation of IE settings changes behavior or enables certain functions within Windows itself. Only a couple of weeks ago I helped an engineer create a GPO exactly like this, because a line-of-business application at a customer would not work properly unless a handful of URLs were plugged into Internet Explorer Trusted Site settings, even though that company does not use Internet Explorer. Sometimes these applications might be trying to run JavaScript or ActiveX controls or something like that, which would be one reason you may find yourself continuing to visit IE security settings on your client computers.When tasked with a change that needs to take place on all of your user’s computers, you could remain reactive and print off an instructions page for the helpdesk on how to do this on each computer, and ask them to spend the time doing it manually for every user who calls in because they cannot access the application. Or you can get smart and proactive, and create a GPO that makes these changes for you automatically on every workstation to save yourself from dealing with all of those phone calls. This is just one tiny example of the power that Group Policy possesses, but it’s a good example because it is useful, and it is a setting that is buried way down in the GPO settings, so you can get a feel for just how deep these capabilities go.Right-click on the new GPO and choose Edit… Now navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Internet Explorer | Internet Control Panel | Security Page. See, I told you it was buried in there!

Figure 5.2: Creating a GPO to manage trusted websites

Now double-click on Site to Zone Assignment List and set it to Enabled. This allows you to click on the Show... button, within which you can enter websites and give them zone assignments. Each GPO setting has a nice descriptive text to accompany it, telling you exactly what that particular setting is for and what the options mean. As you can see in the text for this one, in order to set my websites to be trusted sites, I need to give them a zone assignment value of 2. And, just for fun, I also added a site that I do not want to be accessible to my users and gave it a zone value of 4 so that badsite.contoso.com is a member of the restricted sites zone on all of my desktop computers.Here is my completed list:

Figure 5.3: Assigning websites to different zones

Are we done? Almost. As soon as I click on the OK button, these settings are now stored in my GPO and are ready to be deployed. As you know, we have not yet done any work to assign this new GPO to any users or computers, so for now the GPO is populated with these settings but still doing nothing. Before we push out these settings, let’s build out a few more common GPOs to make sure our examples here are well-rounded.

Mapping network drives

File servers are some of the most common types of servers that exist because all companies across all industries need to create and maintain documentation to run their businesses. This is not a chapter about how to build a file server, set up shares, restrict permissions, or utilize a Distributed File System (DFS) to improve the overall flexibility and resiliency of your file server infrastructure, although these are all good things to learn and we will do exactly that in Chapter 6, File Management. Until we get to that chapter, I have created a couple of really simple shared folders in my test lab that we will make use of:

\\DC1\HR

\\DC2\Accounting

\\WEB3\Installers

Our challenge today is to automate the mapping of these locations on all user workstations in my environment. I could put together a piece of documentation that shows users how to manually get to these locations by using UNC paths plugged into the address bar of File Explorer. Or maybe even take it a step further and show my folks how to map network drives from inside File Explorer so that they end up with drive letters assigned on their computers for ongoing access to these locations. Doing so would work, but it would put an administrative burden on my users and also lead to the possibility of users having differing drive letters. Grace might use her “R” drive letter to map to the accounting share, while Jackson may decide that “T” is his accounting drive letter of choice. If this were to happen, someday one user may send a sharing link to the other that is based on their drive letter location, and that link would fail to open for the recipient. This and many more complications arise if you grant users the ability to map their own network drives.Obviously, there is a better way to handle this situation. One of the very common chores we task to a GPO is the standardized creation of mapped network drives on client computers. Inside a new GPO, we can define UNC paths for shares and assign drive letters to them. We can then assign that GPO to users and computers, and drive letters will magically map when your users log in to their computers.Create a new GPO for this purpose, and edit that GPO, as you already know how to do it. This time, we are navigating to the following location:User Configuration | Preferences | Windows Settings | Drive MapsRight-clicking on Drive Maps and choosing New | Mapped Drive brings you into the configuration section for a single mapped drive letter. You can see in the screenshot below that I am mapping a drive to \\DC1\HR, and assigning it a drive letter of H:

Figure 5.4: Mapping drives with Group Policy

You’ll notice the Action dropdown menu has four different options: Create, Replace, Update, and Delete. This series of options is commonly referred to as CRUD, which is hilarious. What is no joke, however, is the important distinction between these options and that you absolutely must understand how they work if you are going to create successful GPOs.Many GPO preference configurations contain this same CRUD drop-down selection. Here is a quick summary of each available option as it relates to our new drive-mapping policy:

Create: Use this action to create the new mapped drive only if it does not already exist. If the H: drive is already in use on a workstation, this new mapping will then be ignored. In our example, if I were to configure this new drive mapping for Create, it would only take an action if the H: drive letter was currently open and available.

Replace: Use this action to remove an existing setting and replace it with a new setting. In our case, it will update whatever mapped drive is using H: to our \\DC1\HR. For drive mappings, the Replace option is redundant because the Update option does effectively the same. However, other GPO preferences that you push out, a connection to a new printer perhaps, could make more effective use of the Replace selection.

Update: This is the default action for most preference settings and is generally the most useful. If the setting that we are configuring (H: drive) doesn’t exist, Update will create it. Additionally, if the setting (H: drive) is already in place on the workstation, it will now be updated to reflect our new definition inside the GPO. Drive mapping policies almost always use the Update action to push new drive letters into place.

Delete: This removes the specific setting from the client machine. If you are removing a network share and want to ensure that it is removed from all of the computers in your domain, this would be a useful action to ensure that happens.

Before clicking OK on this new drive mapping, go ahead and visit the Common tab. This tab and its five options are commonly shown on many preference settings that you plug into a GPO. Most of these are self-explanatory, though we will discuss item-level targeting more in just a few pages. For our drive-mapping GPO, I like to point out the Run in logged-on user’s security context checkbox. This tells Group Policy to run whatever setting or preference the GPO is putting into place under the logged-in user’s account. For mapped drives, this is particularly useful because you typically want users to interface with their mapped drives in their regular user context.While it is not common to check this box for most GPO settings, for drive-mapping GPOs, I always do:

Figure 5.5: Map drives under user’s security context

Rinse and repeat for any additional drive letters that you want to include in your new GPO, and you are now well on your way to automating the mapping of all drive letters across your entire network! I set up drive letter mappings for each of my shared folders and also included a GPO setting to delete the Z: drive if it exists.There has never been a Z: drive in my test lab, but here you can see what a drive deletion looks like inside the policy:

Figure 5.6: Mapped drives via GPO

Once again, this new GPO is now filled with settings but does not apply to any users yet. Never fear – once we finish creating a few more example GPOs, we will move on to scoping GPO settings, which is where we will push the new GPOs into action and verify that settings and mapped drives show up automatically on our client computers.

Installing registry keys

In much the same way that mapped network drives can be pushed to users via GPO, we can implement registry keys and values on computers automatically as well. This is spectacularly powerful because almost anything within a Windows environment can be manipulated by using registry keys. Create yet another new GPO and this time, navigate to the following location:User Configuration | Preferences | Windows Settings | RegistryCreating, replacing, updating, or deleting registry keys flows in very much the same fashion as it does for mapping network drives. The tricky bit is making sure that the options are specified properly, or they won’t work, particularly the Key Path and Value information. For our example, I am going to push a registry value that prevents users from being able to change their desktop background image and specifies a custom desktop background of my own.In my experience, the easiest way to ensure that a GPO-based registry setting is configured properly within the GPO is to manually edit the registry first, placing the new registry key and/or value that you are working with on the server or computer from which you are running the GPMC. When you click the ellipsis button shown in Figure 5.7, you will then be able to successfully navigate directly to this regkey and simply select it, instead of worrying about whether you are typing the syntax correctly to make the Key Path field happy.Keep in mind, GPMC is similar to any other Windows Server administrative console, in that you can use it directly from a Domain Controller or from another server or even from a Windows client workstation where you have installed the RSAT tools. Be very careful not to manually chop up the registry too much on a Domain Controller, simply because you are using it as the point from which you are editing GPOs. It is much smarter to setup the needed registry key on a client workstation and run GPMC from there, in which case you are not touching the registry on your Domain Controller at all.The registry information that I am putting into place is: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System Inside the system registry key, the registry value name is Wallpaper. Here is my populated entry inside Group Policy:

Figure 5.7: Adding registry keys via Group Policy

Because I have selected this registry value to be pushed as an Update action, every time that Group Policy processes on this computer, it is going to ensure that this registry key is present, thus continually preventing users from being able to adjust their desktop wallpaper.I chose this example because it is straightforward and because often in Group Policy you will find that there are multiple ways to accomplish the same thing. Instead of using a registry value to lock down wallpaper settings, I could have alternatively created a GPO that utilized the following GPO setting, and it would have accomplished the same thing without having to touch registry settings:User Configuration | Policies | Administrative Templates | Desktop | Desktop | Desktop Wallpaper

Prevent shut down of system

It is very common to utilize GPOs to push security lockdown parameters to computers or servers. Many corporations use Remote Desktop Servers to provide virtual desktops for users to log in to. When users work inside an RDS session, they are navigating keyboard and mouse from their computers, but everything they work on or click on happens inside a multi-user server environment. If these users were to do something like shut down the server, even accidentally, that would have an enormously negative impact on other users of that server. The same type of logic could apply to common-use kiosk workstations, perhaps shared computers that are often accessed by a myriad of employees. There are many common lockdown restrictions for these types of environments, but one that I often find to be in place is a policy setting that prevents users from being able to shut down the computer they are logged in to.Creating another GPO, or editing an existing one to implement this restriction alongside settings that already apply to your kiosk machines or RDS servers or to whichever machines you want to apply this policy, navigate to the following location:Computer Configuration (or User Configuration) | Policies | Administrative Templates | Start Menu and TaskbarNow seek out the setting called Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate commands. Double-click this setting and flip it to Enabled.

Figure 5.8: GPO to prevent shut down or restart

Once enabled, this is a simple single-action policy restriction that will prevent select users from being able to shut down computers or servers within your domain environment. To which computers or users this policy applies has not yet been determined, as we still have not discussed how to properly scope a GPO. Never fear, that information is soon to come! Once this GPO is applied, if a user were to attempt to shut down a computer, they would no longer see the option to be able to do so. In fact, this policy is not only a graphical update to hide away the button. Even if the user were IT-smart enough to attempt something like pressing Alt + F4 at the desktop or initiating a shutdown via command prompt, they would be prevented from doing so.

Figure 5.9: User is prevented from shutting down the system

While this Group Policy setting is a great way to keep 99% of your users from accidentally or intentionally shutting down or restarting an RDS server, this setting is technically a “Start Menu and Taskbar” setting. What this is really doing is hiding away options for the user to interact with GUI tools for shut down or restart functions, it does not block the shutdown commands. If an end user were savvy enough to launch Command Prompt or PowerShell and throw some commands around, they could still reboot an RDS server if they really wanted to. These types of users are a little outside the scope of my example here, but if you find yourself with problematic end-users who are bent on doing things they shouldn’t be doing, there are many more restrictive options available to push with local security or GPO-based policies.

Disable removable USB drives

Have you ever heard of the Dropped Drive Experiment? Originally implemented by penetration testers, it is an extremely creative way of testing your workforce to find out how security-savvy they are. You may or may not know that plugging an unknown USB stick into your computer is risky business. There are many viruses and attacks that can be accomplished by simply convincing a user to plug an infected USB drive into their computer. The user doesn’t even need to click on anything to be compromised, the act of plugging that USB stick into your computer is all it takes. The premise of the Dropped Drive Experiment is simply to load USB sticks with malicious software, drop one or more in a company parking lot, and see what happens. Chances are people are going to find these USB sticks and plug them into their computers to see what is on them. At that point it is too late, the attacker already has control of your system and your information.If ever you find a USB stick sitting on the ground, or even if a vendor hands you one as a fancy way of providing marketing materials about their business during a trade show, there is only one appropriate action to take with these USB sticks: throw them in the garbage.Can you send an email to your staff and inform them of this risk? Sure. Can you ask them to never plug USB drives into their computers? Sure. Will they actually listen? I can almost guarantee they won’t. Protection against this scenario is what our next example of a GPO setting is all about. Flip one simple switch inside a GPO that applies to all your domain computers, and you provide immediate protection to your business against this very real vulnerability.Computer Configuration | Policies | Administrative Templates | System | Removable Storage Access | All removable storage classes: Deny all accessesEnable this option, and you’re good to go.

Adding a shortcut to the desktop

Let’s walk through one more sample GPO before moving on to the next section. A fairly common ticket we see on support desks goes something like this: “Could you push out an icon to everybody’s computer for such-and-such?” Now, some companies will have their own RMM toolsets from which you may be able to accomplish this task in a myriad of ways, but we are limited to a simple test lab with a couple of Windows Servers. Can we do this?Computer Configuration or User Configuration | Preferences | Windows Settings | ShortcutsSimilar to the way that you craft a new network drive mapping, printer, or registry key, create a new shortcut here and define the necessary properties. You can see in Figure 5.10 that my new icon is going to be a shortcut pointing to a URL, which will land my users onto our company’s Intranet website. After configuring this GPO and scoping it to apply to all domain-joined computers in my network, this is now my guarantee that a link to our company Intranet site will exist on everybody’s computers, even new computers that are deployed in the future!

Figure 5.10: Pushing out a desktop shortcut to all computers

Today we sent out a URL shortcut to everyone’s Desktop, but you could just as easily send out a shortcut pointing to an application executable and store that icon somewhere else, such as the Quick Launch Toolbar or even inside the All Users Startup folder. The ability to centrally control shortcuts can be a powerful one.

Scoping a GPO

I briefly mentioned the ability to scope GPOs, which is the ability to determine what GPO settings need to apply to what computers or users in your environment. This is probably the single most important piece of the Group Policy puzzle to understand and lock into memory. You have already seen a few examples of plugging settings into GPOs, and information is abundant on the internet with useful and exact policy settings and how to put those into place. If there is some particular task you are trying to accomplish on a large scale, turn to search engines and look for that item while including the search word GPO, and you’ll quickly find information about how to set up your new GPO to do that thing.What those articles, Microsoft documents, and blog posts are not going to define for you is to what extent you push those settings into your network, and how to ensure your new GPO is not too far-reaching. That decision is yours alone. In this section, we will discuss the different options available within every GPO that allow you to pinpoint very specific details about who should or should not receive those GPO settings.

Links

A GPO link is arguably the most important tool in your Group Policy toolbox. Links simply take a GPO and bind it to a location in Active Directory. The GPO that you have now linked will start applying its contained settings to users and devices that are within that location.We have created multiple GPOs inside Group Policy but have not yet applied them to anything. What this means is that we have not yet linked those GPOs to anything, and when we do, that is when they will be set loose and start doing their work. Before we link one of our new GPOs, let’s take a look at which GPOs currently apply to my Windows 10 computer. That way, we can check again after creating our link to prove to ourselves that the new GPO is doing something.

Gpresult

So far, we haven’t talked at all about how to check individual machines to discover what policies may or may not apply to them. Let’s take a break from configuration and do that now. Logging into my Windows 10 client machine, I can open Command Prompt, PowerShell, or Terminal and run the following:

Gpresult /r

This spits out quite a bit of interesting information, but what we are most interested in here is the section called Applied Group Policy Objects. In fact, you may notice that there are two sections to this output and find two instances of Applied Group Policy Objects. One will be listed beneath COMPUTER SETTINGS, and the other under USER SETTINGS. Shortly, we will describe the differences between computer and user settings within a GPO, but for our example now, I want to point out that the output on my test client shows us that no GPOs are being applied at the User Settings level, as you can see in Figure 5.11:

Figure 5.11: No GPOs applied to the user

After becoming more familiar with Group Policy, you may often find yourself running gpresult and wanting to narrow down the results to either computer or user settings. You can easily do this by adding a switch to your gpresult command:

Gpresult /r /scope computer Gpresult /r /scope user

Continuing with the link

Back inside the GPMC, find the location to which you want to link your new GPO. I am going to link my Drive Mappings GPO and prove to you that all of my mapped network drives are created automatically during my next login to a workstation. The user account I am logging in with resides inside an OU called Accounting Users. Seeking out the Accounting Users OU, I right-click on it and choose the Link an Existing GPO… option. On the screen that follows, find your newly created GPO and select it. You have now linked the GPO to this specific OU, and this change immediately takes effect in your network. You can see in Figure 5.12 that my GPO link is displayed under the Accounting Users OU:

Figure 5.12: Linking a GPO to the Accounting Users OU

The next time users inside this OU log in to a domain-joined computer, their network drives should be mapped for them during the login process.Logging in to my Windows 10 workstation, I now find that to be true and running gpresult /r again proves that my GPO has successfully been applied!

Figure 5.13: GPO has been successfully implemented

You can link a GPO to more than one OU. Just follow the same process again, this time choosing a different OU to make the link, and that GPO will now apply to both OUs that have active links. You can remove links by right-clicking on them and deleting them (don’t worry, deleting a GPO link does not delete the GPO), or by clicking on the Group Policy Object itself to view and modify its link properties.

Group Policy processing order

In the GPO linking example that was just completed, we linked a GPO to a specific OU. You probably noticed in some of the screenshots that there are GPOs linked at different levels too, like right at the root of my contoso.local domain. What’s that all about? As it turns out, when logging in to a computer, there are four different levels of Group Policy processing that happen. The location of your links can make a big difference to the proper effect your GPO has on your computers and users. Let’s discuss these four levels of GPO processing.

Local Policy

Assuming you have worked in IT for a little while, it is very likely that you have followed a blog post or forum that has led you to a modification via gpedit.msc. Running gpedit.msc on any Windows system brings you into the Local Group Policy Editor. This is the set of policy objects and settings that exist on an individual machine. They can be manipulated manually via gpedit.msc or they can be manipulated and overwritten by GPOs.The key point that I want to make is that when your Windows computer boots and logs in, the very first thing that happens is that settings inside the Local Group Policy Editor are processed. Since Local Policy is first to apply, it means that any levels of Active Directory Group Policy, which we are about to discuss, will take priority over Local Policy. In other words, your computer may have Local Policy settings in place, but milliseconds later during the boot process, those local settings could be overwritten by AD policy settings.

Site-level policies

Remember back in Chapter 3, Active Directory, when we discussed Active Directory Sites and Services? That comes into play here. If your environment is large enough to contain multiple sites, it is possible to link GPOs at an individual site level, thus enabling Group Policy to issue settings to computers or users based on which site they reside within.Having GPOs linked to sites is quite a rare occurrence in my experience, but it is something to keep in the back of your mind when troubleshooting GPO applications. Computers and users will only receive site-level policies when they physically reside within those sites, based on the IP addressing scheme and subnets you defined inside AD Sites and Services. If a computer is handed GPO settings based on a site-level link, and these settings contradict what is in Local Group Policy, the site-level policies will override the Local Policy, and these will be the new settings as you continue the login process.

Domain-level policies

Some policies and settings are going to be things that you want to apply to all machines or users in an entire domain, and the appropriate place for those settings is domain-level GPOs. As we talk about all these different policy levels, it’s important to point out that the GPOs themselves are not different. A GPO is a GPO. The level at which the GPO is linked is what we are discussing in relation to these hierarchical levels.Links created at the root, or top level, of a domain inside Group Policy Management will by default attempt to apply to any user or computer that is part of the domain. There are many other factors that can filter domain-linked GPOs, but for the most part, if you link a GPO to the domain name, you had better be okay with the settings inside that GPO applying to potentially every workstation, every server, and every user. If you peek back a few pages at some of the screenshots from inside the GPMC, you can see that my IPAM GPOs are all linked directly to contoso.local. These are known as domain-level links.Pretending that we are still flowing through a computer login process with these examples, domain-level policies apply after site-level policies. So any settings that came down to you via site-level policies have now been added to, or potentially overridden by (if there was a conflict), our domain-level policies.

OU-level policies

We started our login journey with Local Group Policy settings, which were then added to or overwritten by site-level GPOs, and those were then added onto again (or overwritten again in the case of conflicts) by domain-level GPOs. You can guess where this is heading. OU-level policies now apply on top of domain-level GPOs.OUs, as you know, are containing folders for computer and user accounts that are joined to your domain. Most companies take good advantage of using multiple OUs inside Active Directory to differentiate types of machines and users. Servers are separated from workstations, accounting users are different from HR users, and so on. Nesting OUs is a common practice as well. Just like creating folders inside of other folders by using File Explorer, you can use AD Users and Computers to create OUs inside other OUs. This is important to the organization of your domain objects, and it is also important to Group Policy.Linking GPOs to particular OUs gives us flexibility in handing different settings to different groups of people or machines. When a GPO is linked to a single OU, only computers or users inside that OU, or downstream from it, will be affected by the GPO. You can even have multiple GPOs linked to the same OU.Nested OUs provide an additional tier to this GPO workflow. Remember the general rule is that Group Policy processes from the top down, so GPOs that are linked to a nested OU will most likely outweigh GPOs that are linked at a higher-level OU.

Security Filtering

Now that you have created a GPO and linked it to particular OU, you have enough information to start using Group Policy in your environment. Using links to determine what machines or users get what policies is the most common method that I see admins use, but there are many circumstances where you might want to take filtering a step further. What if you had a new GPO and had it linked to an OU that contained all of your desktop computers, but then decided that some of those machines needed the policy and some did not? It would be a headache to have to split those machines up into two separate OUs just for the purpose of this policy that you are building. This is where GPO Security Filtering comes into play.Security Filtering is the ability to filter a GPO down to particular Active Directory objects. On any given GPO in your directory, you can set filters so that the GPO only applies to particular users, particular computers, or even particular groups of users or computers. I find that using groups is especially useful.For our Drive Mappings GPO, right now I have it linked to my Accounting Users OU, but what if I wanted to filter that GPO in a different way? Rather than limit the scope of this GPO to a single OU, I would prefer to make it a little bit further-reaching, and I’m going to link the GPO to my contoso.local domain. Yikes, doesn’t that mean it’s going to apply to everything? Yes, unless you utilize the Security Filtering section to define user accounts or groups of accounts to which it should apply.

I always make my Security Filtering decisions before creating a link. Links are live as soon as you create them, so building Security Filtering first ensures proper distribution from the start.

Clicking on any GPO inside the GPMC will display information about that GPO, and the Scope tab displays any links that exist for this GPO, as well as Security Filtering information. All new GPOs will have Authenticated Users defined inside Security Filtering, which essentially means “all domain users and computers.”Remember that it means both! In the next screenshot, you can see my Drive Mappings GPO, which is linked to the Accounting Users OU. It has Authenticated Users listed for Security Filtering. If I were to simply remove the existing OU link and create a new domain-level link, this GPO would immediately start applying to all user accounts in my whole domain:

Figure 5.14: Security Filtering settings for GPOs

Instead of doing that, I will adjust my Security Filtering settings first. All accounting users are part of a security group called Acct Group (I’m so creative!). Adding Acct Group to Security Filtering for this GPO and REMOVING Authenticated Users means that now no matter where I link this GPO, only members of the Acct Group group are going to receive the GPO settings. Now that I have added Acct Group to my Security Filtering, I can safely link the GPO to the top level of my domain and remain confident that only members of Acct Group will receive my GPO settings:

Figure 5.15: Filtering a GPO to Acct Group

Another cool feature that is just a click away is the Settings tab on this same screen. Click on that tab, and it will display all of the configurations currently set inside your GPO. This is very useful for checking over GPOs that someone else may have created to see what settings reside inside the policy.

WMI Filtering

Using a combination of well-designed links and Security Filtering to narrow the scope of your GPOs, you will likely be able to perfectly plan and apply policy settings 90% of the time. Our next few sub-headings reflect that remaining 10%, as we cover some of the advanced filtering techniques that are available to get even more granular when filtering GPOs.WMI Filtering is a genius, although slightly confusing, tool to further define GPO application. WMI filters tap into the WMI information that exists on every Windows computer and use that WMI data to further filter GPO settings. WMI filters can be defined to look for operating system version numbers, types of CPU, quantities of RAM, the amount of available disk space, and sometimes even things like BIOS firmware. Once a WMI filter is defined, you can then select that filter for each GPO, in the section titled WMI Filtering, which is immediately below Security Filtering inside the GPMC.WMI filters enable you to do things like “only install this huge piece of software if there is at least 5 GB of available disk space” or “only implement these firewall settings on machines running a Windows Server operating system.” Another real-world example uses WMI Filtering to identify whether or not a machine is running mobile hardware, which allows your GPOs to apply only to laptops and tablets, and not desktop computers.WMI Filtering draws information from other components inside the operating system, and therefore causes Group Policy to take a little bit more time and CPU processing power to function. This can cause an increase in system resources on your endpoint computers and also slows logins, as that processing happens in the background.Building WMI filters is getting in the weeds with Group Policy, and so for further instruction on that, I will point you toward the Summary section at the end of this chapter, where I will reference another publication dedicated entirely to Group Policy.

Item-level targeting

Links, Security Filtering, and WMI Filtering are fantastic ways to determine which GPOs apply to which computers and users. But what if you need to take it a step further? What if you have a single GPO that contains multiple settings, and you only want some of those settings to apply to certain users or computers, and other settings in the same policy to apply to different users and computers?A prime example of this is a Drive Mappings GPO. It is common to place all network drives in a single GPO in the domain and call it Mapped Drives or something similar. It is also common that not all users should get all mapped network drives. What is the best way to handle that? For this scenario, you could break your GPO out into many smaller GPOs, creating a separate GPO for each drive letter and then determining with links and filters which users get which drive letters. But then you have a horde of GPOs to deal with.Enter Item-level targeting (ILT). You may not remember, but earlier we glanced at a special Common tab that exists inside many GPO settings. One of the five settings inside the Common tab is Item-level targeting, and this is exactly the clarifying setting we need to make our Drive Mappings GPO dreams come true.Referencing the same Drive Mappings GPO that I have worked with for many pages now, you know that this policy contains multiple drive letters. Currently, my Acct Group users receive all of those mapped drives. Let’s pretend for a minute that I only want the Acct Group to receive one of those drive letter mappings and not the others. Editing the GPO, I double-click on my P: drive mapping, and then visit the Common tab. Here, I check the box for Item-level targeting and click on the Targeting… button.Inside the Targeting Editor, choose New Item and you will find a large list of criteria that can be utilized for these additional targeting parameters:

Figure 5.16: Adding a new security group in Targeting Editor

I want to instruct this GPO that the P: drive should only be mapped for users who are part of the Acct Group security group.Choosing to add a new security group to my ILT, I can define the Acct Group and you can see in Figure 5.17 that my P: drive ILT settings have now been updated so that only if the user is a member of the CONTOSO\Acct Group security group will that user receive the P: drive mapping when they log in:

Figure 5.17: Applying the P: drive mapping to CONTOSO\Acct Group

Repeat this process with the rest of the drive letters in your GPO, and you now have a single GPO containing all drive letter mappings for your entire organization. You can link this GPO to the domain, and leave it security-filtered for all authenticated users, as it is by default, and yet based on ILT, only drive letters that correspond to their appropriate groups will now be mapped for each user who logs in. ILT is the bomb! Wow, I can’t believe I just typed that…

Delegation

Consider this scenario: the executive leadership at your company has asked you to lock down security restrictions on all computers in the domain. That sounds like a job for Group Policy! Except, since they are the leadership and don’t want their own systems to hinder their ability to browse Instagram and configure desktop backgrounds of smiling kittens, they have required that these lockdown settings apply to everyone except members of the Leadership group in Active Directory.We know plenty of ways to filter GPOs to certain users or groups, but how do we filter GPOs for everything except a certain user or group? For this, we visit GPMC, click on the GPO in question, and visit the tab called Delegation.If your GPO has custom Security Filtering applied, you’ll notice the names of those users or groups inside the Delegation screen as well.When configuring Security Filtering, what the GPMC is really doing is configuring delegation permissions on the GPO in the background. I have navigated to the Delegation tab of my Drive Mappings GPO, which is currently still security-filtered for the Acct Group. Inside Delegation, clicking on the Advanced… button near the bottom left brings me into the nitty-gritty security details behind the delegation and permissions settings on this GPO.In Figure 5.18, you can see that my Acct Group currently has Read and Apply group policy permissions configured to Allow. This is what happened when I added Acct Group to Security Filtering. This is the set of permissions making the magic happen so that whenever someone logs in to a computer in my domain, they are allowed to both read settings in this GPO and to apply settings from this GPO:

Figure 5.18: Acct Group has read and apply permissions

Circling back to the matter at hand, in the Microsoft world, a denial of permission always trumps a permission allowance. If you need to deny a particular user, computer, or group from receiving GPO settings from a particular GPO, you simply add them to the Delegation permissions and check the Deny box for Apply group policy. Even if they are allowed a Group Policy based on another permission entry in this list, they will now be denied this GPO applying to them. To make this crystal-clear with another screenshot, here you can see that my Leadership group is now denied from applying the Desktop Wallpaper GPO.When anybody logs in who is part of this Leadership group, they will NOT receive the wallpaper restrictions that are in place for the rest of my users:

Figure 5.19: Denying a group from receiving this GPO

Use with caution! Creating GPO denials inside the Delegation tab works great, but it is very easy to forget or overlook these settings in the future. I have assisted admins numerous times with troubleshooting a GPO that did not seem to be applying properly, only to find out that a denial permission inside Delegation was causing all the grief.

Computer settings and user settings

After poking around inside GPOs for a few minutes, you are likely to notice that the Group Policy Management Editor is split into two different sections. When drilling down inside a GPO to find the particular setting that you are about to roll into place, the first choice you need to make is whether you are working on a Computer Configuration or a User Configuration. Understanding the differences and always keeping these differences in mind is important not only for finding the setting you are searching for but also for ensuring that your new GPO is linked to the correct place and applies to the proper type of object.You can see these two sections of any GPO in Figure 5.20:

Figure 5.20: Computer Configuration and User Configuration

Let’s briefly go over these options.

Computer Configuration

All GPO settings listed beneath Computer Configuration are, of course, settings that can apply to your domain-joined computers. Duh! Aren’t all GPO settings applied to computers? No, they are not. Many GPO settings do apply to the computer object in Active Directory, and all these types of GPO settings fall beneath Computer Configuration. Some GPO settings are even things that you can configure at either a computer level or a user level. And other times you might have similar options inside both computer and user configuration that accomplish the task in slightly different ways.A good example is an idle screen lockout policy. It is a common requirement for companies to require computer screens to lock themselves after a certain number of minutes of inactivity. This way, if a user walks away from their computer and forgets to manually lock the screen, it will self-lock after, say, 15 minutes.If you are tasked with creating such a policy, you need to decide whether you want this GPO to apply at the computer level or the user level. This will have to be decided for yourself, based on your normal user activity.If you determine that the best method for locking the screen is to do so at the computer level, meaning that the screen will lock after 15 minutes no matter who is logged into that computer, then this is the specific configuration that you want to set inside your GPO:Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Security OptionsInteractive logon: Machine inactivity limit = Enabled and specified to 900 seconds (15 minutes)

User Configuration

On the other hand, many other GPO settings apply not to the computer account at all, but rather to the domain user who is logging in to that computer. User Configuration settings follow the user account around and apply to whichever workstation that user logs into. If you look back at our Drive Mappings GPO, you’ll see that the network drive configurations that we created in that GPO all fall under User Configuration. This means that those drive mappings will attempt to map themselves anywhere that the user logs in. You cannot create mapped network drives as a native GPO setting from within Computer Configuration.Revisiting our idle screen lockout example, what if you have decided that you want the idle screen to happen for a certain type of user, or perhaps even all users, and that the screen lock would happen for those users no matter which computer they logged in to? In this case, there is not a specific “screen-lock” policy setting that you can configure inside User Configuration, but what is generally recommended is to get creative with screen saver settings, which are User Configuration settings. If you configure the following four GPO settings, you will effectively create the same behavior as the Computer Config machine inactivity limit timeout setting, but now this policy takes effect based on user accounts rather than computer accounts:User Configuration | Policies | Administrative Templates | Control Panel | Personalization Enable screen saver = EnabledForce specific screen saver = Use this to define which screen saver you want to run Screen saver timeout = Enabled and set to 900 secondsPassword protect the screen saver = Enabled

Linking GPOs accordingly

As you seek out GPO configurations to put into place in your environment, sometimes you will find you have no choice between computer or user configuration, as some options will only exist in one location or the other. Other times, you will find that the settings you are putting into place could be configured from either place, and the decision of how to best set the GPO depends upon which level you want the GPO settings to apply.This decision ties in directly with the location to which you are going to link this GPO! If your GPO contains Computer Configuration settings, those settings can only apply to computer objects and so that GPO would need to be linked to OUs that contain computer objects. Or linked at the domain level, of course, which covers all OUs.Vice versa is also true; if your new GPO contains only User Configuration settings, that GPO is only going to apply to user objects, and any links you create for that GPO should be links to OUs that contain the user objects to which you want the GPO to apply.You may have already figured this out, but it is generally best practice to create GPOs as either computer-based GPOs or user-based GPOs. A single GPO can contain a lot of different settings, and if that GPO is linked at a high enough tier, it might indeed be able to apply both user and computer configuration settings all from within a single GPO. But this makes for a higher administrative burden on that single GPO, and it is typically considered best practice for any GPO to contain only Computer Configuration settings or User Configuration settings. Try not to mix the two.

Group Policy loopback processing

There is a special function inside GPOs that essentially blends computer and user configuration together, to be used in special cases: namely, if you have the requirement to push User Configuration settings to particular computers but want those computers to treat them as if they were Computer Configuration settings, applying the same policy settings to any user who was to log in to that computer.Maybe Laura in HR has a certain set of policies on her everyday workstation, but also occasionally logs into a public kiosk workstation sitting in the lobby. You have a set of lockdown restrictions that are applied to that kiosk, but since it is domain-joined, normally when Laura logs into the kiosk, Group Policy would treat it just like it was her own workstation and apply all of the same user-based GPO settings. If you create a User Configuration GPO that has loopback policy processing enabled and link the GPO to this kiosk workstation, it will now apply all of those special configurations to Laura, even though she does not receive these GPO settings on her regular computer. If Laura were to log in to this kiosk and have access to sensitive documents based on her standard login policies, you would probably want to stop that from happening when she logs in to this public access kiosk workstation, just as one example of where this might be useful. Another scenario where loopback processing is commonly used is when working with Remote Desktop servers, and using GPOs to apply settings to all users who log into an RDSH.For more detail on loopback processing, I will once again direct you to the Summary section at the end of this chapter, where I’ll refer you to a great location for learning more on this topic.

Policy versus preference

There is an important distinction that every Group Policy administrator needs to understand about GPO settings. There are two different types of policy settings, and they behave very differently. Now that we understand the differences between Computer Configuration and User Configuration, the next tier you’ll notice inside Group Policy Management Editor are sub-folders titled Policies and Preferences.

Policies

Managed policies, the items listed under the Policies section of both computer and user configurations, generally behave like true gentlemen. These are settings that you put into place and expect results, forcing the setting into place, and nothing the user tries to do can change them. When reversing course and removing a GPO from a system, they happily comply. What do I mean by that? When you plug some policy settings into a GPO and then link that GPO to a location, you expect those settings to be put into place on the machines or users to which you have filtered the GPO. And that indeed works for any GPO setting, whether policy or preference, managed or unmanaged. But what about when that GPO no longer applies to a user or machine? What if you delete the GPO link, or adjust security filtering on the GPO so that it no longer applies to a workstation? Do those settings continue to be applied, or are they actively removed?The answer to that question depends on whether you are working with a policy or a preference. Policy items will actively remove themselves from a computer when a GPO no longer applies. This is true of most built-in configuration settings inside Group Policy. Technically, under the hood, what is really happening is that Group Policy monitors four special sections of the Windows Registry and reprocesses all of them during Group Policy refresh cycles. All GPO settings that affect these areas of the registry are capable of self-removal. Unmanaged policy settings, even some of those listed beneath the Policies folder, could potentially fail to remove their settings when a GPO is unlinked. It just depends on what setting you are talking about and what it is manipulating on the client machines to make the change.Technically, there are managed policies and unmanaged policies – and both of these things are outside the scope of Group Policy preferences, which we will discuss next.

Preferences

Policies force things to happen, no matter what the user wants. Preferences, on the other hand, are often reversible by the user. Preferences are a good way to configure settings that will make life easier for the user, but you need to ultimately be OK with the fact that those changes and settings could be changed again manually by your users. Some GPO settings exist inside both policies and preferences, and this is your deciding factor – do you want to allow users to manipulate and change the configuration, or always force it into place?Preferences are also sticky! While most policy settings will self-remove when a GPO stops applying to a computer, preferences do not. This is very important to understand when deleting GPOs or GPO links. Group Policy preferences do not live in those special sections of the registry that we talked about earlier, and so Windows does not actively rescan those settings to find out whether they should continue to apply. When a GPO puts a preference setting into place, even though the user could adjust that setting if they wanted to, removal of the GPO will NOT revert the computer to its original, default state. The GPO preference setting will hang around and continue to apply to the machine even after the GPO is long gone. To change a preference setting back to defaults, the user will either have to adjust it themselves, or you will need to push out a new GPO that accomplishes that reversal.

Default Domain Policy

Throughout this chapter, we have bounced in and out of the GPMC a number of times, and now that you know what a GPO looks like and how to identify GPO links, you have probably noticed a GPO linked to the root of the domain called Default Domain Policy. This GPO comes built in with Group Policy. Every environment has one unless an admin has taken steps to delete it, which I would not recommend.The Default Domain Policy applies to every user and computer that is part of your domain directory. Since this GPO is completely enabled right off the bat and applies to everyone, it is commonplace for companies to edit this default policy to enforce global password policies or security rules that need to apply to everyone. In fact, many who are unfamiliar with Group Policy and uncomfortable with creating, linking, and filtering their own GPOs will just continually throw more and more settings in the Default Domain Policy. There are even many blog posts about creating GPO settings that instruct you to edit the Default Domain Policy.All of these settings will apply successfully, of course – to ALL users on ALL machines, including servers in your network. Eventually, this mentality is going to come back and bite hard.My general rule is to never touch the Default Domain Policy except for one reason – creating global password expiry and complexity requirements within your domain. In fact, in some cases, not even a password policy is appropriate for the Default Domain Policy. As an example, if you wanted to create a fine-grained password policy that comes with some additional bells and whistles, such as the ability to require different password criteria for some users compared to others. We will cover fine-grained password policies in Chapter 10, Hardening and Security, so for the time being, let’s stick with the idea that we want to create one password policy and apply it to everyone. This seems like a good example to walk through, and remember – if you find yourself heading into the Default Domain Policy to do anything other than password management - you’re probably doing it wrong. Just create your own GPO, for crying out loud!With any GPO that you see in the management console, if you right-click on that GPO and then choose Edit... you will see a new window open, and this GPO editor contains all of the internals of that policy. This is where you handle any settings or configurations that you want to be a part of that particular GPO. So, go ahead and edit your Default Domain Policy, and then navigate to Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies | Password Policy:

Figure 5.21: Password settings in Default Domain Policy

Here, you can see the list of settings that currently comprise the Password Policy within your domain. These settings are out-of-the-box behavior for a brand new Windows Server environment, and are currently active in my environment, even though I took no intentional steps to enable them. Double-clicking on any of these settings allows you to modify them, and that change immediately starts to take effect on all of your domain-joined computers in the network. For example, you can see that the default minimum password length is set to 7 characters. Most companies have already worked through discussions about their written policy on the standard length of passwords in the network, and in order to set up your new directory infrastructure to accept your decision, you simply modify this field.Changing the minimum password length to 14 characters here would immediately require the change to be made for all user accounts the next time they reset their passwords.It’s worth repeating: while the Default Domain Policy is a very quick and easy way to get some settings configured and pushed out to everyone, tread carefully when making changes to this default policy. Every time that you make a setting change here, remember that it is going to affect everyone in your domain, including yourself. Many times, you will be creating policies that do not need to apply to everyone. In those cases, it is highly recommended that you stay away from the Default Domain Policy. Instead, set up a new GPO for accomplishing whatever task it is that you are trying to put into place.

Administrative Templates

Go ahead and edit a GPO, any GPO, so that you have the Group Policy Management Editor open in front of you. Expand the Policies folder for either Computer Configuration, User Configuration, or both, and you will notice a folder inside each called Administrative Templates. Most of us generally think of Administrative Templates the same as any other GPO configuration setting, simply a collection of items with which you can manipulate users or computers, right? Sort of, but while Software Settings and Windows Settings are built into Group Policy and are basically the same for any domain environment, Administrative Templates are customizable.Administrative Templates showcase the flexibility of Group Policy. Each setting within Administrative Templates is pulled from template files that reside on your domain controller servers. These template files are ADMX files. All of the information needed to display the setting inside Group Policy Management Editor is contained inside these ADMX files. This information includes the different selectable options, any drop-down boxes that need to be displayed, and what the description fields will say when an admin double-clicks on the policy setting.Along with each ADMX file comes an accompanying ADML file. This is a language file that is used to define the language for the settings contained within the ADMX file.Back in Windows XP (and earlier) days, these file types did not exist. Settings inside Administrative Tem- plates were based on ADM files instead. Nobody should be running Windows XP anymore, except I know that some of you are, because I still touch Windows XP machines for some customers at least once a month. So I figured I would include that info as an FYI. Sidenote: get rid of your Windows XP computers!Windows 7 and newer know how to work with ADMX/ADML files, so I’m going to assume that your environment is fully up to date. Hopefully that means you don’t even have any unsupported Windows 7 or Windows 8 machines hanging around, but…

Implementing ADMX/ADML files

There are two reasons why you might find yourself monkeying around with ADMX files. The first is when moving to a newer version of Windows Server in your environment. Each release of the operating system – 2012, 2012R2, 2016, 2019, 2022, 2025 – comes with some new and updated Group Policy settings. When you install your first domain controller of a newer flavor into your environment, the installation will generally run through a process called ADPrep. This process prepares the Active Directory schema for the new operating system and also populates the new Group Policy settings. However, there are times when the first new release operating system introduction you are making to the environment is not a domain controller. In this case, Group Policy won’t be updated with new settings, but what if you wanted those new settings to be available within Group Policy anyway? Manually copying ADMX/ADML files into place could satisfy that need.The second and most common reason to plug new ADMX/ADML files into place manually is when a software vendor, often Microsoft themselves, releases custom ADMX files. These files, when installed in Active Directory, will provide new settings inside Group Policy that don’t exist natively inside Windows Server. Let’s try it right now!Google Chrome (did I just say those words in a Microsoft book???) is one of the most popular web browsers on the planet. The centralized configuration of Chrome is something that many administrators struggle with. What may or may not be news to you is that Google has its own set of ADMX files! You can plug these files into Group Policy and utilize Google-defined settings directly from within the GPMC to push Chrome-related configurations out to your workforce.First, we need to download these files. At the time of writing, this link will do the trick: https://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip.If you are unable to use that link, simply perform a web search for “download chrome admx files" and you should be able to find it.Copy these files to your domain controller and extract them so that you can find the ADMX and ADML files; they should be inside a folder called windows. The couple of ADMX files are located right there inside a subfolder called admx, and the ADML files will be grouped into folders by language. This matches what we will find inside Group Policy in just a minute. Now that you have the files in hand, go ahead and open the following folder on the domain controller:

%systemroot%\PolicyDefinitions

(On most servers this will be C:\Windows\PolicyDefinitions.)In Figure 5.22, you can see my Chrome files that have been downloaded, alongside the PolicyDefinitions folder. As you can also see, there are already numerous ADMX files inside PolicyDefinitions, as to be expected. These ADMX files are the reason that we have any settings currently inside Group Policy, under the Administrative Templates folders:

Figure 5.22: Copying new ADMX files to the domain controller

Simply copy your new Chrome ADMX files into PolicyDefinitions, and then copy the accompanying language ADML language file from its folder, into the corresponding language folder inside PolicyDefinitions. That’s it! As evidenced in my screenshot and the text you are reading, I am working within the context of US English, so I only need to copy the ADML files from within en-US folder, to the en-US folder that already exists inside PolicyDefinitions. There is no need to copy languages other than the one already existing on your server’s hard drive. If you now close and reopen GPMC, take another look inside Administrative Templates to find some new Google Chrome settings!There are tons of them in here, all from those two little ADMX files:

Figure 5.23: Google Chrome GPO settings

For this example, I am working with my test lab and making the assumption that you have a single domain controller in your environment. If you have multiple DCs, you will either have to copy these files into %systemroot%\PolicyDefinitions on each of your domain controller servers, or continue reading the next section of this chapter to learn more about the Central Store.

The Central Store

When opening the Group Policy Management Console and creating or editing a GPO, the settings available within your console session are settings pulled from ADMX/ADML files that are on the hard drive of the computer or server from which you are using the GPMC. When implementing new settings via ADMX files, it would be a huge chore to have to copy those new files into place on every one of your domain controllers, in addition to all of the client computers where you might have the RSAT tools installed. Thankfully, there is a solution to automate this for you!The Central Store is something that can be enabled in Active Directory that allows the replication of ADMX/ADML files. Once you enable the Central Store, all of your Group Policy management machines, such as domain controllers, will look to the store as its repository for these template files.

Enable the Central Store

All that it takes to enable the Central Store in Active Directory is the creation of two folders inside a special folder called SYSVOL. Once created, the GPMC will check this location on subsequent launches, and pull in any new ADMX/ADML files that have been added. Log in to a domain controller server, and create the following new folder:

%systemroot%\SYSVOL\sysvol\contoso.local\Policies\PolicyDefinitions

Create an additional folder within your new PolicyDefinitions folder to contain language-specific ADML files. In my case, I need one for English such as the following:

%systemroot%\SYSVOL\sysvol\contoso.local\Policies\PolicyDefinitions\en-US

Obviously, you’ll want to replace contoso.local with your own internal domain name, and you’re finished! As soon as you have created these two new folders, utilize this location from now on to copy in new ADMX and ADML files, and those new settings will show up from wherever you launch GPMC in the future.

Populate the Central Store

You probably didn’t have an immediate reason to check inside one of your GPOs and find out what the Administrative Templates folder looks like now that we enabled the Central Store, but let’s go ahead and do that now. Open GPMC and edit any of your existing GPOs. Take a look inside one of the Administrative Templates folders, and it’s empty! Yikes! You’ll also notice that the name of the Administrative Templates folder has now changed to reflect the fact that it is looking to the Central Store for this in- formation: Administrative Templates: Policy definitions (ADMX files) retrieved from the central store.

Figure 5.24: The Administrative Templates folder is empty!

Give us our settings back! Thankfully, they are still sitting on the hard drive of your domain controller, in the same location where we added the new Google settings just a few minutes ago. Perform the following file-copy jobs, and you should be back in business with all settings now stored inside the Central Store.Copy %systemroot%\PolicyDefinitions to %systemroot%\SYSVOL\sysvol\contoso.local\Policies\ PolicyDefinitions.Copy %systemroot%\PolicyDefinitions\en-US to %systemroot%\SYSVOL\sysvol\contoso.local\ Policies\PolicyDefinitions\en-US (adjust accordingly for whichever languages you need):

Figure 5.25: The Central Store is now populated with settings

As you can see, the Administrative Templates folder is still pulling from the Central Store, but following our file copies, the Central Store is now populated with ADMX files and settings to utilize inside a GPO. The Central Store is now available to all domain controllers in your environment, because SYSVOL is one of a few special folders that are automatically replicated among all Domain Controller servers in a domain, and what we have done today is simply make use of that replication.

Summary

Group Policy is an incredibly powerful tool to have at your disposal when working within a domain environment. Many pre-built configurations and settings exist, and as you have seen some are being used whether you realize it or not, due to them being configured inside the Default Domain Policy. Because Group Policy even has power to manipulate the registry on client machines, the sky is pretty much the limit on what you can manage on your client computers via GPOs.Some of the most common ways I see Group Policy utilized are automatic drive mappings, printer installations, desktop personalizations, centralized security standards, and password management. Additionally, it can be used to push out RDS security policies, to lock down kiosk stations, to automatically install applications, and so much more. Group Policy is even commonly used to assist companies who are on cloud migration paths, through things like centralized OneDrive administration.As is the case with many topics inside Windows Server, there is so much information related to Group Policy that it warrants a book of its own. Thankfully, I had the opportunity to do exactly that! If you are interested in discovering more about Group Policy and all of the ways that it can be used to secure your infrastructure, check out my title Mastering Windows Group Policy (https://www.packtpub.com/en-us/product/mastering-windows-group-policy-9781789345438).

Questions

Are screensaver settings computer or user configuration?

Do domain-level or OU-level links process first?

What is the special GPO setting that forces user settings to apply to any user on a given computer?

What type of GPO filtering do you configure inside the GPO itself, such as with a mapped network drives policy?

True or false – It is possible for a user to override a Group Policy preference.

What is the default timer between Group Policy background refresh cycles?

What kind of GPO filtering could be utilized to assign settings only to laptop computers?

If you find a USB stick on the ground labeled “CEO financials,” what should you do with it?

Bonus question: What is the name of Microsoft’s cloud-based technology that provides some of the same functionality as Group Policy, but specifically for Entra-joined computers?

6 File Management

Join our book community on Discord

https://packt.link/zYovfEveryone loves a good library, am I right? There’s no sense of accomplishment quite like mastering the Dewey Decimal system and inhaling layers of dust before discovering the content you seek. It’s almost like being in an Indiana Jones movie, without the rolling boulder. While you may not share a passion for books in quite the same way as my homeschooling family, my attempt at a segue here is that every business I have ever worked with quickly builds up its own library-esque mountain of data. The way you have built your organizational structure for housing such digital volumes of data makes all the difference upon whether or not this information is easily accessible to those who need it. In this chapter, I would like to take time to discuss another core narrative in the world of server administration, file management. While you may not be the person authoring all of this data and perhaps couldn’t care less about the content, make no mistake that you are the party responsible for keeping it safe, secure, and accessible. Follow along as we dig into the following topics.

Data is a company’s lifeblood

File Shares

Automated drive mappings

File Permissions

Distributed File System (DFS)

File Transfer Protocol (FTP)

SMB over QUIC

Data is a company’s lifeblood

A large portion of Microsoft’s success tracks back to the Office applications. Microsoft Word and Excel are so universally used, and have been for so long, that they have been common household names for much of my life. Even though many of us wish that it would simply go away at this point, email is integral to the way that we live and work. When email became popular and companies needed to decide on how to best house that information, they didn’t have to turn their attention very far before realizing that Outlook was sitting right there, next to Word and Excel, waiting to be used. There are always naysayers about every globally adopted application, but the easy truth is that Word, Excel, and Outlook are by far the most prevalent platform by which the world creates documents, spreadsheets, and email communications. All these things are valuable data that you cannot simply leave to fate by allowing users to store it on their local computers.Communication, processes, documentation, intellectual property, papers of legalese. Words are powerful, words shape our entire existence. Why do I own my house? This piece of paper declares it. Why do I have a job? My employer and I signed these documents stating the arrangement into existence. What stops someone from simply walking away with another person’s property? The law, written into action and then upheld by people sharing this common ideology. This idea is fascinating, that words put down on paper can easily become legally binding, and thereby shape or re-shape the world that we live in.No matter what industry you are part of, you create words that matter. You create data that matters, and it would be harmful to your business to lose or have to re-create that data. This statement reminds me of a company that I recently worked with. This is a fairly small company who maintains, like so many in the manufacturing industry, very low standards for IT infrastructure. The amount of money spent on machinery and buildings in these places is usually quite high, and by all appearances this is a business that prides itself on providing great products, and understands what it takes to do that successfully, which is great! As with most modern CNC, lathe and milling machinery, large and time-consuming CAD data accompanies every single project and part that are created by this company. Indeed, looking under the hood here exposed more than 8TB of engineering files. The good news is that these files are, for the most part, spread out across only two separate network drive mappings, meaning that the ability for employees to find the data they are looking for was actually quite good. However, digging further into the server infrastructure supporting these files we quickly found a house of cards. Everything, every single piece of that data, resides on a single physical server running Windows Server 2012R2 (hey, can’t knock that it’s been running successfully for more than a decade), with a single Veeam license that is backing up the server to a USB drive once per day. Does that drive gets swapped out and rotated offsite? No. Does it sync to the cloud somewhere? No. Was anybody even checking the backups? No…Oh. My. Word. This is literally a disaster waiting to happen. The loss of this engineering data would cripple this business, very possibly to the point of no return. Now, this is not a chapter about backups, though we will discuss that later in the book. This is a chapter about data, and I hope the story illustrates how easy it is to take your data for granted, not understanding that in many situations, it is quite literally the one thing that you cannot afford to mis-manage. Let’s dive in together to find out what file management opportunities exist inside Windows Server today.

File Shares

The most common way for users at a company to open, save, and otherwise interact with company files is through traditional drive mappings. Anyone who has worked a helpdesk for any amount of time is very familiar with words like “I can’t get to my K: drive”, or “I seem to have lost connection to my T: drive” or “I’m working from home today and can’t get to my S: drive”. Offering up file shares on your file servers so that users can map drive letters to them is File Management 101, and an essential baseline to cover for anybody who touches file servers.Once established, tapping a user’s computer into a server-sourced file share can be accomplished in many ways, and we will look at some of those soon. Before you get to the point of mapping client computers, first we need to create a file server and designate space to house those drive mappings. Where do we begin?

The Role

As with any Windows Server purpose in life, there is an accompanying Role in Windows to get the job done. It is possible to create folders and share those folders on any Windows computer in the world, whether officially a “file server” or not, and so file sharing is unique in that it does not require a role to be installed to be able to share files and folders. There is still an accompanying File Server role that can be installed, which provides additional tools and prioritizations inside Windows for your servers that are intentionally going to be file servers. Go ahead and install that Role called File Server, and take note of how many sub-roles exist that are related to file and storage services, some of which we will utilize throughout this chapter.

Figure 6.1: Installing the File Server role

Define storage space

This may seem like a no-brainer, but your files need to be stored somewhere. This somewhere could be any folder location on your file server, but I mention it here because this is a very important step, and worthy of spending a few minutes to think about. Is it possible to create a simple folder like C:\Shares and start immediately sharing space from it? Sure. Is that very smart? Not in my opinion.If possible, and in the world of VMs it should be easily possible, plan for your file shares to sit on a volume that is separate from your operating system. Creating shares from the C: volume will inter-mix your user data with operating system data and create a lot of potential for problems later. What if your user documents cause the C: drive to run out of space? You could cause Windows to fall on itself and the whole file server could stop working. What if a Windows Update needs to install itself on C:, because that is where Windows is running, and now causes your file shares to be out of space? What if you somehow expand file share permissions too broadly, perhaps accidentally, and now users have the ability to browse around inside Windows system files on C:? There are so many reasons never to create file shares on C:, and instead install a separate hard disk, or at the very least a separate volume, for the purpose of keeping file shares.On my FS01 server, which is a VM, I simply added a second virtual hard disk to this VM.

Figure 6.2: Creating a new disk for file sharing

This second disk is the D: drive on my server, and I am going to use it to store all the file shares for my business.

Plan carefully

As we flow through the configuration of my test lab, you will notice that I like to keep shared folders at a top-root level. I have created my D: volume to store folders which are going to be shared, and the folders that I plan to turn into shares are all going to sit directly inside the root of D:. It is absolutely possible to share folders from any location in Windows. For example, I could take the following folder:D:\Accounting\Payroll\Documents\JobDescriptions and create a share that is simply called “Job Descriptions”, and then share it with anybody who needs to see or contribute to our company’s job posting information. I could do this, but it’s risky business!In the scenario above, it would be so, so easy to accidentally provide the wrong users with access to Payroll information, because you are giving them permissions to access folders within the same file path. There are successful ways to create such a scenario, but it is never worth the risk. I have worked way too many tickets in my life where a customer has discovered that Sally has access to private CEO or HR files that she should definitely not have access to, only to find that somebody created a location for those “private” files in a place that would be almost impossible to keep safe and secure long-term.Be very careful when planning your file shares, and don’t allow a user’s request to steamroll good planning. I find it a good rule to never create a file share in a subfolder location. If a new share is needed, put it directly in the root of the drive, alongside all of your other shares. This mentality will make your information more secure, and much easier to administer long-term.

Create shares

Call to action! Let’s create some shares. I will be creating file shares on my FS01 server, upon which I have added a second virtual hard disk to use for the purpose of file shares and data storage, and I have installed the File Server role as we discussed. Since I have set myself up for success and have a brand new volume dedicated to file shares, I am going to plan from the very beginning for each share to have its own root folder inside my D: volume. It makes sense in my organization for each department to have a dedicated share where other departments do not have access, and also a general shared space where all groups and departments can swap content. I have created the following folders:

D:\Accounting

D:\HR

D:\IT

D:\Marketing

D:\Sales

D:\Public

Each of these folders will be individually shared so that only members of the corresponding department have access to them. The process for sharing each of these folders is simple. Right-click on the folder, and navigate to Properties. Inside Properties, visit the Sharing tab. There are two buttons on this screen, either basic or advanced setup of your share. I recommend using Advanced Sharing… which provides the most options.Inside Advanced Sharing, check the box to Share this folder, and here you can adjust the Share name if necessary. This is a good function to point out. Even though my physical folder is called Accounting, I could name my share something completely different, such as “Secret FBI Files”. Just an example. Here is a screenshot encompassing all of the steps we have taken so far to create these folders, and the process for sharing them.

Figure 6.3: Creating a file share

Share permissions

We will talk more extensively about file permissions in an upcoming section of this chapter, but right here in our sharing screen we also have a Permissions button. What’s that all about? There are two tiers to permissions whenever accessing a Windows server-based file share, and it is very important to understand that both exist, and in which order they apply. When any user accesses any share, they will first be allowed or disallowed based on Share permissions, which is the button we are currently looking at. Then once they have passed the test to get into the share, they will again be allowed or disallowed based on Security permissions.It is general practice to keep Share permissions broad, and then create nitty-gritty permissions using the Security tab. “Broad” could mean a couple of different things. If you only expect users who have Domain user accounts to be accessing this file share, you could setup share permissions so that all Domain Users have Full Control access. That is quite broad and may seem scary, but remember that we will have opportunity in a few minutes to make our permissions more granular at the Security tab level. Another common way to setup Share permissions is to use the built-in group called Everyone, and give that group Full Control. What is the difference between Everyone and Domain Users? Everyone allows essentially anything through the door. This would include non-domain-joined computers or devices as well. This may come in handy if you have any machinery that needs access to files, like a CNC machine on a shop floor, or a printer/scanner that may be trying to reach into the file share to store scanned documents.Although it seems like a terrible idea from a security perspective, the most common way to setup file share permissions is to set Everyone=Full Control. Then decide on the permissions you really want later, when we talk about File Permissions. Here is an example of how I am going to configure all of my shares on FS01 at a sharing permission level.

Figure 6.4: Common setup for share permissions

Even after reading this text, you may be tempted to narrow your share permissions only to provide access for those people who really need it. That is fine, but I can tell you from experience that it is unnecessary and creates a lot of troubleshooting headaches down the road. I have helped engineers numerous times to troubleshoot scenarios where certain users could not access certain files or folders on their file server. The engineer had wracked their brain mowing up and down through file permissions and simply could not find any reason why access was being denied. Of course you now know that they probably overlooked these share-level permissions completely. It’s easy to forget that these permissions even exist, especially when working in an environment where your shares have been around and static for 10 years or more.However you decide to setup permissions for your shares, keep these things in mind. My favorite way to handle them is to always go with Everyone=Full Control on the share level, and then granularize permissions inside the Security tab, to which we have a section dedicated in just a few pages.

Discovering shares

We have some folders stored in a strategic location on FS01, and each of them has been shared. Great! Now what? Before we get into creating permanent mappings to these shares from client computers, I wanted to point out a quick way to discover what shares are visible on any given server, without needing to know the names of those shares. The tasks we are about to walk through are tools that will come in handy hundreds or even thousands of times throughout your IT career, if you aren’t already using them regularly. Let’s pretend you are hired into an existing environment, and are now tasked with discovering what shares are being used by this workforce.

Computer Management

If you are already logged into the file server, discovering all file shares present on this system is easily accomplished by right-clicking on the Start button, and launching Computer Management. Once inside, expand System Tools > Shared Folders > Shares. Here you will quickly find any folder that is shared on this machine.

Figure 6.5: Using Computer Management to view active shares

You may notice one or more shares that end with $. These are still valid folders that are shared from this machine, but they are not visible via public query of the server. Anytime you want to “share” a folder, but keep visibility of that share away from the general population, simply create the share name of your folder with a $ at the end of the name.

In our next section we will pull a public query of FS01 to find out what shares it is presenting to the outside world, and you will notice that my C$, D$, IPC$, and ADMIN$ shares are not visible. Yet if I knew that insider information and mapped a connection directly to \\FS01\C$, it would work.

Backslash-Backslash (\\)

Now let’s attempt to discover shares that exist on FS01, without even logging into that server. This can be a really useful task when exploring an environment that you do not have unfettered access to log directly into servers, or just a quicker way to remind yourself of a share mapping without having to reference the server or documentation. From any machine within your network, simply open File Explorer and type \\SERVERNAME into the address bar. In my test lab, I am logged into my WIN10 computer and am navigating to \\FS01.This action queries the FS01 server for any shares that it is presenting. In Figure 6.6, you’ll notice all of the departmental shares that we created a few minutes ago, and there is even a printer being shared from here! I added that printer and shared it from FS01 for the purpose of showing this capability, whenever you are sitting in front of a workstation and want to map to something on a server, whether it be a file share or a printer, \\SERVERNAME is often the quickest way to find what you are looking for.

Figure 6.6: Querying FS01 for shared items

It would be entirely possible to train your users that each time they needed to access information inside a file share, open File Explorer and contact the server by name. However, that would become extremely annoying for users and I’m sure you don’t want to install a complaints box next to your office door. Instead, let’s take this one step further and create a permanent drive mapping on this WIN10 workstation.

Mapping a drive

The term “mapping a drive” generally refers to selecting a folder that is shared from a server in your environment, and creating a semi-permanent link to it through use of a drive letter on the local workstation. By default, the “C: drive” is where all Windows operating system files are stored, even end users generally understand this. If your computer has a CD/DVD drive, it oftentimes utilizes the D: drive designation on that computer. You may be wondering what happened to A: and B:, those used to be commonly utilized by these things called floppy drives, which I am certainly old enough to remember but you may have never seen one.Mapped network drives are the same idea, designating a specific drive letter as a semi-permanent link to a network location, usually a folder that is shared from a file server. I keep saying “semi-permanent” because it is entirely possible to disconnect drive letters and reconnect them to new places, which is fairly difficult to do with physical items like C: and D:. Therefore, network drive mappings are usually higher in the alphabetical range, like the K: drive, M: drive, S: drive…you get the picture.We’ll look at a couple of options for automating this drive mapping process in a few pages, but it is also important to know how to manually map a network drive when needed. One of the easiest ways is to query the file server just like we did a minute ago, by using \\FS01 into File Explorer. Once you see the network folder that you want to map to, simply right-click on that folder and select Map network drive…A new window appears, with the folder destination already populated to the network location of the drive you right-clicked on. I am trying to map my \\FS01\Marketing location to my local M: drive, and all I need to do is right-click, choose to map the drive, select my M: drive letter from the dropdown list, and Bob’s your uncle.

Figure 6.7: Manually mapping a drive letter

From this point forward, until I disconnect the drive letter or something happens inside Windows that disconnects it for me, every time that I open File Explorer I will have an M: drive. Clicking upon this M: drive connection will navigate me directly into the Marketing shared folder on my FS01 server.

Mapping via command line

Anything accomplished via graphical interface inside the Microsoft Windows world is also accomplishable via command line. Mapping network drives is something easily done from Windows Terminal, PowerShell, or good ole Command Prompt. Taking what you already know, that you must designate a drive letter to be mapped to a network location, open your favorite command line interface and utilize the following context:

Net use S: \\FS01\Sales

The above command will immediately create a drive mapping of your S: to the Sales share on FS01. However, and this is a big however, using the preceding command will mean that the next time you reboot this computer, the S: drive will disappear. If you refer back to Figure 6.7, you’ll notice that checkbox Reconnect at sign-in. When mapping via command line, we did not designate anything that specifies that we want to retain this drive letter on subsequent logins, so it assumes we do not want to do that. To correct this situation, because it is almost never the case that you want to map a network drive only for your current Windows session, simply add a /persistent switch to the end of your command, like this:

Net use S: \\FS01\Sales /persistent:yes

Now each time that you log back into this computer, your S: drive will be mapped to the Sales share. At any point, if you want to view your mapped drive letters right here in command prompt, net use will spit them out:

Figure 6.8: Using NET USE to create and view drive mappings

Backups, backups, backups

As already mentioned, we will talk more specifically about backup capabilities inside Windows Server later, inside Chapter 17. I mention it here because proper backups are of critical importance to any file server. Data is so valuable to all companies, protecting that data should be a top priority. Any IT department knows that recovery of files or folders is a commonplace task. Sometimes users accidentally delete things, sometimes they nefariously delete things, sometimes they make mistakes while updating a file, sometimes they unknowingly drag folders inside other folders. The list goes on and on about reasons why you may have to turn to your backup system to recover files and folders to your file servers.Do not save money on backups. Get good ones, and make sure they backup once an hour during working hours. Sometimes you may want to push that further and back file servers up every 15 minutes. It all depends on your worker’s habits and workflow.

Automated drive mappings

Knowing how to manually map network drives is essential information for working in IT, but unless your company consists of 10 people, you are certainly not going to walk around to every user at every computer anytime you want to make a drive mapping addition or adjustment. There are two primary technologies that exist in the Microsoft world for the purpose of automating this process, let’s take a look at both of them.

GPO drive mapping

This shouldn’t come as a surprise, if you have been reading through the book front to back. We already talked through the possibility of automating your drive map process in Chapter 5, when we worked together to create a Group Policy Object and configured settings inside that GPO to map network drives based on Active Directory group membership. Indeed, this GPO is exactly the reason why some of my drive letters shown in Figure 6.8 exist.Inside any traditional Active Directory domain environment, where servers and computers are joined to the domain and are regularly in contact with a Domain Controller server, establishing automated drive mappings via GPO is by far the most common approach to dealing with this topic. I don’t want to re-hash everything we talked about in Chapter 5, but there is granular ability inside GPOs to determine which employees get access to which drive letters, and to make sure those drive letters are automatically put into place every time that those users log into their computers. If you missed that section, please turn back a few pages right now!

Intune drive mapping

More companies move resources into the cloud every day, and oftentimes a business who has always used Microsoft technology inside their walls decides to continue using Microsoft technology outside of those walls. What this often means in practice is that M365 and Azure are entrypoints to cloud productivity, but almost never transitioning in one fell swoop. It would be pretty cavalier to spend a weekend throwing all company resources into the cloud and expecting users to deal with the differences and changes on Monday morning. So instead, most of these transitions will take the approach of creating a hybrid environment for a while, where computers are hybrid joined to both Active Directory and Entra.I suppose that information is not necessarily here nor there when it comes to Intune capabilities. Whether your computers are “hybrid joined” or directly joined to Entra, Microsoft Intune has the ability to manipulate those computers. I mention this to reinforce the fact that this section about mapping network drives via Intune policy is only for companies who have moved far enough into the cloud space that their workstations are joined to Entra in some capacity. Using M365 for email is not enough, you must have already taken intentional steps to fully join machines to Entra so that they are “enrolled” inside Intune. The processes and licensing requirements for Entra-joining machines are outside the scope of this chapter, but I say this as a precursor that only some of you will have an environment that is capable of building an automatic drive mapping policy from inside Intune.Assuming you do have Intune and your computers are already enrolled in it, your home for creating an automated drive mapping script is inside the Microsoft Admin portal, specifically inside the Microsoft Intune admin center (intune.microsoft.com). There are multiple different ways that you can use Intune to create drive mappings on your user’s computers. The most classic is to ask Intune to run a PowerShell script on your computers, and that script handles the mapping of network drives. That is the approach we will take today, because the functionality is built into Intune without modifications. Alternatively, some people have created custom ADMX templates that can be uploaded into Intune which, once uploaded, create an even easier experience of defining network drive mappings inside an Intune Configuration Profile. This is an exciting topic, but our book is not really an Intune book, so as I mentioned we will stick with the script method today as it already exists inside any Intune environment.Microsoft Intune admin center > Devices > Manage devices > Scripts and remediations > Platform scriptsVisiting this section of the Intune portal will bring you to the place where you can create or manage any number of scripts that you want to toss at your Intune-joined computers. As of right now I have no such scripts, and so I simply click Add > Windows 10 and later to begin the process of crafting a new script that I will push at my Windows devices.The options selectable in this wizard are self-explanatory, but after defining a name for my “Automatic Drive Mapping” policy, I am faced with a box asking me to upload a .PS1 script file. Uh oh, I don’t have a script file…

Figure 6.9: Creating an Intune policy that will run my non-existent script

Let’s figure out how to remedy that.

Crafting the drive mapping script

I worked through this example backwards on purpose, because sometimes encountering issues causes us to remember better for next time. It is helpful for you to generate your .PS1 PowerShell script before you try to add it into Intune. But, no harm done, we will go create the script now. Fortunately for us, Microsoft has a website hanging out there for anybody to use, which allows you to simply enter your drive letters and drive mapping information, click a button, and it spits out a .PS1 script that you can bring right over to the Intune portal.https://intunedrivemapping.azurewebsites.net/DriveMappingVisit this site and select Build from scratch. Now simply use the Edit, Delete, and Add entry buttons as needed to inject all of your drive letters and mappings that you would like to accomplish via this PowerShell script. When finished, you should see a list of the automated drive mappings that you are asking this script to run, with a button to Download PowerShell script.

Figure 6.10: Crafting a .PS1 using the Intune Drive Mapping Generator

Once downloaded, you simply upload this script into the Intune window and select what Entra group or groups you want it to apply to, and bingo – Intune will begin pushing this script down to your users. What this script really does is create a Scheduled Task on each computer, which attempts to run the script during user login. This is the activity that causes the script to map network drives automatically in the background, without the user having to do anything. Scripts are incredibly powerful, and can be tweaked or manipulated in an unlimited number of ways. You could follow this same process to script any kind of change to your Windows computers. You could also tweak the .PS1 script before uploading to Intune to manipulate the Scheduled Task and cause it to run more often than only during user login, which is sometimes necessary if you have remote workers who rarely visit the office.

A special note about updating Intune drive mappings

Unfortunately, once you upload your drive mapping script to Intune there is no way to edit that script from inside the admin center. Down the road you may encounter the need to add a new drive mapping or edit an existing one, and you will visit the Intune portal only to find that you can see the name of the .PS1 script that is running, but there is not a way to edit or even to download that script to see what is going on within.Instead, you’ll need to create a new .PS1 script, and upload the new copy into your Intune policy, replacing the old script with new. This is easily done, the tricky bit is remembering what was inside the original script so that you can include that information in the new one. There are some secret-sauce ways of extracting this script from Intune but they’re not for the faint of heart. Instead, take care to save a copy of your .PS1 script somewhere on your computer or on the network, so that you can easily come back and reference it again later.

File Permissions

After a brief detour into the cloud, we are back on-prem and working with shares on the FS01 server. When creating these shares, we went into detail about share-level permissions and mentioned further file-level permissions, but have not yet taken a firsthand look at these.Share permissions are processed first when any user attempts to access any shared folder or file. If you wanted to divvy up access about who can get to what resources, you could do it at a share level, but it would be tricky and difficult to administer long-term. Instead, it is common practice to leave share-level permissions wide open (Everyone=Full Control) and handle your real file and folder access by using folder-level permissions. These permissions are accomplished inside the Security tab of any file or folder on a Windows file system.File permissions inside the Security tab are sometimes referred to as “NTFS permissions”, but that is not technically accurate. You can define Security permissions on files and folders, whether they are stored on a volume that has been formatted using FAT, FAT32, NTFS, or ReFS. I think the origination story behind calling them “NTFS permissions” is to help distinguish this level of permission from share-level permissions. But in keeping with proper definitions, we should call these File Security Permissions.Logging back into FS01, I navigate to the D: drive where my shared folders are located, and I am going to play around with Security permissions for my Accounting folder. Share-level permissions are Everyone=Full Control, so there are no current restrictions on this folder other than what is inside the Security tab. Right-clicking on the Accounting folder and going into Properties, then the Security tab, I can quickly see the current definition for who has access to this folder. Right from this screen, I could also Edit permissions and Add or Remove Active Directory users or groups of users, and selectively give them read-only access, modify access, or full control access. By default, Administrators have access to this folder (which makes sense), and the general Users group also has some level of access. I don’t like the idea of all Users having access into my Accounting folder, so I have removed that designation and instead added an intentional group called Acct Users. As you can see in Figure 6.11, I have granted anybody who is a member of the Acct Users group to have Modify permissions of data that sits inside the Accounting folder.

Figure 6.11: Adjusting file permissions for the Accounting folder

Let’s define some of these permission options, in case you have any questions there.

Full control = Truly full control of the folder. Users would have the ability to read, write, move, delete, or even come into these permission settings and make adjustments. Typically, the only entities you want to have Full Control permissions are IT administrator accounts.

Modify = Selecting Modify automatically checks boxes for both read and write access.

Read & execute = Allows users to read and open files, and to execute application-type files. The key difference here is that if Modify is not also checked, users will be able to open files but not able to make changes within them.

List folder contents = Allows users to navigate into this folder and to see what other subfolders or files are contained within. This one almost always accompanies Read permissions.

Read = Pretty simple, grants permission to read data from within this folder or file.

Write = Similarly, the Write permission grants access for users to create new documents or folders.

Special permissions = Lots of things. Rather than try to tell you about them here, backtrack to the main Security tab for a folder and then click on the Advanced button. Inside Advanced, you will see a similar permission definition screen, but expanded with some new functions shown. Clicking on one of the permission Principals, such as my Acct Users group, click the Edit button and you will find multiple tiers for crafting special and unique permissions. Some of the reasons you may create your own special permissions are if you want to setup permissions that only apply to one folder and for some reason do not apply to subfolders, or if you want to specifically allow users to be able to modify folder contents, but not to be able to delete anything inside those folders. Those and many more options are available within the advanced permissions screen, for slicing and dicing up your file/folder permissions.

Figure 6.12: Advanced file and folder permissions

It would be almost impossible to discuss every permission scenario that you may encounter, but keep in mind that if you are tasked with a complex requirement for allowing or restricting access in a way that doesn’t seem possible in the simpler permissions screens, the Advanced button opens a whole new world for file and folder permission options.

Use those groups!

When thinking through file and folder permissions, it’s easy to get lost in a whirlwind of who needs access to view things, who needs access to modify things, who doesn’t need access at all…there are so many factors to consider. I find that making use of multiple standardized groups helps tremendously.First, make sure your shared folders do not allow the generic Users directory to have access to it. If you do that, you very well may circumvent real permissions that you put into place on the same folder. Remove Users, and plan to utilize your own groups that are specific to the purpose. I find it extremely helpful to create an Active Directory group for users who need Write/Modify access to each share, and a separate group which grants Read-only access to that same folder.It is also very helpful to your future self to name these groups very specifically, so that you remember 5 years from now that these AD groups are for the purpose of file share permissions, and not other things. Here is an example, once again looking at my Accounting folder, of groups that I would setup in a production customer environment to serve this purpose.Group names:

Folder – Accounting – Read-Only

Folder – Accounting – Read-Write

After creating these groups, we of course add both of them into Security permissions for the Accounting folder, and set their permissions according to their names.

Figure 6.13: Using groups to distinguish read-only versus read-write permissions

Using groups to build file and folder permissions is such a smart thing to do. If you ever find yourself adding an individual user account to file permissions, you are probably doing something wrong. Establishing good habits about folder permissions up front will save you so much thinking and headache down the road. When groups are well defined, adding or removing users from folder permissions is as simple as adding or removing them from AD groups. There is literally no need to even log into the file server. You could, of course, utilize these same group names as specifications inside Item-Level Targeting inside a drive mapping GPO, knocking out two birds with one stone.Now let’s discuss that little button and checkbox shown near the bottom of Figure 6.13. What is all this about inheritance and child object permissions?

To inherit or not to inherit…that is the question

By default, when you configure a root folder and create subfolders and files within, Security permissions from the parent root folder are inherited by all subfolders. Anything contained within that shared folder will have the same permissions, so you know that users who are in the group to grant them access to the folder also have permission to access all items stored within. Unfortunately this is only default behavior, and can be overruled. I am normally a big fan of flexibility in configuration and so from an ideological perspective I think it is wonderful that you can “break inheritance” and cause certain subfolders to no longer pay attention to the permissions of its parent folder. In practice, however, I have only found this to be problematic.In Figure 6.13 you see a button to Enable inheritance. This implies that the folder whose permissions we are viewing is not currently inheriting access controls from its parent folder. That is because we are viewing permissions of a root folder and I intentionally stopped it from inheriting permissions at the D: volume root, thus allowing all of my root folders to be individually managed for permissions. Alternatively, if any folder was inheriting permissions from above, you would instead see a Disable inheritance button listed here. Enabling or disabling inheritance is as simple as clicking that button, although treating this button like an Easy Button is bound to cause you grief. Every time that you enable or disable inheritance, the operating system has to re-hash through all subfolders and files to set permissions accordingly, and in large file server structures with many tiers of data, there is a real possibility that it will run into some kind of problem. Making high-level permission changes to files and folders always comes with a little bit of risk in well-established environments, because a permission change literally rolls through every object one at a time, and if that process is interrupted, it will leave some of your files and folders with new permissions, and others with old permissions.Let me prove to you why it is that I don’t like moving away from standards and disabling inheritance on folders, by telling you a true story that happened literally this week.A company has a drive mapping for a Public space, the folder is literally named “Public” and share permissions are configured that all Domain Users have access to read and write documents into it. Diving into this folder, there are many subfolders that people have added over the years, with one that stands out like a bright red thumb, a subfolder called “HR PRIVATE”. Yikes, that definitely sounds like a folder that you would NOT want to be sitting inside a Public file space! Yet, there it is. At some point, the HR Department decided they wanted to have a private space for their documents, and rather than requesting a new share and drive mapping, they self-created this HR PRIVATE folder and then asked IT to lock it down for them. This is easily done, all you need to do is click that Disable inheritance button and then configure your own specific file permissions on the HR PRIVATE folder. Bingo, that folder is now locked down! I have recreated this scenario in my test lab, and you can see that even though HR PRIVATE exists inside a Public folder space where everyone has access, individualized Security permissions exist on this one folder that only allow the HR Users group to have access to this folder. You can also see in the screenshot that inheritance has been disabled on HR PRIVATE, which is what allows this exception to the rules.

Figure 6.14: HR PRIVATE is currently locked down

Hopefully you already recognize how dangerous this situation is, although as of right now this folder is properly locked down and only users who are either administrators or members of the HR Users group will be able to access the HR PRIVATE folder in any way. As you can properly imagine, the issue that I was asked to help with was that non-HR users were able to access the HR PRIVATE folder, which was really, really bad. Rather than talk through my entire thought process about how this may have happened, let’s take some actions inside this lab to prove that it can easily happen to you.Pretend that our file server is properly configured right now, as I just showed in Figure 6.14, so that HR PRIVATE sits among Public folders, but is itself locked down. Nothing dangerous so far, except for this scenario involving unnecessary risk. Now pretend that your IT staff receive a request that reads something like this: “Please ensure that members of the Contractors group do not have access to get to anything inside the Public share.”Your new Tier 1 engineer perks up, “I can take care of that!” Naturally, he logs into the file server, finds the root folder of the Public share, and heads inside Security permissions. Now, he may not be entirely familiar with all of the options in here, and certainly doesn’t want to make any unnecessary changes, so he simply adds the Contractors group into permissions with a specific Deny permission. So far things are sounding okay, and then he notices that checkbox near the bottom of the permissions window. Replace all child object permission entries with inheritable permission entries from this object. Those words are a little strange, but the ticket request from our CEO did state that they wanted to block Contractors from getting to anything inside the Public share, and this checkbox sounds like it will accomplish exactly that. It’s just a little checkbox, what harm could it cause?Well, it caused exactly the issue that I discovered this week. After making that tiny change at the root level of Public, re-visiting the Security tab of the HR PRIVATE folder now shows me that HR PRIVATE is configured to inherit permissions from above, and it is now denying access to the Contractors group (like every other folder is), but is now allowing read and modify access for all Domain Users in our network.

Figure 6.15: Permissions on HR PRIVATE have been overruled by a root level change

You may be thinking, “I would never allow a green engineer to be changing permissions on the file server”, and maybe that is true. But this scenario can be caused even by senior-level engineers. Maybe you attempted to change permissions on the Public folder and as those permissions were working their way through all files and folders, the process was interrupted and now some subfolders have your new permissions and some do not. You attempt to push those changes again, and it continues to hit some kind of trouble. You yourself may try checking that box to remediate the issue, or you may even turn to deeper command line troubleshooting to try and combat these permission woes, but the whole time you are working from an understanding that the root folder being manipulated is called Public, and assume that all permissions inside Public should be the same. You may have no idea that at some point, years in the past, the HR Department unknowingly requested for those inherited permissions to be circumvented. This situation can become even easier to step into if the differing, non-inherited folder is buried multiple layers deep. If you are adjusting permissions on D:\Public, would you really have any chance in the world to know that a folder such as D:\Public\Scans\MainOffice\HR was disabled from inheritance and should be considered “private”?The moral of this story is not to beat up anybody who contributed to the situation, but rather as a forewarning to plan folder structures and permissions very carefully, and stick to the rules that you put into place. Maybe this means that you decide to never ever disable inheritance on folders, that is one way to keep things clean. If you do click that Disable inheritance button, just remember that you are setting yourself, or someone else, up for possible failure in the future.

Deny always wins

Most often when thinking about file permissions, you will be taking the perspective of granting users access into areas of the file server. However, Microsoft’s stance with pretty much everything is that a denial always trumps an allowance, and the same is true for file share permissions. Referring back to Figure 6.15, you can see that the Contractors group is now denied permission to the HR PRIVATE folder, and indeed that denial permission is actually configured at the root folder called Public. Any user account added to the Contractors group will be a member of both Contractors and Domain Users, but even though their rights as a Domain User would normally allow them access into the Public share, membership inside Contractors means that those users will be denied access to look inside the Public share at all.Whenever adding a Deny permission to a folder, this is pretty clear by reading over the warning prompt that Microsoft displays when saving such a permission.

Figure 6.16: Let’s keep Gru out of this folder

With all of the available tiers of permission, options to enable or disable inheritance for each folder, and denials taking priority over approvals, hopefully you can now understand why thinking through your file shares and taking the time to plan carefully is time well spent.

Effective Access

While we could probably talk all day about different file permission scenarios, let’s end this section with just one more useful tool. When working within and modifying folder permissions, it is a common thing to ask yourself questions like “I wonder if Susie can access this?” or “I hope this change really blocks Gru from accessing the HR folder, how can I confirm that?”Thankfully, that Advanced screen within each folder’s permissions has a tool called Effective Access, which serves exactly this purpose.Going back to my HR PRIVATE example, right-clicking on that folder and going into Properties, then the Security tab and then the Advanced button brings me to a screen we have visited before. What we have not yet done is click on that tab for Effective Access to see what it does. Click on Effective Access, and then click on one of the relevant links to narrow your search down to either a specific user or group inside the domain. Once you have identified a user or group to test permissions against this folder, click the View effective access button, and you will immediately find results for what specific permissions that person or group does or does not have within this folder. Working through that example a couple of times, I can see that Susie (a member of the HR department) has access to read and modify inside this folder, but Gru (a Contractor) does not. I am met with a series of green checkmarks or red x’s, clearly indicating what level of access is available for each of those users.

Figure 6.17: Effective Access is a power tool for reviewing file permissions

Effective Access is a great way to test recent changes and ensure they have taken effect, or to check on a particular user’s level of access without needing to touch their computer or communicate with that user at all.

Distributed File System (DFS)

Proper configuration of a single file server is a great place to begin, but as your company grows you are going to quickly outgrow the notion of one file server providing ownership over all documents. Creating another file server and manually sharing the load is easily done, you could slide some shares onto one server and other shares onto another. Thinking ahead to creating drive map policies for those drives, they begin to feel a little messy. Some file shares pointing at \\FS01 and some at \\FS02, even you may lose track of which server is providing which purpose, and your users certainly won’t care to remember the differences.Distributed File System (DFS) is a system that takes multiple servers who are running multiple shares, and binds them all together under one common DNS name for access. These servers can all be sitting in one physical site, or spread across multiple locations. Instead of accessing files by \\FS01 or \\FS02 and so on, instead users can get to any share they need by simply visiting \\contoso.local (just an example), and DFS takes care of the heavy lifting to determine which file server and share need to be passed along to the user’s File Explorer window. There are two key components to the way that DFS works, DFS Namespaces and DFS Replication.Thankfully, DFS is a technology that is built right into Windows Server! We are able to make use of these abilities without any further purchases or licensing; all it takes is time and knowledge. Let’s build out a DFS environment together.

DFS Namespaces

The core component of DFS, Namespaces are the secret sauce which create a centralized namespace for the purpose of accessing files across the network, even across multiple file servers located in multiple physical sites. A root namespace is established (most often reflecting the name of your internal domain), and that name can then be used for access to files. When accessing those files, users are unaware of where the files are stored. They might be opening files on FS01, FS02, DC1, etc. The point is that they don’t need to care, they simply access \\contoso.local and navigate from there, always knowing that the files they need are somewhere that appears to be centralized and is easy to remember.

Standalone vs Domain-based namespaces

DFS configuration needs to be stored somewhere, of course. One or more servers are responsible for receiving requests from workstations and then deciding where those requests must navigate for successful connectivity. Let’s say LAPTOP1 is asking for \\contoso.local\HR. Who is responsible for telling LAPTOP1 that the HR share is actually located on \\FS02\HR and that is where they need to connect to? The DFS Namespace, which is interactive on one or multiple servers, depending on your choice here.Standalone DFS namespaces are independent, and I almost never find them in the wild. If you are somehow running a Windows environment without a domain, then I suppose this would be your ticket to entry for DFS. A standalone DFS is going to be hosted on a single server, which is a single point of failure, and I do not recommend you pursue this route.Domain-based DFS namespaces are what everybody typically uses. Almost every business network is centered around an Active Directory network, and in such a network enabling DFS in a domain-based fashion is a no-brainer, because your namespace information is stored in Active Directory itself, so that any Domain Controller can respond to those name lookup requests.

Establishing DFS Namespaces

As with most technologies inside Windows Server, the beginning of life for any capability equals the installation of a Role. This is true for DFS. Log into the server that you want to be your first DFS Namespace server, usually this will be your file server but it could also be a domain controller. I am going to add the DFS Namespace role to FS01. (take note of the DFS Replication role that sits alongside DFS Namespaces, as we will make use of replication later in this chapter)

Figure 6.18: Installing the DFS Namespaces role

Once installed, you will find a new toolset inside your Server Manager Tools menu called DFS Management. This will be your home configuring the DFS Namespace and all shares and links that appear inside DFS. Clicking on Namespaces currently shows nothing, because we have not yet created a DFS Namespace. Right-click on Namespaces, and the option for New Namespace… will get us kicked off.First, define the server that will host this new DFS Namespace. This is an important clarification to make. I installed the DFS Namespaces role onto FS01, but I could have just as easily installed the role onto a different server while still wanting FS01 to host the namespace itself. In my simple test lab, and in most production networks I have worked within, we are going to use the same server for this purpose. The role is installed on FS01, and I am going to host the namespace on FS01.Our next screen asks us to define Namespace Name and Settings. This is important, as this name will be visible and similar for every share that you add into DFS. DFS Namespaces, once created, are accessed by UNC paths such as the following (these are all separate examples):

\\contoso.local\DFS

\\contoso.local\Shares

\\contoso.local\Files

When mapping network drives to DFS locations, whatever you specify as the Namespace Name will be reflected in the beginning portion of that mapping. Most often you will use some automated method to map these drives, but in a surprising number of cases, your users will figure out how to manually navigate to your DFS location, because they see it all the time. This is the reason that I like going with something like “Files” for the name, because it is very easy to remember if a user were to attempt to manually navigate to it.Once a name has been defined you will see that Edit Settings… button light up as available to click on. Go ahead and click on that, we won’t make any changes here, but this screen tells you a little bit about how DFS works under the hood. Effectively what DFS is doing is creating a share right here on the FS01 server, that shared folder will be sitting in C:\DFSRoots\Files. At first glance you may want to change that location because you are nervous that you don’t want users to fill up the C: drive of this server. You can certainly change the location of this new DFS-specific share, but it’s not generally necessary. This is because the new C:\DFSRoots\Files folder and share being created will only contain shortcuts to the actual file shares. Those file shares might exist on FS01, or FS02, or any other server. We’ll see that firsthand in just a minute. But it is important to understand that your DFS shared folder specified here will remain very small, as it only contains pointers to other locations.

Figure 6.19: Creating our first DFS Namespace

Next, we select whether this will be a Domain-based or Stand-alone namespace. We already discussed those differences, and 99% of the time you’ll want to stick with the default Domain-based namespace. Gotta love that checkbox left over from years ago to Enable Windows Server 2008 mode. Clearly DFS is a technology that has been around for a long time, and with the release of Server 2008 they made some enhancements to DFS that would have been optional at the time. Apparently they are still optional, but why you would choose not to enable your domain-based DFS namespace to be capable of high availability is beyond me. Go ahead and leave that box checked. Also interesting in this screen is that you see a preview of what your exact namespace is going to look like on the network. I gave you a sneak-peek into this already, but our new namespace is:\\contoso.local\Files

Figure 6.20: Defining our DFS Namespace

Finishing out the wizard, our new DFS Namespace is listed inside the DFS Management console. You can certainly create multiple DFS Namespaces to break up access to certain types of files into separate namespaces, but in our test lab I will focus on just one namespace and add my file shares to it.

Adding folder targets to your DFS Namespace

You may remember that I currently have shared folders scattered all around my network. Some on FS01, certainly, but others on FS02, a couple on DC1, and still more on DC2. Wow, I just now realized that I named all my servers via single-digit numbers except for my file servers where I added an unnecessary zero into the mix. Insert eyeroll (at myself) here.Right now, if we were to open File Explorer from any client computer in this network and navigate to \\contoso.local\Files, File Explorer would open to the location but it would be completely empty. By creating the namespace we have crafted this new centralized share in our domain, but as of this moment there are no shares linked into, or “targeted by”, this namespace. Inside DFS Management, right-click on the name of your DFS Namespace and select New Folder… A simple screen emerges where we define a Name and one or more Folder targets. This is where we get some real action going, we are going to tell DFS about the files and folders that are shared on our network. As you can see in Figure 6.21, I have added numerous folders into my DFS namespace, all pointing at existing file/folder shares around my network. Some of these shares are on FS01, some on FS02, and some even hosted from DC1 and DC2.

Figure 6.21: Adding Folders (targets) to my DFS Namespace

One special note about the Name field. Your shared folders are obviously shared with whatever name you chose for the share back when you created these shares. For example, “HR”. When adding pointers into DFS for these shares, you do not have to call them by the same name. Even though my “HR” folder might be shared as such, I could choose to name this new folder inside DFS “HR Files” as you can see in Figure 6.21, or anything else that I want to call it. The name you define here is the name that will be presented to users when they navigate the namespace.Immediately after creating all these folder links inside my DFS Namespace, I can take two actions to prove that this is really working, and to show you exactly what DFS usage looks like from a user perspective. First, on FS01 when I now open C:\DFSRoots\Files I will see evidence of all the folder shortcuts I just added into DFS. This is part of the magic behind the curtain of DFS, when users hit up your namespace on their computers, they are really being steered to this special shared location, and from there bouncing to the actual shares located on other servers.

Figure 6.22: Folder shortcuts are stored inside the DFSRoots location

And for our final test to prove DFS is working, open File Explorer on any workstation in the environment and navigate to \\contoso.local\Files. You should immediately see all of your shared folders together in one location, even though those shares are spread across four different servers in our environment. In the future whenever you need to visit one of these shared folders, there is no need to remember what server it is stored on. Simply visit the DFS Namespace, and double-click on the folder from there!

Figure 6.23: DFS presents all these shares in one place

Such is the power of DFS!

Re-map your network drives

This section is just a reminder of a common-sense task. Prior to running DFS, you most likely had an extensive network drive mapping policy that was crafting many drive letters on user’s computers. Once DFS is implemented, you may be able to cut down drastically on that policy. If all your shared folders can live alongside each other inside one DFS Namespace, you can now provide users with one single mapped drive, mapping of course directly to the DFS location. Or even if you decide to break your file and folder mappings out into a couple of different DFS Namespaces for privacy and security reasons, you have greatly reduced the amount of network locations at play when dealing with network drive mappings. Be sure to re-visit that policy and clean things up, now that DFS is doing its work.Another huge advantage of using DFS when accessing files is that you have now obfuscated the actual file server names from user eyeballs, and also from things like mapped network drives. This creates a lot of flexibility for growth and maintenance down the road. If you ever need to move a folder share location from one server to another, you can do so silently in the background and user drive mappings never even need to change, because you simply come into DFS Management and tell that shortcut to point at the new location. Or maybe your file server is on its last leg and needs to be replaced with a new one. Build the new server, copy everything to it, and your cutover process takes about 3 seconds as you change those pointers inside DFS to steer at the new server instead of the old one.

DFS Replication (DFSR)

This technology is most commonly referred to as DFSR, but I have also seen it written out as DFS-R, “DFS Replication”, or even “DFS with Replication”. These all mean the same thing. In this section, we are going to enable the second component of DFS file management, which is the ability for servers not only to create shortcut pointers to folders on other servers, but also bind those shared folders together in a special way that replicates data between them. When DFSR is enabled, your file servers can keep files and folders synchronized all the time, even spanning across multiple sites. As a quick real-world example, I just helped someone configure DFSR for an “IT Tools” type of folder. This company has 6 or 7 different offices spread across multiple states, and each office has a local server. By configuring DFSR on one folder in each site, those folders all now stay in sync with each other. The addition of information or tools to one server automatically replicates around to all 6 other sites. In most DFSR implementations, this happens via multi-master replication, or “full mesh” as Microsoft calls it, where an update to any node will be replicated to all other nodes.DFSR is probably already running in your environment, without anyone knowing. Unless you are using very old infrastructure, Microsoft uses DFSR under the hood to replicate some information between Domain Controllers. For example, there is a special folder called SYSVOL that is very important to Active Directory, and when you do things like create GPOs you of course want that policy information to remain consistent among DCs. For this information to be mirrored across your Domain Controllers, the SYSVOL folder is replicated among them all, using DFSR. I say “unless you are using old stuff” because DFSR does have a predecessor called File Replication Service (FRS) that used to accomplish the same function. The problems with FRS were numerous, most notably that it would simply delete information occasionally. As an example, if you were to be running Forest and Domain functional levels of Server 2008 R2 but then introduce a Server 2012 Domain Controller to the mix, everything might run okay for a while. But you may someday perform a simple update to a GPO from your Server 2012 DC, and find out the next day that your entire GPO was deleted. All settings inside it were simply…gone. FRS is troublesome, and newer Domain Controllers all run DFSR to keep themselves inline as a default.Let’s build DFSR together, and the screens we encounter will tell us a little bit more about how DFSR works as we move along.

Enabling DFSR

First, we need to provide shared folders on multiple servers. DFSR is going to take these shared folders and handle replication between them, but the creation of the folders, shares, and sharing permissions are all manual labor that must be accomplished first. Create shared folders on multiple servers, it can be two or three or even ten servers, but just make sure that you setup sharing and file permissions exactly the same on these folders. You wouldn’t want to confuse things by creating differing permissions on different shares, right? Now, even though permissions need to be the same among shared folders, it is interesting to note that the names of those shares do not have to be the same. I could setup two shared folders like this and tie them together in a replication group:

\\FS01\Accounting

\\FS02\Accounting

Or I could add these three shared folders into a single replication group:

\\FS01\Accounting

\\FS02\MoneyStuff

\\DC1\Private

The second set of example share names is much more confusing at surface level, but remember that DFS Namespaces is going to make these folders accessible via a nice and pretty name like \\contoso.local\Files\Accounting. DFSR doesn’t really care what share names it is binding together, but you want share and file permissions to be similar across them all. As your users travel among sites you want them to maintain the ability to access this DFS folder from wherever they are, and no matter which server it is that they are tapping into.Now that you have some folders shared on different servers, we want to make sure that the DFS Replication role is installed onto each of those servers. You don’t necessarily need the DFS Namespaces role installed, but I find it easiest to keep both of those roles installed on all servers where DFS is at play, so you probably want to go ahead and install both the DFS Namespaces and DFS Replication roles onto each of your file servers where you plan to configure sync’d folders.File servers joined to the domain – checkFile shares created – checkDFS Roles installed – checkOpen the DFS Management console, and let’s get down to business. I need to decide which shares on what servers need to be bound together in a replication group. Let’s setup one replication group that spans two servers, and another group spanning three, just to show that this really works. I gave some examples earlier, but here are the real shares that I am going to bind together as replicated folders.Group 1:

\\FS01\Accounting

\\FS02\Accounting

Group 2:

\\FS01\HR

\\FS02\HR

\\DC1\HR

(I do not generally recommend user-facing files to be shared on a domain controller, but since this share already exists inside my test lab, let’s run with it)Inside DFS Management on one of the servers where you have the DFS management tools installed, right-click on Replication, and create a New Replication Group… I am not going to screenshot every available option here, as that would really expand our page count without adding a whole lot of value, but we will certainly look at a few together and we will talk through each step of the wizard as we progress.Our first option is whether to establish a Multipurpose replication group or a Replication group for data collection. There is some good text on this screen defining differences between the two, but for DFS replication groups that users will be accessing on a regular basis, you typically want to choose Multipurpose.Naming your replication group is usually simple, most people name it mirroring the share names that this group is going to be replicating. For my Group 1, I will name it Accounting. Remember that I am creating two separate replication groups, but this means I will be navigating through this wizard two separate times to create the two groups. Group 2 will be called HR, eventually, but I didn’t want to confuse you into thinking that I am somehow doing them both at once. For this first walkthrough I am only working on the Accounting replication group.To add Replication Group Members to this replication group, simply use the Add… button to add your servers where the shared folders are sitting. Inside my Accounting group, I am adding FS01 and FS02.

Figure 6.24: Walking through the wizard to create our first replication group

The Topology Selection screen offers some interesting selections. As you can see, in this first replication group where I only have two file servers defined, my only options are Full mesh or No topology. It is most common across the DFS world for replication groups to be configured as Full mesh. This will tell all replication group members to keep their data in sync among themselves, but it is important to understand the limitation that Full mesh only works well if you have 10 or fewer members in the same group. Hub and spoke is currently grayed out, because I only added FS01 and FS02. For my second replication group that I will create next, I am going to be adding three servers and so I could choose Hub and spoke if I wanted to. This topology is for environments with a lot of member servers, or for scenarios where you expect your data to only be updated on one server (the Hub) and replicated outward to other member servers (the Spokes).

Figure 6.25: Topology Selection choices for your DFS replication group

The Schedule and Bandwidth page is self-explanatory, but a really cool function. Depending on your LAN/WAN capabilities, DFS could soak a lot of bandwidth while users are trying to get their work accomplished. If you find that to be true in your environment (you probably won’t with the massive internet connections we have today), you could visit this page and configure DFS to throttle the bandwidth it is allowed to use, and even set it to only replicate information during certain times of the day. This is a little bit risky if you expect users to update files on both or all of the servers in a replication group throughout the day, you may find yourself with many sync conflicts to deal with.Primary Member reminds me of something I have not yet told you; when creating DFS replication groups you will have to choose the initial source of truth for files. In my current example, I am using an Accounting folder that exists on two separate servers. If both of my Accounting folders already had documents and data inside, this screen allows me to choose which one is the “right one”. Whatever server I choose here will be authoritative during the initial data sync, so make sure you have the correct data on your primary server. Many times when we are setting up DFSR, we are taking an existing share and replicating it to a new share on a new server that is currently empty, which works out very well.Under Folders to Replicate go ahead and add in the folder location that you want DFSR to start replicating. This screen displays an interesting component. So far we have spoken about the Accounting folders in terms of shared folders, but when you select the Accounting folder here, you may notice that DFSR doesn’t care about the fact that it’s a shared folder. Rather, you select the physical path to this folder. In other words, C:\Shares\Accounting on my FS01 server. This implies that DFSR doesn’t require these folders to be shared at all. You would typically have the folders shared from both servers, so that users can tap into these folders (maybe by straight drive mappings, maybe through a DFS Namespace), but there is no requirement for DFSR that the synchronized folders be shared. DFSR can be used to keep folders in sync across multiple servers, whether or not those folders are visible to user’s eyeballs.

Figure 6.26: Defining the primary folder to be replicated by DFSR

After specifying FS01 as my primary replication server, the wizard correctly infers that the other side of this sync group is going to be FS02, and asks me to define what folder path I need to sync to on FS02. Use the Local Path of Accounting on Other Members screen to define the physical folder path on FS02.That’s it! You will now see a summary screen of the DFSR options being put into place, and then a warning that you may have to wait a little while before this replication takes effect. That is because we are using DFSR with Active Directory, and you need to wait for these changes to flow around your domain before FS01 and FS02 will start using the new replication group.I walked through this wizard two separate times, creating one Accounting group and another HR group, as I mentioned near the beginning of this section. Back inside the main screen of DFS Management, you can see both replication groups, now working in the background to keep my folders in-sync with each other!

Figure 6.27: We have now created two replication groups

After giving these new replication groups some time to sync up with each other, let’s make sure this is really working.

Verify it works

If your initial folder on the primary member had a bunch of data already inside it, the fact that DFSR is working might be really obvious. You should see that data sync’d to the specified folders on your other member servers. In my test lab, I didn’t have much stored in those folders, so I am going to add some new folders and files into \\FS01\Accounting, and then add some other folders and files into \\FS02\Accounting. This replicates common user behavior if I had users in two separate sites, each with one file server.

Figure 6.28: DFSR is working!

These files and folders are being immediately replicated between FS01 and FS02! One thing that is important to understand is that DFSR only replicates files once they are closed. If users are creating files and editing them for long periods of time, you may see delays in those file changes being sync’d to other servers. Once the user saves and closes out the file, it will be spread around among the other servers in your DFSR group.

Filter out certain files

DFSR is pretty awesome by default, but there are some more advanced things that can be done with it also. One of those is filtering out certain file types from being replicated. Why would you want to do that? Maybe you are utilizing a shared folder that is part of DFSR, and as an IT guy you are loading in some huge files. For example, an ISO to upgrade Windows Servers. Perhaps DFSR will give you exactly what you want in copying a 6GB file around to a bunch of file servers in your environment, or maybe you are working on a temporary project and you want to ensure that DFSR doesn’t take these huge files and spend resources chugging them around the network when it really isn’t necessary. Another example might be for TMP or BAK files, things that are not generally very important, and you may simply want to give DFSR some breathing room not to worry about these files.Back inside the Replication section of DFS Management, click on the replication group that you want to modify and then visit the tab called Replicated Folders. Inside this tab, you will see the list of folders that this group is syncing. Right-click on the folder you wish to modify, and head into Properties.Here you can see that BAK and TMP files are already being filtered out, even though I did not do that intentionally. All you need to do to exclude a file type, or as you can see in Figure 6.29 you can even exclude an entire Subfolder, simply enter that information into this screen. In my example, I am going to be using a folder called Jordan_Temp for a while to finish a project that I am working on, and I plan to delete this folder when finished, so I don’t want DFSR to spend any time trying to replicate the Jordan_Temp folder.

Figure 6.29: Excluding the Jordan_Temp folder from replication

File Transfer Protocol (FTP)

Most often when discussing file access and protocols in the Windows world, we are talking about classic file sharing and access as has been described so far in this chapter. When a user accesses a regular network drive, this is generally making use of a protocol called Server Message Block (SMB) to browse, open, and save files on the network. SMB has gone through a few iterations over the years, and is certainly safer and more comprehensive than it has ever been, but you still today would not allow SMB to flow natively over the internet because the traffic is easily interceptable. We will talk shortly about a new way to use SMB that is actually safe for use over the internet, but this technology is quite new and in most networks today SMB is strictly for use within company walls, protected behind your firewalls.File Transfer Protocol (FTP) is another protocol used to move files from one place to another, but using different methodology and toolsets. For most purposes, SMB beats out FTP. SMB file shares are easy to create, easy to use, and allow for two-way traffic. You can copy something from a server and paste something back to that server at the same time. FTP is less functionally useful and quite a simple, straightforward file transfer mechanism, but it is valuable to understand what FTP is and how to use it, because there are some use cases where it will be necessary to forego SMB and look for something else. FTP is often this something else.There are two use-cases for FTP that I find to be common. First is to provide a way for non-employees to be able to download or upload documents to your company. I say “non-employees” because your employees will likely have a company laptop with VPN access, and they can simply use their SMB-based network drives to access files and folders, no matter where they are. Non-employees such as customers or vendors will not and should not have such direct access into your network and file servers, but it’s quite common that you need to share files with or retrieve files from one of these entities. Many times these files are simply too large to be emailed, at which point you begin to explore solutions for moving files in and out of your network through the firewall. FTP can be used for exactly this purpose.The second reason I see FTP being commonly utilized is primarily in the manufacturing industry, but I’ve even seen it with some healthcare devices. Let’s pretend that you have a really expensive piece of machinery, some kind of CNC. These can run millions of dollars when new, so you’ve sourced a used one for only a few hundred thousand dollars. The trade-off here is that this machine was built in the year 2004. Now, that may seem really old, but in the world of high-dollar machines it simply means that it has proven its worth and has probably been rebuilt/restored a few times through those years. It can still be an extremely useful tool for making parts and money, who cares if it’s old? Well, you as the IT guy should care because old=insecure, but you absolutely do not get a vote in decisions like this. Without even realizing it is coming, suddenly this CNC is being installed on the shop floor. Whatever, it’s a piece of machinery, what does it matter to me? Then you watch as they string a CAT6 cable over to said machine, and plug it in. Hmm…I wonder what the purpose of that cable is? You’ve probably guessed by now, this CNC machine requires programming files to know how to run its jobs, and those files can be transferred to/from the machine via network. It was a beautiful thing in 2004, plug-and-play and your Windows XP and Server 2003 machines could interact with this equipment all day long.In some of these cases, the machinery doesn’t know anything about SMB. In others, it may well be capable of receiving files via SMB, but only the early SMBv1 which has now been essentially outlawed by Microsoft due to how insecure it is. In either case, you’re facing a real challenge because you are now tasked with figuring out a process that operators can follow to push programming files at this CNC. Enter FTP. I have seen a lot of these machines, and faced this scenario dozens of times, and it is almost always true that the machine is capable of establishing an FTP connection with an FTP server. Is it clunkier than SMB? Sure. But when the only other option is that operators in the company physically carry their programming files back and forth to the machine via USB stick, FTP is suddenly looking quite fancy.

FTP vs FTPS vs SFTP

FTP is not encrypted traffic, so it is risky pushing standard FTP over the internet. There are two ways to enhance security of FTP-like file transfers, FTPS and SFTP. Let’s describe some key differences between them, if nothing else this will help you to be able to quickly determine which one is at play when you step into an already-established environment.FTP is straightforward file transfers. These connections may be authenticated, but not encrypted. When setting up FTP or reviewing firewalls that host FTP connections, you’ll find inbound port 21 being used, as well as a “passive” port range. FTP transmissions require large groups of ports to be dedicated to FTP, because every client who reaches in to the FTP server will begin on port 21, and then dynamically utilize one of many other ports to accomplish the file transfer.FTPS is FTP with an added layer of TLS security. You may still find port 21 being used at the firewall level, but more likely it will be configured to use port 990. There will still be a passive port range identified on the firewall as well. You should really try to setup any FTP connection with this extra layer of security, running generalized FTP over the internet is quite risky in today’s world.SFTP is often confused with FTPS, but they are totally different. SFTP is still all about transferring files from one place to another, and in a secure fashion, but SFTP is not actually “FTP traffic” at all. Rather, SFTP is the SSH file transfer protocol and uses SSH to do its work. If you’ve worked with FTP servers before, you may even think right now that you can correctly identify FTP or FTPS by looking for either port 21 or 22 on the firewall, but if you find port 22 at play, you are actually looking at SFTP, this SSH-based protocol. It’s not even real FTP!

Create a Windows FTP Server

To be honest, there are non-Microsoft FTP server solutions that are much more popular than the Windows Server FTP offering. These third-party options are more intuitive to setup, and offer clearer security settings. One of the common FTP solutions to find in smaller companies is called FileZilla, primarily because it has a free option. This toolset does quite a great job of providing a really fast way to setup FTP connections between clients and servers, by installing FileZilla on both ends of the equation.This is a book about Windows Server 2025, so let’s take a quick look at what it takes to build an FTP server using native functionality built into the operating system.

Install the Role

As with anything inside Windows Server, there is a role built for the purpose, but this one isn’t so easy to find. FTP Server is a component of Web Server (IIS). On the primary screen to select your new server role, you will need to check the box next to Web Server, and then click Next a couple of times to find yourself at the Select role services screen. Here you see a breakdown of all the different options and components of the Web Server role, and FTP Server is one of the selectable options here.

Figure 6.30: Finding and installing the FTP Server role

Configure FTP services

Role now installed, you’ll notice that Server Manager does not contain a tool that is named anything related to FTP. Rather, just like the role itself, you must utilize the web server tools to configure this server as an FTP server. Web services on a Windows Server are served up by Internet Information Services (IIS), and so this management console is the one used to create both websites as well as FTP listeners.Launching IIS Manager, if you click on the name of your server in the left window tree, you will see many available icons for manipulating different aspects of FTP. As of right now there is no FTP listener published on this server, but poking around in these buttons will help to shed light on the configurable options available to you.

Figure 6.31: FTP configurable options inside IIS Manager

We are interested in a couple of specific ones and will discuss them further below.

FTP SSL Settings – As previously discussed, secure flavors of FTP include TLS, which requires an SSL certificate. We will talk more about certificates in Chapter 7, but I want to point out this function because this is the applet you can visit to define the SSL certificate used by FTPS, or to swap out an expiring certificate with a fresh one annually.

FTP Firewall Support – Here you define which range of ports are to be used by FTP. You will also notice a field in this screen to identify the External IP Address of Firewall. Now, you certainly shouldn’t plug this Windows FTP Server directly into the Internet. Rather, we assume that you are going to NAT traffic inbound through your firewall toward this FTP server. Configuring the public IP address that clients are going to utilize to contact your firewall on this screen allows for the FTP server to passively accept those connections, even though they are passing through a third party first (the firewall). After defining port information in this screen, IIS will reach into your Windows Firewall with Advanced Security ruleset and establish firewall rules locally on the server, allowing this traffic to be successful.

FTP Authorization Rules – Use this section to specify what users are allowed to read or write via FTP. For my example today, I am specifying that Anonymous Users have both Read and Write permissions.

Once you are happy with your selections on this screen, our last step is to “publish” FTP from this server. In other words, we are going to tell the server to start listening for FTP client connections to come in via the FTP control port, typically port 21.Still inside IIS Manager, right-click on the Sites folder and select the option to Add FTP Site…Name your site, and select a physical path. This is a folder on the local server that will be used to store and present data to FTP clients. When a client connects to this FTP site to pull data, it will be data from within this folder. On the flip side, if an FTP client logs into FTP to upload a file, that new file will be dropped into the defined folder.

Figure 6.32: Establishing our first FTP site

If you’d like to run multiple FTP listeners on the same server, this is very possible but you need to identify either a unique IP address for each one, or a unique control port. On our Binding and SSL Settings screen, you will find options for defining the IP address binding and port for your new FTP site. You will also find SSL certificate settings. Since I do not yet have any SSL certificates in my environment, I am going to setup this FTP site for No SSL, but obviously a production environment that is exposed to the internet should be protected behind an SSL certificate and require SSL.

Figure 6.33: Configuring binding and SSL settings for this site

The last setup screen for our FTP site is to identify authentication requirements for this new site. If you’d like any and all clients to tap into it, choose Anonymous. If you would like to restrict the FTP server to only be contactable by certain domain users or groups, choose the option for Basic authentication and select your user or groups as needed.That’s it! FTP is now listening via port 21 on this server, and we should be able to tap into it from an FTP client running on a workstation.

Test file transfer via FTP

An FTP server isn’t very useful unless you have some clients who are connecting to it! There are numerous ways that a client can tap into an FTP server, but most often it is through a software application specifically made for transmitting files via FTP. One of those we already mentioned, a freebie called FileZilla. For our example today we will utilize another free FTP app called WinSCP, which is quite popular in the wild.You can download WinSCP for Windows from their website, winscp.net.Once installed, launching WinSCP and connecting to your first FTP site is straightforward. Simply configure the name or IP address of the FTP server, the port it is running on, which protocol you want to use and whether it requires encryption to make the connection. If you have required username/password for login, go ahead and specify it here as well.

Figure 6.34: Using WinSCP to tap into the new FTP listener

When connected, WinSCP will show your local file system of the workstation in the left windowpane, and the remote FTP server’s folder structure on the right. You can see in Figure 6.35 that there are already some files inside the FTP server that are easy to grab and download from here, or I can choose files from my local computer to “push” at the server, uploading them into the C:\FTP folder on that server.

Figure 6.35: WinSCP is an easy way to download/upload files to an FTP server

Again, using FTP to transfer files around your internal network is not the greatest thing since sliced bread. There are much easier ways to do that, namely traditional drive mappings that use the SMB protocol. However, FTP has its place and is great information to keep in your back pocket. The next time you are struggling through getting files back and forth between a server and manufacturing equipment, Linux-based appliances, or even copy machines…remember that FTP could be your golden ticket!

SMB over QUIC

Numerous methods exist for users to access their documents. We have looked over a few together in this chapter, and there are others that we simply don’t have time to discuss in depth. More and more of the general workforce is on the road or working from home, and many companies have turned to OneDrive, SharePoint, and even Azure Files to provide new and different ways for file access to happen without requiring a constant VPN connection back to the office.Even though the preceding paragraph is true, there are so many companies still making use of classic Windows file servers, and entrance into something like SharePoint is a heavy lift, because it greatly moves everybody’s cheese. The user experience is vastly different. Classic file access via File Explorer and mapped network drives is still the preference of almost everybody working inside an office, but this uses the SMB protocol that is not inherently safe to publish over the internet. What if we could pull a magic lever, and give all employees access to their files via mapped network drives inside File Explorer, but that this access would work whether employees are inside or even outside of their office?Hello, SMB over QUIC! As mentioned, there is no way that you as a security-conscious administrator would permit native SMB, which uses TCP port 445, to flow over the internet. What is the “QUIC” part of SMB over QUIC? Effectively, it means that these SMB connections are now encrypted! Most firewalls will (and should) block TCP 445, so SMB over QUIC pushes itself through firewalls by utilizing port 443, similar to HTTPS traffic. SMB over QUIC technically uses UDP port 443, though in a lot of installations it makes use of both TCP 443 for something called KDC Proxy and also UDP 443 to carry the workload. SMB over QUIC is encrypted via TLS 1.3, so it is quite secure and protected.I mentioned the KDC Proxy and if you haven’t heard of this before, it is an authentication component that underpins a few Microsoft technologies. KDC Proxy is what causes the authentication magic to happen, where your SMB file connections can be successfully authenticated to a domain controller, even though that DC server is certainly not going to be exposed to the internet. If KDC Proxy makes use of TCP 443, yes that does mean that the server you utilize for SMB over QUIC cannot be serving other web-facing purposes, such as hosting a website. You would certainly not want to combine these roles. Whatever server you use to host SMB over QUIC file access, let that guy be a file server and nothing else. One question that may pop into your mind as you think through what this could look like in your environment, can my SMB over QUIC server also be a “normal” file server? Yes! One of these servers can run regular file connections inside the network using TCP 445, while at the same time serving up files via SMB over QUIC using TCP/UCP 443 for those coming in from the internet, through your firewall.SMB over QUIC has been available to us for a few years, but previously you could only make use of this technology by deploying that special version of the operating system, Windows Server 2022 Datacenter: Azure Edition. The big news here is that with the release of Windows Server 2025, Microsoft has now enabled SMB over QUIC to work from any version of Server 2025!

Deployment via WAC

To make use of SMB over QUIC in your environment, you need to perform the following:

Build a file server running Windows Server 2025 or 2022 Datacenter: Azure Edition.

Identify a public DNS name to use for these connections, such as files.contoso.com, and install an SSL certificate to the file server that can validate and protect that name. Your SSL certificate must protect both this public name and the internal hostname of your server, so that SMB over QUIC can be successful whether users are inside or outside of the network. In our example, I have configured my SSL certificate to protect the following DNS names:

Files.contoso.com

FS02.contoso.local

Configure networking from the internet inbound to this server. Use your firewall to NAT traffic from a public IP address (where files.contoso.com resolves) to flow inbound to this new file server. You need to allow TCP and UDP port 443 to flow, and make sure you do NOT allow TCP 445! This would be a sure way to ask bad things to happen in your network.

Configure the file server to be enabled and listening for SMB over QUIC requests. This part is fairly simple, but there is an inherent complication here as of the time I am writing these words because Microsoft has not yet updated Windows Admin Center (WAC) to be able to enable SMB over QUIC on Server 2025. I genuinely hope that by the time you are reading this, that stance has changed and you can now make use of WAC to deploy SMB over QUIC to your new Windows Server 2025 machines, but for the time being, these are the rules when configuring SMB over QUIC:

Windows Server 2022 Datacenter: Azure Edition = Installation via WAC or PowerShell

Windows Server 2025 = Installation via PowerShell

We will walk through configuration via both methods, in case one fits your needs better than the other. Inside WAC, it is very straightforward. We already have WAC running in this test lab, all I need to do is log into it, make sure it is configured to know about my new file server, and update one setting. I have already installed an SSL certificate onto the FS02 server for files.contoso.com.We are logged into WAC and have navigated to the FS02 server. Here we visit Settings, and the first screen that should be shown displays settings for File shares (SMB server), but if yours does not default to this, navigate to these settings. There are a few interesting SMB-related settings on this page, but the section to Configure SMB over QUIC is a simple button near the bottom.

Figure 6.36: Configuring SMB over QUIC via Windows Admin Center

After clicking the Configure button, you will see all available options for configuring SMB over QUIC. With a few simple mouse clicks, we select the SSL certificate that needs to be used to protect this traffic, then choose the checkboxes for which DNS names clients will be contacting. The configuration wizard pulls these names from the SSL certificate, and it is very important that your certificate, and therefore these checkboxes, reflect both the internal and external names. In Figure 6.37 you can see both files.contoso.com and fs02.contoso.local DNS names are going to be part of this configuration.

Figure 6.37: Configuring SMB over QUIC options

After those few selections, click the Enable button, and WAC reaches out to the file server to configure what is needed for SMB over QUIC to begin accepting connections!

Deployment via PowerShell

Once again, I really hope that Microsoft has permitted SMB over QUIC on Windows Server 2025 to be configured by WAC by the time you are reading these words, but just in case they haven’t, or if you prefer PowerShell anyway, there is also a quick way to enable SMB over QUIC on Windows Server 2025 by using CLI. Let’s work through that together.Once again, I am assuming that you already have your valid SSL certificate installed on this file server. Once you do, open PowerShell and work through the following cmdlets:

Show your installed certificate with this command:

Get-ChildItem -Path Cert:\LocalMachine\My

Plug your certificate into a variable that PowerShell can use moving forward. Obviously you’ll want to swap out files.contoso.com with your own DNS name:

$serverCert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -Match "files.contoso.com"}

Verify it correctly pulled your certificate info into the variable:

$serverCert

Enable SMB over QUIC, telling it to make use of your certificate. You’ll need to once again replace my DNS name with your own:

New-SmbServerCertificateMapping -Name files.contoso.com -ThumbPrint $serverCert.Thumbprint -Storename My

Figure 6.38: Configuring SMB over QUIC through PowerShell

That’s it! I now have SMB over QUIC running on my FS01 server, courtesy of PowerShell. Earlier I enabled SMB over QUIC on FS02 by configuring that server via WAC, and if I open Terminal on either of these servers and run a netstat -ano, I can see in the output that both servers are listening on TCP 445, which is expected simply because both of these are file servers, but they are also now listening on TCP 443 and UDP 443, which are the ports used by SMB over QUIC.

Figure 6.39: FS02 is now listening on TCP and UDP 443, ready for SMB over QUIC connections

I do want to add a note here that even though Microsoft’s official stance is that you can only utilize PowerShell to configure SMB over QUIC on Windows Server 2025, inside my test lab I just successfully utilized WAC to configure SMB over QUIC on FS02. You probably noticed that FS02 is running Windows Server 2025, so this is the exact scenario Microsoft calls out in their documentation that is currently not supported, and yet it worked just fine for me today. I’m not advocating that you work against Microsoft documentation, but it’s entirely possible that their Microsoft Learn document simply needs some updating.

Testing it out!

I enabled SMB over QUIC on two different file servers, but only because I wanted to show the differences between WAC and PowerShell configuration methods. I would love to test and make sure this is really working from a client computer, and I will focus on the FS02 file server for this. One prerequisite is that I need the files.contoso.com name to resolve to the FS02 server, so I have of course configured DNS to do this. In the real world, I would use my edge firewall to configure a NAT rule to push TCP 443 and UDP 443 at FS02 from a public IP address, and then I would configure my public DNS also to point files.contoso.com at this public IP address. The problem with that in my test lab is that I have built this lab specifically blocked away from the internet, and I cannot show you that exact scenario.So instead, I will use a local firewall rule on FS02 to block inbound TCP 445 traffic. If I block inbound TCP 445, this will break any ability for client workstations to access shared folders on this file server using normal, inside-the-network SMB, and force those clients to attempt access using SMB over QUIC instead. After creating this block rule inside Windows Firewall with Advanced Security, I have verified that I can no longer access my \\FS02\Scans folder, or any of the other folders shared from that server.

Figure 6.40: TCP 445 is blocked on FS02, I can no longer access file shares

Except…if, instead of trying to access \\FS02\Scans from my client computer, I instead navigate my File Explorer to \\files.contoso.com\Scans …. Success!! In a traditional environment with an inbound firewall and public IP addresses, I would be able to access files shares from the internet, outside of my building, even without building a VPN tunnel.

Figure 6.41: SMB over QUIC is working!

Although we have proven here that SMB over QUIC is working, by blocking TCP 445 and still being able to navigate files through our files.contoso.com name, your users are generally not going to remember that they need to open File Explorer, visit the address bar, and manually type in this destination. How can we translate these new file paths into traditional drive letter mappings? Let’s explore that next.

Mapping SMB over QUIC network drives

“How do I map network drives using SMB over QUIC?” The short answer is that you do this exactly the same way you would map any network drive.In current client workstation operating systems, the net use command attempts to connect using TCP 445, and if not available fails over to UDP for SMB over QUIC. So you can get away with regular old commands such as this:

Net use S: \\files.contoso.local\scans

(tries TCP to see if you’re inside the network, then flips over to UDP)If you wanted to force a client to map their drive using SMB over QUIC, and bypass TCP 445 altogether, you can tag your net use command with the following bits:

Net use S: \\files.contoso.local\scans /TRANSPORT:QUIC

(skips TCP and goes directly to UDP)

Summary

Administration of your files can take on many forms. How does that saying go? This is data’s world, we’re just living in it. Sometimes we cannot control whether users make good decisions about how they work within files, but at least we can know that we have provided them with a safe, protected, and redundant mechanism for accessing those files. Automating your drive mappings can save much time and effort. Making use of DFS and especially adding onto that acronym by spinning up DFSR can make life easier for your workforce and creates efficiencies for traveling users. While we as a population continue to become less and less patient with multiple steps to perform any task, Microsoft continues to innovate within the age-old topic of file access, by releasing a game-changer like SMB over QUIC so that remote users can now access their files without having to connect that clunky VPN.One of the trickiest bits about working on this Mastering book series is deciding what content is appropriately included. This largely depends on you, the audience, and what I have found over the years is that we have an extremely wide range of experience, backgrounds, and skillsets perusing these words. If you are someone who has followed along with previous editions of the book, released in the same cadence as Microsoft releases new versions of Windows Server, you may have realized that I like to include at least one brand new, from-scratch chapter inside each new edition. Chapter 6 has been that new chapter. Is file management a new idea as of Windows Server 2025? Absolutely not. Proper administration and safekeeping of company files is a core function of any server administrator, I simply bypassed this topic in previous editions. Following the release of Mastering Windows Server 2022, I received numerous feedback strands asking for information about file management, specifically about DFSR. I hope this chapter has filled in those gaps!

Questions

On a shared folder, do permissions under the Share tab or the Security tab take priority?

When mapping network drives via GPO, are these settings stored in the Computer Configuration or User Configuration section of the policy?

As more companies move into cloud environments, how would you automate the mapping of network drives on your client computers, if those computers are joined to Entra and not part of a local domain?

If Tom has access to the entire HR directory today, what change could you make to block his access to the subfolder HR\Payroll?

What is the minimum number of member servers required to create a hub-and-spoke DFS Replication Group?

When creating a DFS Namespace, what kind of information is stored inside C:\DFSRoots? (assuming you chose default options when creating the namespace)

Which free FTP client software did we utilize to connect into our FTP server?

When issuing the SSL certificate used by SMB over QUIC, which two DNS names must be included inside that certificate’s DNS names?

What ports are used by SMB over QUIC, when KDC Proxy is enabled?

7 Certificates

Join our book community on Discord

https://packt.link/zYovf

“Gross, it says we need to use certificates to make this work.”

Real-life quote from any admin after discovering their latest software purchase requires the use of certificates

If the quote above sounds familiar, or perhaps even a variant more colorful than this, you are not alone! But take heart, let’s not scrap that new project just yet. For some reason, the use of certificates seems like a daunting task to many of us, even those who have worked in IT for many years. I think this is probably because there are many different options available on a certificate server, but there is not a lot of common sense or user-friendliness built into the management console for dealing with certificates. This, combined with a general lack of requirements for certificates on servers for so many years, means that, even though this technology has existed for a long time, many server administrators have not had the opportunity to dig in and deploy certificates for themselves. I regularly deploy a couple of technologies that require the broad use of certificates in an organization, often needing to issue them to every workstation or user in the network, and I hear these kinds of concerns all the time. Issuing a certificate to a single business-critical webserver sounds daunting enough if you don’t have any experience with the process, let alone issuing hundreds or thousands of certificates across the company.Another common scenario is one where a company determines certificates to be in their best interests but lacks the on-staff resources to make it happen and so hires a third party to implement certificates within the network. While this gets certificates rolling, it often leaves a knowledge gap that never gets filled, so you may have a certificate server up and running, but not be at all comfortable with modifying or utilizing it. Certificates expire, often after one year, and your newly purchased and installed certificates might carry you through the next 364 days, and suddenly stop working if you don’t have the knowledge to manage them.The broad term for a certificate environment is public key infrastructure (PKI). I call that out specifically because you will probably see PKI listed in documentation or requirements at some point if you haven’t already. Your PKI is provided by servers in your network, and helping you to understand how to configure those servers to issue certificates is the purpose of this chapter.The servers that you determine to be your certificate servers are known as certification authority (CA) servers, and we will refer to them as CA servers throughout this book.To get you started with using certificates in your network, here are the topics that we will cover in this chapter:

Common certificate types

Planning your PKI

Creating a certificate template

Issuing certificates

Creating an auto-enrollment policy

Obtaining a public authority SSL certificate

Exporting and importing certificates

OpenSSL for Linux webservers

Common certificate types

There are several different types of certificates that you may find a need to publish. As you will soon see, when you need a certificate that has a list of particular requirements, you can build a certificate template to match whatever specifications you like. So, in a sense, there aren’t really certificate types at all, but just certificate templates that you scope to contain whatever pieces of information are needed for that certificate to do its job. While this holds true technically, it is generally easier to segment certificates into different groups, making them more distinguishable for the particular job that they are intended to perform.

User certificates

As the name implies, a user certificate is one used for purposes that are specific to the users holding those certificates. One driving force behind higher levels of certificate adoption in general is strengthening the network authentication process. Companies that are looking into stronger authentication in their environments often look at certificates as part of that authentication process. Smart cards are one of the mechanisms that can be used for this purpose, specifically, some sort of physical card to be plugged into a computer in order for the user to gain access to that computer.Smart cards can also be stored virtually within a special place on modern machines, called the TPM. But that is a discussion for a different day. The reason we mention smart cards here is that, often, the core functionality of smart-card authentication is provided by a user certificate that has been stored on that smart card. If you find yourself in the middle of a project to deploy smart cards or some form of physical key login, you will probably find yourself in need of a PKI.Another popular strong authentication form is one-time password (OTP), a function of multifactor authentication. These OTPs require the user to enter a randomly generated PIN in addition to their regular login criteria, and in some cases, when the user enters their PIN, they are issued a temporary user certificate to be used as part of their authentication chain.Additional places where user certificates are commonly found include when companies employ file-encrypting technologies, such as EFS (short for Encrypting File System), or when building up virtual private network (VPN) systems to enable remote users to connect their laptops back to the corporate network. Many companies don’t want to rely purely on a username and a password for VPN authentication, so issuing user certificates and requiring that they be present to build that VPN tunnel is commonplace.

Computer certificates

Often referred to as computer certificates or machine certificates, these guys get issued to computers to assist with the interaction between the network and the computer account itself. Technologies, such as SCCM, that interact with and manage the computer systems regardless of which users are logged in to those computers make use of computer certificates. These kinds of certificates are also used for encryption processing between systems on the network, for example, if you were interested in using IPsec to encrypt communications between clients and a highly secure file server. Issuing computer or machine certificates to the endpoints within this communication chain would be essential to make that work properly. I often find myself issuing computer certificates to a business’ machines to authenticate DirectAccess tunnels, a form of automated remote access. There are many different reasons and technologies you may be interested in that require the issuance of certificates to the client workstations in your environment.

SSL certificates

If you find yourself in the middle of the certificate road, where you haven’t really managed a CA server but you have at one point issued and installed some kind of certificate, chances are that the certificate you worked with was an SSL certificate. This is by far the most common type of certificate used in today’s technology infrastructure, and your company is more than likely using SSL certificates, even if you are not aware of them and do not have a single CA server running inside your network.SSL certificates are most commonly used to secure website traffic. Any time you visit a website and see HTTPS in the address bar, your browser is using an encrypted packet stream to send information back and forth between your computer and the webserver that you are talking to. The webserver has an SSL certificate on it, and your browser has checked over that certificate before allowing you onto the web page, to make sure that the certificate is valid and that the website really is what it says it is. You see, if we did not use SSL certificates on websites, anyone could impersonate our site and gain access to the information being passed to the website.Let’s provide a quick example. Let’s say one of your users is at a coffee shop, using public Wi-Fi. An attacker has figured out a way to manipulate DNS on that Wi-Fi network. Your user tries to visit mail. contoso.com to access the company’s Outlook Web Access to check their email, but the attacker has hijacked that traffic and the user is now accessing a website that looks like their company portal but is actually a website hosted by the attacker. Your employee types in their username and password, and bingo, the attacker now has that user’s credentials and can use them to access your real network.What prevents this from happening every day in the real world? SSL certificates. When you force your externally facing websites, such as that email login page, to be HTTPS sites, it requires the client browsers to check over the SSL certificate that is presented with the website. That SSL certificate contains information that only you as a company have; it cannot be impersonated. This way, when the users access your real login page, the browser checks out the SSL certificate, finds it to be correct, and simply continues on its merry way. The users never even know they are being protected except for the little lock symbol up near their browser’s address bar. On the other hand, if their traffic is being intercepted and redirected to a fake website, the SSL certificate check will fail (because the attacker would not have a valid SSL certificate for your company website name), and the user will be stopped in their tracks, at least to read through a certificate warning page before being able to proceed. At this point, the user should back off, realize that something is wrong, and contact IT staff to investigate the issue.SSL certificates used by websites on the internet are almost never provided by your internal CA server but by a public certification authority. You have probably heard of many of them, such as Verisign, Entrust, DigiCert, and GoDaddy. Companies generally purchase SSL certificates from these public authorities because these authorities are trusted by default on new computers that users might purchase in the field. When you buy a new computer, even straight from a retail store, if you were to open up the local store of certificates that exists out of the box on that system, you would find a list of trusted root authorities. When you visit a website protected by an SSL certificate issued from one of these public authorities, that certificate, and therefore the website, is automatically trusted by this computer. The public CAs are publicly recognized entities, known for their capacity to securely issue SSL certificates.When a company acquires an SSL certificate from one of these public authorities, there is an in-depth verification process that the authority goes through to make sure that the person requesting the certificate (you) is really someone working with the proper company and authorized to issue these certificates. This is the basis of security in using SSL certificates from a public CA. All new computers know by default to trust certificates that have been issued by these authorities, and you don’t have to take any special actions to make your websites function on the internet. On the other hand, it is possible to issue SSL certificates from a CA server that you built yourself and have running inside your network, but it requires a couple of things that make it difficult, because your CA server is obviously not trusted by all computers everywhere, nor should it be. First, if you want to issue your own SSL certificate for use on a public website, you need to externalize at least part of your internal PKI, known as the certificate revocation list (CRL), to the internet. Any time you take a component that is internal to your network and publicize it on the internet, you are introducing a security risk, so unless you absolutely have to do this, it is generally not recommended. The second reason it is difficult to utilize your own SSL certificates on public websites is that only your own company’s domain-joined computers will know how to trust this SSL certificate. So, if a user brings their company laptop home and uses it to access their email login page, it will probably work fine. But if a user tries to access the same email login page from their home computer, which is not part of your domain or network, they will get a certificate warning message and have to take special steps in order to gain access to the website. What a pain for the users. You should never encourage users to accept risk and proceed through a certificate warning message—this is a recipe for disaster, even if the certificate they are clicking through is one issued by your own CA. It’s a matter of principle never to accept that risk.These issues can be alleviated by purchasing an SSL certificate from one of those public CAs, and so purchasing these kinds of certificates is the normal and recommended way to make use of SSL on your publicly facing websites. Websites that are completely inside the network are a different story, since they are not facing the internet and their security footprint is much smaller. You can use your internal CA server to issue SSL certificates to your internal websites, and not have to incur the cost associated with purchasing certificates for all of those websites.There are a few different tiers of SSL certificates that you can purchase from a public CA, information for which is listed on the authority’s own websites. Essentially, the idea is that the more you pay, the more secure your certificate is. These tiers are related to the way that the authority validates against the certificate requester, since that is really where the security comes into play with SSL certificates. The authority is guaranteeing that when you access the page secured by their certificate, the certificate was issued to the real company that owns that web page.Other than the validation tier, which you get to choose when purchasing a certificate, there is another option you have to decide on as well, and this one is much more important to the technical aspect of the way that certificates work. There are different naming conventions available to you when you purchase a certificate, and there is no best answer for which one to choose. Every situation that requires a certificate will be unique and will have to be evaluated individually to decide which naming scheme works best. Let’s quickly cover three possibilities for an SSL certificate naming convention.

Single-name certificates

This is the cheapest and most common route to take when purchasing a certificate for an individual website or web service. A single-name certificate protects and contains information about a single DNS name. When you are setting up a new website at portal.contoso.com and you want this website to protect some traffic by using HTTPS, you would install an SSL certificate onto the website. When you issue the request to your certification authority for this new certificate, you would input the specific name of portal.contoso.com into the Common name field of the request form. This single DNS name is the only name that can be protected and validated by this certificate.

Multi-domain or subject alternative name certificates

Multi-domain certificates, sometimes called subject alternative name (SAN) certificates, generally cost a little bit more than single-name certificates, because they have more capabilities. When you request a SAN certificate, you have the option of defining multiple DNS names that the certificate can protect. Once issued, the SAN certificate will contain a primary DNS name, which is typically the main name of the website, and further, inside the certificate properties, you will find listed the additional DNS names that you specified during your request. This single certificate can be installed on a webserver, or perhaps multiple servers, and used to validate traffic for any of the DNS names that are contained in the certificate. Now don’t laugh, yes I do realize that Lync is discontinued and even Skype for Business is leaving us, now that Teams has taken over the world, but an on-premise Lync server is a prime example of a technology that required the use of multi-domain certificates that protected numerous DNS names. Another example would be an on-premise Exchange server. Either of these technologies use many different DNS names, but all names sit within the same DNS domain. Here is an example list of the names we might include in a single SAN certificate for the purposes of Lync:

Lync.contoso.com (the primary one)

Lyncdiscover.contoso.com

Meet.contoso.com

Dialin.contoso.com

Admin.contoso.com

These different websites/services used by Lync were then implemented across one or multiple servers, and you could utilize the same SAN certificate on all of those servers in order to validate traffic that is headed toward any of those DNS names.It is possible to include multiple names in a SAN certificate that really have nothing to do with each other, and are used by completely different types of systems within your environment. For example, if you have an email portal, RD Gateway, and a VPN solution, you could certainly acquire one SAN certificate with the following names:

Mail.contoso.com

Gateway.contoso.com

VPN.contoso.com

The above certificate would be a little weird, and not a common thing to find in the real world. Instead, when facing the need to use a single certificate across multiple systems, it is much more common to purchase…

Wildcard certificates

Last but certainly not least is the wildcard certificate. This is the luxury model, the one that has the most capabilities, gives you the most flexibility, and at the same time offers the easiest path to implementation on many servers. The name on a wildcard certificate begins with a star (*). This star means any, as in anything preceding the DNS domain name is covered by this certificate. If you own contoso.com and plan to stand up many public DNS records that will flow to many different websites and webservers, you could purchase a single wildcard certificate with the name *.contoso.com, and it may cover all of your certificate needs.Typically, wildcards can be installed on as many webservers as you need, with no limit on the number of different DNS names that they can validate. I have run across an exception to this once, when a particular customer’s agreement with their certification authority specified that they had to report and pay for each instance of their wildcard certificate that was in use. So watch those agreements when you make them with your CA. Most of the time, a wildcard is meant to be a free-for-all within the company so that you can deploy many sites and services across many servers and utilize your wildcard certificate everywhere.The downside of a wildcard certificate is that it costs more, significantly more. But if you have large certificate needs or big plans for growth, it will make your certificate administration much easier, faster, and more cost-effective in the long run.

Planning your PKI

Since we are revolving all of our discussion in this book around Windows Server 2025, this means that your internal CA server can and should be one provided by this latest and greatest of operating systems. As with most capabilities in Server 2025, the creation of a certification authority server in your network is as simple as installing a Windows role. When you go to add the role to a new server, it is the very first role in the list, Active Directory Certificate Services (AD CS). When installing this role, you will be presented with a couple of important options, and you must understand the meaning behind them before you create a solid PKI environment.

Your server’s hostname and domain status cannot be changed after implementing the CA role. Make sure you have set your final hostname and joined this server to the domain (if applicable), prior to installing the AD CS role. You won’t be able to change those settings later!

Role services

The first decision you need to make when installing the AD CS role is which role services you would like to install, as you can see in Figure 7.1:

Figure 7.1: Installing the AD CS role

Clicking on each option will give you a description of its capabilities, so you can probably determine which pieces of the role you need by poking around on this screen. Here is a short summary of these options. Note that I am listing them out of order, because of the way that I typically see them configured in the field:

Certification Authority: This is the primary certificate engine that needs to be installed for this server to officially become a CA.

Certification Authority Web Enrollment: Often, this one gets installed as well, especially in environments that are small enough to be running a single CA server for the entire environment.

The web enrollment portion will install IIS (webserver) capabilities on this server and launch a small website that is used for the purpose of requesting certificates. We will discuss this further when we walk through issuing certificates from this web interface later in the chapter.

Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service: Most of the time, we are only concerned with issuing certificates to our company-owned, domain-joined systems. In those cases, these two selections are not necessary. If you plan to issue certificates to non-domain-joined computers from this CA server, you want to select these options.

Network Device Enrollment Service: As the name implies, this piece of the CA role provides the capability to issue certificates to routers and other kinds of networking devices.

Online Responder: This is a special function reserved for larger environments. Inside every certificate is a specification for a CRL. When a client computer utilizes a certificate, it reaches out and checks against this CRL to make sure that its certificate has not been revoked. The CRL is an important piece of the certificate security puzzle; in an environment with thousands of clients, your CRL may be very, very busy responding to all these requests. You can deploy additional CA servers that are running Online Responder to help ease that load.

For the purposes of our lab, and to cover the required capabilities of most small-to-medium businesses out there, I am going to select the two options shown in Figure 7.1: Certification Authority and Certification Authority Web Enrollment.

Enterprise versus standalone

Following the installation of your AD CS role, Server Manager will notify you that certificate services need some additional configuration, as is common with many role installations. When configuring your CA role for the first time, you will be presented with a big choice. Do you want this CA server to be an enterprise CA or a standalone CA?Let’s start with the enterprise CA. As the wizard will tell you, an enterprise CA server must be a member of your domain, and these certificate servers typically stay online so that they can issue certificates to computers and users who need them. Wait a minute! Why in the world would we want to turn a certificate server off anyway? We will discuss that in a minute, but if you intend to utilize this CA to issue certificates, it must obviously remain turned on. Most CA servers within a domain environment will be enterprise CAs. When creating an enterprise CA, your templates and some certificate-specific information can store themselves within Active Directory, which makes integration between certificates and the domain tighter and more beneficial. If this is your first interaction with the CA role, I recommend you start with an enterprise CA because this better meets the needs of most organizations.As you can correctly infer from the preceding text, this means that a standalone CA is less common to see in the wild. Standalones can be members of the domain, or they can remain out of that part of the network and reside in a local workgroup. If you had a security requirement that dictated that your certificate server could not be domain joined, that might be a reason why you would use a standalone CA. Another reason might be because Active Directory simply does not exist in the chosen environment.In my eyes, it would be extremely rare to find a network where someone was trying to use Windows Server 2025 as their certification authority and at the same time was not running Active Directory Domain Services, but I’m sure there is a corner case somewhere that is doing exactly this. In that case, you would also need to choose standalone. A third example of when you would choose standalone is the event we alluded to already, where you might have a reason to turn off your server. When you employ this scenario, it is typically referred to as having an offline root authority. We haven’t talked about root CAs yet, but we will in a minute. When you run an offline root, you create the top level of your PKI hierarchy as a standalone root CA, and then you build subordinate CAs underneath it. Your subordinate CAs are the ones doing the grunt work of issuing certificates—which means that the root can be safely shut down since it doesn’t have any ongoing duties. Why would you want to do this? Well, most companies don’t, but I have worked with some that have very high-level security policies, and this is why this topic might be relevant. If all of a company’s CA servers are tied together as enterprise CAs with all of their information being stored inside Active Directory, a compromise to one of the subordinate issuing CAs could spell disaster for your entire PKI. It is possible that the only way to remediate an attack would be to wipe out the whole PKI environment, all of the CA servers, and build them up again. If you had to do this, it would mean not only rebuilding your servers but also re-issuing brand-new copies of all your certificates to every user and device that has them.On the other hand, if you were running a standalone root CA that was offline, it would not have been affected by the attack. In this case, you could tear down your affected subordinate certificate servers, but your core root server would have been safely hidden. You could then bring this root back online, rebuild new subordinates from it, and have an easier path to being 100% operational because your root keys that are stored within the CA would not have to be re-issued, as they never would have been compromised in the attack.As I said, I do not see this very often in the field, but it is a possibility. If you’re thinking about moving forward with an offline root CA only because it seems like it’s more secure, but you don’t have a specific reason for doing so, I recommend you change gears and go ahead with an online enterprise root CA. While there are some security advantages to the offline root, most companies do not find those advantages to be worth the extra hassle that accompanies using an offline root CA. There are usability trade-offs when going down the offline route. If you find yourself wanting to set up a standalone CA that you are planning to take offline, but that is also domain joined, now you’re really asking for trouble. Such a server will quickly fall out of sync with the domain while it is offline, and down the road, when you find the need to turn that root CA back on, you have an enormous headache waiting for you.In most cases, you’ll want to select an enterprise CA and proceed from there.

Root versus subordinate (issuing)

This is the second biggest choice you need to make when building a new CA. Is your new server going to be a root CA or a subordinate CA? In some cases, even in a lot of Microsoft documentation, a subordinate CA is more often called an issuing CA.Generally, in a multi-tiered PKI, the subordinate/issuing CAs are the ones that do the issuing of certificates to users and devices in your network.The difference really is just a matter of what you want your CA hierarchy to look like. In a PKI tree, there is a single high-level certificate, self-signed to itself by the root CA, that everything chains up to. A subordinate CA, on the other hand, is one that resides below a root CA in the tree, and it has been issued a certificate of its own from the root above it.If your plans are to only run a single CA server, it must be a root. If you are creating a tiered approach to issuing certificates, the first CA in your environment needs to be a root, and you can slide subordinates in underneath it. You are allowed to have multiple roots, and therefore multiple trees, within a network. So your particular PKI can be structured however you see fit. In smaller companies, it is very common to see only a single CA server, an enterprise root. For the sake of simplicity in administration, these customers are willing to take the risk that, if something happens to that server, it won’t be that big of a deal to build a new one and re-issue certificates.For larger networks, it is more common to see a single root with a couple of subordinates below it. Typically, in this case, the root is only responsible for being the top dog and the holder of important keys, and the subordinate CAs are the ones doing the real work—issuing certificates to the clients.

Naming your CA server

At this point, now that you have installed the role, the hostname of the server itself is set in stone. You already knew this. But as you progress through the wizards to configure your CA for the first time, you will come across a screen called Specify the name of the CA. Huh? I thought we already did that when we set the hostname?Nope, we do have our final hostname, and that server name is plugged into Active Directory as our server is joined to the domain, but the actual “CA name” is something else altogether. This is the name that will be identified inside the properties of every certificate that this CA issues. This is also a name that will be configured in various places inside Active Directory, since we are building an enterprise CA. The wizard identifies a possible name for you to use, which many administrators simply take and use. If you want to configure your own name, this is where you should do it.Once you set the name here, this is the name of the CA forever:

Figure 7.2: Setting the name of the CA

Can I install the CA role onto a domain controller?

Since the role is officially called the Active Directory Certificate Services role, does that mean I should install this role onto one of my domain controller servers? No! Unfortunately, I have run across many small-to-medium businesses that have done exactly this, and luckily they don’t have too many problems. So technically, it does work. However, it is not a Microsoft-recommended installation path, and you should build your CAs on their own servers; try not to co-host them with any other roles whenever possible.

Creating a certificate template

Enough talk. It’s time to get some work done. Now that our CA role has been installed, let’s make it do something! The purpose of a certificate server is to issue certificates, right? So, shall we do that? Not so fast. When you issue a certificate from a CA server to a device or user, you are not choosing which certificate you want to deploy; rather, you are choosing which certificate template you want to utilize to deploy a certificate based upon the settings configured inside that template. Certificate templates are sort of like recipes for cooking. On the CA server, you build out your templates and list all the particular ingredients (settings) that you want to incorporate into your final certificate.Then, when the users or computers come to request a certificate from the CA server, they “bake” a certificate into their system by telling the CA which template recipe to follow when building that certificate. Relating certificates to food? Maybe that’s a stretch, but it’s 5:30am and I haven’t eaten breakfast yet.When you walk through the steps to configure your first CA server, it comes with some prebuilt certificate templates right in the console. In fact, one of those templates, called Computer, is typically preconfigured to the point where, if a client computer were to reach out and request a computer certificate from your new CA, it would be able to successfully issue one. However, where is the fun in using prebuilt templates and certificates? I would rather build my own template so that I can specify particular configurations and settings inside that template. This way, I know exactly what settings are contained within my certificates that will ultimately be issued to my computers in the network.Once again, we need to launch the proper administrative console to do our work. Inside the Tools menu of Server Manager, click on Certification Authority. Once inside, you can expand the name of your certification authority and see some folders, including one at the bottom called Certificate Templates. If you click on this folder, you will see a list of the templates that are currently built into our CA server. Since we do not want to utilize one of these pre-existing templates, it is common sense that we would try to right-click here and create a new template, but this is actually not the correct place to build a new template. Understanding the reason why new certificate templates are not built directly from this screen must be above my pay grade because it seems silly that they aren’t. Alas, in order to get to the proper screen for managing and modifying our templates, we need to right-click on the Certificate Templates folder and then choose Manage:

Figure 7.3: Managing certificate templates

Now you see a much more comprehensive list of templates, including several that were not visible on the first screen. To build a new template, what we want to do is find a pre-existing template that functions similarly to the purpose that we want our new certificate template to serve.Computer templates are becoming commonly issued across many organizations due to more and more technologies requiring these certificates to exist. Yet, we don’t want to utilize that baked-in template, which is simply called Computer, because we want our template to have a more specific name and we want the flexibility to modify template settings. Perhaps we want the certificate’s validity period to be longer than the default settings or some kind of similar specification. Right-click on the built-in Computer template and click on Duplicate Template. This opens the Properties screen for our new template, from which we first want to give our new template a unique name inside the General tab.In an upcoming chapter, we will discuss DirectAccess, the remote access technology that will be used in our environment. A good implementation of DirectAccess includes machine certificates being issued to all mobile client workstations, so we will plan to make use of this new template for those purposes. The General tab is also the place where we get to define our validity period for this certificate, which we will set to 2 years:

Figure 7.4: Crafting our certificate template

If the certificates that you want to issue require any additional setting changes, you can flip through the available tabs inside Properties and make the necessary adjustments. For our example, another setting I will change is inside the Subject Name tab.I want my new certificates to have a subject name that matches the common name of the computer where it is being issued, so I have chosen Common name from the drop-down list:

Figure 7.5: Specifying the certificate Subject Name

We have one more tab to visit, and this is something you should check for every certificate template that you build: the Security tab. We want to check here to make sure that the security permissions for this template are set in a way that allows the certificate to be issued to the users or computers that we desire, and at the same time make sure that the template’s security settings are not too loose, creating a situation where someone who doesn’t need it might be able to get a certificate. For our example, I plan to issue these DirectAccess certificates to all of the computers in the domain, because the kind of machine certificate I have created could be used for general IPsec authentications as well, which I may someday configure.So, I am just making sure that I have Domain Computers listed in the Security tab, and that they are set for Read and Enroll permissions, so that any computer that is joined to my domain will have the option of requesting a new certificate based on my new template:

Figure 7.6: Certificate permissions

Since that is everything I need inside my new certificate, I simply click on OK, and my new certificate template is now included in the list of templates on my CA server.

Issuing certificates

Next comes the part that trips up a lot of people on their first attempt. We now have a brand-new template to issue, and we have verified that the permissions within that certificate template are appropriately configured so that any computer that is a member of our domain should be able to request one of these certificates, right? So our logical next step would be to jump onto a client computer and request a certificate, but there is first one additional task that needs to be accomplished in order to make that possible.Even though the new template has been created, it has not yet been published. So at the moment, the CA server will not offer our new template as an option to the clients, even though security permissions are configured for it to do so. The process to publish a certificate template is very quick—only a couple of mouse clicks—but unless you know about the need to do this, it can be a very frustrating experience because nothing in the interface gives you a hint about this requirement.

Publishing the template

If your Certificate Templates console is still open (the one where we were managing our templates), close it so you are back at the main certification authority management console. Remember how we noticed that the list of available certificate templates that shows up here is much shorter? This is because only these certificate templates are currently published and available to be issued. To add additional templates to the published list, including our new one, we simply right-click on the Certificate Templates folder and then navigate to New | Certificate Template to Issue:

Figure 7.7: Publishing our new template

Now we are presented with a list of available templates that are not yet issued. All you need to do is choose your new template from the list and click on OK. The new template is now included in the list of “published” certificate templates, and we are ready to request one from a client computer:

Figure 7.8: Selecting the new certificate template to issue

If you look through this list and do not see your newly created template, you may have to take an additional step. Sometimes simply waiting will resolve this behavior, because occasionally the reason that the new template does not show up in the list is that you are waiting for your domain controllers to finish replicating. At other times, you will find that, even after waiting for a while, your new template is still not on this list. In that case, you probably just need to restart the certification authority service to force it to pull in the new template information. To restart the CA service, you right-click on the CA’s name near the top of the Certification Authority management console and navigate to All Tasks | Stop Service. The stopping of that service typically only takes a second or two, and then you can immediately right-click on the CA name again, and this time navigate to All Tasks | Start Service, as seen in Figure 7.9.Attempt to publish your new template again, and you should see it in the list:

Figure 7.9: Restarting the CA service

Requesting a certificate from MMC

Our new certificate template has been created, and we have successfully published it within the CA console, thereby making it officially ready for issuing. It’s time to test that out. Go ahead and log in to a regular client computer on your network. There are a couple of standard ways to request a new certificate on a client computer. The first is by using the good old MMC console. On your client computer, launch MMC and add the snap-in for Certificates. When you choose Certificates from the list of available snap-ins and click on the Add button, you are presented with some additional options for which certificate store you want to open. You get to choose between opening certificates for My user account, Service account, or Computer account. Since we are trying to issue a certificate that will be used by the computer itself, I want to choose Computer account from this list, and click on Finish:

Figure 7.10: Snapping in computer certificates

On the next page, click on the Finish button again to choose the default option, which isLocal computer. This will snap in the local machine’s computer-based certificate store inside MMC.Alternatively, on any Windows version newer than Windows 8 and Windows Server 2012, there is an MSC shortcut for opening directly into the local computer’s certificate store. Simply type CERTLM.MSC into a Run prompt and MMC will automatically launch and create this snap-in for you.When you are installing certificates onto a computer or server, this is generally the place you want to visit. Inside this certificate store, the specific location where we want to install our certificate is the Personal folder. This is true whether you are installing a machine certificate as we are doing here or installing an SSL certificate onto a webserver. The local computer’s personal certificate folder is the correct location for both kinds of certificates. If you click on Personal, you can see that we do not currently have anything listed there:

Figure 7.11: Personal is empty

To request a new certificate from our CA server, we simply right-click on the Personal folder, and then navigate to All Tasks | Request New Certificate… Doing so opens a wizard; go ahead and click on the Next button once.Now you encounter the screen shown in Figure 7.12, which looks like something needs to be done; but in most cases, because we are requesting a certificate on one of our corporate, domain-joined machines, we actually do not need to do anything on the screen presented in the following screenshot.Simply click Next again and the wizard will query Active Directory to show all certificate templates that are available to be issued:

Figure 7.12: Click Next to query Active Directory

Next, the Request Certificates screen is shown, which is the list of templates that are available to us. This list is dynamic; it is based on what computer you are logged in to and what your user account permissions are. Remember when we set up the security tab of our new certificate template? It is there that we defined who and what could pull down new certificates based on that template, and if I had defined a more particular group than domain computers, it is possible that my new DirectAccess Machine template would not be displayed in this list. However, since I did create that template to be issuable to any computer within our domain, I can see and select it here:

Figure 7.13: Certificate templates available for issuing

If you do not see your new template in the list, click on the Show all templates checkbox. This will give you a full list of all the templates on the CA server, and a description of each one with the reason that it is currently unavailable for issuing.Put a checkmark next to any certificates that you want and click Enroll. Now the console spins for a few seconds while the CA server processes your request and issues a new certificate that is specific to your computer and the criteria that we placed inside the certificate template. Once finished, you can see that your brand-new machine certificate is now inside Personal | Certificates in the MMC. If you double-click on the certificate, you can check over its properties to ensure all of the settings you wanted to be pushed into this certificate exist:

Figure 7.14: Certificate properties

Requesting a certificate from the web interface

I typically use the MMC for requesting certificates whenever possible, but in most cases, there is another platform from which you can request and issue certificates. I say in most cases because the existence of this option depends upon how the CA server was built in the first place. When I installed my AD CS role, I made sure to choose the options for both Certification Authority and Certification Authority Web Enrollment.This second option is important for our next section of text. Without the web enrollment piece of the role, we would not have a web interface running on our CA server, and this part would not be available to us.If your CA server does not have web enrollment turned on, you can revisit the role installation page in Server Manager and add it to the existing role:

Figure 7.15: Installing Certification Authority Web Enrollment

Once Certification Authority Web Enrollment is installed on your CA, there is a website running on that server that you can access via a browser from inside your network. Having this website is useful if you have the need for users to be able to issue their own certificates for some reason; it would be much easier to give them documentation or train them on the process of requesting a certificate from a website than expect them to navigate the MMC console. Additionally, if you are trying to request certificates from computers that are not within the same network as the CA server, using MMC can be difficult. For example, if you have the need for a user at home to be able to request a new certificate, without a full VPN tunnel, the MMC console is more than likely not going to be able to connect to the CA server in order to pull down that certificate. But since we have this certificate enrollment website running, you could externally publish this website as you do with any other website in your network, using a reverse proxy or firewall to keep that traffic safe and present users with the ability to hit this site and request certificates from wherever they are.To access this website, let’s use our regular client computer again. This time, instead of opening MMC, I will simply launch Edge, or any other browser, and log in to the website running at https://<CASERVER>/ certsrv.For my specific environment, that exact web address is https://CA1/certsrv:

Figure 7.16: Viewing the CA web enrollment site

Our URL starts with HTTPS. This website must be configured to run on HTTPS instead of regular HTTP to allow the website to request certificates. It does not allow issuing certificates over HTTP because that information would be traveling in cleartext to the client. Enabling the website on the CA server for HTTPS ensures that the certificate issued will be encrypted while it travels. Depending on how your CA server was originally configured, it is possible that nobody has yet setup the CertSrv website to run on HTTPS (port 443) and you may need to visit IIS Manager on your CA server to update the website binding before you can access it.Clicking on the Request a certificate link brings you into a wizard in which we can request a new certificate from the CA server. When you ask users to navigate their own way through this web interface, it is typically for the purpose of a user-based certificate, since we have some pretty easy ways of automatically distributing computer-level certificates without any user interaction. We will discuss that in a moment. However, for this example, since we are asking our users to log in here and request a new User Certificate, on the next page, I will choose that link:

Figure 7.17: Selecting a certificate type

If you were not interested in a user certificate and wanted to use the web interface to request a machine certificate, a webserver certificate, or any other kind of certificate, you could instead choose the link for advanced certificate request and follow the prompts to do so.Next, click the Submit button, and once the certificate has been generated, you will see a link that allows you to Install this certificate. Click on that link, and the new certificate that was just created for you will be installed onto your computer. You can see in the following screenshot the response that the website gave me, indicating a successful installation, and you can also see I have opened the current user certificates inside MMC in order to see and validate that the certificate really exists:

Figure 7.18: Certificate being successfully installed

In this section, we have proven that our CA server is working; follow along with the next few pages as we take certificate issuance to the next level.

Creating an auto-enrollment policy

Our certification authority server is configured and running, and we can successfully issue certificates to the client machines. Great! Now let’s pretend we have a new project on our plates, and one of the requirements for this project is that all the computers in our network need to have a copy of this new machine certificate that we have created. Uh oh, that sounds like a lot of work. Even though the process for requesting one of these certificates is very quick—only a handful of seconds on each workstation—if you had to do that individually on a thousand machines, you’d be talking about a serious period of time needing to be spent on this process. Furthermore, in many cases, the certificates that you issue will only be valid for one year. Does this mean we are facing an extreme amount of administrative work every single year to re-issue these certificates as they expire? Certainly not!Let’s figure out how to utilize Group Policy to create a GPO that will auto-enroll our new certificates to all of the machines in the network, and, while we are there, also configure it so that when a certificate’s expiration date comes up, the certificate will auto-renew at the appropriate intervals.Let’s pop into the Certification Authority management console on our CA server and look inside the Issued Certificates folder. I only want to look here for a minute in order to see how many certificates we have issued so far in our network. It looks like just a handful of them, so hopefully once we are done configuring our policy, if we have done it correctly and it takes effect automatically, we should see more certificates starting to show up in this list:

Figure 7.19: Certificates issued by our CA

Log in to a domain controller server, and then open up the Group Policy Management console. I have created a new GPO called Enable Certificate Auto-enrollment, and am now editing that GPO to find the settings I need to configure to make this GPO do its work:

Figure 7.20: Editing the new Auto-enrollment GPO

The settings inside this GPO that we want to configure are located at Computer Configuration | Policies | Windows Settings | Security Settings | Public Key Policies | Certificate Services Client - Auto-Enrollment.Double-click on this setting to view its properties. All we need to do is change Configuration Model to Enabled, and make sure to check the box that says Renew expired certificates, update pending certificates, and remove revoked certificates. Also check the box for Update certificates that use certificate templates.These settings will ensure that auto-renewal happens automatically when the certificates start running into their expiration dates over the next few years:

Figure 7.21: Enabling Auto-Enrollment

What is the last thing we need to do on our GPO to make it active? Create a GPO link so that it starts applying! For your own environment, you will probably create a more specific link to a particular OU, as we discussed in the last chapter; but for my lab, I want these certificates to apply to every single machine that is joined to the domain, so I will link my new GPO at the root of the domain so that it applies to all of my clients and servers.Now that the GPO is created and configured, and we have linked it to the domain, I would think that some new certificates would be issued and there would be more names shown inside my Issued Certificates folder inside my certification authority console. But there are not. Wait a minute, in our GPO, we didn’t really specify anything particular to my DirectAccess machine certificate template, did we? Could that be the problem? No, there wasn’t even an option for specifying which template I wanted to set up for auto-enrollment. So what gives?When you enable auto-enrollment in Group Policy, you are simply flipping an on/off switch and turning it on for every certificate template. Now that we have a GPO that is configured to enable auto-enrollment and is linked to the domain, thus making it live, auto-enrollment has been enabled on every domain-joined computer, for every certificate template that is published on our CA server.Yet, none of them are issuing themselves to my computers. While I have successfully enabled certificate auto-enrollment in my environment, they are not being issued to computers because I need to adjust the security settings on my new DirectAccess Machine template. Currently, I have it configured so that all domain computers have Enroll permissions, but if you remember that Security tab within the certificate template’s properties, there was an additional security identifier called Autoenroll. Every certificate template has the Autoenroll permission identifier, and it is not allowed by default. Now that the light switch has been flipped on for auto-enrollment in our domain, we need to enable the Autoenroll permission on any template that we want to start distributing itself. As soon as we enable that permission, these certificates will begin flowing around our network.Head into the certificate management section of your CA server and open Properties of your new template, then make your way to the Security tab and allow Autoenroll permissions for the Domain Computers group.This should tell the CA to start distributing these certificates accordingly:

Figure 7.22: Template security for Autoenroll permissions

And sure enough, if I let my environment sit for a little while, giving Active Directory and Group Policy a chance to update on all my machines, I now see more certificates have been issued from my CA server:

Figure 7.23: Certificates are now being auto-enrolled

To automatically issue certificates from any template you create, simply publish the template and make sure to configure the appropriate auto-enroll permissions on that template. Once the auto-enrollment GPO is in place on those clients, they will reach out to your CA server and ask it for certificates from any template for which they have permission to receive a certificate. In the future, when that certificate is about to expire and the machine needs a new copy, the auto-enrollment policy will issue a new one prior to the expiration date, based on the timestamps you defined inside the GPO.Certificate auto-enrollment can take what would normally be an enormous administrative burden and turn it into a completely automated process!

Obtaining a public authority SSL certificate

We are now comfortable grabbing certificates from our own CA server inside our own network, but what about handling those SSL certificates for our webservers that should be acquired from a public certification authority? For many of you, this will be the most common interaction that you have with certificates, and it’s very important to understand this side of the coin as well. When you need to acquire an SSL certificate from your public authority of choice, there is a three-step process to do so: create a certificate request, submit the certificate request, and install the resulting certificate.We are going to use my WEB1 server, on which I have a website running. Currently, the site is only capable of handling HTTP traffic, but when we turn it loose on the internet, we need to enable HTTPS to keep the information that is being submitted to the site encrypted.To use HTTPS, we need to install an SSL certificate onto the WEB1 server. This webserver is running the Microsoft web services platform, Internet Information Services (IIS).The three-step process you take is the same if you are running a different webserver, such as Apache or NGinx, but the particular things that you have to do to accomplish these three steps will be different because Apache or any other webserver will have a different user interface than IIS. Since we are working on a Windows Server 2025 webserver, we are utilizing IIS 10.

Public/private key pair

Before we jump into performing those three steps, let’s discuss why any of this even matters. You have probably heard of the term private key but may not quite understand what that means. When we send traffic across the internet, from our client computers to an HTTPS website, we understand that the traffic is encrypted. This means that the packets are tied up in a nice little package before leaving my laptop so that nobody can see them while they travel, and are then unwrapped successfully when those packets reach the webserver. My laptop uses a key to encrypt the traffic, and the server uses a key to decrypt that traffic, but how do they know what keys to use? There are two different kinds of encryption methodology that can be used here:

Symmetric encryption: The simpler method of encryption, symmetric, means that there is a single key, and both sides utilize it. Traffic is packaged up using a key, and the same key is used to unwrap that traffic when it reaches its destination. Since this single key is the all-powerful Oz, you wouldn’t want it to get into the wrong hands, which means you will not be presenting it out on the internet. Since you cannot safely share it on the internet, you would need some other way to manually get this key to both client and server. This obviously wouldn’t work to be giving users copies of encryption keys whenever they visit your website. Therefore, symmetric encryption is not generally used for protecting internet website traffic. Rather, it is used more commonly in places where you control both sides of the communication stream, such as VPN traffic.

Asymmetric encryption: This is our focus with HTTPS traffic. Asymmetric encryption utilizes two keys: a public key and a private key. The public key is included inside your SSL certificate, and so anyone on the internet can contact your website and get the public key. Your laptop then uses that public key to encrypt the traffic and sends it over to the webserver. Why is this secure if the public key is broadcast to the entire internet? Because the traffic can only be decrypted by using a corresponding private key, which is securely stored on your webserver. It is very important to maintain security over your private key and your webservers, ensuring the key doesn’t fall into anyone else’s pocket.

Creating a certificate signing request

If you’ve already jumped ahead and acquired an SSL certificate from your public CA entity by logging in to their website, purchasing a certificate, and immediately downloading it, you’ve already missed the boat. For some reason it is sometimes possible to download SSL certificates that cannot do anything, the reason they cannot do anything is that you haven’t given that certificate any information about what private key to use on your server. An SSL certificate that is not aware of a corresponding private key is effectively useless.When you install an SSL certificate onto a webserver, it is very important that the certificate knows about your private key. How do we make sure that happens? This is where the certificate signing request (CSR) comes into play. The first step in correctly acquiring an SSL certificate is to generate a CSR from your local webserver. When you create that file, the webserver platform creates the private key that is needed and hides it away on your server.The CSR is then created in such a way that it knows exactly how to interact with that private key, and you then utilize the CSR when you log in to the CA’s website to request the certificate.The private key is not inside the CSR, and your CA vendor never knows what your private key is. This key is ultra-important and is only ever stored on your webserver, inside your organization.To generate a CSR, open IIS from the Tools menu of Server Manager, and then click on the name of the webserver from the navigational tree on the left side of your screen. This will populate a number of different applets into the center of the console. The one we want to work with is called Server Certificates. Go ahead and double-click on that:

Figure 7.24: Viewing Server Certificates via IIS

Now, on the Server Certificates screen, you can see any existing certificates that reside on the server listed here. This is where we ultimately need to see our new SSL certificate so that we can utilize it inside our website properties when we are ready to turn on HTTPS. The first step to acquiring our new certificate is creating the certificate request to be used with our CA, and, if you look on the right side of your screen, you will see an Actions section, under which is listed Create Certificate Request....Go ahead and click on that action:

Figure 7.25: Creating a certificate request

In the resulting wizard, you need to populate the information that will be stored within your SSL certificate. The Common name field is the most important piece of information here. It needs to be the DNS name that this certificate is going to protect. So basically, you enter the name of your website here, then continue with filling out the rest of your company-specific information. A couple of special notes here that often seem to trip up admins are that the Organizational unit can be anything at all; I usually just enter the word Web. Also make sure to spell out the name of your State; do not use an abbreviation:

Figure 7.26: Populating information for the certificate

On the Cryptographic Service Provider Properties page, you typically want to leave Cryptographic service provider set to its default, unless you have a specialized crypto card in your server and are planning to use it for handling encryption processing for this website. On an IIS server, you will almost always have Microsoft RSA SChannel Cryptographic Provider listed here. What you do want to change, however, is the Bit length. The standard bit length for many years was 1024, and that continues to be the default choice in Windows Server 2025, please don’t ask me why. The general industry for SSL encryption has decided that 1024 is too weak, however, and the new standard is a minimum of 2048 bits. When you head onto your CA’s website to request a certificate, you will more than likely find that your request needs to have a minimum of 2048 bits, possibly even 4096. So go ahead and change that drop-down setting to a minimum of 2048:

Figure 7.27: Setting the encryption bit length to 2048

The only thing left to do for our CSR is to give it a location and filename. Saving this csr as a text file is the normal way to go and serves our purposes well because all we need to do when we request our certificate is open the file and then copy and paste the contents. We have now created our csr file, and we can utilize this file to request the certificate from our public CA.

Submitting the certificate request

Now head over to the website for your public certification authority. Again, any of the companies that we mentioned earlier, such as GoDaddy or Verisign, are appropriate for this purpose. Each authority has its own look and feel for its web interface, so I cannot give you the exact steps that need to be taken for this process. Once you have an account and log in to the authority’s site, you should be able to find an option for purchasing an SSL certificate. For some CAs, the purchasing process and the certificate acquisition process are two different things. For example, you may purchase and pay for your new SSL certificate and then discover that you must visit a different section of the interface to use the “certificate credit” you just purchased to create a certificate. On the other hand, some CAs walk you through the entire process from start to finish. In any case, once that certificate has been purchased, there will be a process for requesting and deploying that certificate.Once you have found the interface used for generating the new certificate, you will generally be asked for four pieces of information:

Validity period – How long should this SSL certificate last? It used to be common that companies would purchase SSL certificates with one-year, two-year, or even three-year validity periods, meaning that the certificate was “good” for that amount of time. A few years ago, Apple flexed its muscles in this space and decided that the Safari web browser will only trust certificates that have a validity period of one year, more or less.

Rather than push back, the industry said “sure, why not?” and so moving forward, SSL certificates will only be valid for one year at a time. For clarity, you can still purchase an SSL certificate for multiple years at a time, which can sometimes get you a better deal on the cost per year, but even if you have purchased multiple years’ worth of SSL certificate use, you will still need to replace the certificate every year with a fresh one from your certificate provider. We will talk more about this shortly, when we discuss re-keying certificates.

Webserver platform – What type of webserver are you running? The answer to this question impacts what type of file is available to download at the end of this process. When working with Windows Server, your answer will be “IIS,” but other possible options include Apache, Tomcat, NGINX, and many more Linux-based webserver selections.

Domain ownership validation – This one is interesting, and if you haven’t been through this process before, you likely haven’t thought about why it is necessary. What’s to stop hacker Joe sitting in an internet café halfway across the world, or a 12-year-old playing video games in their basement, or even your next-door neighbor from creating their own CA login and purchasing an SSL certificate that has your company name and website on it? The validation of domain ownership is a process to prove that you really own contoso.com (or whatever your domain is) so that only you are allowed to purchase valid SSL certificates that protect traffic for your domain name. The most common way to validate domain ownership is to select from a list of pre-defined email addresses inside the CA, after which the CA will send some flavor of validation email to that email address. For example, you might have a selection of email addresses like the following:

admin@contoso.com

administrator@contoso.com

webmaster@contoso.com

hostmaster@contoso.com

All you need to do is verify that you can receive an email to one of those email addresses, and by selecting this option, you will receive an email to that address that usually contains a link and a code. Simply copy the code and paste it into the link, and this is an easy way to validate domain ownership because as the owner of that domain, only YOU would have access to those email addresses. A second form of ownership, if email doesn’t pan out, is that the CA may give you a special DNS record that can be put into place in your domain’s public DNS. You input the record, the CA sees that record show up on the internet, and they validate you are the domain owner. This process takes much longer to accomplish than email verification, so it is rarely used.

CSR – The last (and most important) thing you will be asked to provide is the text from inside that CSR file we created a few minutes ago. There will be either an upload function or simply an input box, and all you need to do is copy/paste the entire contents of the CSR into that box.

If you open the text file we saved earlier, you will see a big lump of nonsense:

Figure 7.28: The text inside a CSR file

This mess of data contains information about your certificate request and is exactly what the CA needs in order to create your new SSL certificate so that it knows how to interact with your webserver’s private key. Only the server that generated the CSR will be able to accept and properly utilize the SSL certificate that is based on this CSR.

Downloading and installing your certificate

Next, you sit back and wait. Depending on which authority you are using and on how often your company purchases certificates from this authority, your certificate might be available for download almost immediately, or it could take a few hours before that certificate shows up in the available downloads list. The reason for this is that some CAs utilize human approval for new certificates, and you are literally waiting for someone to take a look at the certificate request and your information to make sure you really work for the company and that you really own this domain name. Remember, the real benefit to a public SSL certificate is that the CA is guaranteeing that the user of this certificate is the real deal, so they want to make sure they aren’t, for example, issuing a certificate for portal.contoso.com to someone in the Fabrikam organization by mistake.Once you are able to download the certificate from the CA’s website, go ahead and copy it over to the webserver from which we generated the CSR. It is critically important that you install this new certificate onto the same server. If you were to install this new certificate onto a different webserver, one that did not generate the CSR this certificate was built from, that certificate would import successfully, but would not be able to function. Once again, this is because the private key that the certificate is planning to interact with would not be present on a different server.Back inside the IIS management console, we can now use the next action shown along the right side of Figure 7.25, called Complete Certificate Request. This launches a short little wizard in which you point at the newly downloaded certificate file, and the wizard then imports it into our server. Now that the certificate resides on the server, it is ready to be used by our website.There is one additional item that I always check after installing or importing an SSL certificate. You can now see your new certificate listed inside IIS, and if you double-click on your new certificate, you will see the Properties page for the certificate. On the General tab of these properties, take a look near the bottom. Your certificate should display a little key icon and text that reads You have a private key that corresponds to this certificate. If you can see this message, your import was successful and the new certificate file matched up with the CSR perfectly. The server and certificate now share that critical private key information, and the SSL certificate will be able to work properly to protect our website. If you do not see this message, something went wrong in the process to request and download your certificate. If you do not see the message here, you need to start over by generating a new CSR, because the certificate file that you got back must not have been keyed appropriately against that CSR, or something along those lines. Without the You have a private key that corresponds to this certificate text at the bottom of this screen, your certificate will not validate traffic properly. You can install it, you can tell a website to use it, everything will appear to be working inside IIS, but the website simply will not function until you fix that certificate.Here is an example of what it should look like when working correctly:

Figure 7.29: This certificate properly matches up with a private key

Re-keying certificates

While poking around in your public CA’s interface, you may have noticed a function or button to “re- key” a certificate. What does that mean? When you purchase a certificate such as portal.contoso.com from your CA, you are now able to use a CSR to craft a certificate based on that name. You then install that certificate onto your webserver, and it then protects traffic for your website portal.contoso.com. Each year, you can re-purchase the certificate, re-create a fresh CSR, and reinstall the certificate as if it were brand new. But what if you need to reinstall this certificate in the middle of the year? Perhaps you paid for a certificate from January through January, but it is now July and your webserver dies? You replace the server, reinstall your website, and realize that you need to get a new SSL certificate onto this new server to protect traffic for the same portal.contoso.com website. Do you need to purchase another SSL certificate and take the hit for the cost of the six months that you didn’t use? No, this is where re-keying a certificate can help you out. If you use your new webserver to generate a new CSR, you can then take that new CSR to your CA’s website and find the certificate that you already purchased, and simply re-key the certificate against your new CSR. This process will invalidate the old copy of the certificate, and will issue a new certificate based on the new CSR (based, of course, on the new server’s private key), which you can then install to your new webserver. This way, you can continue to make use of that SSL certificate you purchased on a new server and finish out the year.Another possible reason you might find yourself re-keying a certificate is when you have purchased multiple years’ worth of an SSL certificate. If you purchased portal.contoso.com for three years, remember that you can only issue a certificate for one year at a time. So every year, on or before that certificate’s expiration date, you will need to revisit your CA and re-key your certificate to pull down a fresh copy, giving you protection for another year. You won’t have to pay for this if you have already purchased the certificate for multiple years, but will still need to perform the certificate re-key and replacement for your webserver to continue working properly.

Exporting and importing certificates

I often find myself needing to use the same SSL certificate on multiple servers. This might happen in the case where I have more than one IIS server serving up the same website and I am using some form of load balancing to split the traffic between them. This need may also arise when working with any form of hardware load balancer, as you sometimes need to import certificates onto not only the webservers themselves but also the load balancer box. Another example is when using wildcard certificates; when you purchase a wildcard, you typically intend to install it onto multiple servers.Does this mean that you need to generate a new CSR from each server, and request a new copy of the same certificate multiple times? Definitely not, and in fact, doing so could cause you other problems: remember that when a public CA re-keys a certificate—in other words, if you have already requested a certificate with a particular name and then come back again later to request another copy of the same certificate—that CA will most likely invalidate the first one as it issues the second copy. This is not always immediately apparent, as there is usually a timer set on the invalidation of the first certificate. If you revisit the CA’s web interface and request a new copy of the same certificate using a new CSR for your second webserver, you might discover that everything works fine for a few days, but then suddenly the primary webserver stops validating traffic because its SSL certificate, the original copy, has expired.When you need to reuse the same SSL certificate on multiple servers, you can simply export it from one and import it on the next. There is no need to contact the CA at all. This process is quite straightforward, and there are two common places where you can do it: inside either the MMC snap-in for certificates or from within IIS itself. It is important to note, though, that the process is slightly different depending on which avenue you take, and you must be especially aware of what is happening with the private key as you step through these wizards.

Exporting from MMC

Head back into your Local Computer certificate store in MMC and navigate to Personal | Certificates so that you can see your SSL certificate listed. Right-click on the certificate, and then navigate to All Tasks | Export… When you walk through this export wizard, the important part that I wanted to mention happens right away in the wizard steps. The first choice you have to make is whether to export the private key. Again, the private key is the secret sauce that allows the certificate to interact properly with the server on which it is installed. If you export without the private key, that exported certificate will not work on another server. So it is important here that, if you are exporting this certificate with the intention of installing it onto a second webserver and using it for validating SSL traffic, you select the top option for Yes, export the private key:

Figure 7.30: Exporting a certificate using MMC

As the wizard sufficiently warns you, when you choose to export a certificate that contains private key information, you are required to supply a password, which will be used to protect the exported PFX file. It is important to choose a good password. If you forget it, your exported file will be completely useless (which isn’t terrible, because you can simply export it again). If you input a password that is very simple or easy to guess, anyone who gets their hands on this PFX file may be able to use your certificate and private key on their own webservers, which would not be good.

Exporting from IIS

Alternatively, an exported PFX file can be generated from inside the IIS console. Inside the Server Certificates applet for IIS, just right-click on the certificate and choose Export....This launches a single-page wizard that simply asks you for a location and password:

Figure 7.31: Exporting a certificate using IIS

We had many more options that we could have chosen or denied when we exported using MMC, so why is this so short? IIS makes assumptions for the rest of the settings to speed up the export process. When you are exporting an SSL certificate, it is almost a guarantee that you also intend to export the private key. Therefore, IIS simply makes that assumption and bypasses the rest of the choices. You are forced to enter a password because you don’t have a choice about the private key; it will be included with the certificate export automatically. So, if you had some reason to export a certificate that did not contain the private key info, you could not utilize the IIS console for this task. You would need to open MMC and walk through the more extensive wizard found there.

Importing into a second server

Whichever direction you take for accomplishing the export, once you have the fully fleshed PFX file available, importing into your second server is very easy. From within either console, MMC or IIS, you can right-click and choose the Import action. Walking through the steps, you simply choose the PFX file and then input the password that you used to protect the file. The certificate is then imported, and, if you open Properties, you will see that the little key icon and the private key message are displayed properly at the bottom of the certificate properties screen. If you do not see the you have a private key message, you did something incorrectly during the export process and you’ll need to try it again.Go ahead and try it yourself; find a server with an SSL certificate and test exporting that certificate with and without the private key. When you import into a new server, you will see that importing the certificate file without a private key does not lead to this message being displayed at the bottom of the properties page, but the exported file that does contain the private key results in the proper message being shown here. To take it a step further, try utilizing both certificates on a non-important website and see what happens. You will find that the certificate lacking the private key will fail to validate SSL traffic.

If you attempt to export an SSL certificate and the option to include the private key is grayed out, this means when the original administrator installed this certificate to the webserver, they chose a special option that blocks the ability for the private key to be exported in the future. In this case, you will not be able to export the certificate with the private key.

OpenSSL for Linux webservers

This chapter should give you all the information needed to protect websites with public CA-based SSL certificates…as long as you are running a Windows webserver. While this is obviously a Microsoft-centric book, the majority of webservers out there are not running on Microsoft webserver platforms. Alas, you will likely run into just as many Linux-based webservers as you do instances of IIS, and it will be very helpful to your role as server administrator to be able to install certificates onto these webservers as well.One significant difference between Windows and Linux webservers is the type of files used for certificates. IIS hides away the private key; you don’t really deal with it at all. When downloading certificate files for IIS, those are usually CER or CRT files. A Linux webserver, however, expects something else. On most Linux webservers, the certificate file and the private key are each individual files that are quite visible right on the server. Both files generally have the PEM file extension.Fortunately, the overall three-step process for acquiring and installing a certificate is exactly the same. Generate a CSR, use the CSR to get a certificate from your CA, and install the certificate to your webserver. Within those three steps are some significant differences between a Windows and a Linux platform. Let’s discuss them.

Generate a CSR

Shortly, we will install a toolset called OpenSSL and use it for some certificate-related functions. There is a way within the OpenSSL tool to generate a private key file and a corresponding CSR file, but this is not the approach that I find to be the most user-friendly. Instead, when dealing with the requirement to install an SSL certificate onto a Linux-based webserver, I turn right back to the Windows world and generate my CSR from inside IIS. Wait a minute, what?? Didn’t I just say that the processes in Windows and Linux are different? Yes, but bear with me for a minute. The CA doesn’t care where the CSR file comes from, and so rather than use a CLI-based platform like OpenSSL to monkey around with command syntax and eventually resort to Google to come up with the right commands, I simply create a CSR file exactly the same way that I would for a Windows Server, right inside IIS.

If you don’t have a server with IIS installed, you can just as easily craft a CSR right from your Windows 10 or 11 computer. If you head into Control Panel and find the option to Turn Windows features on or off, you will discover an option to install Internet Information Services. This installs the same IIS management interface to your Windows 10/11 computer as it would to a Windows Server. From within this IIS Management Console, you will have the same actions available to generate and complete certificate signing requests, right on your laptop. Once you have installed this feature, open IIS on your laptop and follow the exact process we outlined earlier, during our section about Creating a certificate signing request.

Figure 7.32: Installing IIS onto Windows 10

Acquire the certificate

After using the IIS Management Console to gain yourself a CSR file, follow through the same series of steps we previously discussed to submit your CSR to a CA, validate yourself as the owner of the domain, and download the resulting certificate file.

Install the certificate

Here is where we begin to steer the ship differently to deal with a Linux webserver. First of all, you need to install the certificate onto the same IIS server (or workstation) from which you generated the CSR file. Once again, this is critically important so that your new certificate successfully pairs up with the private key that was created when you created your CSR. Once you have the new certificate installed and have validated that it looks good, you can now use the knowledge you have from a few pages ago and export this certificate (including the private key) to a PFX file.Your newly created PFX file contains both the certificate and the private key. The only remaining step is to pump your PFX file through a couple of OpenSSL commands, which will then convert this PFX file into two separate PEM files, one containing the SSL certificate and another the private key. These two files are exactly what most Linux-based webservers are looking for when they ask you to provide an SSL certificate.Here are the steps required to accomplish this last piece of the puzzle:

Download and install OpenSSL. The available version of this will change occasionally, so I cannot provide a static download link, but you can easily find it by searching the web. A specific version and filename that I know works for this purpose, because it is the one installed on my computer right now, is Win64OpenSSL-1_1_1n.exe.

Put your PFX file in a location that we will reference in our commands. For the sake of our example, I will assume your PFX file is named Export.pfx, and that it is sitting inside a folder called C:\Cert.

Open Command Prompt and navigate to the folder where OpenSSL is installed. For my version, this is the command to take me to that folder:

CD C:\Program Files\OpenSSL-Win64\bin

Run the following two commands:

openssl pkcs12 -in c:\cert\export.pfx -nokeys -out c:\cert\portal. contoso.com-crt.pem -nodes
openssl pkcs12 -in c:\cert\export.pfx -nocerts -out c:\cert\portal.

(You will be asked to enter your PFX password after each of these commands.)That’s it! The two commands above will place two new files inside your C:\Cert folder. The first is your certificate, while the second is your private key. These two files will need to be either copied to a particular folder on your Linux webserver or uploaded into a graphical interface of whatever software you have running on that webserver, to specify the SSL certificate that is going to be used by the site.

Figure 7.33: Converting a PFX into Linux-ready certificate files

These steps are kind of a weird combination of using Windows and Linux tools to get an SSL certificate into Apache, Tomcat, NGINX, or other similar webservers. I employ this method because I always have IIS at the ready by keeping its toolset installed onto my Windows workstation, and this way I can simply have those two OpenSSL commands stored away for quick access to convert certificate files when needed.

Linux chaining certificate

When installing SSL certificates onto a Linux-based webserver, you may encounter one other requirement that doesn’t exist in the Windows world, a chain certificate. Some Linux webservers will ask you to provide a PEM file for your certificate, a second PEM file containing your private key, and yet a third PEM file that is your chaining file. What in the world is a chaining file?Whenever you download an SSL certificate from your public CA, your download will include multiple certificate files. Only one of those files is the real SSL certificate you are looking for, the other files are copies of the root and intermediate certificates, which are certificates provided by the CA to validate that your specific certificate was really crafted by them. These root/intermediate certs are the CA’s own internet-based validation records.On a Windows IIS webserver, you generally do nothing with these files, because the latest copies of all popular certification authority provider’s root and intermediate certificates are always in place on a Windows server. If you do feel a need to manually install these subsidiary files when downloading your certificate, you simply double-click on them to install them into the appropriate Trusted Root Certification Authorities and Intermediate Certification Authorities folders inside CERTLM.MSC. This imports the certificates into those folders on an IIS server, and then when users tap into your SSL certificate to validate it, these root and intermediate certificates create a validation “chain” to the CA.Some Linux-based webservers need a little more manual attention with their chaining files, and that is typically by way of crafting yourself a chaining certificate, or chaining file as some will call it. The process is fairly simple, but quite a mystery if you have never seen it before. This is what needs to happen:

Copy your Root and Intermediate certificate files into a folder.

Open each of these files using Notepad or any other text editor, inside you will see a mess of numbers and letters, looking very much like our CSR file in Figure 7.28.

Copy the contents of each of these files, and paste them sequentially into a brand new Notepad document. Place the Root certificate on top, and then paste in the one or more Intermediate certificates immediately below the Root inside the file. In the end, this Notepad will have 2 or 3 sets of gross-looking number/letter sequences.

Save this new file as Chain.PEM or whatever you want to name it.

Upload this new Chain.pem file into your Linux webserver application to use as the chaining certificate.

Figure 7.34: A newly created chain.pem file

Linux webservers will not always ask you for a chaining file, but if they do, now you know what in the world that is. Figure 7.34 shows us an example chain.pem file that I just finished creating.

Summary

Humans tend to dislike what we don’t understand. Certificates often get a bad rep, and I believe this is because most people see them as a headache to deal with. A box of complex mysteries. I see their point. Without knowing how to navigate through the various administrative consoles that deal with your certificate infrastructure, it would be difficult to make even the simplest certificate deployment successful. By walking through the most common certificate-related tasks that any server admin will eventually have to tackle within their own networks, I hope that you have now found some comfort and confidence to progress with those projects that might be currently sitting on hold, waiting for the certificate infrastructure to be built. SSL certificates are commonplace and important for any IT administrator to understand, but gaining control of a Windows internal CA, manipulating templates, issuing them to clients, and configuring autoenrollment policies will really make your skillset stand out among the crowd.

Questions

What is the name of the role inside Windows Server 2025 that allows you to issue certificates from your server?

What kind of CA server is typically installed first in a domain environment?

Should you install the certification authority role onto a domain controller?

After creating a new certificate template, what next step needs to be taken before you can issue certificates to your computers or users from that new template?

What is the general name of the GPO setting that forces certificates to be issued without manual intervention by an administrator?

An SSL certificate will only be able to validate traffic properly if it shares key information with the webserver.

What is the primary piece of information that a public certification authority needs in order to issue you a new SSL certificate (hint: you generate this from your webserver)?

What kind of file contains both a certificate and a private key?

What is a command-line tool that can be used to manipulate certificates?

8 Networking with Windows Server 2025

Join our book community on Discord

https://packt.link/zYovfThis is a book about servers, specifically Windows Servers. I often drop comments about servers making for great paperweights if they don’t have any roles installed to give those servers a purpose in life. Along those same lines, servers are quite useless if they are not connected to a solid network. Your network is the platform that supports the company infrastructure; it makes up the channels that all devices inside your company use to communicate with each other.Traditionally, there have been server admins and network admins in the IT industry, separated roles, and in many places that is still the case. An administrator who primarily works on servers does not generally have enough time in the day to also support the network infrastructure in an organization of any size, and the reverse is also true. Network administrators generally stick to their own equipment and management tools and aren’t interested in diving too deeply into the Windows Server world. However, many of us work in smaller companies where many hats must be worn. Some days, the server admin and the network admin hats sit on top of each other, so we must understand at least the baseline of networking and the tools that we can use to troubleshoot connections that are not working. In addition, Windows Server 2025 includes components to build a newer flavor of networking mindset, one that many companies have not yet ventured into: network virtualization. There will always be some semblance of a physical network, using physical switches and routers to move packets around between different rooms and buildings. But now we are also incorporating the idea of software-defined networking (SDN) into our Windows servers, which gives us the capability to virtualize some of that configuration. Network traffic and routing can now be managed from within a server console, rather than command-line interfaces running directly on our routers and switches.Hold the phone; I am getting ahead of myself. First, let’s talk about some of the useful things inside Windows Server 2025 that do involve working with physical networks (or any networks) because these are going to be important for any administrator in today’s networking world. Later, we will take a few moments to further explore this new idea of network virtualization.The following are topics we plan to discuss in this chapter, areas where the lines between server administration and network administration begin to blur:

IPv4 “need to know” information

Introduction to IPv6

Your networking toolbox

The Windows routing table

NIC Teaming

Software-defined networking

IPv4 “need to know” information

A general understanding of IPv4 networking is essential to do any type of work in the IT world, enough so that I have taken this topic for granted in previous editions of this book, always assuming that the reader already understood networking baselines. The more I work with engineers fresh in the industry, the more I realize that school and lab-based learning does not always stack up against the school of hard knocks, which accurately describes my journey into networking. This will not be a section where we talk in-depth about the TCP/IP protocol and things like OSPF or BGP or CRC error checking, rather a simple country boy’s description of networking components that are “need-to-know” so that you can successfully get your Windows Servers talking to each other.

IP addresses

By far the most common network-based talking point among all IT people, IP addresses are unique identifiers on your network that allow any device to communicate with any other device. Think of IP addresses like house addresses. If you live at 123 Quincy and your brother lives at 456 Hawthorn, you have all the information needed to communicate with each other and to have “packets” delivered back and forth between your homes.You already know that DNS turns names into IP addresses, so that you don’t have to memorize hundreds or thousands of numbers that look like a hot mess until you have stared at them for so long that suddenly they make sense. Think back to when you first started working with computers, or think about just yesterday when you visited your in-laws for Sunday dinner and wowed everyone by running an ipconfig while troubleshooting the wireless printer in the living room. IP addresses may seem simple to you now, but to most of the population this is entirely like reading Greek. Don’t feel bad if this is still unfamiliar territory.DHCP, as we already discussed, often manages IP addressing within our networks. A DHCP server can be a tremendous help in keeping IP addressing straightened out, and for assigning addresses to devices on the network. To correctly build a DHCP server configuration you must understand these basics of networking concepts. In addition to DHCP, you will certainly have times, many times, where you are configuring static IP addresses on your devices. It is common practice not to rely on DHCP for IP addressing assignments to Windows Servers, and instead exclude their addresses from DHCP altogether, in favor of configuring static IP addresses onto each server. When a server has a static IP address, even if the DHCP server goes offline, that server will still be accessible and able to communicate with the network. Let’s look at a screenshot of the IP address configuration screen inside a Windows Server, so that we have something to reference throughout these talking points.

Figure 8.1: A typical IP addressing screen

Every device must have a unique IP address in your network. This is where DHCP becomes extremely helpful, but if you statically address your servers, you will want to maintain good documentation so that everybody knows which IP addresses are in use, and which are still available. Figure 8.1 depicts my FS01 server. Imagine I shut down this server for some maintenance, and while I was working on it, another admin was building a new server. If we don’t keep good documentation about the fact that 10.10.10.30 is used by FS01, they may simply start pinging IP addresses within 10.10.10.x, find that the .30 IP address does not reply (because the server is shut down), and then configure 10.10.10.30 on their new server. This will work just fine for them, until I turn FS01 back on at which time both of those servers are going to be in for a whirlwind of a ride as the networking equipment and other devices in the network struggle to figure out which instance of 10.10.10.30 is the real one. Mis-managed IP addresses and assigning duplicates can literally take down a network.

VPN overlap

One common place to encounter IP addressing overlaps is when helping users through VPN connection troubleshooting. Many businesses allow employees to bring a laptop home and create a VPN connection from their house into the corporate network, so that they can access company resources from home. If the user’s home router assigns their laptop an IP address in the 192.168.1.x range, and there is also a network inside the business network that is 192.168.1.x, what happens? Things get messy is what happens, where sometimes that user may be able to access information over the VPN, sometimes not at all, sometimes only certain servers and not others. These variables depend upon the configuration and capabilities of the platform providing your VPN, but ultimately the only way you will truly help that employee to have a normal, successful VPN connection is if you walk them through changing their entire home network to no longer run on 192.168.1.x, but something entirely different, perhaps 192.168.100.x or even 10.10.10.x.So many home-class routers default to using 192.168.0.x or 192.168.1.x IP addresses, that any network admin worth their salt should never configure a business network to utilize either of these IP addressing ranges.

Private addressing

Why is it that every time you read about internal networks in a book, or (hopefully) every time that you encounter one in the wild, that the IP addresses always seem to look similar to these examples?192.168.1.1, 192.168.3.30, 172.16.1.3, 172.24.100.46, 10.10.10.30, 10.1.2.1, etc.There are many, many combinations of numbers to create many unique IP addresses, but why do they always seem to begin with 192 or 172 or 10 when dealing with IP addresses inside your network? This is because when IPv4 was invented, those engineers realized that standards were needed to create safe separation between the public network (Internet) and company’s private networks. There are nowhere near enough public IPv4 addresses for every device who needs access to the internet to have a unique IP address directly on the internet, so a standard was created for sections of IP addressing that are deemed “Private IP addressing space”. In other words, you will never find the following IP addresses in use on the internet, and these addresses are always safe to utilize inside your private networks. In other words, any internal network that you ever create should be contained within the following:

192.168.0.0 through 192.168.255.255

172.16.0.0 through 172.31.255.255

10.0.0.0 through 10.255.255.255

If you ever hear someone talking about RFC 1918, this is exactly what is being discussed. The Internet Engineering Task Force (IETF) recognized this need for IP addressing space to be kept away from the public internet long ago, and RFC 1918 is the technical standard that was created to privatize these three groupings of IP addresses and make them be forever dedicated to only internal addressing. By making use of the above IP addressing options within our internal networks, we can create huge networking spaces to safely keep our devices separated from each other. And since none of these IP addresses will ever be used and routed over the public internet, every company can safely make use of the same sets of IP addresses without conflict occurring among different companies. This is the reason why so many home routers all run 192.168.1.x, and yet there are no conflicts on the internet because of it.The reason I said “hopefully” you always find internal networks running only these private IP addresses is because it is entirely possible to utilize public IP addressing inside your network. I have come across networks such as these a few times in my career, and there is never a legitimate reason to have created the internal network that way. It was simply a network admin who wasn’t quite sure what he was doing. You could certainly configure all your servers and computers inside your network to run something like 8.8.8.x, and they would be able to communicate with each other just fine. They would even be able to communicate with at least some of the internet, but anytime they tried to reach areas of the internet which are making use of the “real” IP addresses (publicly owned IP addresses) within this range, communications would certainly fail, because your network routing rules and equipment would keep that traffic inside the network. Networks like these make for some very interesting stories!Don’t do it.

Subnet mask

Referring back to Figure 8.1, the next piece of information we must populate for a successful network connection is the Subnet mask. In almost all home networks, you might find your IP address to be something like 192.168.1.100. This is your full IP address, but what isn’t immediately obvious is that only the last portion (.100) is your individual workstation identifier on the network. The rest of that address (192.168.1.) is known as a network address. In IPv4-land, the way that IP addressing works is that each of those four octets can contain a number from 0 through 255. You can define whether more of your IP addresses should be dedicated to network addressing, or to host/device addressing. There are three classes of IPv4 subnets, and each one has advantages/disadvantages because they allow either more separated networks within your environment, or more host addresses within each network. Let me break it down this way, by looking at a few different subnet mask options:

Class A subnet = 255.0.0.0 = 128 different networks, each with 16,777,216 hosts

Class B subnet = 255.255.0.0 = 16,384 networks, each with 65,536 hosts

Class C subnet = 255.255.255.0 = 2,097,152 networks, each with 256 hosts

Any IPv4 subnet consists of 32 bits, four sections of 8 bits each. If you look closely at what numbers I put in bold above, you can see that in a Class A subnet the first number is the network identifier, and the remainder of the address can be assigned to devices. In a Class B, half (16 bits) are a network identifier, and the latter half are for devices. And in a Class C subnet, the most common, three-quarters of this address are assigned to be the network identification, and only the last part of this address can be used for device/host addressing.So in a Class C network that has a subnet mask of 255.255.255.0, there are 256 available addresses but the first and last are always hands-off. For example, 192.168.1.0 is a subnet identification number that cannot be used by a device, and 192.168.1.255 is called a broadcast address, which also cannot be used by a device because it is inherently responsible for getting packets to their destination between two machines that are on the same subnet.All these numbers make you dizzy after a while, and it’s good to know that there is a shorthand way to discuss different subnet mask numbers. Instead of saying something like 255.255.255.0, you can instead use the CIDR number “/24”. We often say words like “this is a slash-24 network”, and in fact some devices require you to specify the CIDR as a subnet mask identifier instead of the actual subnet mask number. Here are common CIDRs for the same subnet numbers we discussed earlier:

255.0.0.0 (/8)

255.255.0.0 (/16)

255.255.255.0 (/24)

There are many more CIDRs for other sizes of networks. As an example, let’s say your internal network is 192.168.2.0/24 (meaning that you have 254 usable IP addresses, .1 through .254). What if your business grows and you run out of IP addresses? You could setup a second /24 network, such as 192.168.3.0/24. Each of these networks would be a separate /24, and the two networks would not know about each other at all. For devices on these two networks to communicate with each other, even if they were plugged into the same switch, you would need to introduce a Layer 3 router (gateway) into the mix, so that the router could then be aware of both individual networks and route traffic back and forth between them.Or…you could move to a /23 network instead. When changing from /24 to /23, you are still running within a Class C subnet designation, but you double the amount of host addresses. Adjusting to a /23 means you would change your subnet mask to 255.255.254.0 on all of your devices, and once you do that all of these IP addresses can know about and talk with each other, even without a router:192.168.2.1 through 192.168.3.254A subnet mask defines boundaries for routing. It tells your equipment what to expect by way of network packet flow. You can easily test these theories if you have access to two computers and a simple switch, or if you have a Hyper-V or VMware server where you can establish two VMs. Go ahead and setup an extremely simple network consisting of two devices connected together by a switch. Even with no firewall, router, or gateway to help them pass traffic from one network to another, you will find that if you setup IP addresses like this, the two computers will be able to communicate:

Computer1 = 192.168.1.100/24 (255.255.255.0 subnet)

Computer2 = 192.168.1.150/24 (255.255.255.0 subnet)

But if you change Computer2 to be 192.168.2.150/24, the two computers are still physically connected to each other through the same switch, but they will no longer be able to communicate at all.Then try changing from a /24 to a /16, like this:

Computer1 = 192.168.1.100/16 (255.255.0.0 subnet)

Computer2 = 192.168.128.150/16 (255.255.0.0 subnet)

Since we are now using a /16 subnet, that means the entire latter half of the IP address is dedicated to host addressing, and so even though 192.168.1.x and 192.168.128.x seem like they are very far apart, within a /16 network these two sets of IP addresses (and everything in between) are all part of the same network. In this scenario, your two test computers would be able to talk to each other just fine.

Public subnetting

Our information so far all pertains to internal networks and private IP addressing, but the same math and mechanisms exist on the public internet. When purchasing internet service for a business, or even your home, a common question from the ISP is whether you want any static IP addresses to be part of your service. If you say yes, they will ask how many you need. The entire internet plays by these same IPv4 rules we have been discussing here, and so available and usable IPv4 addresses on the internet are limited. It is very common for companies to be given a very small set of usable IP addresses, maybe 5 or perhaps even 1. The way that ISPs control distribution of these tiny amounts of IP addresses is by dedicating even more of the IP address to be network identification, thereby causing less of the IP address to be usable for host addressing. When dealing with public IP addressing, it is common to see CIDRs and Subnet masks such as the following:255.255.255.252 (/30) = 2 usable IP addresses (one for you to use)255.255.255.248 (/29) = 6 usable IP addresses (five for you to use)255.255.255.240 (/28) = 14 usable IP addresses…and so on.If you ever need to remind yourself of these numbers, or figure out what subnet sizing is appropriate based on the number of IP addresses you require, you can turn to the internet and search out “subnet calculator” to find numerous free online calculators to play around with subnetting information, or search “CIDR chart” to find images that can be printed to become a quick reference guide for subnet sizing.

Default Gateway

While subnet masks can be a complex topic, your Default Gateway is quite simple. Inside any network interface’s IP addressing information, you will find a field to define a gateway. Every computer or server has a built-in routing table that contains a list of rules and destinations for sending network traffic. If you are plugged into a network like 192.168.1.0/24, when Windows attempts to contact any IP address that is within 192.168.1.x, it knows that the NIC is on-subnet (on-link) with those other IP addresses, and it simply throws the packets out that NIC. If a server has two NICs, one on 192.168.1.0/24 and another on 10.10.0.0/16, once again if any traffic needs to be sent to IP addresses within these networks, your server is smart enough, based on its own routing table, to get those packets where they need to go.The routing table in Windows is built primarily based on what IP address and Subnet Mask are configured in your NICs. All Windows needs are those couple pieces of information in order to build successful routing rules into those networks. It is also possible to manually manipulate a routing table and add custom rules, and indeed we will do that later in this chapter, but what about when your computer or server needs to reach outbound and contact an IP address that is not listed in its routing table? Maybe you open a web browser and head to google.com, and DNS sends your request to 8.8.8.8 (I know this isn’t accurate, but stick with me here)…how in the world does your computer know how to get to 8.8.8.8? The Default Gateway, that’s how.Your Default Gateway is a “catch-all”. Every time your machine needs to send network packets outbound to a location that is not listed in its local routing table, it will send those packets at whatever IP address is defined as your Default Gateway. This gateway is almost always a router or firewall of some kind. At home, it’s probably your home wireless router. At work, it is likely a firewall or a switch that is acting as a Layer 3 routing mechanism on your network.We will talk more about default gateways later, when we look more closely into the Windows routing table. But remember this – on any Windows computer, Windows Server, or really any networking device in the world, you should only ever have ONE Default Gateway on the entire system.

MAC addresses

Discussion of network traffic almost always lands on verbiage about IP addresses and subnets, which is accurate but not the full story. Every network card connected to your network has a unique identifier. Every computer NIC, every server, every printer, every PLC…the list goes on and on. You might be thinking “Hello Jordan, we just finished talking about these identifiers – IP addresses!” You’re not wrong, but you’re also not comprehensively right.IP addresses are configured on NICs, and are every device’s location on a network. However, when networking equipment such as firewalls, routers, and switches send traffic between sources and destinations, they are actually sending and tracking devices by information that is even further under the hood, MAC addresses. Every network card has a MAC address, which is a unique physical identifier on the network. IP addresses can be moved from one device to another, MAC addresses are typically bound to the network card. On a Windows machine, you’ll see some evidence later in this chapter that a NIC’s MAC address is displayed when you look at an ipconfig command. For something like a label printer, the MAC address is usually printed on a sticker directly attached to the back of the printer. You may remember that we had to define a MAC address inside DHCP back in Chapter 4, so that DHCP could always hand the same IP address to the device with a specific MAC address.Since we already discussed MAC addresses somewhat in our DHCP section, and will work directly with them again later in this chapter, I won’t expound upon this right now. But it is important to remember that IP addresses are not the end of the road when network traffic happens. DNS names are turned into IP addresses, IP addresses are turned into MAC addresses, and traffic then flows through your switches.

Introduction to IPv6

Welcome to the dark side! Unfortunately, that is how many people think of IPv6 for the time being. While IPv6 is by no means a new thing, in my experience, it is still something that almost no one has deployed in their networks. While working with hundreds of different companies all over the world over the past few years, I came across only two organizations that were running IPv6 over their entire production network, and one wasn’t even truly native IPv6. Instead, they were using a tunneling technology, called ISATAP, over their whole network to make all of the servers and clients talk to each other using IPv6 packets, but these packets were still traversing an IPv4 physical network. Don’t get me wrong; I found plenty of cases where companies were toying around with IPv6 and had some semblance of it configured in a sectioned-off piece of their networks, but using it for the entire production network? Most of us just aren’t ready for such an enormous change. Why is it so difficult to put IPv6 into place? Because we have used IPv4 since basically the beginning of time, it’s what we all know and understand, and there really isn’t a great need to move to IPv6 inside our networks. Wait a minute; I thought there was some big scare about running out of IPv4 addresses. Yes, that is true for IP addresses on the public internet, but that has nothing to do with our internal networks. You see, even if we run out of public IPv4 addresses tomorrow, the internal networks of our companies are not going to be impacted. We can continue to run IPv4 inside the network for a long time to come, possibly forever and always, as long as we are comfortable using NAT technologies to translate the traffic down into IPv4 as it comes into our network from the internet. We have all used NAT in one form or another for almost as long as IPv4 has existed, so it is obviously something people are very comfortable with.Let me be clear: I am not trying to convince you that sticking with IPv4 is the way of the future. I am just laying out the fact that, for most organizations over the next few years, this will simply be the truth. The reason I want to discuss IPv6 here is that, eventually, you will have to deal with it. And once you do, you’ll actually get excited about it! There are some huge advantages that IPv6 has over IPv4, namely, the enormous number of IP addresses that you can contain within a single network. Network teams in companies around the world struggle every day with the need to build more and more IPv4 networks and tie them together. Think about it: there are many companies now with employee counts in excess of 10,000. Some have many, many times that number. In today’s world, everyone needs almost constant access to their data. Data is the new currency. Most users now have at least two physical devices they utilize for work, sometimes more than that: a laptop and a tablet, a laptop and a smartphone, or a desktop and a laptop and a tablet and a smartphone; you get the idea. In the IPv4 world, where you are dealing with comparatively small IP address ranges, you must get very creative with creating subnets in order to accommodate all of these physical devices. Each needs a unique IP address to communicate on the network.The biggest advantage of IPv6 is that it resolves all these problems immediately and by default, by providing the capability to have a huge number of IP addresses within a single network. How many more addresses are we talking about? The following comparison data gives a little perspective:

An IPv4 address is a 32-bit length address that looks like this: 192.168.1.5

An IPv6 address is a 128-bit length address that looks like this: 2001:AABB:CCDD:AB00:0123: 4567:8901:ABCD

As you can see, the IPv4 address is much shorter, which obviously means there are fewer possibilities for unique IP addresses. What you don’t see is how much longer IPv6 addresses really are. These examples portray IPv4 and IPv6 addresses as we are used to seeing them, in their finished forms. Really though, the IPv4 address is shown in decimal form, and the IPv6 in hexadecimal. IPv6 addresses are shown and used via hex so that the addresses are compressed as much as possible. In reality, if you dig around under the hood, an IPv6 address in its native 128-bit form might look something like this (and indeed, this is how it looks inside the actual packet):00010000010000010000110110011000000000000000000100000000000000000001000000000000000000000000100000000000000000000000000000000001That’s an impressive set of digits, but not something that is very usable or friendly to the human eye. So, rather than show the bits, what about an IPv6 address shown in decimal format in the same way that IPv4 addresses have always been shown? In that case, an IPv6 address might look something like this:192.16.1.2.34.0.0.1.0.0.0.0.0.0.0.1Now we fully understand why IPv6 is always used and shown in hexadecimal; the addresses are long even in that compressed format!When we set up IPv4 networks, subnetting is extremely important because it is what enables us to have more than one collection of IP addresses within the same network. In the most basic form of networking, where you set up some IP addresses and run a /24 subnet, you are limited to 254 unique IP addresses. Ouch! Some companies have thousands of servers, without accounting for all of their client computers and devices that also need to connect to the network. Thankfully, we can build out many different subnets within a single IPv4 network to increase our usable IP address scope, but this takes careful planning and calculation of those subnets and address spaces and is the reason that we rely on experienced network administrators to manage this part of the network for us. One invalid subnet configuration in a routing table can tank network traffic flow. The administration of subnets in a large IPv4 network is not for the faint of heart.When we talk about IPv6 addressing, the sky almost seems to be the limit. If you were to calculate all the unique IPv6 addresses available in the preceding 128-bit space, you would find that there are more than 340 undecillion addresses available to be created. In other words, 340 trillion, trillion, trillion addresses. This is the number being touted out there about how many available addresses there are on the IPv6 internet, but what does that mean for our internal networks?To discuss the number of addresses we could have inside a typical internal network that runs IPv6, let’s first step back and look at the address itself. The address I showed earlier is just something I made up, but we will break down the parts of it here:2001:AABB:CCDD:AB00:0123:4567:8901:ABCDCompared to 192.168.1.5, this thing looks like a monstrosity. That is because we are generally not accustomed to dealing with the hexadecimal format; it is just a different way of looking at data. As we mentioned, this is a 128-bit address. It is broken into 8 sections, each sized at 16 bits and each section separated by a colon. The first 64 bits (the first half) of the address are routing information, and the latter 64 bits are the unique device ID on the network. Within the first part, we have two different components. The first 48 bits (3 groups of hex) are an organizational prefix that will be the same on all of our devices in the network. Then the fourth set of information, the next 16 bits, can be our subnet ID. This gives us the flexibility of still having many different subnets if we so desire in the future by using multiple numbers here as the subnet ID. After dedicating the first half of the address, we now have the latter half to work with, the last 64 bits. These we can leave for device IDs. This part of the address will be different for every device on the network and will define the individual static IPv6 addresses that will be used for communication. Let’s lay out our example address into the following parts:

Overall IP address: 2001:AABB:CCDD:AB00:0123:4567:8901:ABCD

Organizational prefix: 2001:AABB:CCDD

Subnet ID: AB00

Device ID: 0123:4567:8901:ABCD is one unique device ID

How many devices can we have in our network with an IP schema such as this? Well, even in our example, where we only allocated one 16-bit section for subnetting and 64 bits for actual IP addresses, that would provide us with the capability to have more than 65,000 subnets and quintillions of unique device IDs in our IP range. Impressive, isn’t it?If we stick with this and use only a single subnet to contain all of our machines, the first half of our addresses will always be the same, making these long addresses much easier to remember and deal with. It is surprising how quickly you will get used to seeing these large hex numbers in your environment, but even though you will start to recognize them, you still are probably not going to quickly jump into servers or computers in your network anymore by using the static IP addresses. I know a lot of us are still in the habit of saying: “I need to jump into my web server; I’ll just RDP into 192.168.1.5.” Even if you can remember an IPv6 address, the time that it takes to type out these addresses isn’t generally worth it. IPv6 will bring with it a larger reliance on DNS to make it usable.Now that we understand what sections of the address are going to be used for what purposes, how do we go about assigning the individual device ID numbers for all of the computers, servers, and other devices on our network? You could start with number 1 and go up from there. Another idea is to calculate the old IPv4 addresses into hex and use this as the last 32 bits of the address—open up Windows Calculator on your computer, drop down the menu, and change it into Programmer mode. This is a quick and easy tool that you can use to convert decimal into hexadecimal, and vice versa. Let’s take the example of my web server that is running on 192.168.1.5. I want to implement IPv6 inside my network, and I want my server’s IPv6 addresses to reflect the original IPv4 address in the device ID section of the new address. In my calculator, if I type in 192 and then click on HEX, it will show me the corresponding hexadecimal for the decimal of 192, as shown in Figure 8.2:

Figure 8.2: Using Windows Calculator to convert decimal into hexadecimal

If we do that with each of the octets in our IPv4 address, we will see the following:

192 = C0

168 = A8

1 = 01

5 = 05

So, my 192.168.1.5 factors out to C0A8:0105. I can now utilize that in combination with my organizational prefix and my subnet ID to create a static IPv6 address for my web server:2001:AABB:CCDD:0001:0000:0000:C0A8:0105You’ll notice in the preceding IPv6 address that I input the hex for the device ID at the end, but I also made a couple of other changes. Since we are leaving the last 64 bits available for the device ID, but my old IPv4 address only consumes 32 bits, I am left with the 32 bits in the middle. It would be kind of weird to have data in there that didn’t mean anything to us, so we will simply make it all zeros to simplify the addressing scheme. In addition to that change, I also adjusted my subnet ID to the number 1, since this is the first subnet in my network.Our new addressing is starting to look a little cleaner and makes more sense. Now that we see this new address for our web server laid out, I can see that there are some additional clean-up tasks we can perform on the address in order to make it look even better. Right now, the address listed earlier is 100% accurate. I could plug this IP address into the NIC properties of my web server and it would work. However, there are a whole lot of zeros in my address, and I don’t need to keep them all. Any time you have unnecessary zeros within a 16-bit segment that are preceding the actual number, they can simply be removed. For example, our subnet ID and the first 32 bits of our device ID have a lot of unnecessary zeros, so I can consolidate the address down to the following:2001:AABB:CCDD:1:0:0:C0A8:0105Then, to take it even a step further, any time you have full 16-bit sections that are composed entirely of zeros, they can be fully consolidated into a double colon. So, the first 32 bits of my device ID that are all zeros, I can replace with ::. The following is the full address and the consolidated address. These numbers look quite different. My consolidated address is much easier on the eye, but from a technological perspective, they are exactly the same number:2001:AABB:CCDD:0001:0000:0000:C0A8:01052001:AABB:CCDD:1::C0A8:0105In fact, if you set up a lab or want to quickly test IPv6, you can use addresses as simple as the following example. The two addresses that I will show you here are precisely the same:2001:0000:0000:0000:0000:0000:0000:00012001::1It is important to note that you can only use a double-colon once within an IP address. If you had two places where it was applicable within the same address, you could only implement it in one of those places, and you would have to spell out the zeros in the other place. For example, changing 2001:AA BB:0000:0000:0001:0000:0000:0123 into 2001:AABB::1::123 would cause your computer grief, as it would not know what to do with that second double-colon.With the information provided here, you should be able to put together your own semblance of IPv6 and start issuing some IPv6 addresses to computers or servers in your network. There is so much more to be learned on this subject that an entire book could be written, and indeed there are numerous offerings to choose from. Recent Windows computers and servers are well equipped to start using IPv6 right now inside NIC properties but keep in mind that other types of devices on your network, especially older ones, may not have any knowledge of IPv6 nor have a field to even input an IPv6 address. Legacy devices could be a major deciding factor, or roadblock, on your journey toward IPv6.

Your networking toolbox

Whether you are a server administrator, a network administrator, or a combination of the two, there are a number of tools that are useful for testing and monitoring network connections within the Windows Server world. Some of these tools are baked right into the operating system and can be used from Command Prompt, PowerShell, or Terminal, and others are more expansive graphical interfaces that require installation before running. The following are the built-in Windows network tools that we are going to look at:

ping

tracert

pathping

Test-Connection

telnet

Test-NetConnection

netstat

All of these tools are free and included out of the box, so you have no excuse to delay getting acquainted with these helpful utilities. Let’s explore these, as well as some more enhanced options provided by special teams at Microsoft, or even third parties.

ping

Even the newest IT pros are usually familiar with this one. ping is a command that you can utilize from Command Prompt or PowerShell, and it is simply used to query a DNS name and/or IP address to find out whether it responds. ping is, and has always been, our go-to tool for testing network connectivity between two devices on a network. From my Windows 10 client on the LAN, I can open a prompt and use ping <IP_ADDRESS>. Alternatively, because I am using DNS in my environment, which will resolve names to IP addresses, I can also use ping <SERVERNAME>, as shown in Figure 8.3. You can see that my server replies to my ping, letting me know that it is online and responding:

Figure 8.3: Pinging a server

Ping traffic is technically called ICMP traffic. This is important because the ICMP protocol is blocked by default more and more often these days, with firewalls being turned on by default on so many of our systems and devices. Historically, ping was always a tool that we could count on to tell us with a fair degree of certainty whether connectivity was flowing between two devices, but that is no longer the case. If you build a brand new Windows box and plug it into your network, that computer may communicate with the internet and all of the servers on your network just fine, but if you try to ping that new computer from another machine on your network, the ping will probably fail. Why would that happen? Because Windows has some security measures built into it by default, including blocking ICMP traffic in Windows Defender Firewall. In that case, you would need to either turn off the Windows firewall or provide it with an access rule that allows ICMP traffic. Once such a rule is enabled, pings will start replying from this new computer. Keep in mind whenever building new systems or servers in your network that ping is not always the most trustworthy tool to depend upon in today’s security-focused world.It’s easy to allow ICMP responses by plugging a rule into Windows Defender Firewall with Advanced Security, though you still wouldn’t want to have to remember to do this manually on every new system you introduce into a network. Thankfully, you already know how to utilize Group Policy to build a GPO and push it out to all machines on your network, and yes, you can absolutely place firewall rules inside that GPO. In fact, we will do exactly this in Chapter 10, Hardening and Security. This is a common way to allow or block ICMP throughout an entire organization, by issuing a firewall rule via Group Policy.

tracert

tracert, which is pronounced Trace Route, is a tool used to trace a network packet as it traverses your network. What it really does is report all of the places the packet bumps into before hitting its destination. These bumps in the road that a network packet needs to get through are called hops. tracert shows you all of the hops that your traffic takes as it moves toward the destination server or whatever it is trying to contact. My test lab network is very flat and boring, so doing a tracert there wouldn’t show us much of anything. However, if I open up a PowerShell prompt from an internet-connected machine and tracert to a web service, such as Bing, we get some interesting results:

Figure 8.4: Using tracert

If you utilize tracert but are not interested in seeing all of the DNS information provided in the output, use tracert -d to focus only on the IP addresses.This information can be extremely useful when trying to diagnose a connection that is not working. If your traffic is moving through multiple hops, such as routers and firewalls, before it gets to the destination, tracert can be essential in figuring out where in the connection stream things are going wrong. Given that the preceding screenshot shows a successful tracert to Bing, now let’s see what it looks like when things are broken. I will unplug my internet modem and run the same tracert www.bing.com again, and now we can see that I am still able to communicate with my local router, but not beyond it:

It is important to note that tracert relies on ICMP to receive responses back from the network devices that it contacts. If those network devices don’t permit an ICMP response, you won’t receive information back from those hops.

pathping

tracert is useful and seems to be the de facto standard for tracing packets around your network, but this next command is even more powerful in my opinion. pathping essentially does the same thing as tracert, except that it provides one additional piece of crucial information. Most of the time, with either of these commands, you are only interested in figuring out where in the chain of hops something is broken. Often though, when I’m setting up networking on new servers, I am working with servers and hardware that have many different network cards. When dealing with multiple NICs in a system, the local routing table is just as important as the external routers and switches, and I often want to check out the path of a network packet to see which local NIC it is flowing out of. This is where pathping becomes more powerful than tracert. The first piece of information that tracert shows you is the first hop away from the local server that you are traversing. However, pathping also shows you which local network interface your packets are flowing out of.Let me give you an example: I often set up remote access servers with multiple NICs, and during this process, create many routes on the local server so that it knows what traffic needs to be sent in which direction, such as what traffic needs to go out the internal NIC, and what traffic needs to go out the external NIC. After completing all of our routing statements for the internal NIC, we test them by pinging a server inside the network. Perhaps that ping fails, and we aren’t sure why. I can try a tracert command, but it’s not going to provide me with anything helpful because it simply cannot see the first hop; it just times out. However, if I use a pathping command instead, the first hop will still time out, but I can now see that my traffic is attempting to flow out of my external NIC. Whoops! We must have set something up incorrectly with our static route on this server. Pathping can be the key to realizing that I need to delete that route and recreate it to make this traffic flow through the internal NIC instead.The following is the same PowerShell prompt from the same computer that I used in my tracert screenshot. You can see that a pathping command shows me the local IP address on my laptop where the traffic is attempting to leave the system, whereas the tracert command did not show this information:

Figure 8.6: pathping shows the source NIC

Test-Connection

The commands we have discussed so far can be run from Command Prompt or PowerShell, but now it’s time to dive into a newer one that can only be run from the PowerShell prompt (or Terminal, of course, which can run PowerShell all day): a cmdlet called Test-Connection; it is sort of like ping on steroids. If we open a PowerShell prompt in the lab and run Test-Connection WEB1, we see output that is very similar to what we’d get with a regular ping, but the information is laid out in a way that I think is a little easier on the eyes. There is also an unexpected column of data here called Source:

Figure 8.7: Using Test-Connection

That is interesting. I was logged into my DC1 server when I ran this command, so my source computer for this command was DC1. But does this mean that I can manipulate the source computer for the Test-Connection cmdlet? Yes, this is exactly what it means.As with everything in Windows Server 2025 management, the need to be logged in to a local server is decoupled. Specific to the Test-Connection cmdlet, this means you can open a PowerShell prompt anywhere on your network and test connections between two different endpoints, even if you are not logged in to either of them. Let’s test that out.I am still logged in to my DC1 server, but I am going to use a Test-Connection cmdlet to test connections between a number of my servers in the network. You see, not only can you specify a source computer other than the one you are currently logged in to, but you can also take it a step further and specify multiple sources and destinations with this powerful cmdlet. So, if I want to test connections from a couple of different source machines to a couple of different destinations, that is easily done with the following command:

Test-Connection -Source DC1, DC2 -ComputerName WEB1, FS01

You can see in Figure 8.8 that I have ping statistics from both DC1 and DC2 to each of the WEB1 and BACK1 servers in my network. Test-Connection has the potential to be a very powerful monitoring tool:

Figure 8.8: Multiple sources and destinations using Test-Connection

One more useful function to point out is that you can clean up the output of the command by using the -Quiet switch. By adding -Quiet to a Test-Connection command, it sanitizes the output and only shows you a simple True or False for whether the connection was successful instead of showing you each individual ICMP packet that was sent. Unfortunately, you cannot combine both the -Source switch and the -Quiet switch, but if you use Test-Connection from the original source computer that you are logged in to, like most of us will be doing anyway, -Quiet works great. Most of the time, all we really care about is yes or no as to whether these connections are working, and don’t necessarily want to see all four attempts. By using -Quiet, we get exactly that:

Test-Connection -Quiet -ComputerName WEB1, DC2, CA1, FS01

If I were to use Test-Connection in the standard way to try to contact all of the servers in my network, that would turn into a whole lot of output. But by using the -Quiet switch, I get back a simple True or False on whether each individual server could be contacted:

Figure 8.9: Using the -Quiet switch

Telnet

telnet provides quite a bit of remote management capability; it essentially offers the ability to make a connection between two computers to manipulate the remote machine through a virtual terminal connection. What I find telnet most useful for is a simple connection testing tool, usually to verify that a server is listening on a certain port, and that my client can connect to that port.When we discussed ping, we talked about the downside of ICMP: it is easily blocked, and it’s more common in today’s networks for pings not to be successful, even if the destination server is online. This is unfortunate since ping has always been the most common form of network connection testing, but the reality is that, if ping makes our lives easier, it also makes the lives of hackers easier. If we cannot rely on ping to tell us with certainty whether we can contact a remote system, what do we use instead? Another case that I see often is where a server might be responding correctly, but a particular service running on that server has a problem and is not responding. A simple ping may show the server to be online, but it can’t tell us anything about the service specifically. By using the Telnet Client commands, we can easily query a server remotely. Even more importantly, we can opt to query an individual service on that server to make sure it is listening as it is designed to do. Let me give you an example that I use all the time.I often set up new internet-facing web servers. After installing a new web server, it makes sense that I would want to test access to it from the internet to make sure it’s responding, right? But maybe the website itself isn’t online and functional yet, so I can’t browse it with Edge or any other browser. It is quite likely that we disabled pings on this server or at the firewall level because blocking ICMP over the internet is very common for lowering the security vulnerability footprint on the web. So, my new server is running, and we think we have the networking all squared away, but I cannot test pinging my new server because, by design, it fails to reply. What can I use to test this? telnet. By issuing a simple telnet command, I can tell my computer to query a specific port on my new web server and find out whether it connects to that port. Doing this establishes a TCP socket connection to the port on that server, which is much more akin to real user traffic than a ping would be.If a telnet command connects successfully, you know your traffic is making its way to the server, and the server service running on the port we queried seems to be responding properly.The ability to use telnet is not installed by default in Windows Server 2025 or any other Windows operating system, so we first need to head into Server Manager and then Add Roles and Features to install the feature called Telnet Client:

Figure 8.10: Installing Telnet Client

You only need to install Telnet Client on the machine from which you want to do command-line testing. You do not have to do anything on the remote server that you are connecting to. In the screenshot above, I am installing this feature onto a workstation in my test lab.Now that the Telnet Client feature has been installed, we can utilize it from Command Prompt or PowerShell to do the work for us by attempting to make socket connections from our computer to the remote service. All we need to do is tell it what server and port to query. Then, telnet will simply connect or time out, and based on that result, we can see whether that particular service on the server is responding. Let’s try it with our own web server. For our example, I have turned off the website inside IIS, so we are now in the position where the server is online but the website is dead. If I ping WEB1, I can still see it happily responding. You can see where server-monitoring tools that rely on ICMP would show false positives, indicating that the server is online and running even though our website is inaccessible. Just below the successful ping in Figure 8.11, you can see that I also tried querying port 80 on the WEB1 server. The command that I used for that was telnet web1 80. That timed out. This shows us that the website, which is running on port 80, is not responding:

Figure 8.11: Failed connection on port 80

If I turn the website back on, we can try telnet web1 80 again, and this time, I do not get a timeout message. This time, my PowerShell prompt wipes itself clean and sits waiting on a flashing cursor at the top. While it doesn’t tell me “yay, I’m connected!” this flashing cursor indicates that a successful socket connection has been made to port 80 on my web server, indicating the website is online and responding:

Figure 8.12: A flashing cursor signals a successful connection

After creating a successful telnet socket connection, you may be wondering how to get back to the regular PowerShell interface. Press the Ctrl + ] keys together (that second one is a closed bracket key, usually next to the backslash key on your keyboard), type the word quit, and then press Enter. This should return you to a regular prompt. Or simply close the PowerShell prompt and open a fresh one.

Test-NetConnection

If ping has an equivalent and improved PowerShell cmdlet called Test-Connection, does PowerShell also contain an improved tool that works similarly to telnet for testing socket connections to resources? It sure does. Test-NetConnection is another way to query particular ports or services on a remote system, and the displayed output is friendlier than that of telnet.Let’s walk through the same tests, once again querying port 80 on WEB1. You can see in the following screenshot that I have run the command twice. The first time the website on WEB1 was disabled, and my connection to port 80 failed. The second time, I re-enabled the website, and I now see a successful connection:

Test-NetConnection WEB1 -Port 80

Figure 8.13: Using Test-NetConnection to test individual port connections

Packet tracing with Wireshark

Eventually, you might need to look a little deeper into your network packets. Now we are entering territory where your network team may also be involved, but if you are familiar with these tools, you may be able to solve the problem before needing to call for assistance. Making use of command-line tools to check on the status of servers and services is very useful, but occasionally, it may not be enough. For example, you have a client application that is not connecting to the application server, but you don’t know why. Utilities such as ping and even telnet might be able to connect successfully, indicating that network routing is set up properly, yet the application fails to connect when it opens. If the application’s own event logs don’t help you troubleshoot what is going on, you might want to take a deeper look inside the network packets that the application is trying to push toward the server.This is where the Wireshark application comes in handy. Microsoft used to supply and support a couple of self-developed tools called NetMon and Message Analyzer that served similar functions, but both have now been officially retired. Probably because Wireshark is great, and it’s free! This tool captures network traffic as it leaves or arrives to and from a system, and captures the information that is inside the packets so that you can take a deeper look into what is going on. In our example of an application that cannot connect, you could run Wireshark on the client computer to watch outgoing traffic, and also on the application server to watch for incoming traffic from the client.There is a whole lot of functionality inside Wireshark, and we don’t have the space to cover all of it here, so I will leave you with a link from which to grab this tool so you can start testing it out for yourself: https://www.wireshark.org/download.html.

PsPing

Upcoming in Chapter 17, we will discuss SysInternals tools, what they are and the history behind their existence. One of these tools is called PsPing, useful for enhanced network pings and connectivity testing. Not only can it be used to ping resources for simple connectivity checks and to check latency between endpoints, but can even be used to measure bandwidth between devices! PsPing is a standalone executable file that you must download and store on your Windows machine before you can make use of it via command line. Go ahead and grab it from here, and then we will look at a few of the most common uses of PsPing:https://learn.microsoft.com/en-us/sysinternals/downloads/pspingTo simply check for ICMP response between one device and another, throw something like this into the command line:

psping WEB1

You could tell PsPing to throw packets at a public DNS name, an internal DNS name, or an IP address, of course.Now let’s get a little bit fancier, and use PsPing to test TCP port connection, quite like we did with Test-NetConnection a few minutes ago:

Psping WEB1:80

This reaches out to the WEB1 server, querying whether it can make a successful connection to port 80. You can see the results of both commands in the following screenshot, where our first command was testing quick connectivity via ICMP, and the second command where we queried port 80 shows multiple connection attempts, all successful, using TCP connections to port 80 on WEB1.

Figure 8.14: Using PsPing to test connection between endpoints

TCPView

The tools that we have discussed so far are great and can be used daily for poking and prodding individual resources that you want to test, but sometimes there are situations where you need to step back and figure out what it is you are looking for in the first place. Maybe you are working with an application on a computer and are not sure what server it is talking to. Or perhaps you suspect a machine has a virus and is trying to “phone home” somewhere on the internet, and you would like to identify the location that it is trying to talk to or the process that is making the call. In these situations, it would be helpful if there was a tool that you could launch on the local computer that showed you all of the network traffic streams that were active on this computer or server clearly and concisely. That is exactly what TCPView does. TCPView is another tool created by Sysinternals; you may have heard of some of their other tools, such as ProcMon and FileMon, and of course PsPing which we mentioned only a moment ago. Running TCPView on a machine displays all of the active TCP and UDP connections happening on that computer in real time. Also important is the fact that you do not need to install anything to make TCPView work; it is a standalone executable, making it extremely easy to use and later clear off a machine when you are finished with it.You can download TCPView from:https://learn.microsoft.com/en-us/sysinternals/downloads/tcpviewSimply copy the file onto the computer or server that you want to monitor and double-click on it. Figure 8.15 shows the TCPView interface running on my local computer, displaying all of the connections that Windows and my applications are currently making. You can pause this output to take a closer look, and you can also set filters to pare down the data and find what you are really looking for. Filters get rid of the noise, so to speak, and enable you to look more closely at a particular destination or a specific process ID:

Figure 8.15: TCPView interface

netstat

For anyone who may not be a fan of downloading and running an executable, or just for anyone on the lookout for similar functionality via a built-in Microsoft command, netstat is a command-line tool that has been around for ages and displays similar (if not quite as useful) information to that of TCPView. Netstat will also show you per-port and per-process connection information on what is happening on the machine where you run the command. There are various switches that can be used to manipulate or enhance the netstat command output; if you open Command Prompt and utilize netstat /?, you will be presented with a full list of optional switches and their descriptions.My go-to method of utilizing netstat is by adding –ano. Open Command Prompt on any computer or server, and take a look at the output of netstat –ano, as seen in the following screenshot.

Figure 8.16: netstat displays open connections on my web server

After running your command, scroll back to the top of the output, and look at all those connections showing a Local Address of 0.0.0.0. These are the different ports that your server is currently using to listen for incoming connections. I utilize this output all the time when decommissioning old servers because oftentimes, you can figure out what a server is doing from what ports it is utilizing. In my screenshot above, you can see at a glance that this server is listening on ports 80, 443, and 445, most likely indicating that it is being used as a web server running HTTP and HTTPS connections, and file services over SMB. Over to the right side of the output, visible here due to my use of the -o switch, you can also see which Windows Process IDs (PIDs) own the ports being used.Netstat generates a ton of information, almost always multiple pages of IP address and port information. A lot of the time when utilizing netstat, what you are really trying to do is narrow in on a specific port number or PID, to discover whether that port or process are correctly listening for connections, or perhaps already have established connections on this system. Thankfully, a little bit of extra syntax can be added to our netstat command to narrow in on any flavor of specific information.

Netstat –ano | Select-String “text”

Replace the word “text” with any information you are searching for. If you are trying to figure out what connections are occurring for a process running on PID 1128, try netstat –ano | Select-String “1128”. Or another example, if you are trying to quickly figure out whether this system is listening for web connections on port 443, you can run the following: netstat –ano | Select-String “443”.

Figure 8.17 Searching for unique information within netstat

Now that we have discovered and tested some tools that are useful for testing connections, let’s move on to a new topic where we will begin to manipulate the flow of network traffic from our servers. Follow along as we learn about the Windows routing table.

The Windows routing table

When you hear the term routing table, it is easy to pass that off as something the network folks need to deal with, something that is configured within the network routers and firewalls. It doesn’t apply to server admins, right? Networking servers together has been made easy for us by only requiring an IP address, subnet mask, and default gateway, and we can instantly communicate with everything inside the rest of our network.While there is indeed a lot of networking magic going on under the hood that has been provided to us by networking equipment and network administrators, it is important to understand how routing inside Windows works because there will be some cases when you need to modify or build out a routing table directly on a Windows Server.

Multi-homed servers

Running multi-homed servers is a case where you would certainly need to understand and work with a local Windows routing table, so let’s start here. If you think this doesn’t apply to you because you’ve never heard of “multi-homed” before, think again. Multi-homed is just a funny-looking word meaning your server has more than one NIC. This could certainly be the case for you, even if you are a small shop that doesn’t have a lot of servers. Often, Small Business or Essentials Servers have multiple network interfaces, separating internal LAN traffic from internet traffic. Another instance of a multi-homed server would be a remote access server that provides DirectAccess, VPN, or proxy capabilities at the edge of your network. Yet another reason to be interested in and understand multi-homing is Hyper-V servers. It is very common for Hyper-V servers to make use of multiple NICs because the VMs that run on that server might need to tap into different physical networks within your organization.Now that we have established what a multi-homed server is, you might still be wondering why we are discussing this. If I have more than one NIC, don’t I simply configure each NIC individually inside Windows, giving each one an IP address, just like I would for any NIC on any server? Yes and no. Yes, you configure a distinct IP address on each NIC, because it needs that for the identification and transport of packets on the network. No, you do not set up all of the NICs on your server in the same way. There is one critical item that you need to keep in mind and adhere to in order to make traffic flow properly on your multi-homed server.

Only one default gateway

This is the golden ticket. When you multi-home a server by having multiple NICs, you can only have one default gateway. One for your entire server. This means you will have one NIC with a default gateway, and one or many NICs that do NOT have a default gateway inside their TCP/IP settings. This is extremely important. The purpose of a default gateway is to be the path of last resort. When Windows wants to send a packet to a destination, it browses over the local routing table—yes, there is a routing table even if you haven’t configured it or ever looked at it—and checks to see whether a specific, static route exists for the destination subnet where this packet needs to go. If a route exists, it shoots the packet out of that route and network interface to the destination. If no static route exists in the routing table, it falls back to using the default gateway and sends the traffic to that default gateway address. On all single NIC servers, the default gateway is a router that is designated with all the routing information for your network, so the server simply hands it to the router, and the router does the rest of the work.When we have multiple NICs on a Windows Server, we cannot give each one a default gateway because it will confuse the traffic flow from your server. Which default gateway is the right default gateway? This becomes a crapshoot for every network transmission. I have helped many people troubleshoot servers in the field with exactly this problem.Usually, this situation appears when an admin needed to use their server as a bridge between two networks, or have the server plugged into multiple different networks for whatever reason, and were struggling because sometimes the traffic seemed to work and sometimes it didn’t. We start looking through the NIC properties only to discover that every NIC has its own default gateway address in the TCP/IP properties. Bingo, that’s our problem. The system is completely confused when it tries to send out traffic because it doesn’t know which gateway it needs to use when.If you have ever tried adding default gateways to more than one NIC on the same server, you are probably familiar with the warning prompt that is displayed when you do this. Let’s give it a try. I have added another NIC to one of my servers and have IP settings configured on just one of the NICs. Now, I will add a new IP address, subnet mask, and default gateway onto my second NIC. When I click on the OK button to save those changes, I am presented with the following popup:

Figure 8.18: Warning message when configuring multiple default gateways

This is one of those warnings that is easy to misread because of its slightly cryptic nature, but you get the essence of it: proceed at your own risk! And then what do most admins do at this point? Simply click through it and save the changes anyway. Then, the routing problems begin. Maybe not today, maybe not tomorrow, but perhaps the next time you reboot that server, or maybe three weeks down the road, but at some point, your server will start to send packets to the wrong destinations and cause you trouble.

Building a route

So, what is our answer to all of this? Building a static routing table. When you have multiple NICs on a server, thereby making it multi-homed, you must tell Windows which NIC to use for what traffic inside the routing table. This way, when network traffic needs to leave the server for a particular destination, the routing table is aware of the different directions and paths that the traffic will need to take in order to get there and will send it out accordingly. You will still rely on routers to take the traffic the rest of the way, but getting the packets to the correct router by sending them out via the proper physical NIC is key to making sure that traffic flows quickly and appropriately from your multi-homed server.Now that we understand why the routing table is important and conceptually how we need to use it, let’s dig in and add a couple of routes to my dual-NIC server. We will add a route using Command Prompt, and we will also add one using PowerShell since you can accomplish this task from either platform, but the syntax used is different depending on which you prefer.

Adding a route with Command Prompt

Before we can plan our new route, we need to get the lay of the land for the current networking configuration on this server. It has two NICs: one is plugged into my internal network and one is plugged into my demilitarized zone (DMZ) that faces the internet. Since I can only have one default gateway address, it goes onto the DMZ NIC because there is no way that I could add routes for every subnet that might need to be contacted over the internet. By putting the default gateway on my DMZ NIC, the internal NIC does not have a default gateway and is very limited in what it can contact at the moment. The internal subnet that I am physically plugged into is 10.10.10.0/24, so I can currently contact anything in this small network from 10.10.10.1 through 10.10.10.254. This is known as an on-link route; since I am plugged directly into this subnet, my server automatically knows how to route traffic inside this subnet. However, I cannot contact anything else through my internal NIC because the routing table knows nothing about the other subnets that I have inside my internal network. For example, I have an additional subnet, 192.168.16.0/24, and there are some servers running within this subnet that I need to be able to contact from this new server. If I were to try to contact one of those servers right now, the packets would shoot out from my DMZ NIC because the routing table on my server has no idea how to deal with 192.168 traffic, and so it would send it toward the default gateway. The following is the general syntax of the route statement we need to follow in order to make this traffic flow from our server into the new subnet:

Route add -p <SUBNET_ID> mask <SUBNET_MASK> <GATEWAY> IF <INTERFACE_ID>

Before we can type out our unique route statement for adding the 192.168 network, we need to do a little detective work and figure out what we are going to use in these fields. The following is a break- down of the parts and pieces that are required to build a route statement:

-p: This makes the command persistent. If you forget to put -p in the route add statement, this new route will disappear the next time you reboot the server. Not good.

SUBNET_ID: This is the subnet we are adding; in our case, it is 192.168.16.0.

SUBNET_MASK: This is the subnet mask number for the new route, 255.255.255.0.

GATEWAY: This one is a little confusing. It is very common to think it means you need to enter the gateway address for the new subnet, but that would be incorrect. What you are actually defining here is the first hop that the server needs to hit in order to send out this traffic. Or, in other words, if you had configured a default gateway address on your internal NIC, what would that address have been? For our network, it is 10.10.10.1. This effectively instructs the server, “for any traffic destined for this route (192.168.16.0/24), shoot those packets at 10.10.10.1 (whom you already know how to contact) and that guy will figure out what to do.”

INTERFACE_ID: Specifying an interface ID number is not entirely necessary to create a route, but if you do not specify it, there is a chance that your route will bind itself to the wrong NIC and send traffic out the wrong direction. I have seen it happen before, so I always specify a NIC interface ID number. This is typically a one- or two-digit number that is the Windows identifier for the internal NIC itself. We can figure out what the interface ID number is by looking at the route print command:

Figure 8.19: Acquiring the interface ID number

At the top of route print, you see all of the server’s NICs. In our case, the internal NIC is the top one on the list. I identified it by running an ipconfig /all command and then comparing my internal NIC’s MAC address against the MAC addresses listed here. As you can see, my internal NIC’s interface ID number is 5. So in my route add statement, I am going to use IF 5 at the end of my statement to make sure my new route binds itself to that internal physical NIC.The following is our completed route add statement:

route add -p 192.168.16.0 mask 255.255.255.0 10.10.10.1 if 5

Figure 8.20: Running the complete route add statement

If you now run a route print command, you can see our new 192.168.16.0 route listed in the Persistent Routes section of the routing table, and we can now send packets into that subnet from this new server. Whenever our server has traffic that needs to go into the 192.168.16.x subnet, it will send that traffic out via the internal NIC, toward the router running on 10.10.10.1. The router then picks up the traffic from there and brings it into the 192.168.16.0 subnet:

Figure 8.21: Sending traffic to the 192.168.16.0 subnet

Deleting a route

Occasionally, you may key in a route statement incorrectly. The best way to handle this is to simply delete the bad route and then rerun your route add statement with the correct syntax. There are possibly other reasons why you might need to delete routes every now and then, so you’ll want to be familiar with this command. Deleting routes is much simpler than adding new ones. All you need to know is the subnet ID for the route that you want to remove and then simply use route delete <SUBNET_ID>. For example, to get rid of the 192.168.16.0 route that we created while we were working inside Command Prompt, I would simply issue this command:

route delete 192.168.16.0

Adding a route with PowerShell

Since PowerShell is king when it comes to most command-line-oriented tasks inside Windows Server, we should accomplish the same mission from this interface as well. You can utilize the same route add command from inside the PowerShell prompt and that will work just fine, but there is also a specialized cmdlet that we can use. Let’s utilize New-NetRoute to add yet another subnet to our routing table. This time, we are going to add 192.168.17.0. The following is a command we can utilize:

New-NetRoute -DestinationPrefix "192.168.17.0/24" -InterfaceIndex 5 -NextHop 10.10.10.1

Figure 8.22: Adding another subnet to our routing table

I already knew that my interface number was 5 for this NIC because of my route print output earlier. If you do not know that information and want to stick with PowerShell cmdlets to find it, a quick Get-NetAdapter will tell you everything you need to know

You can see that the structure is similar, but a little bit friendlier. Instead of having to type the word mask and specify the whole subnet mask number, you can use the slash method (CIDR) to identify the subnet and mask within the same identifier. Also, where before we were specifying the gateway, which is always a little confusing, with the New-NetRoute cmdlet, we instead specify what is called the NextHop. This makes a little bit more sense to me.Where we previously utilized route print to see our full routing table, the PowerShell cmdlet to display that table for us is simply Get-NetRoute:

Figure 8.23: Displaying our full routing table

Building routing tables is essential knowledge for any server admin who encounters a server with multiple network interfaces that are connected to different networks. Now, let’s discuss another use case where you may find multiple network cards on the same server, but this time, connected to the same network.

NIC Teaming

Moving on to another network topic that is becoming more and more popular on server hardware, let’s walk through the steps to create NIC Teaming. The ability to team NICs essentially consists of binding two or more physical network interfaces together so that they behave as if they were a single network interface within Windows. This allows you to plug two physical cables into two different switch ports, all using the same settings. That way, if one NIC port, switch port, or patch cable goes bad, the server continues working and communicating without hesitation, because teaming allows the NIC that is still working to handle the network traffic.

NIC Teaming itself is nothing new. It has been around for more than 10 years inside the Windows Server operating system. However, early versions were problematic, and in the field, I find that Server 2019 is the earliest server operating system most IT personnel consider to be stable enough to use NIC Teaming in production.

To begin teaming together your NICs, you need to make sure that you have multiple network cards on your server. I currently have four NIC ports on this machine. I have plans to create two teams: my first and second NICs will be bound together to become an Internal Network Team, and my third and fourth NICs will become a DMZ Network Team. This way, I have network card redundancy on both sides of my network flow on this server.The first thing I want to do is clear out any IP addressing settings that might exist on my NICs. You see, once you tie together multiple NICs into a team, you will configure IP addressing settings for the team—you will no longer dive into individual NIC properties to assign IP addresses. So, open up the properties of each NIC and make sure they are clear of static IP information, like so:

Figure 8.24: Clearing the static IP addresses of each NIC

Now open Server Manager and click on Local Server. Looking inside the properties information for your server, you will see listings for each of your NICs, as well as an option called NIC Teaming, which is currently set to Disabled:

Figure 8.25: NIC Teaming is initially disabled

Go ahead and click on the word Disabled, and now look for a section entitled Teams. Click on the Tasks button and choose to create a New team.Give your new team an appropriate name and select the NICs that you want to be part of this team. Once finished, you can walk through the same steps as many times as you need to create additional teams with your remaining NICs:

Figure 8.26: Creating a new NIC team

Dropping down the Additional properties arrow, you will notice some optional settings that require a little bit of explanation. Depending on what type of system you are running (virtual or physical servers), you may not be able to see or use all of these options.

Teaming mode: Switch Independent is the default, and usually the route you want to travel. This selection means your NICs that are about to be teamed together can be plugged into different switches. Alternatively, Switch Dependent mode does require all NICs to be connected to the same switch and comes with some additional options that need to pair up with your switch configuration.

Load balancing mode: Three options to choose from here. Address Hash is the default, and indicates that packets will be assigned a hash value that is used to direct them toward particular adapters. Hyper-V Port, on the other hand, uses VM MAC addresses to distribute traffic. The third option, Dynamic, sort of meshes the other two options, with outbound traffic using the address hash and incoming traffic being distributed based on the MAC address.

Standby adapter: Your NIC team will be created so that both NICs are handling traffic unless you visit this option and choose differently. Here, you could specify for one of your NICs in a team to run in standby mode, meaning that it will not process network traffic unless one of the other NICs fails.

Once finished, you will see your teams listed inside Server Manager, and if you open the Network Connections screen inside Windows, you can see in Figure 8.27 that, in addition to the four physical NICs, I now have two new entries listed here, which are the configuration locations for our new teams. From here, I can right-click on each of my network teams and configure IP addressing information just like I would have done for a single NIC. IP information input into the team properties will be in effect on all NICs that are part of the team:

Figure 8.27: NIC Teams are listed as additional adapters inside Network Connections

The items we have discussed so far in this chapter are useful for any environment utilizing Windows Server 2025, and can also be applied to many previous versions of the Windows Server operating system. Next, we will move on to a topic that some of you may already be living with, but many others may have never even heard of – software-defined networking.

Software-defined networking

The flexibility and elasticity of cloud computing cannot be denied, and most technology executives are currently exploring their options for utilizing cloud technologies. One of the big stumbling blocks with adaptation is trust. Cloud services provide enormous computing power, immediately accessible at the press of a button. For companies to store their data on these systems, the level of trust that your organization has in that cloud provider must be very high. After all, you don’t own any of the hardware or networking infrastructure that your data is sitting on when it’s in the cloud, and so your control of those resources is limited at best. Seeing this hurdle, Microsoft has made many efforts in recent updates to bring cloud-like technology to the local datacenter. Introducing server elasticity into our datacenters means virtualization. We have virtualized servers for many years now, although the capabilities there are continually being improved. Now that we have the ability to spin up new servers so easily through virtualization technologies, it makes sense that the next hurdle will be our ability to easily move these virtual servers around whenever and wherever we need to.Do you have a server that you want to move into a datacenter across the country? Are you thinking of migrating an entire datacenter into a new co-location across town? Maybe you have recently acquired a new company and need to bring its infrastructure into your network but have overlapping network configuration. Have you bought into some space at a cloud service provider and are now trying to wade through the mess of planning the migration of all your servers to the cloud and onto the cloud provider’s infrastructure? These are all questions that require an answer, and that answer is SDN.SDN is a broad, general term that umbrellas many technologies working together to make this idea possible. Boiled down to a one-liner, Software Defined Networking takes the layers at play in any network interaction, and manages them using software. For example, inside a switch you have the infrastructure layer where the work of moving packets around is happening. You also have the control layer where the switch is remembering all of the information that it needs to correctly tell the infrastructure layer what to do, and then you have the application layer where you as an administrator manage the switch configuration. SDN takes these layers, and breaks each one out in a way that is defined and managed by software. This software is centrally administered by a network controller of some sort. SDN enables you to extend your network boundaries whenever and wherever you need. Let’s take a look at some of the parts and pieces available in Windows Server 2025 that work in tandem to create a virtual networking environment, the first step in adopting our software-defined networking ideology.

Hyper-V Network Virtualization

Hyper-V contains integral components for SDN, allowing you to pick up your networks and servers and slide them around on a layer of virtualization. This makes sense because this is the same platform that we utilize to virtualize servers. With Hyper-V Network Virtualization, we create a separation between virtual networks and physical networks. You no longer need to accommodate IP scheme limitations on the physical network when you set up new virtual networks because the latter can ride on top of the physical network, even if the configurations of two or more networks would normally be incompatible.This concept is slightly difficult to wrap your head around if this is the first time you are hearing about it, so let’s discuss some real-world situations that would benefit from this kind of separation.

Private clouds

Private clouds are steamrolling through datacenters around the world because they make a tremendous amount of sense. Anyone interested in bringing the big benefits of the cloud into their environments, while at the same time staying away from cloud negatives, can benefit from this.Building a private cloud gives you the ability to have dynamically expanding and shrinking compute resources and the ability to host multiple tenants or divisions within the same compute infrastructure. It provides management interfaces directly to those divisions so that the nitty-gritty setup and configuration work can be done by the tenant and you don’t have to expend time and resources on the infrastructure-provider level, making small, detailed configurations.Private clouds enable all of these capabilities while staying away from the big scare of your data being hosted in a cloud service provider’s datacenter, which you have no real control over, and all of the privacy concerns surrounding that.To provide a private cloud inside your infrastructure, particularly one where you want to provide access to multiple tenants, the benefits of network virtualization become apparent, and even a requirement. Let’s say you provide computing resources to two divisions of a company, and they each have their own needs for hosting some web servers. No big deal, but these two divisions both have administrative teams who want to use IP schemes that are within 10.0.0.0. They both need to be able to use the same IP addressing subnets on the same physical core network that you are providing, yet you need to keep all their traffic completely segregated and separated. These requirements would have been impossible on a traditional physical network without creating physical separation between those divisions, but by employing the power of network virtualization, you can easily grant IP subnets and address schemes of whatever caliber each division chooses. They can run servers on whatever subnets and IP addresses they like, and all of the traffic is encapsulated uniquely so that it remains separated, completely unaware of the other traffic running around on the same physical core network that runs beneath the virtualization layer. This scenario also plays out well for corporate acquisitions. Two companies who are joining forces at the IT level often have conflicts with domains and network subnetting. With network virtualization, you can allow the existing infrastructure and servers to continue running with their current network config, but bring them within the same physical network by employing Hyper-V Network Virtualization.Another example is one where you simply want to move a server within a corporate network. Maybe you have a legacy line-of-business server that many employees still need access to, and their daily workload includes the requirement for that LOB application to be working at all times. The problem with moving the server is that the LOB application on the client computers has a static IPv4 address configured, through which it communicates with the server. When the user opens their app, it does something such as talk to the server at 10.10.10.10. Traditionally, that could turn into a deal-breaker for moving the server because moving that server from its current datacenter into a new location would mean changing the IP address of the server, and that would break everyone’s ability to connect to it. With virtual networks, this is not an issue. With the ability to ride network traffic and IP subnets on the virtualization layer, that server can move from New York to San Diego and retain all of its IP address settings because the physical network running underneath doesn’t matter at all. All of the traffic is encapsulated before it is sent over the physical network, so the IP address of the legacy server can remain at 10.10.10.10, and it can be picked up and moved anywhere in your environment without interruption.

Hybrid clouds

While adding flexibility to your corporate networks is already a huge benefit, the capabilities provided by virtualizing your networks expand exponentially when you do finally decide to start delving into real cloud resources. If and when you make the decision to move some resources to be hosted by a public cloud service provider, you will likely run a hybrid cloud environment. This means that you will build some services in the cloud, but you will also retain some servers and services on-site. In fact, some companies may remain in a hybrid cloud scenario for the rest of eternity, as a 100% movement to the cloud is simply not possible given the ways that many of our companies do business. So, now that you want to set up a hybrid cloud, we are again looking at all kinds of headaches associated with the movement of resources between our physical and cloud networks. When I want to move a server from on-site into the cloud, I need to adjust everything so that the networking configuration is compatible with the cloud infrastructure, right? Won’t I have to reconfigure the NIC on my server to match the subnet that is running in my cloud network? Nope, not if you have your network virtualization infrastructure up and running. Once again, software-defined networking saves the day, giving us the ability to retain the existing IP address information on our servers that are being moved and simply run them with those IP addresses in the cloud. Again, since all of the traffic is encapsulated before being transported, the physical network that is being provided by the cloud does not have to be compatible with, or distinct from, our virtual network, and this gives us the ability to seamlessly shuttle servers back and forth from on-premises to the cloud without having to make special accommodations for networking.

How does it work?

So far, it all sounds like a little bit of magic; how does this actually work and what pieces need to fit together in order to make network virtualization a reality in our organization? Something this comprehensive surely has many moving parts and cannot be turned on by simply flipping a switch. In any network where virtualization is functioning, there have been various components configured to make that successful. Let’s do a little explaining here so that you have a better understanding of the technologies and terminology that you will be dealing with once you start your work with software-defined networking.

System Center Virtual Machine Manager

Microsoft System Center is a key piece of the puzzle for creating your software-defined networking model, particularly the Virtual Machine Manager (VMM) component of System Center. The ability to pick up IP addresses and move them to other locations around the world requires some coordination of your networking devices, and VMM is here to help. This is the component that you interface with as your central management point to define and configure your virtual networks. System Center is an enormous topic with many options and data points that certainly won’t fit in this book, so I will leave you with a link as a starting point on VMM learning: https://learn.microsoft.com/en-us/system-center/vmm/?view=sc-vmm-2025.

Network Controller

Microsoft’s Network Controller is a role that was initially introduced in Windows Server 2016, and as the name implies, it is used for control over network resources inside your organization. In most cases, it will be working side by side with VMM to make network configurations as centralized and seamless as possible. Network Controller is a standalone role and can be installed onto Server 2016, 2019, 2022 or 2025 and then accessed directly, without VMM, but I don’t foresee many deployments leaving it at that. Interfacing with Network Controller directly is possible by tapping into its APIs with PowerShell, but is made even better by adding on a graphical interface from which you configure new networks, monitor existing networks and devices, or troubleshoot problems within the virtual networking model. The graphical interface that can be used is System Center VMM.Network Controller can be used to configure many different aspects of your virtual and physical networks. You can configure IP subnets and addresses, configurations, and VLANs on Hyper-V switches, and you can even use it to configure NICs on your VMs. Network Controller also allows you to create and manage Access Control List (ACL)-type rules within the Hyper-V switch so that you can build your own firewalling solution at this level without needing to configure local firewalls on the VMs themselves or have dedicated firewall hardware. Network Controller can even be used to configure load balancing and provide VPN access through Routing and Remote Access Service (RRAS) servers.Prior to Windows Server 2025, it was Microsoft’s recommendation to never install Network Controller onto physical servers, and keep this function on dedicated Hyper-V VMs. However, Server 2025’s release moves the Network Controller function into Failover Cluster services, which you can utilize across physical server instances to provide the Network Controller functions.

Network Security Groups (NSGs)

If you have done any networking inside Azure, you are probably familiar with Network Security Groups. NSGs are sort of like virtual firewalls, keeping network traffic protected behind security rules that define what the NICs (which are part of the NSG) are and are not allowed to communicate with.NSGs can also be used inside a virtualized network infrastructure, even on-premise. In fact, once you have SDN established and are virtualizing your networks, NSGs can be created and modified directly from Windows Admin Center, which is pretty slick.Something new for Windows Server 2025 is that administrators can now utilize tags to associate NSGs and VMs, to control access. Security policies can then be applied to the tags, so that you no longer need to remember IP address ranges when creating your rules. This can be especially helpful when modifying rules that might apply to multiple IP addresses, you can now modify one tag instead of visiting numerous rules to update IP ranges.

Generic Routing Encapsulation

Generic Routing Encapsulation (GRE) is just a tunneling protocol, but it’s imperative in terms of making network virtualization happen successfully. Earlier, when we talked about moving IP subnets around and about how you can sit virtual networks on top of physical networks without regard for making sure that their IP configurations are compatible, we should add that all of that functionality is provided at the core by GRE. When your physical network is running 192.168.0.x but you want to host some VMs on a subnet in that datacenter, you can create a virtual network of 10.10.10.x without a problem, but that traffic needs to be able to traverse the physical 192.168 network for anything to work. This is where routing encapsulation comes into play. All of the packets from the 10.10.10.x network are encapsulated before being transported across the physical 192.168.0.x network. The 192.168.0.x network sees these packets as 192.168.0.x packets, but they are actually carrying payloads for the 10.10.10.x network.There are two specific routing-encapsulation protocols that are supported in our Microsoft Hyper-V Network Virtualization environment. Initially, Microsoft only configured Hyper-V to work with Network Virtualization Generic Routing Encapsulation (NVGRE) when setting up Network Virtualization. Another protocol called Virtual Extensible Local Area Network (VXLAN) is a little bit newer to the Windows Server world, but has existed for quite some time in other technologies. Many network switches—particularly Cisco—that you have in your environment are more likely to support VXLAN than they are NVGRE. Now that VXLAN is a supported encapsulation protocol for Hyper-V Network Virtualization, it is more likely that you would select this option over NVGRE.You don’t necessarily have to understand how these GRE protocols work in order to make them work for you since they will be configured for you by the management tools that exist in this Hyper-V Network Virtualization stack. But it is important to understand in the overall concept of this virtual networking environment that GRE exists, and that it is the secret to making all this work.

Microsoft Azure Virtual Network

Once you have Hyper-V Network Virtualization running inside your corporate network and get comfortable with the mentality of separating the physical and virtual networks, you will more than likely want to explore the possibilities around interacting with cloud service provider networks. When you utilize Microsoft Azure as your cloud service provider, you tap into the ability to build a hybrid cloud environment that bridges your on-premises physical networks with remote virtual networks hosted in Azure. Azure’s virtual network is the component within Azure that allows you to bring your own IP addresses and subnets into the cloud. You can get more info (and even sign up for a free trial for Azure Virtual Network) here: https://azure.microsoft.com/en-us/products/virtual-network/.

RAS Gateways/SDN Gateways

When you are working with physical networks, virtual networks, and virtual networks that are stored in cloud environments, you need some component to bridge those gaps, enabling the networks to interact and communicate with each other. This is where a RAS Gateway (also called an SDN Gateway) comes into play. This role has enjoyed a few different names over the years; you may also see these servers referenced as a Windows Server Gateway or even the Hyper-V Network Virtualization Gateway in some documentation. A RAS Gateway’s purpose is simple: to be the connection between a virtual network and some other network, most often, a gateway between a virtual network and a physical network. These virtual networks can be hosted in your local environment, or in the cloud. In either case, when you want to connect networks, you will need to employ a gateway. When you are creating a bridge between on-premises and the cloud, your cloud service provider will utilize a gateway on their side, which you will tap into from the physical network via a VPN tunnel.A RAS Gateway can be a virtual machine, or an entire pool of virtual machines, and is integrated with Hyper-V Network Virtualization. A single gateway or pool of gateways can be used to route traffic for many different customers, tenants, or divisions. Even though these different customers have separated networks that need to retain separation from the traffic of the other customers, cloud providers—public or private—can still utilize RAS Gateway to manage this traffic because the gateways retain complete isolation between those traffic streams. You can even run entire pools of gateways on a single public IP address, enabling multiple tenants to connect to the same IP, while still maintaining separation between all of those tenants’ traffic streams.The Windows Server Gateway functionality existed back in Server 2016, but once it was put into practice, some performance limitations that restricted network traffic throughput were discovered. Those overheads have been increased dramatically in subsequent versions of Windows Server, meaning that you can flow more traffic and additional tenants through a single gateway than was previously possible.

Virtual network encryption

Security teams are continually concerned with the encryption of data. Whether that data is stored (at rest) or on the move, making sure that it is properly secured and safe from tampering is essential. Prior to Server 2019, getting inner-network traffic encrypted while it was moving was generally the responsibility of the software application, not the network’s job. If your software can encrypt traffic while it is flowing between the client and server, or between the application server and the database server, great! If your application does not have native encryption capabilities, it is likely that the communications from that application are flowing in cleartext between the client and server. Even for applications that do encrypt, encryption ciphers and algorithms are often being cracked and compromised. Your application vendors may or may not be on top of the security game as new vulnerabilities are discovered, and even if your applications are protected today, it’s possible they will not be tomorrow.Fortunately, Windows Server 2025 brings us some comfort on this topic, provided within the boundaries of software-defined networking. This capability is called virtual network encryption, and it does just what the name implies. In an SDN environment, when traffic moves between virtual machines and between Hyper-V servers (within the same network), entire subnets can be flagged for encryption, which means that all traffic flowing around those subnets is automatically encrypted at the virtual networking level. The VM servers and the applications that are running on those servers don’t have to be configured or changed in any way to take advantage of this encryption, as it happens within the network itself, automatically encrypting all traffic that flows on that network.With Server 2025 as the core of your SDN capabilities, any subnet in a virtual network can be flagged for encryption by specifying a certificate to use for that encryption. If the future happens to bring the scenario where current encryption standards are out of date or insecure, the SDN fabric can be updated to new encryption standards, and those subnets will continue to be encrypted using the newer methods, once again without having to make changes to your VMs or applications. If you are using SDN and virtual networks in your environment, enabling encryption on those subnets is a no-brainer!

Bridging the gap to Azure

Most companies that host servers in Microsoft Azure still have physical, on-premises networks and one of the big questions that always needs to be answered is, how are we going to connect our physical datacenter to our Azure datacenter? Most businesses with comprehensive enough networking to be utilizing SDN will establish one of two different methods to make this happen.

A VPN gateway

Microsoft’s VPN Gateway is a SKU that you spin up in Azure, a virtual firewall of sorts that is capable of creating a connection between Azure and your on-premise firewalls or gateway servers using an IPsec site-to-site VPN tunnel. This establishes a continuous tunnel between the two networks, which is managed by you on your own servers or appliances. One benefit to this simple site-to-site VPN tunnel is that it is quick to set up as long as your on-prem equipment is stable and compatible. If your local ISP goes down, then of course your connection to Azure will go down with it. Most admins pursue building a VPN Gateway for the purpose of connecting the entirety of on-premise infrastructure to Azure, but one other neat feature of VPN Gateway is that it also provides point-to-site VPN connection capability. When configured, client computers can connect directly to this Azure-located VPN gateway using SSTP, OpenVPN, or IPsec client VPN connectivity.

Azure ExpressRoute

VPN gateways are great, but completely rely on traditional internet connections. Outages or latency can create significant issues with your connectivity to Azure. If you require higher bandwidth between a local datacenter and Azure, or a higher guaranteed percentage of uptime, Microsoft provides a service called Azure ExpressRoute that can be used for these more intense networking requirements. ExpressRoute is a dedicated connection between your building and Azure; the edge environments on both your side and the Azure side, as well as the connection itself, are dedicated and provided by a third party. ExpressRoute comes with a 99.99% availability Service Level Agreement (SLA) across the entire connection, which is pretty impressive. ExpressRoute is, of course, more expensive than setting up your own VPN, and you need to work with a third-party provider to build and maintain your ExpressRoute connection.

Third-party options

Microsoft partners with various vendors and third parties to provide additional connectivity options between your on-premise datacenter and Azure networks. As an example, the company that I work for deploys and maintains a lot of Cisco Meraki gear. Meraki firewalls have a unique SD-WAN capability that very easily ties all your sites together with constant site-to-site VPN tunnels. This can extend into the Azure environment as well if you place a Meraki firewall into your Azure network. How in the world would I do that? By deploying a Meraki vMX (virtual firewall) appliance into Azure. Once deployed, the vMX simply shows up as one more firewall to be managed and maintained inside your Meraki portal, and it taps into the rest of your Meraki infrastructure seamlessly.There are other network vendors that provide similar services, but I have not personally tried them. I can tell you that the Meraki setup works well, and is often our preferred connectivity method to the cloud for small-medium businesses.

Azure Network Adapter

If you have an on-premises server that you need to quickly connect to your Azure environment, and you don’t already have a permanent connection established between your physical and Azure sites, there is a hybrid cloud capability called Azure Network Adapter that can be attached to Windows Server. To use one of these network adapters, you must utilize Windows Admin Center to manage your servers.Using Windows Admin Center, you can quickly add Azure Network Adapter to an on-premises server, which connects it straight to your Azure network using a point-to-site VPN connection. Cool! This capability is helpful for small businesses that have cloud resources and want to connect just a single on-premises server to Azure, or even within a branch office scenario at a larger company. Rather than creating site-to-site connections between your primary datacenter and every branch office, if your primary datacenter was already permanently connected to Azure, you could then connect branch office servers directly to Azure using Azure Network Adapter.What Azure Network Adapter really does is configure a point-to-site (P2S) VPN for you on that server, connecting the server to Azure via a VPN tunnel. As you know, a VPN tunnel requires both client configuration and a VPN concentrator or gateway on the receiving side, which is exactly what Azure Network Adapter does. It configures the P2S client VPN on the server and spins up a Virtual Network Gateway inside Azure to receive that connection.Even better, this capability has been back-ported so that you can add one of these adapters not only to Server 2025 machines but also to Server 2022, Server 2019, Server 2016, and Server 2012 R2 machines as well.To make this happen, there are a few requirements that need to be in place. You must have an active Azure subscription, and you need to have at least one Azure virtual network configured.Next, you need to register your Windows Admin Center with Azure. This is accomplished by opening Windows Admin Center and visiting Settings. Once inside, navigate to Gateway | Register and walk through the registration process:

Figure 8.28: Registering WAC with Azure

Now that WAC is registered with Azure, open the server that you are managing from inside WAC and head over to the Networks section. You will see any NICs that are present on your server listed here, and near the top of the window is a button to + Add Azure Network Adapter (Preview):

You’ll notice in this text and screenshots that the word “Preview” still exists in the title of this feature, but this capability has existed and continues to be titled “Preview” ever since it was released a few years ago. Microsoft documentation no longer declares this to be a preview feature; I believe they have simply forgotten to remove the word “Preview” from the text inside WAC.

Figure 8.29: Adding Azure Network Adapter

You will find that all of the values Azure needs to make this connection are auto-populated for you, based on your Azure network and subscription. If you don’t already have an Azure virtual network, this wizard can even create one for you. You also get the opportunity to specify your own certificate for authenticating this connection, and doing so would be a good practice if you planned for this to be a long-term connection to Azure; otherwise, you can proceed without any input by allowing WAC/Azure to generate a self-signed certificate and simply clicking on the Create button. Windows Admin Center will go ahead and create a connection between your on-premises server and the Azure virtual network. That was only a couple of mouse clicks! This is an ingenious way of creating ad hoc connections between your servers and Azure very quickly and without complications.If you later need to disconnect this server from the Azure network, you can open Network Connections on that on-premises server, just like you would when modifying any NIC properties on your server, and you will find that what WAC has done under the hood is configure a point-to-site VPN connection, which is listed inside Network Connections. You can simply right-click on that Azure VPN connection and disconnect it.

Summary

Server administration and network administration have historically been different camps, but over time, those lines have blurred. There are numerous networking configurations and tasks that now need to be accomplished by Windows Server administrators without needing to involve a networking team, so it is important that you maintain a good understanding of how your infrastructure is connected. Familiarity with the tools laid out in this chapter will provide you with the ability to configure, monitor, and troubleshoot most Microsoft-centric networks.Our introduction to software-defined networking may have been a partially confusing section if you had never encountered this idea before, but hopefully it prompts you to dig a little deeper and prepare yourself for dealing with this in the future. Ready or not, the cloud is here to stay. Microsoft on-premises networks now have numerous ways to interact with Microsoft Azure, and it will soon be imperative that IT staff is familiar with these concepts. The idea of SDN will grow in popularity over the coming years. At the moment, it may seem daunting, but in a handful of years we may all look back and wonder how we ever made things work with virtual networks, the same way we feel today about virtual servers. There is much more information both on Microsoft Learn and in published books about Hyper-V Virtual Networking and System Center VMM if you are interested in setting this up for yourself. For now, continue on to our next chapter, where we will discuss the componentry in Windows Server 2025 that is going to enable our employees to work remotely, which is particularly interesting content in this new work-from-home world we are living in.

Questions

What is the CIDR that represents a subnet mask of 255.255.255.0?

Why could a corporate subnet of 192.168.1.0/24 cause problems for remote employees?

How many bits in length is an IPv6 address?

Re-write the following IPv6 address in condensed form: 2001:ABCD:0001:0002:0000:0000: 0000:0001.

What is the name of the command that is similar to tracert but displays the local NIC that traffic is flowing out of?

True or False—On a server with multiple NICs, you should input a default gateway address onto each of those NICs.

What is the PowerShell cmdlet that can be used to create new routes on Windows Server?

Which Windows Server operating systems can be used with Azure Network Adapter in order to connect them directly to Azure virtual networks?

Which connectivity method between a local datacenter and Azure provides the fastest, most robust, and most reliable connection?

9Remote Access

Join our book community on Discord

https://packt.link/zYovfProviding employees with the ability to remotely access corporate resources used to be a big benefit to most companies, but not necessarily a requirement. That little C-word which shall not be named changed everything, and quite immediately every company in much of the world suddenly faced a need to grant access to employees who had to work from home. Indeed, as time progressed and some of the turbulence died down, companies realized that they could save quite a few expenses by offering continued work-from-home jobs, and since the year 2020 the working landscape has completely shifted. In fact, many remote workers took this idea and ran even further with it, where “work-from-home” is now “work-from-anywhere”, and I have spoken with multiple remote workers who live and work from a travel trailer. They work by day, travel by night. Or sometimes the reverse. Interestingly, as I type these words there are headlines in the news almost every day about another company who has issued an “RTO order” (return to office). So far this seems to be impacting large organizations and governmental entities, but it will certainly be interesting to watch as this progresses. Regardless of this recent backpedaling, most companies and employees now expect the option to tap into resources from wherever they happen to be. The technology most universally employed to grant remote workers the ability to do their jobs from home, coffee shops, hotels, or even campers, is a Virtual Private Network (VPN) connection.Most VPNs in today’s businesses are provided by products from companies other than Microsoft. I want you to know that the Remote Access role in Windows Server 2025 provides multiple ways to provide that access, without the need to involve a third party. With many improvements having been made to the VPN components right in Windows Server, it is now a feasible and secure platform for providing access to corporate resources from remote computers. In addition to VPN connectivity, we have a couple of more unique technologies baked into Windows Server 2025 that are also designed to provide remote access to corporate resources in a different way than traditional VPN. The topics that we will cover in this chapter are the following:

Regular ol’ VPN

Always On VPN

DirectAccess

Remote Access Management Console

DA, VPN, or AOVPN? Which is best?

Web Application Proxy

Regular ol’ VPN

A traditional VPN involves users clicking on a VPN connection that is configured on their local device, and that device then creates a secure virtual private networking connection to another device sitting in your datacenter, most often a firewall.However, if your firewall doesn’t provide VPN endpoint capabilities, or if you simply want to protect your VPN traffic in a different way, you can utilize a Windows Server to be the VPN termination device.We already mentioned the Remote Access role, and indeed this is a Windows Server role that is ready to be selected and installed on a fresh Windows Server instance. However, before making that leap, you want to formulate a plan for networking with this server. A VPN server can utilize a single NIC that is inside your corporate network, and in this case, you would need to configure your firewall to Network Address Translation (NAT) traffic from a public IP address into that internal NIC’s private IP address. This is necessary because your VPN clients are going to be creating connections from the internet to this VPN server. For that traffic stream to be successful, the client’s traffic must land on the server.Another option is to provide dual NICs on this server. One can be your internal NIC, connected to the internal network. The second NIC can be your external or DMZ NIC, and connected accordingly. This NIC could have its own public IP address and hang right on the internet, or it could be connected inside a DMZ with some protections around it, and traffic passed through to it there. The reasons you might go dual-NIC are security-related so that this Windows Server and its traffic sit behind some layers of firewall protection. If you choose to employ dual NICs, you may want to reference back to our conversation about proper Windows routing table configuration, as you will be in a position to define a default gateway on your external NIC but not the internal, and will then be required to define static routes to navigate VPN traffic around your internal network.

Routing and Remote Access Service (RRAS)

Once networking has been established on your VPN server, it is time to install the Remote Access role. All the different connectivity components that we will discuss in this chapter are contained within this same Remote Access role, so you will find that, upon installing the role, you are asked for some further specifics about what role components you are trying to enable. For the purposes of VPN connectivity, as well as DirectAccess, which we will discuss shortly, simply check the top box and proceed.

Figure 9.1: Installing the Remote Access role for VPN

After role installation is complete, you will find a couple of new tools available inside Server Manager. We will talk more about the Remote Access Management Console near the end of this chapter as that toolset interacts with both VPN and DirectAccess, but when working on traditional VPN connectivity, we want to utilize the console called Routing and Remote Access.

Configuring VPN inside RRAS

Nothing is really happening inside RRAS by default; you can see the name of your server listed with a red arrow next to it, indicating that it is not active. To initiate a configuration wizard that will take us through VPN configuration, simply right-click on the name of your server and select Configure and Enable Routing and Remote Access. The first option we encounter is important. There are a few different uses for RRAS, including the routing of both incoming traffic (VPN) and outgoing traffic (proxy/ NAT). RRAS can also be used as a site-to-site connectivity platform! For our purposes today, the top option will suffice. We are going to configure Remote access (dial-up or VPN).

Figure 9.2: RRAS usage options

The screen is self-explanatory, and kind of funny. Are we setting up a VPN or a dial-up connection? I haven’t encountered anybody using dial-up internet in many, many years. This indicates just how long it has been since Microsoft put any work into updating the RRAS interface and wizards.I suppose “if it ain’t broke, don’t fix it” applies here, because even though this interface looks like it came straight out of Server 2003, an RRAS VPN is still a stable and secure connection method, if configured properly.At this point, you will realize that if you only have one NIC installed in your VPN server, you receive a message about RRAS expecting there to be two. It is possible to configure VPN or DirectAccess with a single NIC, but it is not Microsoft’s default or recommended method. A proper Microsoft remote access server has dual NICs, separating the traffic coming in from the internet and the traffic that moves onward toward your internal network. That is, after all, the purpose of this role: Routing and Remote Access. Assuming you have two NICs on this server, one connected internally and one externally, the next screen will ask you to select the NIC that is facing toward the internet.

Figure 9.3: Defining internal and external NICs

The assignment of IP addresses to remote VPN client computers is our next configuration step, and the default option is to utilize DHCP for this purpose. You almost never want to use your normal DHCP server to provide IP addresses to VPN clients, because your network is then going to think that those remote computers are within your internal network, and routing packets back to those clients becomes problematic. Instead, it is recommended to choose the option to define your own range of IP addresses to assign to VPN client computers, and that this range of IP addresses be from a new subnet that you do not have in use at all inside your network currently. In my case, my internal network is 10.10.10.0/24, and I am going to define 172.16.1.0/24 as my VPN IP addressing subnet.

Figure 9.4: Best practice is to define a new subnet for VPN client IP addresses

Now we define authentication for VPN connections. If you employ another Windows Server running the Network Policy Server (NPS) role, you can point RRAS at NPS to get very nitty-gritty with the authentication of remote computers. This is definitely a good thing, and it will enable you to only allow users who are part of a certain group to be able to connect to a VPN, or only during certain times. You can even use NPS to further enhance VPN connections by requiring MFA when NPS is tied in with an MFA provider. But in our test lab today, I do not have an NPS (RADIUS) server, and so I will proceed with the default option to allow RRAS to directly manage authentication for VPN connection requests.RRAS VPN is now configured on your server!

Securing your VPN

Wait a minute, let’s wrap back to the fact that this RRAS management console appears to be lacking any updates over the past 20 years. While that is not technically true, there are many items in here that have not been updated with the changing times. Primarily what I’m referring to are the different protocols that RRAS is listening on, which could be used to establish a VPN connection between the client and server. It is important to understand what these protocols are so that you can decide which connectivity options you intend to offer to client computers as they make connections. Prior to Windows Server 2025, all four of these protocols were enabled by default, but they are not all good ideas. I’ll list them here in order of “strongest and more secure” all the way down to “don’t touch this one!”

IKEv2

The newest, strongest, and all-in-all best way to connect your client computers via VPN or AOVPN, IKEv2 is the only way to connect the AOVPN device tunnel, which we will hear about in the next section of this chapter. IKEv2 requires machine certificates to be issued to your client computers in order to authenticate. This generally means that if you want clients to connect via IKEv2, those clients will be domain-joined. It is very important to note that IKEv2 uses UDP ports 500 and 4500 to make its connection, which is sometimes a hindrance and blocked by firewalls.

SSTP

SSTP VPN uses an SSL stream to connect. Because of this, it requires an SSL certificate to be installed on the Remote Access server but does not require machine certificates on the client computers. SSTP uses TCP port 443, so it is able to connect even from inside very restrictive networks where IKEv2 may fail (because of IKEv2’s reliance on UDP). I have to say that SSTP is my favorite flavor of Windows RRAS-based VPN connectivity protocol, but it only works from Windows clients. If you have the requirement to connect other devices such as Macs, iPhones, Android, etc., you’ll want to jump below to L2TP.To enable SSTP VPN to be successful on your RRAS server, simply decide on a DNS name to point at your RRAS public IP address, and then acquire a standard SSL certificate for that name. For example, I might choose vpn.contoso.com and get an SSL certificate for the same name. Install that SSL certificate onto your VPN server, and then inside the RRAS console:

Right-click on the name of your server, and head into Properties.

Visit the Security tab.

Down near the bottom is a section called SSL Certificate Binding. Once your SSL certificate is installed on the server, simply use the drop-down menu here to select your certificate. This enables an SSTP VPN to work properly when clients connect and request SSTP.

Figure 9.5: Selecting an SSL certificate to be used by SSTP VPN

L2TP

We have already discussed the two best VPN connectivity options, best from a security perspective anyway. Now we turn to the other two, which are no longer enabled by default in Windows Server 2025, but of which at least this one still serves a valid purpose.Layer 2 Tunneling Protocol (L2TP) is able to establish VPN connections by using certificates or a pre-shared key (PSK). If you are only connecting Windows clients to your VPN, stay away from this one and focus on SSTP. If you have a requirement to connect non-Windows devices to your VPN, utilizing L2TP to establish VPN connections through the use of a PSK is generally the approach that is taken. In my experience, it is quite rare to find a Windows Server hosting L2TP VPN, but it may be a common thing for you to interact with the L2TP protocol on client computers when connecting to other flavors of VPN. For example, if your firewall provides VPN connectivity for workstations, it is fairly common for those firewalls to utilize L2TP to build the initial tunnel. In these scenarios, L2TP itself does not encrypt data, but rather it will be combined with another tunnel (such as IPsec) to secure your traffic.

PPTP

While still a valid configuration option inside RRAS, stay away from this guy! PPTP is no longer a secure method of tunneling, and if you are still running VPN connections based on PPTP, you need to treat those traffic streams as if they were unencrypted and clear-text over the internet. Replace this with something better as soon as possible. Once again, in a brand new Windows Server 2025 instance, PPTP will be disabled.How can you find out if your existing RRAS VPN server is enabled for PPTP? Or perhaps you just finished creating a brand new RRAS VPN in Windows Server 2025, and simply want to verify that this really is disabled by default, where is your confirmation? Let’s open RRAS and take a peek…

Inside RRAS, right-click on Ports and select Properties.

Select WAN Miniport (PPTP).

Click Configure….

Verify that both boxes are unchecked (or go ahead and uncheck them now). The absence of these checkboxes is your confirmation that this server is not listening for VPN connections using PPTP.

Figure 9.6: PPTP is disabled

Throughout these descriptions, I kept specifically mentioning whether these protocols were enabled by default or not. I did this because our behavior has changed as of the Windows Server 2025 release. Prior to our latest operating system, configuring RRAS-based VPN on any Windows Server would net you a VPN server listening for all four, even though they are not all secure. Installing a brand-new Server 2025 RRAS instance will now only provide you with IKEv2 and SSTP out of the box, but the others can be re-enabled if needed. Since a lot of us are currently in the middle of projects to in-place upgrade older versions of Windows Server to the 2025 flavor, it is also important to understand that an RRAS VPN server configured to allow L2TP or PPTP prior to the upgrade, will still be offering those connectivity protocols following the upgrade. The server upgrade process will specifically retain those configurations so as not to break existing VPN client connections, and you need to decide whether they are really still in your best interests.

Configuring VPN on the client

Once the server side of VPN connectivity is established, how do computers create connections to this VPN? It is quite simple to configure a Windows client for VPN connectivity, you generally only need to know the name or IP address where your VPN server is running. Let’s walk through the VPN configuration process on a Windows 11 computer, to see the experience.Click on your Start button, and type “VPN”. The top option is probably VPN settings, which is exactly where we want to go. Once inside, click the button to Add VPN, and you’re already half finished. Name this connection whatever you like, and input the public DNS name that is steering toward your VPN server. Remember earlier when I gave the example of vpn.contoso.com? Something like that. If you have not established a DNS name to resolve these connections, you can alternatively input the public IP address that lands on your VPN server, but doing so would imply that you cannot use SSTP VPN. The most advanced thing you will have to decide on this screen is what type of VPN connection you are creating, and by default your Windows client computer will select Automatic here. If you know that your VPN server is only listening on SSTP (as an example), your VPN will connect slightly faster if you specify SSTP in this drop-down list. If you are unsure of the protocols that are available on your VPN server, or if you intentionally have multiple enabled, then leave it set to Automatic and the client computer will cycle through the options in order of best to worst, to figure out what works.The only alteration to this screen comes if you select L2TP/IPsec with pre-shared key. As with any technology that utilizes PSKs, obviously you need to type in the Pre-shared key here, which must match the PSK established on your VPN server, and so a new field is displayed for you to enter that information. Otherwise, there isn’t much to configure here on the screen to add a new VPN connection, however both IKEv2 and L2TP/certificate require a special certificate to be installed on every computer before the VPN connection will work. While this VPN screen will certainly allow you to establish a VPN connection profile that includes these protocols, pursuing a successfully connected VPN using either IKEv2 or L2TP/certificate means you would need to do a little additional reading on requirements surrounding those specific protocols. Here is our completed Add VPN screen.

Figure 9.7: Configuring VPN on a client computer

After completing the setup of a VPN connection, engaging this connection is as simple as clicking on it from inside VPN settings, or from the wireless connectivity option in the systray. Rather than manually create VPN connections across hundreds or thousands of computers, you could certainly employ Group Policy or InTune to automatically create these connections for you!

Always On VPN

Providing users with access to VPN connectivity traditionally means providing them with a special network connection link (such as the one we just created) that they can launch and enter credentials to pass authentication to connect to their work environment’s network and then communicate with company resources. After launching a VPN, users can open their email, find documents, launch their line-of-business applications, or otherwise work in the same ways that they can when physically sitting in their office. Also, when connected via a VPN, management of their laptop is possible, enabling successful communication flow for systems such as Group Policy and Microsoft Configuration Manager (previously SCCM). VPN connections offer great connectivity back to your network, but (remember, we are talking about traditional, regular VPN connections here) they only work when the user manually launches them and tells them to work. Anytime a user has not connected to their VPN, they are navigating the internet with no connectivity back to the company datacenter. This also means that a traditional VPN connection has no form of connectivity on the Windows login screen because, until they get logged in to the computer and find their way to the Windows desktop, users have no way of launching that VPN tunnel. This means that anything that might attempt to happen on the login screen, such as live authentication lookups, or during the login process, such as Group Policy processing or logon scripts, will not function via a traditional, manual VPN.AOVPN, as you have probably guessed based on the name, is simply the idea of making a VPN connection continuous and automatically connected. In other words, any time that the user has their laptop outside the office walls and is connected to the internet, a VPN tunnel back to the corporate network is automatically established, ideally with zero user input to the process. This enables users to forget about the VPN altogether, as it is simply always connected and ready for them to use. They can log in to their machines, launch their applications, and start working. It also means that IT management functions such as security policies, updates, and installer packages can push out to client machines a greater percentage of the time, since we no longer wait for the user to decide when they want to connect back to work; it happens automatically and pretty much all the time.There are three different ways in which AOVPN can be triggered on the client machine, and none of them involve the user having to launch a VPN connection:

AOVPN can be configured to truly be always-on, meaning that as soon as internet access is available, it will always attempt to connect.

Another option is application triggering, which means that you can configure AOVPN to launch itself only when specific applications are opened on the workstation.

The third option is DNS name-based triggering. This calls the VPN connection into action when particular DNS names are called for, which generally happens when users launch specific applications or URLs.

Since you don’t need Always On VPN to be connected and working when your laptop is sitting inside the corporate network, we should also discuss the fact that AOVPN is smart enough to turn itself off when the user walks through those glass doors. AOVPN-enabled computers will automatically decide when they are inside the network, therefore disabling VPN components, and when they are outside the network and need to launch the VPN tunnel connection.This detection process is known as Trusted Network Detection. When configured properly, Always On VPN components know what your company’s internal DNS suffix is, and they monitor your NIC and firewall profile settings to establish whether that same suffix has been assigned to those components. When it sees a match, it knows you are inside the network and then disables AOVPN.

Types of AOVPN tunnels

Before we get started on the particulars of client and server components required to make AOVPN happen, there is an important core topic that needs to be understood to make appropriate decisions about how you want to utilize AOVPN in your company. There are two very different kinds of VPN tunnels that can be used with Always On VPN: a user tunnel and a device tunnel. As you will learn later in this chapter, the ability to have two different kinds of tunnels is something included with AOVPN to bring it closer to feature parity with DirectAccess, which also has this dual-tunnel mentality. Let’s take a minute and explore the purposes behind the two tunnels.

User tunnels

The most common way of using AOVPN in the wild involves a user tunnel being authenticated at the user level. User certificates are issued from an internal PKI to your computers, and these certificates are then used as part of the authentication process during connection. User tunnels carry all of the machine and user traffic, but it is very important to note that user tunnels cannot be established while the computer is sitting on the login screen because user authentication has not happened at that point. So, a user tunnel will only launch itself once a user has successfully logged in to the computer. With only a user tunnel at play, the computer will not have connectivity back to the corporate network for management functions until someone has logged in to the computer, and this also means that you will rely on cached credentials in order to pass through the login prompt.

Device tunnels

A device tunnel is intended to fill the gaps left by only running a user tunnel. A device tunnel is authenticated via a machine certificate, also issued from your internal PKI. This means that the device tunnel can establish itself even prior to user authentication. In other words, it works even while sitting on the Windows login screen. This enables management tools such as Group Policy and Microsoft Config Manager to work regardless of user input, and it also enables real-time authentication against domain controllers, enabling users to log into a workstation they have never logged into before, even when that computer is outside the office. This also enables real-time password expiry resets from any location.

Device tunnel requirements

A user tunnel can work with pretty much any Windows 10/11 machine, but there are some firm requirements to be able to make use of a device tunnel. To roll out a device tunnel, you need to meet the following criteria:

The client must be domain-joined.

The client must be issued a machine certificate.

The client must be running Windows 10 1709 or newer.

The client must be running Windows 10/11 Enterprise or Education SKUs. (note that Pro is not included in this list)

A device tunnel can only be IKEv2. This is important to understand because, as you already know, IKEv2 utilizes UDP to make its connection. This means that computers that are sitting behind port-restricting firewalls may be unable to establish that device tunnel connection.

AOVPN client requirements

It is important to understand that the Always On part of Always On VPN is client-side functionality. You can utilize AOVPN on a client computer to connect to many kinds of VPN infrastructure on the backend. We will talk about that shortly, in the AOVPN server components section.While creating regular, manual VPN connections has been possible on Windows client operating systems for 20+ years, Always On VPN is a bit younger. Your workforce will need to be running Windows 10 or 11 to make this happen. Specifically, they will need to be running at minimum Windows 10 version 1607.The following are the supported SKUs:

Windows 10 1607+

Windows 10 1709+

Windows 10 1803+

Windows 11

Wait a minute—that doesn’t make any sense. Why list those three Win10 versions separately if they are inclusive of one another? While Always On VPN was technically introduced in Windows 10 1607, it has had some improvements along the way. Let’s list those again, with a brief summary of what has changed over the years:

Windows 10 1607: The original capability to auto-launch a VPN connection, thus enabling Always On VPN.

Windows 10 1709: Updates and changes included the addition of device tunnels. If you intend to run a device tunnel for computer management purposes (and most enterprises will), then consider 1709 to be your minimum OS requirement.

Windows 10 1803: Includes some major fixes that were discovered in 1709. In reality, what this means is that I never see anyone implementing Always On VPN unless they are running 1803. Thankfully, the Windows 10 update platform is much improved, meaning that many more companies are rolling out newer versions of Win10 on an ongoing basis, and 1803 is now mostly in the dust, having long ago been replaced by even newer versions.

Whether you are running 1607, 1709, 1803, 1809, or whatever the latest and greatest version is, the particular SKU within those platforms does not matter. Well, it hardly matters. Always On VPN works with Windows 10/11 Home, Pro, Enterprise, and all of the other flavors. That is, the user tunnel works with all of those.It is important enough to point out once again: if you want to utilize a device tunnel with Always On VPN, using domain-joined Windows 10/11 Enterprise or Education SKUs is a firm requirement.

Domain-joined

As we have already established, when you’re interested in using the AOVPN device tunnel, your client computers must be domain-joined. However, if you are okay with only running the user tunnel for AOVPN access, then there are no domain-membership requirements. Clients still need to be running Windows 10 1607 or newer, but they could be any SKU and could even be home computers that are joined to simple workgroups; no domain is required.This is emphasized specifically in Microsoft documentation in many places because it enables Always On VPN to be utilized (somewhat) by the Bring Your Own Device (BYOD) crowd. While this is interesting, I don’t foresee it being at all common that companies would allow employees’ personal computers to be connected to their VPN. Most organizations are trying to cater in a small way to the BYOD market by providing access to some resources via the cloud, such as Office 365 for email and documents. But connecting those personal computers and devices back to your network with a full-scale layer 3 VPN tunnel? I don’t think so. That is security administrator nightmare fuel.

Rolling out the settings

Let’s say you have all of the server-side parts and pieces ready to roll for VPN connectivity, and indeed, you have successfully established the fact that you can create ad hoc traditional VPN connections to your infrastructure with no problems. Great! Looks like you are ready from the infrastructural side. Now, what is necessary to get clients to start doing Always On connections?Configuration of Always On VPN policy settings isn’t terribly difficult, but they need to be converted into a configuration file or script to run against other computers. A generalized method is that you can build a manual-launch VPN connection, tweak it with some specific security and authentication settings, and then run a utility that exports that configuration out to some configuration files. These VPN profile settings come in XML and PS1 (PowerShell script) flavors, and you may need one or both files in order to roll the settings around to your workforce. The following document from Microsoft outlines this in greater detail, with specific steps to follow: https://learn.microsoft.com/en-us/windows-server/remote/remote-access/tutorial-aovpn-deploy-configure-client.Once you have created your configuration files, you then face the task of pushing that configuration out to the clients. You ideally need to have a mobile device management (MDM) solution of some kind to roll the settings out to your workforce. While many technologies in the wild could be considered MDMs, the two that Microsoft is focused on are Microsoft Configuration Manager and Microsoft Intune.If you have MCM on-premises, great! You can easily configure and roll out PowerShell-based configuration settings to your client computers and enable them for Always On VPN.Perhaps you don’t have MCM, but you are cloud-focused, and you have all your computers tapped into Intune. Wonderful! You could alternatively use Intune to roll out those AOVPN settings via XML configuration. One of the benefits of taking the Intune route is that Intune can manage non-domain-joined computers, so you could theoretically include users’ home and personal computers in your Intune-managed infrastructure and set them up to connect.Microsoft Config Manager and Intune are great, but not everybody is running them. There is a third option for rolling out Always On VPN settings via PowerShell scripting. While this is plan B from Microsoft (they would really prefer you to roll out AOVPN via an MDM solution), I’m afraid that PowerShell will be the reality for many SMB customers who want to utilize AOVPN. The biggest downside to using PowerShell to put AOVPN settings in place is that PowerShell needs to be run in elevated mode, meaning that it’s difficult to automate because the logged-on user (for whom you need to establish the VPN connection) needs to be a local administrator for the script to run properly.I am hopefully and anxiously waiting for the day that they announce a traditional Group Policy template for rolling out Always On VPN settings, but so far, there is no word on whether or not that will ever be an option. Everyone has Group Policy; not everyone has MDM. You will read in a few moments that the rollout of Microsoft DirectAccess connectivity settings (an alternative to AOVPN) is done via Group Policy, which is incredibly easy to understand and manage. As far as I’m concerned, at the time of writing, DirectAccess holds a major advantage over AOVPN in the way that it handles the client-side rollout of settings. But, make sure you check out Microsoft Docs online to find the latest information on this topic, as AOVPN is being continuously improved and there will likely be some changes coming to this area of the technology.

AOVPN server components

Now that we understand what is needed on the client side to make Always On VPN work, what parts and pieces are necessary on the server/infrastructure side in order to allow these connections to happen? Interestingly, the Always On component of AOVPN has nothing to do with server infrastructure; the Always On part is handled completely on the client side. Therefore, all we need to do on the server side is make sure that we can receive incoming VPN connections. If you currently have a workforce that is making successful VPN connections, then there is a good chance that you already have the server infrastructure necessary for bringing AOVPN into your environment.

Remote Access server

Obviously, you need a VPN server to host VPN connections, right? Well, not so obviously. As we have already discussed, the Windows Server role that hosts VPN, AOVPN, and DirectAccess connections is called the Remote Access role, but you can actually get Always On VPN working without Windows Server as your Remote Access server. Since the Always On part is client-side functionality, this enables VPN server-side infrastructures to be hosted by third-party vendors and firewalls. Even though that is technically accurate, it’s not really what Microsoft expects, nor is it what I find in the field. In reality, those interested in using Microsoft Always On VPN often use Microsoft Windows Server to host the Remote Access role, which will be the inbound system that our remote clients connect to.A lot of people automatically assume that AOVPN is married to Windows Server 2022 or 2025 because it is a fairly new technology, but that is actually not the case at all. You can host your VPN infrastructure (the Remote Access role) on Server 2025, Server 2022, Server 2019, Server 2016, or even Server 2012 R2. It works the same on the backend, giving clients a place to tap into with their VPN connections.The setup of your Remote Access server to handle AOVPN connections is really the same process that we already took in the last section of this chapter, configuring RRAS VPN for manual client VPN connections. These same VPN protocols are the ones that your AOVPN clients will be tapping into. The two VPN protocols most utilized by AOVPN are going to be IKEv2 and SSTP. IKEv2 is required for a successful device tunnel, but if you don’t need device tunnels and are focused on more flexible user tunnels for AOVPN, then you can get away with running SSTP as a fallback tunneling method, which connects successfully from almost any internet connection.

Certification Authority (CA)

Machine certificates, user certificates, SSL certificates... Oh, my! Clearly, you need to be familiar working with and deploying certificates to make use of Always On VPN. This is becoming more and more common with newer, well-secured technologies of any flavor. The major requirement here is that you will need to have PKI inside your environment and at least one Windows CA server to issue the necessary certificates. The following is a list of the places in which certificates could be used by an AOVPN infrastructure:

User certificates: These are the certificates issued to your VPN users from an internal CA, used for authentication of the user tunnel

Machine certificates: These are certificates issued to your workstations (mostly laptops) from an internal CA, used for authentication of the device tunnel

SSL certificates: These are installed on your Remote Access server to validate the incoming traffic for SSTP VPN connections

VPN and NPS machine certificates: Your Remote Access server, as well as your NPS servers, which we will talk about in just a minute, require machine certificates issued from your internal CA

Network Policy Server (NPS)

NPS is basically the authentication decision maker for VPN connections. When a VPN connection request comes in, the Remote Access server hands that authentication request over to an NPS server to validate who that user is, and also to verify that the user has permissions to log in via the VPN.Most commonly when working with Microsoft VPN connections, we configure NPS so that it allows only users who are part of a certain Active Directory Security Group. For example, if you create a group called VPN Users and then point NPS to that group, it will only allow users whom you have placed inside that group to make successful VPN connections.NPS is another Windows Server role that can be hosted on its own system or spread across multiple servers for redundancy. As with the Remote Access role, there is no Server 2025 requirement for NPS. You could easily deploy it on previous versions of Windows Server just as well.Keep in mind that you should not install NPS onto the same server where you are running Remote Access. You need to spin up a second server for the purposes of NPS.

DirectAccess

Throughout our discussion about Always On VPN, I mentioned Microsoft DirectAccess a couple of times. DA is another form of automatic VPN-like connectivity, but it takes a different approach compared to Always On VPN. Where AOVPN simply uses expected, well-known VPN protocols and does some crafty magic to automatically launch those otherwise traditional VPN tunnels, DirectAccess tunnels are quite proprietary. Tunnels are protected by IPsec and are essentially impenetrable, and unable to be impersonated. I find that security teams love the protection and complexity surrounding DirectAccess tunnels because they are a connection platform that attackers have no idea how to tamper with or how to replicate.My personal experience in the Microsoft remote access space is that the number of DirectAccess customers outweighs the number of AOVPN customers as of right now. Indeed, I would say that DA is the most common reason that administrators deploy the Remote Access role on a Windows Server instance. As stated, the easiest way to think about DA is to think of it as an automatic VPN. Similar to a VPN, its purpose is to connect users’ computers to a corporate network when they are outside the office. Different from a VPN, however, is the method that employees use to make this connection possible. DirectAccess is not a piece of software; it is a series of components that are already baked into the Windows operating system, working in tandem to provide completely seamless access to the user. What do I mean by seamless? In the same way that AOVPN connects without user interaction, there is nothing the user needs to do to make DirectAccess connect. It does that all by itself. As soon as a mobile computer receives an internet connection, whether that connection is home Wi-Fi, public internet at a coffee shop, or a cell phone hotspot connection, DirectAccess tunnels automatically build themselves using whatever internet connection is available, without any user input.There is a bit of “fortunately/unfortunately” mixed in with recent news on DirectAccess. Fortunately, DA is alive and well in Windows Server 2025. Unfortunately, in June of 2024 Microsoft added DirectAccess to the official list of deprecated Windows Server features. Deprecated does not equal dead, but it does mean that Microsoft has no plans to improve DirectAccess in the future, or add new features to it. It is possible that when Windows Server 2028 (?) is released, DirectAccess could be missing. Or…maybe not. Time will tell. As of this writing, DA continues to be a valid connectivity technology, and an impressive one at that. Given this truth, we are certainly going to discuss the ins-and-outs of DirectAccess so that you have a well-rounded understanding of what Microsoft offers in the remote access space.Whether using Always On VPN or DirectAccess, when your computer connects automatically, it saves you time and money. Time is saved because the user no longer has to launch a VPN connection. Money is saved because time equals money, but also because having an always-on connection means that patching, security policies, and the management of those remote computers always happen, even when the user is working remotely. You no longer have to wait for users to get back into the office or for them to choose to launch their manual VPN connection in order to push new settings and policies down to their computers; it all happens wherever they are, as long as they have internet access. Clearly, with the advent of two different remote access technologies that are both focused on automatic connectivity for remote users, Microsoft is clearing the way for a more productive workforce. The terms user-friendly and VPN have never gone hand-in-hand before, but in the latest versions of the Windows operating systems, that is exactly the goal.DirectAccess has actually been around since the release of Windows Server 2008 R2, and yet I regularly bump into IT people who have never heard of it. In the early days, it was quite difficult to deploy and came with a lot of awkward requirements, but much has changed since inception and DirectAccess is now easier than ever to deploy, and more beneficial than ever to have running in your environment.

The truth about DirectAccess and IPv6

One of the awkward requirements I mentioned used to be the need for IPv6 inside your network. With the first version of DirectAccess, this was an unfortunate requirement. I say unfortunate because, even today, almost nobody runs IPv6 inside their corporate networks, let alone years ago when this technology was released—a lot of admins didn’t even understand what IPv6 was. Fortunately, the requirement for IPv6 inside your networks is no more. I repeat, just in case anybody wasn’t paying attention or is reading old, outdated TechNet documents—you do not need IPv6 to use DirectAccess! I have seen too many cases where DA was considered by a company, but the project was tossed aside because reading something on TechNet made them believe that IPv6 was a requirement, and they discarded DA as something that wouldn’t work. You absolutely do not have to be running IPv6 in your network to make DA function, but it is important to understand how DA uses IPv6 because you will start to encounter traces of it once your deployment gets underway.When I am sitting at home, working on my company laptop, DA connects me to the corporate network. My internal network at work has absolutely no IPv6 running inside of it; we are a completely IPv4 network. This is true for most companies today. However, when I open Command Prompt and ping one of my servers from my DA laptop, this is what I see—apologies for the sanitized output of the screenshot:

Figure 9.8: Pinging an internal server from a DirectAccess laptop

What in the world is that? Looks like IPv6 to me. This is where IPv6 comes into play with DA. All of the traffic that moves over the internet part of the connection, between my laptop and the DA server that is sitting in my datacenter, is IPv6 traffic. My internal network is IPv4, and my DA server only has IPv4 addresses on it, yet my DA tunnel is carrying my traffic using IPv6. This is the core of how DA works and cannot be changed. Your DA laptop sends IPsec-encrypted IPv6 packets over the internet to the DA server, and when the DA server receives those packets, it has the capability to spin them down into IPv4 in order to send them to the destination server inside the corporate network. For example, when I open Outlook and it tries to connect to my Exchange server, my Outlook packets flow over the DA tunnel as IPv6. Once these packets hit my DA server, that DA server reaches out to internal DNS to figure out whether my Exchange server is IPv4 or IPv6.If you are actually running IPv6 inside the network and the Exchange server is available via IPv6, the DA server will simply send the IPv6 packets along to the Exchange server. Connection complete! If, on the other hand, you are running IPv4 inside your network, the DA server will only see a single A host record in DNS, meaning that the Exchange server is IPv4-only. The DA server will then manipulate the IPv6 packet, changing it down into IPv4, and then send it on its way to the Exchange server. The two technologies that handle this manipulation of packets are DNS64 and NAT64, which you have probably seen in some of the documentation if you have read anything about DA online.The purposes of these technologies are to change the incoming IPv6 packet stream into IPv4 for networks where it is required, which is pretty much every network at the moment, and spin the return traffic from IPv4 back up into IPv6 so that it can make its way back to the DA client computer over the IPv6-based IPsec tunnel that is connecting the DA client to the DA server over the internet.It is important to understand that DA uses IPv6 in this capacity because any security policies that you might have in place that squash IPv6 on the client computers by default will stop DA from working properly in your environment. You will have to reverse these policies to allow the clients to push out IPv6 packets and get their traffic across the internet. However, it is also very important to understand that you do not need any semblance of IPv6 running inside the corporate network to make this work, as the DA server can spin all of the traffic down into IPv4 before it hits that internal network, and most DA implementations that are active today run in exactly this fashion.

Prerequisites for DirectAccess

DA has a lot of moving parts, and there are many different ways in which you can set it up. However, not all of these ways are good ideas. So, in this section, we are going to discuss some of the big decisions that you will have to make when designing your own DA environment.

Domain-joined

The first big requirement is that the systems involved with DA need to be domain-joined. Your DA server, or servers, all need to be joined to your domain, and all of the client computers that you want to be DA-connected need to be joined to a domain as well. Domain membership is required for authentication purposes, and also because the DA client settings that need to be applied to mobile computers come down to these computers via Group Policy. You can see here one reason why Microsoft is setting future sights more so on Always on VPN than DirectAccess, flexibility in client computers. AOVPN can work on non-domain-joined computers, yet if you want to utilize AOVPN device tunnels (and you would want to), then the domain-join requirement remains.I always like to point out this requirement early in the planning process, because it means that users who purchase their own laptops at a retail location are typically not going to be able to utilize DA—unless you are somehow okay with adding home computers to your domain—and so DA is really a technology that is designed for managing and connecting corporate assets that you can join to the domain. It is also important to understand this requirement from a security perspective since your DA server or servers will typically be facing the edge of your network. It is common for the external NIC on a DA server to sit inside a DMZ, but they also have to be domain-joined, which may not be something you are used to doing with systems in a perimeter network.

Supported client operating systems

Not all Windows client operating systems contain the components that are necessary to make a DA connection work. Enterprise does, which covers the majority of larger businesses that own Microsoft operating systems, but that certainly does not include everyone. I still see many small businesses using professional or even home SKUs on their client machines, and these versions do not include DA components. The following is a list of the operating systems that do support DA. During your planning, you will need to make sure that your mobile computers are running one of these:

Windows 11 Enterprise

Windows 10 Enterprise

Windows 10 Education

Windows 8.0 or 8.1 Enterprise

Windows 7 Enterprise

Windows 7 Ultimate

(I left these old operating systems listed for accuracy, but please don’t allow your business to run computers this old!)

DirectAccess servers – one or two NICs?

One big question that needs to be answered even prior to installing the Remote Access role on your new server is, how many NICs are needed on this server? There are two supported methods for implementing DA.

Single NIC mode

Your DA server can be installed with only a single NIC. In this case, you would typically plug that network connection directly into your internal network so that it had access to all of the internal resources that the client computers are going to need to contact during the user’s DA sessions. In order to get traffic from the internet to your DA server, you would need to establish a NAT from a public IP address into whatever internal IP address you have assigned to the DA server.Many network security administrators do not like this method because it means creating a NAT that brings traffic straight into the corporate network without flowing through any kind of DMZ.

Dual NICs

Here, we have two network cards in the DA server. The internal NIC typically gets plugged right into the corporate network, and the external NIC’s physical placement can vary depending on the organization. We will discuss the pros and cons of where to place the external NIC immediately after this section of the chapter. Edge mode with two NICs is the way that DA works best. As you may recall from earlier in the book, implementing a Windows Server instance with multiple NICs means that you will be multihoming this server, and you will need to set up network settings accordingly. With a Remote Access server, your external NIC is always the one that receives the default gateway settings, so you need to make sure you follow this rule and do not configure a default gateway on the internal NIC. On the other hand, you do want to configure DNS server addresses into the internal NIC properties, but you do not want to configure DNS servers for the external NIC. Since this server is multihomed, you will likely need to create some route statements to add your corporate subnets into the Windows routing table of this server before it can successfully send and receive traffic.The only networks that would not need to accommodate adding static routes would be small networks, where all of your internal devices are on a single subnet. If this is the case, then you do not need to input static routes. But most corporate networks span multiple subnets, and in this case, you should refer back to Chapter 8, Networking with Windows Server 2025, where we discussed multihoming and how to build out those route statements.

More than two NICs

Nope, don’t go there. If you are familiar with configuring routers or firewalls, you know that you have the potential to install many different NICs on a server and plug them all into different subnets. While there are many reasons why splitting up network access like this on a Remote Access server might be beneficial, it won’t work how you want it to. The DA configuration itself is only capable of managing two different network interfaces.As you can see in Figure 9.9, in the course of the setup wizards, you will have to define one NIC as External, and the other as Internal. Any more NICs that exist in that server will not be used by DA, unfortunately.

Figure 9.9: Defining NICs during DirectAccess configuration

To NAT or not to NAT?

Now that you have decided to roll with two NICs in your DA server, where do we plug in the external NIC? There are two common places that this external network interface can be connected to, but depending on which you choose, the outcome of your DA environment can be vastly different. Before we talk about the actual placement of the NIC, I would like to define a couple of protocols that are important to understand, because they pertain very much to answering this question about NIC placement. When your DA laptop makes a connection to the DA server, it will do so using one of the three IPv6 transition tunneling protocols. These protocols are 6to4, Teredo, and IP-HTTPS. When the DA client connects its DA tunnels, it will automatically choose which of these protocols is best to use, depending on the user’s current internet connection.All three protocols perform the same function for a DA connection: their job is to take the IPv6 packet stream coming out of the laptop and encapsulate it inside IPv4 so that the traffic can make its way successfully across the IPv4 internet. When the packets get to the DA server, they are decapped so that the DA server can process these IPv6 packets.

6to4

DA clients will only attempt to connect using 6to4 when a remote laptop has a truly public internet IP address. This hardly ever happens these days, with the shortage of available internet IPv4 addresses, and so 6to4 is typically not used by any DA client computers. In fact, it can present its own set of challenges when users are connecting with cell phone cards in their laptops, and so it is common practice to disable the 6to4 adapter on client computers as a DA best-practice setting.

Teredo

When DA clients are connected to the internet using a private IP address, such as behind a home router or a public Wi-Fi router, they will attempt to connect using the Teredo protocol. Teredo uses a UDP stream to encapsulate DA packets, and so, as long as the user’s internet connection allows outbound UDP 3544, Teredo will generally connect and is the transition protocol of choice for that DA connection.

IP-HTTPS

If Teredo fails to connect, such as in the case where a user is sitting in a network that blocks outbound UDP, then the DA connection will fall back to using IP-HTTPS, pronounced IP over HTTPS. This protocol encapsulates the IPv6 packets inside IPv4 headers, but then wraps them up inside an HTTP header and encrypts them with TLS/SSL, before sending the packet out over the internet. This effectively makes the DA connection an SSL stream, just like when you browse an HTTPS website.

Installing on the true edge – on the internet

When you plug your DirectAccess server’s external NIC directly into the internet, you grant yourself the ability to put truly public IP addresses on that NIC. In doing this, you enable all three of the preceding transition tunneling protocols, so that DirectAccess client computers can choose between them for the best form of connectivity. When installing via the true edge method, you would put not only one but two public IP addresses on that external NIC. Make sure that the public IP addresses are consecutive as this is a requirement for Teredo. When your DirectAccess server has two consecutive public IP addresses assigned to the external NIC, it will enable the Teredo protocol to be available for connections.This NIC does not necessarily have to be plugged directly into the internet for this to work. Depending on your firewall capabilities, you might have the option to establish a bridged DMZ where no NATing is taking place. You need to check with your firewall vendor to find out whether or not that is an option for your organization. In this scenario, you are still able to configure truly public IP addresses on the external NIC of the server, but the traffic flows through a firewall first, to better protect and manage that traffic.

Installing behind a NAT

It is much more common for the networking team to want to place the external NIC of your DA server behind a firewall, inside a DMZ. This typically means creating a NAT to bring this traffic into the server. While this is entirely possible and better protects the DirectAccess server itself from the internet, it does come with a big downside. When you install a DirectAccess server behind a NAT, Teredo no longer works. In fact, the DA configuration wizards will recognize when you have a private IP address listed on the external NIC and will not even enable Teredo.When Teredo is not available, all your DirectAccess clients will connect using IP-HTTPS. So why does it even matter if Teredo is unavailable? Because it is a more efficient protocol than IP-HTTPS. When Teredo tunnels packets, it simply encapsulates IPv6 inside IPv4. The DirectAccess traffic stream is already and always IPsec-encrypted, so there is no need for the Teredo tunnel to do any additional encryption. On the other hand, when IP-HTTPS tunnels packets, it takes the already-encrypted IPsec traffic stream and encrypts it a second time using TLS. This means all of the packets that come and go are subject to double encryption, which increases processing and CPU cycles and makes for a slower connection. It also creates additional hardware load on the DirectAccess server, because it is handling twice the amount of encryption processing.This is a particularly apparent problem when you are running Windows 7 on client computers, as double encryption processing will cause a noticeably slower connection for users. DA still works fine, but if you sit a Teredo-connected laptop next to an IP-HTTPS-connected laptop, you will notice the speed difference between the two.Thankfully, in Windows 8 and higher, there have been some countermeasures added to help with this speed discrepancy. These newer client operating systems are now smart enough that they can negotiate the SSL part of the IP-HTTPS tunnel by using the NULL encryption algorithm, meaning that IP-HTTPS doesn’t do a second encryption and IP-HTTPS performance is now essentially on par with Teredo.However, this only works for the newer client operating systems (Win7 will always double-encrypt with IP-HTTPS), and it still doesn’t work in some cases. For example, when you enable your DirectAccess server to also provide VPN connectivity, or if you choose to employ a One-Time Password (OTP) system alongside DA, then the NULL algorithm will be disabled because it is a security risk in these situations, and so even your Windows 8, 10, and 11 computers will perform double encryption when they connect via IP-HTTPS. You can see where it would be beneficial to have Teredo enabled and available so that any computers that can connect via Teredo will do so.To summarize, you can certainly install your DA server’s external NIC behind a NAT, but be aware that all DA client computers will connect using the IP-HTTPS protocol, and it is important to understand the potential side effect of implementing it in this way.

Network Location Server

This major component in a DA infrastructure is something that does not even exist on the DA server itself, or at least it shouldn’t if you are setting things up properly. The Network Location Server (NLS) is simply a website that runs inside the corporate network. This website does not need to be available for access over the internet; in fact, it should not be.The NLS is used as part of the inside/outside detection mechanism on DA client computers, similar to the way that Trusted Network Detection works for Always On VPN. Every time a DA client gets a network connection, it starts looking for the NLS website. If it can see the site, then it knows that you are inside the corporate network, and DA is not required, so it turns itself off. However, if your NLS website cannot be contacted, it means you are outside the corporate network, and DA components will start turning themselves on.This prerequisite is easily met; all you need to do is spin up a VM and install IIS on it to host this new website, or you can even add a new website to an existing web server in your network. There are only two things to watch out for when setting up your NLS website. The first is that it must be an HTTPS site, and so it requires an SSL certificate. We will discuss the certificates used in DA, including this one, in the next section of this chapter. In addition to making sure that this website is accessible via HTTPS, you must also make sure that the DNS name you are using to contact this website is unique. You want to do this because, whatever name you choose for the NLS website, that name will not be resolvable when client computers are outside the corporate network. This is by design because you obviously don’t want your DA clients to be able to successfully contact the NLS website when they are working remotely, as that would then disable their DA connection.The reason I bring up the unique DNS name is that I often see new DA admins utilizing an existing internal website as their NLS website. For example, if you have https://intranet running as a SharePoint site, you could simply use this in the DA config as the NLS server definition. However, once you set it up this way, you will quickly realize that nobody who is working remotely can access the https://intranet website. This is by design, because the DA environment now considers your intranet website to be the NLS server, and you cannot resolve it while you are mobile. The solution to this problem? Make sure that you choose a new DNS name to use for this NLS website. Something like https://nls.contoso.local is appropriate.The most important part about the NLS that I want to stress is that you should absolutely implement this website on a server in your network that is not the DA server itself. When you are running through the DA config wizards, you will see on the screen where we define NLS that it is recommended to deploy it on a remote web server, but it also gives you the option to self-host the NLS website right on the DA server itself. Don’t do it! There are many things that can go wrong when you co-host NLS on the DA server. Running the NLS on your DA server also limits your DA potential in the future, because some of the advanced DA configurations require you to remove the NLS from the DA server anyway, so you might as well do it correctly the first time you set it up. Changing your NLS website after you are running DA in production can be very tricky, and often goes sideways. I have helped numerous companies move their NLS website after realizing that they cannot co-host NLS on the DA server if and when they want to add a second DA server for growth or redundancy. The following is a screenshot of the section in the DA config wizard where you choose the location of NLS. Make sure you stick with the top box!

Figure 9.10: Defining the Network Location Server

Certificates used with DirectAccess

Aside from reading and misunderstanding how DA uses IPv6, here is the next biggest “turn-off” for administrators who are interested in giving DA a try. Once you start to read about how DA works, you will quickly come to realize that certificates are required in a few different places. While VPNs generally also require the use of certificates, it is admittedly difficult to distinguish which certificates need to go where when you are wading through Microsoft DirectAccess documentation, so this section clears up any confusion that exists about DA certificates. It really is not very complicated, once you know what does and does not need to be done.The core prerequisite is that you have a Windows CA server somewhere in your network. The stature of your PKI implementation is not that important to DA. We simply need the ability to issue certificates to our DA server and clients. There are only three places where certificates are used in DA, and two of them are SSL certificates.

SSL certificate on the NLS web server

As mentioned previously, your NLS website needs to be running HTTPS. This means that you will require an SSL certificate to be installed on the server that is hosting your NLS website. Assuming that you have an internal CA server, this certificate can be easily acquired from that internal CA, so there are no costs associated with this certificate. You do not need to purchase one from a public CA, because this certificate is only going to be accessed and verified from your domain-joined machines, the DA clients. Since domain-joined computers automatically trust the CA servers in your network, this certificate can simply be issued from your internal CA, and it will do exactly what we need it to do for the purposes of DA.

SSL certificate on the DirectAccess server

An SSL certificate is also required to be installed on the DA server itself, but this one should be purchased from your public CA. This certificate will be used to validate IP-HTTPS traffic streams coming in from the client computers because that is SSL traffic and so we need an SSL certificate to validate it. Since the IP-HTTPS listener is facing the public internet, it is definitely recommended that you use a certificate from a public CA, rather than trying to use a certificate from your internal PKI.If your company already has a wildcard SSL certificate, use it here to save costs!

Machine certificates on the DA server and all DA clients

The last and most complicated part of the DA certificate puzzle is machine certificates. Once you know what is required though, it’s really not hard at all. We simply require that a computer or machine certificate be installed on the DA server, as well as each of the DA client machines. This machine certificate is used as part of the authentication process for IPsec tunnels. It is a big part of the way in which DA verifies that you really are who you say you are when your computer makes that DA connection happen.The best way to go about issuing these machine certificates is to log into your CA server and create a new certificate template that is duplicated from the built-in Computer template. When setting up your new certificate template, just make sure that it meets the following criteria:

The Common Name (subject) of the certificate should match the FQDN of the computer.

The Subject Alternative Name (SAN) of the certificate should equal the DNS name of the computer.

The certificate should serve the intended purposes (Enhanced Key Usage) of both Client Authentication and Server Authentication.

I should note here, though I don’t really want to, that issuing these certificates is not absolutely necessary to make DA work. If you are running Windows 8 or higher on the client side, then it is possible to get DA working without machine certificates. It is possible for client computers running without machine certificates to instead utilize something called Kerberos Proxy for their computer authentication when the IPsec tunnels are being built, but I highly recommend sticking with certificates. Using certificates as part of the authentication process makes the connection more stable and more secure. Additionally, as with the placement of NLS, if you want to perform any advanced functions with DA, such as load balancing or multisite, or even if you simply want to make some Windows 7 computers connect through DA, then you will be required to issue certificates anyway. So, stick with best practices and issue these certificates before you even get started with testing DA.

Do not use the Getting Started Wizard (GSW)!

After making the necessary design decisions and implementing the prerequisites we have talked about so far, it is finally time to install the Remote Access role on your new DA server! After you have finished installing the role, similar to many roles in Windows Server 2025, you will be shown a message informing you that additional configuration is required to use this role. If you follow the yellow exclamation mark inside Server Manager, the only option that you are presented with is Open the Getting Started Wizard. Ugh! This is not what you want to click on:

Figure 9.11: Do not click on this!

Don’t do it!Your home for DA configurations is the Remote Access Management Console, which is available from inside the Tools menu of Server Manager now that our Remote Access role has been installed. Go ahead and launch that, and now we are presented with a choice:

Figure 9.12: Configuring Remote Access

Do not click on Run the Getting Started Wizard! The GSW is a shortcut method for implementing DA, designed only for getting DA up and running as quickly as possible, perhaps for a quick proof of concept. Under no circumstances should you trust the GSW for your production DA environment, because in an effort to make configuration quick and easy, many configuration decisions are made for you that are not best practices.You want to make sure you click on Run the Remote Access Setup Wizard when you are first prompted in the console; this will invoke the full set of DA configuration screens. DA setup consists of a series of four steps, each containing a handful of screens that you will navigate through to choose your appropriate configuration options. There is a good amount of detail on these screens as to what each one of them means and what your options are, so don’t be afraid to dive in and set this up in the proper way. If you have already configured DA and used the Getting Started Wizard, DA may be working for you, but it will not be running as efficiently or securely as it could be. The following is a quick list of the reasons why the Getting Started Wizard is not in your best interests. These are the things that it does that go directly against a best-practice DA install, with accompanying peanut gallery commentary from yours truly:

GSW co-hosts the NLS website on the DA server—bad

GSW applies the DA client GPO settings to all Domain Computers—this is a terrible idea

GSW utilizes self-signed certificates—a Security 101 level no-no

GSW automatically disables Teredo—inefficient

GSW does not walk you through any of the advanced options for DA, probably because the way that it sets everything up invalidates your ability to even use the advanced functions—lame

Remote Access Management Console

You are well on your way to giving users remote access capabilities on this new server. As with many networking devices, once you have established all of your configurations on a Remote Access server, it is pretty common for admins to walk away and let it run. There is no need for a lot of ongoing maintenance or changes to that configuration once you have it running well. However, Remote Access Management Console (RAMC) in Windows Server 2025 is useful not only for the configuration of remote access parts and pieces but for monitoring and reporting as well.When working with DA, this is your home for pretty much everything: configuration, management, monitoring, and troubleshooting. On the VPN/AOVPN side of the remote access toolset, you will be making many of the VPN configuration decisions inside RRAS, but the Remote Access Management Console is the place to go when checking over server-side monitoring, client-connection monitoring, and reporting statistics. Whether you use DA, VPN, or a combination of the two, the Remote Access Management Console is a tool you need to be comfortable with.Let’s take a look inside this console so that you are familiar with the different screens you will be interacting with:

Figure 9.13: Remote Access Dashboard

Configuration

The configuration screen is pretty self-explanatory; this is where you create your initial remote access configuration, and where you update any settings in the future. As you can see in Figure 9.13, you can configure DirectAccess and VPN, and even Web Application Proxy (WAP), right from this Remote Access Management Console.Do not follow my lead with this screenshot. I have installed the DirectAccess/VPN portion of the Remote Access role alongside the WAP portion of the same role, but it is not recommended to run both DA/VPN and WAP together on the same server. I did it simply for the purpose of creating screenshots in my test lab.There is not a lot to configure as far as the VPN goes; you really only have one screen of options where you define what kinds of IP addresses are handed down to the VPN clients connecting in, and how to handle VPN authentication. It is not immediately obvious where this screen is, so I wanted to point it out. Inside the DirectAccess and VPN configuration section, if you click on Edit... under Step 2, this will launch the Step 2 mini-wizard. The last screen in this mini-wizard is called VPN Configuration. This is the screen where you configure these IP addresses and authentication settings for your VPN connections. The remainder of your VPN configuration duties will fall within the traditional VPN configuration console, called RRAS. However, everything about DA connections is configured right from inside Remote Access Management Console and those four mini-wizards:

Figure 9.14: VPN Configuration settings inside RAMC

Dashboard

Remote Access Dashboard gives you a 30,000-foot view of the Remote Access server status. You can view a quick status of the components running on the server, whether or not the latest configuration changes have been rolled out, and some summary numbers near the bottom about how many DA and VPN connections are ongoing:

Figure 9.15: Summary stats on Remote Access Dashboard

Operations Status

If you want to drill down further into what is happening on the server side of the connections, that is what the Operations Status page is all about. Here, you can see more details on each of the components that are running under the hood to make your DA and VPN connections happen. If any of them have an issue, you can click on the specific component to get a little more information. For example, as a test, I have turned off the NLS web server in my lab network, and I can see on the Operations Status page that the NLS is flagged with an error. Clicking on that component gives me additional detail about what is happening, so that I can resolve it:

Figure 9.16: The Operations Status page displays information about server components

Remote Client Status

Next up is the Remote Client Status screen. As indicated, this is the screen where we monitor client computers that are connected. It will show us both DA and VPN connections here. We can see computer names, usernames, and even the resources they are utilizing during their connections. Information on this screen can be filtered by simply putting any criteria into the Search bar at the top of the window.It is important to note that the Remote Client Status screen only shows live, active connections. There is no historical information stored here.

Reporting

You guessed it: this is the window to visit if you want to see historical remote access information. This screen is almost exactly the same as the Remote Client Status screen, except that you have the ability to generate reports for historical data pulled from date ranges of your choosing. Once the data is displayed, you have the same search and filtering capabilities that you had on the Remote Client Status screen.Reporting is disabled by default, but you simply need to navigate to the Reporting page and click on Configure Accounting. Once that is enabled, you will be presented with options for storing historical information. You can choose to store the data in the local WID or on a remote RADIUS server.You also have options here for how long to store logging data and a mechanism that can be used to clear out old data:

Figure 9.17: Configure Accounting (reporting) settings

Tasks

The last window pane in Remote Access Management Console that I want to point out is the Tasks bar on the right-hand side of your screen. The actions and options that are displayed in this taskbar change depending on what part of the console you are navigating through. Make sure you keep an eye on this side of your screen to set up some more advanced functions. Some examples of available tasks are creating usage reports, refreshing the screen, enabling or disabling VPNs, and configuring network load balancing or multisite configurations if you are running multiple Remote Access servers.

DA, VPN, or AOVPN? Which is best?

VPNs have been around for a very long time, making them familiar territory to anyone working in IT. Always On VPN certainly brings its share of new capabilities, but under the hood, what AOVPN is doing is launching a traditionally configured VPN connection, so the connection flow is similar to what we have always known. In this chapter, we have also discussed quite a bit about DA in order to bring you up to speed on this alternative method of automatically connecting your remote clients back to the datacenter. Now that you know there are two great connectivity platforms built into Windows Server 2025 for enabling your mobile workforce, which one is better?You don’t have to choose! You can run both of these technologies side by side, even on the same Remote Access server. Each technology has its pros and cons, and the ways that you use each, or both, will depend upon many variables. Your users, your client computers, and your organization’s individual needs must be factored into your decision-making process. Let’s discuss some of the differences between DA and VPN so that you can make intelligent decisions on which connectivity platforms fit into your organization.

Domain-joined or not?

One of the biggest requirements for a DA client computer is that it must be domain-joined. While this requirement in and of itself doesn’t seem so major, it carries implications. Trusting a computer enough to join it to your domain more than likely means that the laptop is owned by the company. It also probably means that this laptop was initially built and prepped by the IT team. Companies that are in the habit of allowing employees to purchase their own computers to be used for work purposes may not find that DA fits well with that model. DA is also not ideal for situations where employees use their existing home computers to connect to work remotely.In these kinds of situations, such as home and personally owned computers, a VPN may be better suited to the task. Don’t get me wrong, allowing employees to connect a personally owned computer to your corporate network via VPN is a terrible idea from a security perspective. But technically, you can connect to a VPN (including Always On VPN) from a non-domain-joined Windows machine, and you can even establish VPN connections (manual connections) from many non-Microsoft devices. iOS, Android, and Mac—all these platforms have a VPN client built into them, which can be used to tap into a VPN listener on a Windows Server 2025 Remote Access server. If your only remote access solution was DA, you would not be able to provide non-domain-joined devices with a connectivity platform.Keep in mind that, while the Always On VPN user tunnel is more flexible than DA in this regard, if you intend to use the AOVPN device tunnel, then your machines will still need to be domain-joined.

Auto or manual launch

There are multiple ways to look at this one. When discussing whether DA or a traditional VPN is better, DA is the clear winner. Nobody wants to make their users open a connection and manually launch it to establish VPN connectivity when an automated platform is available to use.Always On VPN, however, brings automated and seamless connectivity to the VPN world. AOVPN is almost as seamless as DA in this regard. I say almost because it is not the easiest thing in the world to make a device tunnel work well. This means that most companies rolling out AOVPN only use the user tunnel. In the user tunnel scenario, the VPN does launch automatically, but not until the user has already passed the login screen. That means in these situations, DA still holds an advantage over AOVPN because DA connects seamlessly at the login screen. This enables password resets and new domain users to log in to DA-connected machines. I hope that future improvements will enable AOVPN devices and user tunnels to co-exist in a stable way, which will give true always-on connectivity to AOVPN clients.

Software versus built-in

I’m a fan of Ikea. They do a great job of supplying quality products at a low cost, and somehow package up these products inside incredibly small boxes. After you pay for the product, unbox it, put it together, and then test it to make sure it works—it’s great. If you can’t see where this is going, I’ll give you a hint: it’s an analogy for traditional, third-party VPNs. In other words, you typically pay a vendor for their VPN product, unbox it, implement it at more expense, then test the product. That VPN software has the potential to break and need reinstallation or reconfiguration, and will certainly come with software updates that need to be accomplished down the road. Maintenance, maintenance, maintenance.Maybe I have watched too many home improvement shows lately, but I am a fan of houses with built-ins. Built-ins are essentially furniture that is permanent to the house, built right into the walls, corners, or wherever it happens to be. It adds value, and it integrates into the overall house much better than furniture that was pieced together separately and then stuck against the wall in the corner.DA and AOVPN are built-ins. They live inside the operating system. There is no software to install, no software to update, and no software to reinstall when it breaks. Everything that DA and AOVPN need is already in Windows today; you just aren’t using it. Oh, and it’s free! Well, built into the cost of your Windows license anyway. There are no user CALs, and no ongoing licensing costs related to implementing one of Microsoft’s Remote Access solutions.While third-party enterprise-grade VPN solutions can offer different levels of flexibility and more options for high availability, if your workforce consists of Windows 10 and 11 machines, there are some major factors that show Microsoft DirectAccess and Microsoft Always On VPN should be near the top of your considerations list when designing a remote access solution.

Password and login issues with traditional VPNs

If you have ever worked on the helpdesk for a company that uses a VPN, you know what I’m talking about. There are a series of common troubleshooting calls that happen in the VPN world related to passwords. Sometimes, the user forgets their password. Perhaps their password has expired and needs to be changed—ugh! A VPN doesn’t handle this scenario very well either. Or perhaps the employee changed their expired password on their desktop before they left work for the day, but are now trying to log in remotely from their laptop and it isn’t working.What is the solution to password problems with a VPN? Reset the user’s password in Active Directory, and then ask the user to come into the office for the laptop to re-sync with the domain and recognize the new password. Yup, this kind of phone call still happens every day. This is unfortunate, but a real potential problem with old-school VPNs.What’s the good news? New Microsoft Remote Access solutions don’t have these kinds of problems! Since DA and AOVPN are part of the operating system, they have the capability to be connected anytime that Windows is online. This includes the login screen! Even if I am sitting on the login or lock screen, and the system is waiting for me to input my username and password, as long as I have internet access, I also have a DA tunnel or an Always On VPN device tunnel. This means that I can actively do password management tasks. If my password expires and I need to update it, no problem. If I forgot my password and I can’t get into my laptop, I can call the helpdesk and simply ask them to reset my password. I can then immediately log in to my DA or AOVPN laptop with the new password, right from my house.Another cool function that this seamlessness enables is the ability to log in with new user accounts. Have you ever logged into your laptop as a different user account to test something? Yup, that works over DA and AOVPN as well. For example, I am sitting at home and I need to help one of the salespeople troubleshoot some sort of file permission problem. I suspect it’s got something to do with their user account, so I want to log in to my laptop as them in order to test it. The problem is that their user account has never logged in to my laptop before. With a classic VPN, not a chance; this would never work. With DA, piece of cake! I simply log off, type in their username and password, and bingo. I’m logged in, while still sitting at home in my pajamas.It is important to note that you can run both DA and VPN connections on the same Windows Server 2025 Remote Access server. This enables you to host clients who are connected via DA, via AOVPN, and also via traditional VPN connections if you have non-Windows machines that need to connect. If any of these connectivity technologies have capabilities that you could benefit from, use them all!

Port-restricted firewalls

One of the other common VPN-related helpdesk calls has always been my VPN won’t connect from this hotel. Unfortunately, most protocols that VPNs use to connect are not firewall-friendly. Chances are that your router at home allows all outbound traffic and so, from your home internet connection, everything is fine and dandy when connecting with a VPN. But take that same laptop and connection over to a public coffee shop, a hotel, or an airport, and suddenly the VPN fails to connect, with a strange error. This is usually caused by that public internet connection flowing its traffic through a port-restricting firewall. These firewalls restrict outbound access, oftentimes blocking things such as ICMP and UDP, which can interfere with VPN connections. In the most severe cases, these firewalls may only allow two outbound ports: TCP 80 for HTTP and TCP 443 for HTTPS website traffic. Then they block everything else.In the event that you are sitting behind a port-restricted firewall, how do these newer remote access technologies handle connectivity?DA is built to handle this scenario out of the box. Remember those three different protocols that DA can use to connect? The fallback option is called IP-HTTPS, and it flows its traffic inside TCP 443. So, even while sitting behind the most severe firewalls, DA will generally connect automatically and without hesitation.Always On VPN is generally deployed (as it should be) with best practices in mind, which includes prioritizing IKEv2 as the VPN connectivity protocol. In fact, some companies deploy AOVPN with only IKEv2. For these folks, a port-restricting firewall would be detrimental to that user’s VPN connection, as IKEv2 uses UDP ports to connect. It wouldn’t work. So, hopefully, the main point you take from this is that, when setting up AOVPN, make sure that you take the necessary steps to also enable SSTP VPN connectivity as a fallback method. SSTP flows traffic inside TCP 443, which can connect even through hardcore firewalls.

Super important: The AOVPN device tunnel can only use IKEv2. If you are behind a port-restricting firewall and are relying on a device tunnel for connectivity, it’s not going to work. The AOVPN user tunnel is the only one capable of doing SSTP fallback.

In fact, I have worked through the decision process for using DA or AOVPN with customers many times. To pull out one example from the memory banks, I was talking with a company that manages computers for numerous hospitals and doctors’ offices, and they did not have WAN links to those offices. The offices did have internet access though, and needed the ability to keep those computers automatically connected back to the main datacenter at all times. So far in the scenario, either DA or Always On VPN would fit the bill. Then, during testing, we discovered that many hospital networks restrict outbound internet access. The only way that DA would connect was via IP-HTTPS, and the only way that AOVPN would connect was via SSTP. Not a problem, right? Except that it was. You see, these remote workstations are often treated as kiosks, walk-up machines, where dozens of different employees could walk up at any moment and log into them. Oftentimes, this means that users who have never logged into these machines before are now logging in to them, so they don’t have cached credentials on those computers.If you haven’t figured it out already, we had no choice but to go with DirectAccess in this scenario. DA is always connected at the login screen, even when using its fallback IP-HTTPS method. Always On VPN, however, can only do IKEv2 at the login screen, because the device tunnel requires IKEv2. This uses UDP and was blocked by the firewall, so the only way that AOVPN would connect was by using SSTP, but that wasn’t available until the user tunnel could launch, which was only after the user had logged in to the machine. It was an extremely interesting real-world use case that helped shed some light on the decision-making process you may need to take for your own environment.

Manual disconnect

If you aren’t already convinced that old-school, traditional VPNs are yesterday’s news, let’s throw another point at you. When you use VPNs that require the user to manually launch the connection, you are relying on the user themself to keep that machine managed, patched, and up to date. Sure, you may have automated systems that do these things for you, such as WSUS, SCCM, and Group Policy. But when the laptop is out and about, roaming around away from the LAN, those management systems can only do their jobs when the user decides to establish a VPN connection. It’s very possible that a laptop could spend weeks completely outside the corporate network, connecting to dozens of insecure hotspots while that employee works their way around the Caribbean on a cruise ship.After weeks of partying and Netflix, they connect back into the LAN or via VPN to do some work, and wouldn’t you know it, that machine has been offline for so long that it’s picked up all kinds of fun and creative new software that you now have to deal with.Not so with the Microsoft remote access tools! Providing automatic connectivity via Always On VPN or DirectAccess means that the laptop would have been connected and receiving all of its security policies and patches during that entire vacation.In fact, to take it one step further, on a DA connected machine the user cannot disable their DA tunnels even if they want to. You do have the ability to provide them with a “Disconnect” button, but that basically just fakes out the connection from the user’s perspective to make it feel to them like DA is offline. In reality, the IPsec tunnels are still flowing in the background, always allowing management-style tasks to happen.

Native load-balancing capabilities

Long story short, DA is the winner here. The Remote Access Management Console has built-in capabilities for configuring and managing arrays of DA servers. You can stack multiple DA servers on top of each other, tie them together in load-balanced arrays, and provide redundancy and resiliency right from inside the console, without any extra hardware or traditional load-balancer consideration. You can even configure something called DirectAccess Multisite, where you tie DA servers that reside in different geographical locations together in arrays, giving cross-site resiliency. Almost every company that runs DA configures a redundant environment, providing either inner-site load balancing or multisite, or sometimes both, because these capabilities are built in and easy to configure.Unfortunately, these capabilities are not (not yet, anyway) ported over into the Microsoft VPN world. Whether you are connecting Windows 7 clients via traditional VPN connectivity or getting Windows 10 clients to connect using Always On VPN, the backend infrastructure of an RRAS VPN is the same and has no built-in accommodation for multiple servers or sites. It is certainly possible to do so, making that VPN system redundant, but that would require you to set it up on your own by using external load balancers and, oftentimes, would require the use of global site/server load balancers to make that traffic flow properly.Anyone who has set up load-balanced VPNs of any flavor in the past may be well aware of this process and be able to configure that easily, and that is great. But this is a limiting factor for small business customers who have a limited number of servers, network equipment, and IT experience. All in all, the extra capabilities built into the console related to DA put it a step ahead of any VPN solution in terms of building up your remote access infrastructure to be resilient to failure.

Distribution of client configurations

The last primary consideration that you need to consider when deciding which direction you want to go for remote access is the method by which client-side settings get pushed down to their respective computers:

Third-party VPN: We have already discussed the downsides of dealing with software applications for third-party VPN vendors. If you can use something baked into the Windows operating system instead, that seems like a no-brainer.

Always On VPN: The recommended way to roll out AOVPN settings to client computers is through the use of an MDM solution, namely either MCM/SCCM or Intune. If you have one of these systems and your client computers are joined to it, rolling out AOVPN settings to your workforce is a breeze. If you do not have one of those systems, it is still possible, but not a straightforward process.

DirectAccess: When working in a traditional infrastructure, Active Directory and on-prem servers, DA’s approach to client settings distribution is the easiest to work with. You have to keep in mind that DA is only for your domain-joined systems. Given that you can expect all clients to be domain-joined, you have access to rolling DA connectivity settings out via Group Policy, which exists inside any Microsoft-driven infrastructure.

I genuinely hope that we will see a Group Policy distribution option added in the future for Always On VPN configuration rollouts. There is at least one third-party company who has created an add-on module to do such a thing, but my opinion is that if Microsoft were to release native ADMX for AOVPN profile creation, many people would flock to it.To summarize this whole topic, when comparing DA against traditional, manual-launch VPNs, DA cleanly takes first prize. There really is no comparison. Now that we have Always On VPN at our disposal, the benefits of one over the other (DA or AOVPN) are quite fuzzy. They both accomplish a lot of the same things, but in different ways. My personal experience in working with these technologies for many years is that the primary deciding factors for most customers have always been client-side rollout capabilities, whether or not they have access to an MDM solution, and how important device tunnel connectivity is to them. Microsoft’s goal is for AOVPN to have feature parity with DA, and it’s close. Always On VPN also has some advanced authentication features that DA does not have, such as integration with Windows Hello for Business or Azure MFA. Ultimately, Microsoft’s DirectAccess deprecation announcement seems to have set a firm path forward. Many will still deploy and make use of DA in the future, as Windows Server 2025 is just beginning life and will have some form of support for approximately 10 years, but Microsoft is going to encourage people to lean toward AOVPN. I will happily agree with that blanket recommendation, as soon as they enhance AOVPN to have actual feature parity with DirectAccess. Until then, each continues to have advantages and disadvantages.

Web Application Proxy

DA and VPN are both great remote access technologies, and combining the two of them together can provide a complete remote access solution for your organization, without having to pay for or work with a third-party solution. Better still, in Windows Server 2025, there is yet another component of the Remote Access role available to use. This third piece of the remote access story is Web Application Proxy. This is essentially a reverse-proxy mechanism, giving you the ability to take some HTTP and HTTPS applications that are hosted inside your corporate network and publish them securely to the internet. Any of you who have worked with Microsoft technologies in the perimeter networking space over the last decade will probably recognize a product called Forefront Unified Access Gateway (UAG), which accomplished similar functionality. UAG was a comprehensive SSL VPN solution, also designed for publishing internal applications to the internet via SSL. It was considerably more powerful than a simple reverse-proxy, including components such as pre-authentication, SSTP VPN, and RDS gateway; DirectAccess itself could even be run through UAG.If all of your mobile workers have access to use either DA or VPN, then you probably don’t have any use for WAP. However, with the growing cloud mentality, it is quite common for users to expect that they can open a web browser from any computer, anywhere, and gain access to some of their applications.Document access is now often provided by web services such as SharePoint. Email access is available remotely, from any computer, by tapping into Outlook Web Access. Universal access to SharePoint and Exchange Online is extremely easy to accomplish when using cloud services such as Azure and Microsoft 365, but many don’t realize that this can also be true of on-premises Exchange and SharePoint services.So many applications and so much data can be accessed through only a web browser, and this enables employees to access this data without needing to establish a full-blown corporate tunnel such as a VPN. So what is the real-world use case for WAP? Home computers that you do not want to be VPN-connected. This way, you don’t have to worry as much about the health and status of the home or user-owned computers, since the only interaction they have with your company is through a web browser. This limits the potential for sinister activity to flow into your network from these computers. As you can see, technology such as WAP does certainly have its place in the remote access market.I have hopes that, over time, WAP will continue to be improved and evolve into a true replacement for UAG. UAG ran on Windows Server 2008 R2 and has long been discontinued as a Microsoft product. The closest solution Microsoft now has to UAG is the WAP role. It is not yet nearly as comprehensive, but they are working on improving it. Currently, WAP is useful for publishing access to simple web applications. You can also publish access to rich clients that use basic HTTP authentication, such as Exchange ActiveSync, although, more recently, basic authentication has been put on the naughty list by security teams and so I don’t see this one being utilized very often. Also included is the ability to publish data to clients that use MSOFBA, such as when users try to pull down corporate data from their Word or Excel applications running on the local computer.WAP can be used to reverse-proxy (publish) remote access to things such as Exchange and SharePoint environments. This is no small thing, as these are technologies that almost everyone uses, so it can certainly be beneficial to your company to implement WAP for publishing secure access to these resources; it’s certainly better than NATing directly to your Exchange server.

WAP as AD FS Proxy

Another useful way in which you can utilize a WAP server is when setting up Active Directory Federation Services (AD FS) in your network (this is perhaps the most common use for WAP right now). AD FS is a technology designed to enable single sign-on for users and federation with other companies, and so it involves taking traffic coming in from the internet and passing it into your internal network. In the past, there was a Windows Server role component that accompanied AD FS, called the AD FS Proxy. In the latest versions of AD FS, this separate role no longer exists and has been replaced by the WAP component of the Remote Access role. This better unifies the remote access solution, bringing your inbound AD FS traffic through the official Remote Access server, rather than needing a separate AD FS Proxy server. Anyone implementing outward-facing AD FS in their environments will likely find themselves required to deploy WAP at some point.

Requirements for WAP

Unfortunately, the ability to make use of Web Application Proxy comes with an awkward requirement: you must have AD FS installed in your environment to be able to use it, even to test it, because the WAP configuration is stored inside AD FS.None of the WAP configuration information is stored on the Remote Access server itself, which makes for a lightweight server that can be easily moved, changed, or added to. The downside to this is that you must have AD FS running in your environment so that WAP can have a place to store that configuration information.While a tight integration with AD FS does mean that we have better authentication options, and users can take advantage of AD FS single-sign-on to their applications that are published through WAP, so far, this has proven to be a roadblock to implementation for smaller businesses. Many folks are not yet running AD FS, and if the only reason they are looking into implementing AD FS is so that they can use WAP to publish a few web applications to the internet, they may not choose to invest the time and effort just to make that happen.One thing to keep in mind if you are interested in using WAP and are therefore looking at the requirement for AD FS is that AD FS can certainly be used for other functions. In fact, one of its most common uses at present is integration with Office 365. If you are thinking of incorporating Office 365 into your environment, AD FS is a great tool that can enhance the authentication capabilities for that traffic.

Latest improvements to WAP

WAP was introduced in Server 2012 R2 and had many improvements when Windows Server 2016 was released. There have been few major modifications since that time, but it is still important to point out the latest benefits that have been rolled into this feature to show that it is still learning to do new things. Let’s discuss some of the more recent improvements to Web Application Proxy.

Pre-authentication for HTTP Basic

There are two ways that users can authenticate to applications that are being published by WAP: pre-authentication or pass-through authentication. When publishing an application with pre-authentication, this means that users will have to stop by the AD FS interface to authenticate themselves before they are allowed through to the web application itself.In my eyes, pre-authentication is a critical component of any reverse proxy and I would have to be stuck between a rock and a hard place to externally publish an application that did not require pre-authentication. However, the second option is to do pass-through authentication, and it does exactly that. When you publish access to an application and choose pass-through authentication, all WAP is doing is shuttling the packets from the internet to the application server, in true reverse proxy form. Users can get to the web application without authentication, so in theory, anyone on the internet can hit the web frontend of your application. From there, the application will likely require the user to authenticate, but there is no man-in-the-middle protection happening; that web application is available for the public to view. As you can tell, I do not recommend taking this route.We already know that WAP can pre-authenticate web applications, but the original version could not do any form of pre-authentication on HTTP Basic applications, such as when a company wanted to publish access to Exchange ActiveSync.This inability leaves ActiveSync a little bit too exposed to the outside world and is a security risk. Thankfully, this changed in Windows Server 2016 and continues to be a benefit today—you can now pre-authenticate traffic streams that use HTTP Basic.

HTTP to HTTPS redirection

Users don’t like going out of their way or wasting time by having to remember that they need to enter HTTPS:// in front of the URL when they access applications. They would rather just remember email.contoso.com. The inability of WAP to do HTTP to HTTPS redirection was an annoyance and a hindrance to adoption, but that has since changed. WAP now includes the capability for WAP itself to handle HTTP to HTTPS redirection, meaning that users do not need to type HTTPS into their browser address bar any longer; they can simply type in the DNS name of the site and let WAP handle the translations.

Wildcard domain publishing

Early versions of WAP didn’t play nicely with some SharePoint environments, because of limitations in the way that WAP handled domain names. The external URL utilized for publishing an application through WAP can now include a wildcard identifier, which enables the newer versions of on-premises SharePoint to be successfully published to the internet, via WAP. This will simplify SharePoint publishing over WAP, making it successful in more cases.

Client IP addresses forwarded to applications

In the reverse proxy and SSL VPN world, we occasionally run across applications that require knowing the client’s local IP address. While this requirement doesn’t happen very often and is typically segregated to what we would call legacy applications, it does still happen. When the backend application needs to know what the client’s IP address is, this presents a big challenge with reverse-proxy solutions. When the user’s traffic flows through WAP or any other reverse proxy, it is similar to a NAT, where the source IP address information in these packets changes. The backend application server is unable to determine the client’s own IP address, and trouble ensues. WAP now has the ability to propagate the client-side IP address through to the backend application server, alleviating this problem.

Publishing Remote Desktop Gateway apps

One of the items that UAG was commonly used for was publishing access to Remote Desktop Services. UAG was essentially its own Remote Desktop Gateway, which gave you the ability to publish access to RDSH servers, individual RDP connections to desktop computers, such as in a VDI implementation, and even access to RemoteApp applications. Unfortunately, WAP cannot do any of this, even in the new version, but the fact that Microsoft added a little bit of functionality here means movement in the right direction is happening.What has been improved regarding WAP and Remote Desktop is that you can now use WAP to publish access to a Remote Desktop Gateway server. Traditionally, a Remote Desktop Gateway sits on the edge of the network and connects external users to internal Remote Desktop servers or RemoteApps. Remote Desktop Gateway servers are a common attack vector, and placing WAP in front of the Remote Desktop Gateway allows stronger pre-authentication for Remote Desktop services and creates a bigger separation between the internal and external networks.All of my fingers are crossed that we will continue to see improvements in this area and that WAP can be expanded to handle traffic like Remote Desktop natively, without even needing a Remote Desktop Gateway in the mix.

Improved administrative console

The original version of WAP inside Windows Server 2012 R2 was best served using PowerShell to implement it. You can certainly still use PowerShell to create your publishing rules if you choose, but the Remote Access Management Console has now been improved in terms of how it relates to WAP. Before you can find WAP in the Remote Access Management Console, you need to make sure that the appropriate box was checked during the Remote Access role installation. If you did not select Web Application Proxy when you first installed that role, revisit the add/remove Roles function inside Server Manager to add WAP to this server:

Figure 9.18: Adding WAP to a server

Note that, while WAP is a component of the same Remote Access role that houses DA and VPN, it is not recommended to run WAP alongside DA and VPN on the same server. As you already know, you can co-host DA and VPN connections together, simultaneously, on a single Remote Access server. But once you make the foray into WAP, this should be a standalone component. Do not run WAP on a DA/VPN server, and do not run DA/VPN on a WAP server.Now that we have added Web Application Proxy to our server, you can open the Remote Access Management Console and see it listed inside the Configuration section. From here, you launch the Web Application Proxy Configuration Wizard and start walking through the steps to define your AD FS server, the certificates you are planning to use, and other criteria needed for the role:

Figure 9.19: Configuring WAP from the Remote Access Management Console

Summary

The nature of the world today demands that most companies enable their employees to work from wherever they are. Working from home has become normal over the past few years; with a worldwide pandemic, we have seen staggering increases in the percentage of employees who work outside of an office building. Companies need a secure, stable, and efficient way to provide access to corporate data and applications for these mobile workers. The Remote Access role in Windows Server 2025 is designed to do exactly that. With three different ways of providing remote access to corporate resources, IT departments have never had so much remote access technology available at their fingertips, built right into the Windows operating system that they already own. If you are still supporting a third-party or legacy VPN system, you should at least explore the capabilities provided here.DirectAccess and Always On VPN are particularly impressive and compelling connectivity options—a fresh way of looking at remote access. Automatic connectivity means your machines are constantly patched and updated because they are always connected to your management servers. You can improve user productivity and network security at the same time. These two things are usually oxymorons in the IT world, but with the Microsoft remote access stack, they hold hands and sing songs together.Next, we are going to look at some of the security functions built into your Windows Server 2025 operating system, and at some of the ways that your servers can be hardened to provide even better security than what comes out of the box.

Questions

What two VPN protocols are no longer enabled by default in Windows Server 2025?

What does AOVPN stand for?

What are the two primary protocols used for connecting AOVPN clients?

In which version of Windows 10 was AOVPN released?

In what special instance would an AOVPN client be required to be joined to your domain?

Does DirectAccess require your corporate internal network to be running IPv6?

What is the name of the internal website that DirectAccess clients check in with to determine when they are inside the corporate network?

What ports are used by Teredo and IP-HTTPS?

How do you provision DirectAccess configuration settings to the client machines?

What role does a Web Application Proxy server hold in a federation environment?