Windows Server

In preparation for the Active Directory forest to be upgraded (to Windows Server 2012 R2), it may be prudent to re-evaluate Active Directory disaster recovery plans.

Active Directory if configured correctly will just sit there and work; servicing all requests that are presented and because of this robustness, its importance is often overlooked and its criticality not understood.

Management buy in.

The most critical component in the disaster recovery plan, is the education of management and key stakeholders in the criticality of Active Directory to the business. No Active Directory can mean, no authentication; no authorisation; no name resolution or no printing;  effectively the IT function may cease to operate until the Active Directory is restored or made available.

Plan and approach.

Define what Active Directory recovery scenarios that are being catered for, is it total loss of the Active Directory or the loss of objects within the Active Directory?

Agree with the business and calculate realistic Recovery Point Objectives (RPO’s) and Recovery Time Objective (RTO’s) for Active Directory.

RPO – this is the point where you have to recover to (or the amount of information you can afford to lose).

RTO – this is the time you have to recover the environment back to the RPO.

Choose your method of backup

When if actually comes to backing up Active Directory, technical insight is needed to understand the scenarios that are being protect against.  Ensure that each scenario is catered for so that Active Directory can be recovered.

Domain/Forest Recovery.

In a worst case scenario it would mean restoring a single domain controller from backup and then rebuilding all the existing domain controllers to be domain controllers to this restored domain.

This could be a logistical nightmare to perform and orchestrate.

Object Recovery

This would usually mean restoring a domain controller from backup and then marking the object(s) that are to be recovered as authoritative.

Active Directory Recycle Bin.

The Active Directory Recycle Bin provides a certain degree of insurance in protecting Active Directory, but it will only enable the recovery of deleted items and not for example the recovery of modified users or groups. All domain controllers must be running at a minimum Windows Server 2008 R2 and the forest mode is Windows Server 2008 R2.


All of the well-known backup providers support the backing up of Active Directory, a key component of backing up the AD is that it is not only the Operating System that needs to be backed up, but the entire system state, which includes all the underlying  components of the Operating System and Active Directory.

Quest Recovery Manager for Active Directory – Forest Edition.

The only tool I have found on the market that provides Active Directory Disaster Recovery from a single pane of glass, it enables recovery from a single attribute to a full forest recovery.

Recovery Manager for Active Directory

Test your processes

Whatever process or method you take to back up your Active Directory, ensure that you are confident and able to recovery your Active Directory not only in the time required, but also physically able to do so.

As I review and update my old consulting notes I have decided to publishing them. These are by no means definitive and are intended as an ‘aide memoire’ to enable discussion.
Please feel free to comment.


Microsoft have stated for numerous years that anyone with Kerberos authentication issues often due to users being in multiple groups and commonly known as Token Bloat should increase the MaxTokenSize to 65535 bytes.

Whilst reading Understand and Troubleshoot Dynamic Access Control in Windows Server 2012 guide, I read that

“Previous versions of Windows had a default maximize token size of 12k.  However, this value remained too low for many environments and required reconfiguring each computer in the enterprise.  Windows Server 2012 and Windows 8 increase the default maximum token size to 48k.  This new value is the maximum viable size for SSPI tokens in Windows and may require additional settings changes for applications to support. For example, HTTP settings are required for SSPI tokens over 12K.”

But this article How to use Group Policy to add the MaxTokenSize registry entry to multiple computers also stated the 48K maximum and with a similar reasoning.

“The maximum allowed value of MaxTokenSize is 65535 bytes. However, because of HTTP’s base64 encoding of authentication context tokens, we do not recommend that you set the maxTokenSize registry entry to a value larger than 48000 bytes. Starting with Windows Server 2012, the default value of the MaxTokenSize registry entry is 48000 bytes”.

This lead me to do a little further research as Microsoft stated in the article Active Directory Maximum Limits – Scalability that the “maximum recommended size for a Kerberos ticket is 65,535 bytes”


Getting nowhere fast, I had an email exchange with the Active Directory Documentation team, it was confirmed that this value should now be set to 48K

The Active Directory Maximum Limits – Scalability website should be updated soon (approx. 09/05/2013) to confirm this.

The question now to ask though is – I have set the MaxTokenSIze to 65535 bytes, should I now change it to 48000 bytes?

So I asked the question:-

“What happens to people who have set the key to 65535? Should they test and change it to 48000 now?  Will Windows Server 2012 break? Will things fail as a result of having it set to the maximum?”

The response:-

Kerberos itself doesn’t really understand the concept of a token size because what it transports is opaque to the protocol. 

Applications, however, are different and can implement their own constraints such as buffer size.  Applications ask SSPI (Kerberos) for the size of the authorization buffer of the authenticating user.  If the size reported back is greater than the buffer allocated by the application, authentication fails.  The size reported back is the actual size not the maximum size.  Therefore, with MaxToken set to 65k and authorization data amounting to 12k; Windows will only report back 12k.  MaxTokenSize simply limits the maximum value the SSPI can return to an application.  Prior to Windows 8/2012 , most environments would set MaxTokenSize to the maximum because it was nearly impossible to determine a user’s true token size.  Therefore, if you set it to the max, and still had an authentication problem it was not because of MaxTokenSize ( at which point engineers would instruct customers to return the setting to the prior value).

With MaxTokenSize defaulting to the max Authentication buffer size for IIS; there shouldn’t be a authentication  problem resulting from token size.  Http caps out at 48k.  Making it higher won’t fix the authentication issue. So it there is no gain people nothing by increasing it.

While the setting in the documentation should mostly be harmless; we should suggest 48k as the ideal setting for MaxTokenSize and point to the Group Policy setting in Windows Server 2012/Windows 8 as the means which to modify it.

and now we know.

This guide follows on from the excellent Windows Server 2008 and 2008 R2 Performance Tuning Guidelines and describes important tuning parameters and settings that you can adjust to improve the performance and energy efficiency of the Windows Server 2012 operating system. It describes each setting and its potential effect to help you make an informed decision about its relevance to your system, workload, and performance goals.

The guide is for information technology (IT) professionals and system administrators who need to tune the performance of a server that is running Windows Server 2012.

Included in this white paper:

  • Choosing and Tuning Server Hardware
  • Performance Tuning for the Networking Subsystem
  • Performance Tools for Network Workloads
  • Performance Tuning for the Storage Subsystem
  • Performance Tuning for Web Servers
  • Performance Tuning for File Servers
  • Performance Tuning for a File Server Workload (FSCT)
  • Performance Counters for SMB 3.0
  • Performance Tuning for File Server Workload (SPECsfs2008)
  • Performance Tuning for Active Directory Servers
  • Performance Tuning for Remote Desktop Session Host (Formerly Terminal Server)
  • Performance Tuning for Remote Desktop Virtualization Host
  • Performance Tuning for Remote Desktop Gateway
  • Performance Tuning Remote Desktop Services Workload for Knowledge Workers
  • Performance Tuning for Virtualization Servers
  • Performance Tuning for SAP Sales and Distribution
  • Performance Tuning for OLTP Workloads

Performance Tuning Guidelines for Windows Server 2012

I have previously written about this, but feel it’s worthy of another mention.  Microsoft have hidden away on their WHDC (Windows Hardware Developer Central) website, an excellent document on Performance Tuning Guidelines for Windows Server 2008 R2.  It is worthy of a read as it details lots of changes in functionality that can affect performance.

The paper was last updated on the May 16th 2011 and details:

Choosing and Tuning Server Hardware
Performance Tuning for the Networking Subsystem
Performance Tuning for the Storage Subsystem
Performance Tuning for Web Servers
Performance Tuning for File Servers
Performance Tuning for Active Directory Servers
Performance Tuning for Remote Desktop Session Host (formerly Terminal Server)Performance Tuning for Remote Desktop Gateway
Performance Tuning for Virtualization Servers
Performance Tuning for File Server Workload (NetBench)
Performance Tuning for File Server Workload (SPECsfs2008)
Performance Tuning for Network Workload (NTttcp)
Performance Tuning for Remote Desktop Services Knowledge Worker Workload
Performance Tuning for SAP Sales and Distribution Two-Tier Workload
Performance Tuning for TCP-E Workload

October 2012 Update: 

Updated Server Core Installation Option, Correct Memory Sizing for Child Partitions, and Correct Memory Sizing for Root Partition.

September 2012 Update:

Further updates to the Performance Tuning guidance for the TPC-E Workload section

May 2011 Update:

“Performance Tuning for Web Servers” – Updated guidance to reflect that Http.sys manages connections automatically.

“Performance Tuning for File Servers” – Fixed typos in NFS Server tuning parameter registry keys.

“Performance Tuning for Virtualization Servers” – Added information about Dynamic Memory tuning.

“Performance Tuning for TPC-E Workload” – Clarified tuning guidance.

“Resources” – Updated references.

October 15th Update:

Throughout the paper – Clarified some explanations; clarified energy consumption vs. power consumption.

“Interrupt Affinity” – Added recommendation to use device-specific mechanism for binding interrupts, if supported by the driver model.

“Network-Related Performance Counters” – Added IPv6 and TCPv6.

“Performance Tuning for the Storage Subsystem” – Various minor updates throughout.

“Performance Tuning for File Servers” –Added guidance for NtfsDisableLastAccessUpdate; added “Tuning Parameters for NFS Server”, “File Server Tuning Example”, and “File Client Tuning Example”.

“Performance Tuning for Remote Desktop Session Host” – Added references to two new white papers on capacity planning.

“Monitoring and Data Collection” (multiple sections) – Updated the list of counters to monitor.

“Performance Tuning for File Server Workload (SPECsfs2008)” – New section.

“Performance Tuning for SAP Sales and Distribution Two-Tier Workload” – Substantial updates to the whole section.

“Performance Tuning for TPC-E Workload” – New section.

“Resources” – A few additions and updates.


Microsoft have published an excellent document on Single-Label-Domains in Active Directory Domain Services (AD DS) – Considerations, Migration, and Co-existence. It is well worth a read, even if you are not impacted by this issue.

Management Summary

An Active Directory domain name that contains one or more labels separated by a dot is referred to as a fully qualified domain name with two or more names and it will be referred as FQDN in this document. In contrast there is the concept of single-label domain (SLD), which refers to Active Directory domain names with only one label.

Given that SLD is not a commonly deployed configuration and that many Microsoft and third-party applications have not been tested under an SLD configuration, Microsoft recommends FQDN Active Directory deployments. For companies who have deployed SLD, they should transition to an FQDN Active Directory deployment. This will ensure that they get the most value out of their deployed applications.

For companies that will be evaluating transition to FQDN from SLD configurations, this document describes the options and considerations that they will need to take into account. In particular it describes Domain Migration and Domain Rename operations and explains the different considerations of these two options, so that companies can build a transition plan that makes sense to them.

Long-term, the goal of Microsoft is to have customer infrastructures using common, tested configurations to minimize costs and effort to administrate the Active Directory (AD) and DNS environment. The use of multi-label names is Microsoft’s recommended naming configuration.

Organizations that have SLD configurations should begin by analyzing their current environment to find out the best mitigation option.

Domain rename operations might be feasible in certain scenarios, mainly for smaller organizations or those that can tolerate some outage while removing and reinstalling applications that are incompatible with domain rename.

The migration into a non-SLD forest and domain structure should be well aligned with the product lifecycle and the future IT infrastructure roadmap of the organization.

The transition from a single label to a fully qualified Active Directory domain namespace puts your clients, servers, domain controllers, the operating systems and applications in a namespace configuration that can deliver the following benefits:

  • Provides the broadest application support, including the ability to deploy applications on day 1 after release without fear that support will be deprecated in a future release, will be deferred until a future release, or will never support forests configured with SLDs, possibly even blocking installation in SLDs.
  • Receives the highest number of test passes by Microsoft and third-party application developers
  • Requires the least additional configuration to register and resolve DNS names of interest
  • Delivers the lowest total cost of ownership (TCO) by reducing complex configurations and by consolidating forest and domain structures
  • Enables enhanced security capabilities of new versions of AD DS
  • Aligns the namespace assigned to your forest with same type of namespace assigned to the top thousands of domains deployed and operated by other customers over the last decade or more
  • Receive Microsoft cloud support, because only domains with fully qualified DNS names are supported by Microsoft cloud services such as BPOS and Office 365

Download: Single-Label-Domains in Active Directory Domain Services (AD DS) – Considerations, Migration, and Co-existence