 Hello, and welcome to our Windows Server Engineering Summit presentation for what's new in Active Directory for Server 2025. My name is Cliff Fisher, Senior Technical Program Manager for Active Directory, and I'll be joined today by our principal software engineers, Jiajing Zhu, Linda Taylor, and Wayne McIntyre, who will be presenting demos. First, a little bit about myself. I joined Microsoft as a full-time employee in 2015 after nearly 10 years in various AD support and admin roles for companies in the healthcare, travel, and banking industries. After spending nearly six years in CSS, troubleshooting, and debugging AD, I took a dream role as the Active Directory Technical Program Manager for Windows Servicing and Delivery, managing the overall vision and business goals for AD feature development and servicing. So what are we going to talk about today? Well, first, we want to cover functional level and schema updates, then we'll move on to scalability improvements, security improvements, supportability improvements, and then we'll talk about some closing thoughts. So when we talk about improvements for Active Directory in server 2025, they fall into three main buckets or pillars. First and foremost is security. Security is top of mind for us, and we know it's top of mind for you too. So we've definitely invested in this area in server 2025. We've also invested in scalability. As we know that a lot of companies out there have been running their AD workloads since 1999 or maybe a little later, and they're running into some of those limitations that were implemented back when AD was created in 1999. Therefore, we're starting to invest in scalability improvements to help our enterprise customers better scale their Active Directory implementations. Finally, we're investing in supportability as we know that support of Active Directory is tough, and we know that admins out there need as much help as they can get keeping their environment protected, safe, and secure. So we've invested in supportability improvements. So before we talk about those improvements, let's cover some of the functional level and schema updates. So first of all, we've implemented a new functional level for the first time since Server 2016. That functional level for Forest and Domain will be called Windows Server 2025. You can see it says v next here in the slide that's been updated with the name of the new Windows Server 2025 OS. Now there is one caveat here, and that's you must be on Windows Server 2016 domain or forest functional level in order to deploy a Server 2025 DC in your environment. Next, since we did make updates to Active Directory, we had to also update the schema. Therefore, you will get a schema update as soon as you deploy your first DC for Server 2025 or for an insider build of Server 2025. And now let's talk about some scalability improvements. So over the last few years, we've seen some scalability challenges with our large enterprise customers as well as internally as we start to push the limits of what Active Directory was designed to do back when it was created in 1999. As such, we've seen some customers run into some issues such as high CPU load or ATQ thread exhaustion in their environments, perhaps some LDAP, unresponsiveness, lack of authentication. We've seen massive domains of 800 to 1000 to 1200 DCs. We've seen database files, the ntds.dit file increase to hundreds of gigabytes in size for some large customers. And we've also seen a high churn rate of object replication. So how are we going to address that? Well, first I'd like to pass it off to Jiajing Zhu, who will talk about our improvements to the Jet database. Jiajing? Hi, I'm going to talk about a new feature introduced in Active Directory 2025, the Jet 32K page feature. Well, we are talking about the Active Directory features. Why is Jet in this picture? Jet is the database engine that Active Directory uses. Active Directory data is stored in Jet database. If you check the folder of your domain controller, you may see a file named ntds.dit. This is the Jet database file. Active Directory data is stored in this file. Next question is, what is a Jet page? A Jet page is a storage unit that Jet database keeps its data. A Jet page has a fixed size. Jet supports multiple page size that one can choose from when create a new database image, which in all contact is the ntds.dit file. Once a page size is chosen, it is stepped on DB header and cannot change it again on that database. Ever since Active Directory was first released, we have been choosing to use a Jet page size of 8K that ntds.dit has been stepped to 8K. Now, on our new Windows Server 2025 domain controllers, we support a big Jet page size of 32K. Why Jet page size matters? Let's start from how Active Directory data is stored in the Jet database. This is a picture of a DC. You may see that all the items on the left side window are AD objects. These objects are stored in the Jet database table. With each object taken role in that table. Each attribute value on that object is stored on the corresponding attribute column of that role. For example, the DomainGaest object. The value of attribute name is stored in the name column with the value DomainGaest. The value of object class is group and is stored in the object class column. And the value of attribute description is all DomainGaest, which is stored in the description column. This is the table, and the table with roles and columns is the logic view of a Jet database. Physically, Jet stores a role of a table into a Jet page. Again, let's take DomainGaest object as an example. The non-empty values of this object are stored in a Jet page. A value can be stored either directly or indirectly on a page. For example, the value of attribute object class is group, which can be stored directly on this 8K page. The value of attribute description is all DomainGaest, which can be stored at some off-page place with a pointer pointing to this place on that 8K page. All the non-empty columns of a single role must fit in only one page, with either keep the value on the page or keep the pointer on the page. This means that the attribute value on a single active directory object must fit an 8K page in Jet. And this is why Jet page size matters. It decides how many non-empty attribute values we can store on a single AD object. You may see there are multiple documentation suggesting the maximum attribute value AD can support. The number may vary depends on the different usage pattern, but basically it's around 1K non-link attribute values with the underneath 8K Jet page. Now, with Jet 32K page support, our custom can have more values on a single object. Yeah! How to enable this feature? First, it's need to be running our forest with every DC 30K Jet page available. Like we mentioned earlier, an ntds.dev file can only be chosen to support 32K page when it is created, or in other words, this is when a DC is promoted. For compatibility reasons, a 32K page available DC can be running in 8K mode in hybrid environment, where you have mixed 2025 DCs and a down level DCs. Once all the DCs are 32K page available, we can enable the real 32K page mode by enabling this optional feature called database 32K page feature. It requires a forest behavior version of 10, which is the behavior version of Active Directory 2025. This is the screenshot of enabling this optional feature by the normal PowerShell commands. By increasing the Jet page size from 8K to 32K, are you going to support 4 times attribute values in a single object? Well, in our testing environment, we are seeing that with 32K Jet page, we now can add attribute values of about 3200, comparing to 1200 values we can add before. Yes, we can support much more values, but not exactly 4 times. Let's introduce another feature that comes with Jet 32K page, the 64-bit LBID feature. In this talk, we explained that some big size value may be stored off the page with the point pointing to the place it is actually stored. In Jet Contact, this point is called LBID, the long value ID. Precisely, this is not a memory pointer, but more like an index that is incremental and once used, never can be reused by other value. LBID is a precious resource. With 32-bit LBID, it can be used to store a maximum of 4K values. Once this space is used up, no more off-page value can be added. We have been seeing all customs running out of LBIDs in large, long-existing DCs, and the only way to reclaim the LBID space is to offline defrag the database or to rebuild the DC. Jet Database supports 64-bit LBID. Now by adopting this 64-bit LBID in Active Directory, we will have much longer life of LBID space and thus much longer life of a domain controller before it has to go offline maintenance. Thanks, Judging. But what about the CPU load issues and the replication challenges that our large enterprise customers face? Do we have anything to help them? One of the biggest limitations AD had in terms of scale is that we were not NUMA aware that for customers who buy 80 cores, 128 cores based NUMA machines, AD would only see the CPUs on the first NUMA group and only utilize them. AD is now fully NUMA aware and will take advantage of all the cores in all NUMA groups to use the full computation power the hardware can provide. This allowed the thread pool to grow much larger than it could previously and for a single DC to handle more incoming workload. This change is also back-ported to Server 2022. The NUMA support is enabled by default. I'm going to talk about replication priority boost feature. As we all know, Active Directory is a distributed system. When a write happens on one DC, it propagated to other DC by replication. Changes may happen concurrently on multiple DCs. A destination DC gets the changes from its replication partners one after another. When a destination DC retrieves changes from many other DCs, these tasks are served based on their priorities. What is the priority of a particular task is determined by a set of hard-coded numbers in Active Directory. The priority numbers are designed to use some heuristic rules. For example, configuration ANC has a higher priority because a topology change might be more important. Intracite partners has higher priority because geographically closed DCs might be more relevant changes for the DCs in the same site. While this building priority number works fine in most cases, it is not the most efficient way in some scenarios. For example, in some air environment, sites are not designed by closed locations but by their functionalities like a primary rights versus backup sites. Sometimes the changes in configuration ANC are not important and sometimes we want to stick on a single partner DC over the rest in the same group. Therefore, we introduce the new feature replication priority boost. This feature allows an admin to manipulate the priority to get the most efficient replication order to fit their environment. This feature uses a root DAC mode to add a boost factor on the system designed priority and a root DAC attribute to read this boost factor. This is a screenshot of using this feature. Set priority boost root DAC mode boost the replication priority of a partner by five and this root DAC attribute MSDS priority boost read this boost factor that we set on our replication partner in our case, which is five. Big thanks to Jiajing for showing off some of our scalability improvements. Now let's talk about security improvements. So the first big feature we want to talk about is delegated managed service accounts. This is a collaboration between our team and the Kerberos authentication team to address issues with service accounts. As you may know, service accounts are identities that are used in conjunction with line of business apps such as SQL, IIS, or other third party applications that may need to talk to AD. Typically these accounts have passwords that are either old, not very secure, maybe they haven't changed in a long time, and maybe they're not managed regularly. Well, there was a desire to get people into a state where those service accounts could be used, but they could also be managed. And we want that to all happen seamlessly behind the scenes. So we developed delegated managed service accounts and here's basically how it works. There's a diagram here. So first, DMSAs allow migrating normal accounts used for services to move to a GMSA or group managed service account style of account with automatic password management. The domain admin when setting up the DMSA can link a service account to be superseded by the DMSA. This account is only accessible by the KDC and cannot be accessed by LDAP or any other means. And there are no changes required on the actual service configuration, which is part of what makes this so great. You can leave the service configured however you want on your SQL or IIS or line of business app. And AD and the KDC will handle all the stuff on the back end to make sure that there's a seamless handoff between that account and the DMSA. Here's Wayne McIntyre to talk more about delegated managed service accounts and to give you a demo of how this looks. Thanks, Wayne. Hi, my name is Wayne McIntyre. I am a software developer on the Active Directory team. In this video, we're going to demo the delegated managed service account feature, which is the next evolution of GMSA accounts. If you haven't seen our technical takeoff session for what's new in AD, I recommend watching that for additional context. So first, we're going to go ahead and create a new DMSA account. And it uses the same command that a DMSA does, but it has a new switch for create delegated service account. It's a Kerberos encryption types to AES-256. We'll call it DMSA demo. It takes a host in. Okay, so now we've created a new DMSA account. We'll just hop over to LDP really quick, and we should have a new account under managed service accounts. And there it is. And I'm just going to point out a few attributes. You'll see the delegated MSA state is zero, which just basically means it's on length and not in any specific state at this moment. But it also has all the same type of attributes that you would find on a GMSA, which is the password ID and password interval. All right, so the main purpose of the DMSA account is to allow you to supersede an existing service account. That's just the normal user. So in this case, I have this myService account, and I'm going to go ahead and start a migration using this account. So the new command line is start a service account migration. We're going to give it the identity of the DMSA we just created. And then we're going to specify the account that we're going to supersede. And it wants a distinguished name, so just grab it from here. And that should start the migration process. And during this state, if we go back to the DMSA demo account, there'll be a few new attributes. So you'll see here, the delegated MS date is now one, which means it's linked. And it's also going to point to the account that it's preceded by. So in this case, it's that myService account. Likewise, if we jump over to the service account, you will also see that it does similar things where the superseded managed account link is now the DMSA demo account. And its state is also set to one. It's also important to note that all steps can be undone. So if you feel this was an error and you don't want to actually link these two accounts, you could just change this to undo. And it'll undo the last step. There's also a reset, which will reset back to the starting state as well. But in this case, we want to go ahead and actually perform the migration. So we'll go ahead and run it again. And while it's in this state, everything that logs on with the service account will still function normally. But it's also going to add the machines that the logon are occurring from to the principles allowed to retrieve managed password attributes. So I'm just going to do a logon real quick from my member server that has a service running as that service account. Let's just stop it. And then we'll start it. So I should do a new logon. And we'll hop back to the DC. And let's see the current state of that DMSA demo account. We want to look at the principles allowed to retrieve. And you'll see in this case, we now have TT DMSA, which is actually the machine account or the member server name that just did the logon. And it's a computer account. So at this point, the account is in that migration stage and it's going to start adding machines to this attribute so they retrieve the managed password. Once we're comfortable that we've gotten all of the machines that are using this service account, we can now complete the AD service account migration and that's just going to be complete AD service account migration, all the other parameters are the same. And at this point, what should happen with the service account is a few things one. The main thing is this service account is now disabled. The current state is in a state where it's considered delegated or superseded. And the other attribute or points back to the DMSA demo is still the same. Likewise, if we go over to the DMSA demo account. One other thing that is important here is that any service principle names that were owned by the service account have now moved over here. So you'll see the service principle name for my servers.com. All right, so at this point, the migration is completed. And that anyone that logs in with the my service account will now have a more secure password using the DMSA demo account. And that concludes the DMSA demo. Thank you. Awesome stuff, Wayne. Now let's talk about DC locator improvements. DC locator, as its name suggests, is a way for us to find a DC when we need to communicate with one. Sometimes in order to do that DC locator has to map a net bios name into a DNS name. Think of a scenario where you're logging on with Contoso backslash cliff. Contoso is actually the net bios name of the domain that you're trying to log into. And that domain is probably really called Contoso.com or Contoso.org, etc. Well, we need to convert that Contoso into a DNS name that can then be looked up to get an IP address for a DC in that domain. Therefore, we have DC locator to help do that. We also made some improvements in this area to help us deprecate a really ancient technology called mail slots. If you want to know more about mail slots, please read Ned Piles blog post on the beginning of the end of remote mail slots. Windows Server 2025 will have the setting enabled by default. And we've added a policy here as well to configure this if needed. You can also go to the AD domains and trusts snap in and specify a manual net bios mapping if you need to. So you may be wondering how all this works. Well, let's start by talking about how it works in the current version of Windows. If DC locator needs to find the Contoso domain via net bios name, it starts by looking in its own DC locator cache. If the domains already been looked up, it'll be in the cache and no other work is needed. If it's not there, we move on to looking at the list of domains in the current forest. If it's not there, we look at a list of all the trusts that we have with other domains, forest trusts, external trusts, etc. And we look for Contoso there. If you can't find it there, we look at sign-in sessions on the client machine. And then if we can't find it there, that's when we use net bios-based discovery. Blah. So let's see how we've improved this. Well, we still look up the Contoso domain in the cache first and then we move on to the forest and the list of trusts. However, we've now implemented the admin configured domain name mappings that we mentioned in the previous slide. And if we can't find it there, we also have a list of all domain mappings from the trust scanner. The trust scanner will run every so often and will pull all of the known trusts and trusted domains, child domains, etc. And then if we can't find it there, we still fall back to looking at sign-in sessions on the client machine. And now I'll hand it off to Linda Taylor with a demo on how all this works. Hello, my name is Linda Taylor and I'm a software engineer in the Active Directory development team at Microsoft. In this video, I'll be demoing the new improvements in the DC location algorithm. If you haven't seen our session on technical takeoff regarding all the new features in the Active Directory domain services, I also highly recommend you go and watch that for some background. So I'm here on the main page for what's new in Active Directory domain services inside a preview documentation where we have documented some brief overviews of all of the new bits in the inside preview. In today's demo, we will be looking at the improvements in DC location algorithm. And even though it looks like a very small section, there's actually a whole dedicated pager on the DC Located Changes. I also want to give a shout out to my teammate, Jay Simmons, who actually did all the hard work here that I'll be demoing today. So as of the next version of Windows, the DC location algorithm no longer uses mouse locks. For net buyers based discovery, when it only has a net buyers main and it needs to find the domain. For this demo, I have, let's close this, I have two forests. I have Contoso.com forest on the left hand side here. And on the right hand side, I have fabricand.com. These two forests don't have a trust between them. They just have some DNS settings so they can find each other with DNS. The first new thing I want to demo is that the behavior that we are discussing, not to use wins and mouse locks can also be controlled through some group policies. These new group policies can be found under computer configuration in the admin templates section and in system, under net logon, inside the DC locator and DNS records folder. You will notice that there are two new settings that relate to net buyers based discovery. The first one is do not use net buyers based discovery for domain controller location when DNS based discovery fails. So this is the default behavior, but you can control it with a policy. And the second one is block net buyers based discovery for domain controller location. Again, secure by default. Okay, so what happens instead now? So instead, the net logon service downloads from the domain controller a set of name mapping pairs to keep itself knowledgeable about DNS style names that map to different net buyers names. So how can you see what net logon knows about? I'll be using the tool called nltest to show you this demo. And so the first thing we're going to do is we're going to run nltest slash list DC loc mappings. This tells us about what name mappings net logon knows about. Here you can see I know about my own domain called fabricham.com, the DNS name, maps to fab net buyers name. On the left hand side here, it tells us where it got this information from. So this particular name mapping was found through looking at the trusts. There are also other sources that we discussed in our presentation. So just to show you, if I run nltest slash dsget dcname dsget dc and try to locate a DC in Contoso using its net buyers name, it's not going to be able to do that because it doesn't know what Contoso means. So another new piece of functionality that relates to these changes is the ability to define some admin based mappings as well as what's already in the trust based information. And you can do that here in Active Directory Domains and Trusts. As a domain admin, you can go and add some DC locator mappings in this new tab. So I'm going to add Contoso.com and the net buyers name Contoso as a name pair. I'm going to say OK and apply. So my domain or my DC now knows about this name mapping and it will store it in Active Directory. Just in case you're wondering where, let me show you. So I've just opened a tool called LVP, which is a very basic LDAP browser. And it's just one of my favorite tools of browsing, AD. So I'm going to bind to this domain controller and I'm going to view the configuration container. This is where we store these admin based mappings. And those are stored under services and Windows NT. You will see a new object or a container called DC locator domain name mappings, funny enough. And in here you can see that this is where it stored my new name pair in an MSDS settings attribute on this object. So NetLogOn will now also query this in addition to all the trust information and all the other information when it's trying to learn about the name pairs and then resolve the names during DC location. So you've probably noticed I'm using this as a client and DC just for the simplicity of the demo. So in real life, this would be a client machine. So the NetLogOn service will download these name mappings periodically and not all the time. So to help it do so quickly in this demo, we can run another command called NR test, update DC loc mappings. Usually NetLogOn will do this every 12 hours. And you can see it says a DC locator name mappings update request was successfully submitted and check the Microsoft Windows security NetLogOn operational event log for details. So you can go there and check that this is where it will log the outcome. But for the purposes of the demo, I know it's working. So I'm now again going to say NL test list DC loc mappings. And we can now see that I have a new mapping from the source admin. So this is the admin based mapping that somebody has defined. And it says that contoso.com maps to Contoso. And just to show you that we can also now find a DC in Contoso by running NL test. This get DC Contoso. And there we go. We have found a DC. And that's because the DC locator knew that Contoso maps to Contoso.com. So then it could go and ask DNS. And it was absolutely no need for mouse lots or let bias names. One last thing I want to show you on this demo is you may know that if you want to troubleshoot DC location and also anything that NetLogOn does is always logged to a debug log called the NetLogOn log. And you can enable that using NL test as well. NL test slash db flag. There are different flags. I'm just going to enable all of them. They are documented just for fun. And if I now go and update the mappings again, just for fun and open the NetLogOn log. The NetLogOn log lives in C windows debug folder. And it's a very easy to read text file that has anything DC locator and NetLogOn in it. So if we go right to the bottom of it, somewhere around here, we can see the request for the name mappings starting and then successfully completing. And we can also see the DS get DC name calls and such. Okay. And that concludes today's demo. Thank you very much. Awesome. Thanks, Linda. So let's talk about a few other security improvements we've made. We'll start with LDAP. So as you probably know, AD is a high value target. And one of the ways that AD is attacked in the modern landscape is relaying credentials via LDAP. So we've made some improvements. Now, these improvements have been around for a while. LDAP signing and LDAP channel binding have existed for a while now, but they're not enabled by default. Well, now, starting with server 2025, we are enforcing LDAP signing by default. And we have LDAP channel binding set to win supported. In addition, confidential attributes require an encrypted connection to be transmitted. And on the client side, LDAP client encryption is now preferred by default. We've also added LDAP channel binding token auditing recently for server 2019 and above via windows updates. So that will definitely be available by default and will be enabled by default in Windows Server 2025. Finally, let's talk about some Kerberos security enhancements. Our friends in the Kerberos authentication team have included support for AES, SHA-256 and 384. And they've been making improvements to PKNIT support for cryptographic agility. So be on the lookout for more announcements from our Kerberos authentication team. Finally, let's talk about supportability improvements. Supportability is another important area for the AD product group. We know that AD is difficult to troubleshoot and we know that it's a critical application for you. So we want to make sure that our IT admins in the field, as well as our CSS engineers, have the right tools to troubleshoot and monitor their environments. Supportability also helps us, frankly, because we help troubleshoot internal issues at Microsoft with Active Directory. So these are all really good improvements and we wanted to share them with you today. First things first, we added some LDAP client counters to performance monitor. This should help admins troubleshoot issues where maybe an application is sending a lot of LDAP requests to a DC. And you need to see where that's coming from, who's doing it, what app, how many connections there are, etc. We've implemented some performance counters here to help troubleshoot those issues. We've also included DC locator performance counters. Now these are client side and server side, or DC side you'll see there in the label. And this allows our admins to monitor various things about DC locator, like how many active mail slot pings there are, or how many requests per second there are from a client. Finally, we've added some performance counters for SID to name and name to SID lookups. Sometimes in an environment, your username needs to be converted into a SID. When you access a file share, your permissions to that file share are stored and are referenced by your SID. So when you access that file share, the username that you're using needs to be converted into a SID. Sometimes there are a lot of these requests, or the DC gets backed up processing these requests. So we've added performance counters here to help better track the volume of the lookups, as well as other aspects of those lookups. Now I'll pass it over to Linda and Wayne to demo these performance counters. Hi, my name is Wayne McIntyre. I am a software developer on the Active Directory teams. In this video, we're going to demonstrate the new LDAP client perf counters. If you haven't seen our takeoff session for what's new in Active Directory, I recommend watching that for additional context. So first I'm just going to generate some traffic, and then I'm going to go ahead and launch perf one, the new LDAP counters. So it should be under LDAP and then client, LDAP client. And you'll see here we have a number of different counters for LDAP. That will measure binds, connections, TCP, UDP, TLS, there's bandage, Modify, search, etc. Each one is per process. So you'll see there's an instance of each process. We're going to look at LDAP connection. And we'll do base searches, actually subtree, successful responses. Let's go pending, average response time, request count, request per second. And we'll go ahead and add those. Now you'll see the perf counters in action where we're able to monitor on an individual machine level, all the LDAP requests the specific process is making. And this could be important for heavy server workloads to kind of monitor this type of traffic. And that concludes the LDAP perf counters. Thank you. In this video, we're going to demo the new domain controller locator perf counters. And if you haven't seen our takeoff session yet for what's new in AD, I recommend watching that for additional context. So first we'll start with an overview of the new performance counter sets that we have. And you can see there are three new ones here. We have the DC locator client, the DC locator DC and the DC locator net logon. The client counters are going to measure per process running on this machine. The domain controller counters are going to only exist on actual DC and those are incoming LDAP pings and mail slot pings for DC lookups. And then the net logon version is very similar to the client counters, but it's broken down per name lookup. So I'll go ahead and expand client and you can see the granularity of the perf counters. So you can break the request down based on what flags are being set set and request per second. If it GC require KDC required and so forth. Then you have the overall breakdown of request, whether what the failure latency the success latency is failures per second successes, etc. Now I guess click on one of these and you can see here that they are indeed broken down by process and process ID. And if we jump over to the net logon counters, you'll see that they're mostly the same with with flags or some additional ones with cash hits per second and misses per second. So you can see how many times a DC lookup is being resolved by the cash or whether it has actually make a call in the wire and then make the DNS queries but then after that it's very similar with breakdown per flags. And then the number of requests failures and successes and so forth. But if I click on one of these you'll see here that the breakdown is per naming context or or name that was looked up. So in this case we have can toast it on calm which is obvious and then there's some other lookups like DC one doctor toast it calm and so forth. All right, so let's look at these per counters in action actually have a stress tool that's running right now that's just looping and making a number of DC locator requests. And it breaks down the successes successes failures and average response time and we're getting average response time of zero milliseconds. And that's mostly because the client and DC are the same machine. So there's no network latency involved. And if we look at some of the first counters I've already added, we could see that it's already tracking this terms of the number of requests per second, the total active request which I have is eight. And then we can add flags, the writable requests per second for the net log on counters. And then we could also probably add some to make controller counters to get some idea of how often the DC is receiving lookups for itself. And that's it that concludes the demo for the new to make controller locator performance counters. Thank you. My name is Linda Taylor and I am a software engineer in the active directory development team at Microsoft. In this video, I'm going to demo the new LSA lookup performance counters that are coming up in the new release of windows. Here I have opened the page for what's new in active directory domain services in the inside of preview. And if you haven't seen our technical takeoff session on this topic, I would highly recommend it so that you get some background. So these performance counters have been added to help administrators monitor and troubleshoot the performance of name to save lookups. And all the other equivalent APIs. Here is the public definition of LSA lookup names function. And the thing that I wanted to point out is that, for example, here it says that LSA lookup names is superseded by LSA lookup names too. For the performance counters, they monitor the very internal guts of the code. So it doesn't really matter which API was used because the monitoring happens in the actual internal workings. So we are monitoring all of the different calls. Okay, let's begin the demo. Here I have a member server and this server is in a domain in a child domain of Contoso. I have opened the performance monitor and I'm going to show you the new performance counters and talk through what they can be used for. And that will do a quick demo of them in action. So the performance counter set is called LSA lookups. And you can see it here. So let's begin with the first couple. So isolated names in bound requests and isolated names are bound requests. An isolated name is a name that doesn't have a domain part. So for example, the name Linda inbound request is a request that comes into this particular machine from a application or from a remote machine. So an isolated name inbound request is another process or another machine looking for the name Linda. And similarly, an outbound request is a request that has to go to a remote machine. For example, if I tried to look at the name Linda on demo SRV1 and it didn't exist in the local accounts database, demo SRV1 would forward this request to its primary domain controller. So that would be an outbound request of the isolated name. So we have separate counters for names inbound and outbound and then the isolated names because the two are different. Next we have some cache monitoring counters. The local LSA keeps a name and SID cache every time it resolves a name or a SID. It puts the name SID pair in the cache so that we don't have to keep asking a remote domain controller. And these counters allow us to measure the growth of this cache. It allows us to see the size of the cache and therefore see whether maybe the cache needs to be adjusted to improve the performance of the server. After this we have some other counters for, for example, names completion time. This counter can tell us how long it took to complete a name request in total. The next counter can tell us how many name requests erred out. So for example, if you have a server and it's being overwhelmed with lots of name requests and they are all failing, then there is probably something that is sending a bad name to us that is worth investigating and therefore taking up the resources on this server. So that would be one useful scenario for this counter. Next we have names inbound requests. So similar to the isolated names, but just all names and outbound. Then we can also monitor the requests that go off to the primary domain separately and how long they take. And also trusted domain and forest requests again. We can also see how many names did not get resolved as well. And then similarly we have all the same counters for the SID lookouts as well. Hopefully they will be useful. So now that I've showed you the counters, let's add them all. And I will pick up a small script so we can see them in action. So here are my counters now. And you can see nothing is happening. I'm now going to run my script that is going to bombard me with requests. And straight away you can see the green line is going up. So this one is names of cache entries added so we can see that we are actually warming up the cache. So the cache is empty after reboot because it's an in-memory cache. And the second line that's going up is also the powerful one is the cache descent file. And then you can also see the maximum number of entries in the cache. Right now it's 4096 and that is the default cache size starting from Windows 2019. It used to be 128. Having a big cache isn't always good by the way, because you don't want the entries in there to become too stale if your names change, for example. Okay, hopefully that was useful. And then one last thing I wanted to mention is this is a domain controller and if you use the Active Directory diagnostics data collector sets these counters are also now included there by default. You don't need to add them separately. That concludes the end of this demo. Thank you very much. Big thanks once again to Wayne, Linda, and Jiajing for all the great demos today. Now let's recap. The Active Directory team has made improvements in three key areas, security, scalability, and supportability. For security improvements, we've implemented delegated managed service accounts, we've deprecated DC locator based mail slot usage, and we've implemented security features in LDAP and Kerberos as well. For scalability, we've implemented JET 32K page size, NUMA support, and replication priority. And for supportability, we've implemented various performance counters and performance monitor to help you better monitor your environment. The only thing left to do is for you to go try them for yourself. Try out these new features in Windows Insider Previews. You can download them from the Microsoft.com website if you are a member of Windows Server Insiders. And you can download some ISOs, set up a lab, and play with all these new features yourself. And keep an eye on learn.microsoft.com on our What's New and Active Directory Domain Services Insider Preview page for more preview features. Thank you so much for checking out our Windows Server Engineering Summit presentation on What's New and Active Directory for Server 2025. My name is Cliff Fisher, and you can reach me at cliff.fisher at microsoft.com. Thanks so much. Have a great day.