IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Be sure to read the entire series on the AD Upgrade
- Upgrading or Migrating Active Directory to Windows Server 2012 – Build Your Roadmap Now
- Upgrade Active Directory to Windows Server 2012 – Phase 1: Assessment
- Upgrade Active Directory to Windows Server 2012 – Phase 2: Build Your Plan
Here’s the next step in our AD Upgrade Series – building your plan. Below is your template, just fill in the blanks. Don’t forget that the assessment data you’ve already collected will fill in a lot of the blanks.
Active Directory Health
The health of the Active Directory environment is critical to the overall success of the upgrade. Ideally, you should be monitoring the health of AD real-time 24x7x365. Periodically you may wish to do a more thorough analysis of the health of the environment with an Active Directory Risk Assessment.
⎕ Check health now, and remediate any serious health issues before proceeding.
o AD Replication
o SYSVOL Replication
o DC Performance (Memory, CPU, Disk)
o Time Synchronization
⎕ Keep checking health as you proceed to make sure you don’t accidently break something.
Proactively Addressing Known Issues
Install these recommended hotfixes for AD-specific issues, on new and existing DCs to proactively avoid known issues. These may, or may not, affect you; however its good practice to be proactive and avoid issues.
On your Windows Server 2003 DCs install these hotfixes:
On your Windows Server 2008/2008R2 DCs install these hotfixes:
On your Windows Server 2012 Server DCs install these hotfixes:
⎕ Be aware, if you host Virtual DCs on Server 2012 Hyper-V, you’ll definitely want to Install the July 2013 Update Rollup on your Hyper-V hosts.
Active Directory Design and Architecture
Upgrading the Active Directory infrastructure is an ideal time for addressing any architectural changes to the forest. This could include changes to sites, site-links, the number of domain controllers in the forest, the sizing of domain controllers or the placement of domain controllers. Prior to upgrading the Active Directory the forest architecture should be reviewed, the desired end-state should be specified and upgrade plans should include provisions to reach the desired state.
⎕ Look at your current AD Architecture. Print out AD Topology Diagram.
⎕ Document your future (desired) Architecture including any changes to:
o Domain controller placement
o GC placement
o DNS Server placement
o DNS configuration
Domain Controller Build
Once the architecture/design has been finalized, the build for new domain controllers should be determined. This should include the following considerations:
⎕ Do you have a base OS build for Server 2012?
⎕ Amount of memory/CPU/disk is required to meet the performance profile of the domain controller. Look here for a detailed approach to capacity planning.
⎕ Will virtual domain controllers will be deployed? Be sure to review best practices.
⎕ Will RODCs will be deployed? Understand the differences between RODCs and RWDCs.
⎕ Do you have non-default configurations that need to be carried forward? How will you do so, configuration in the build? GPOs?
The first step towards compatibility testing is generating a list of applications that depend upon Active Directory. While the information may never be perfect, it should include at least those applications upon which the business depends. For each of the dependents, determine if the applications/client is compatible with the new OS version on the new Domain Controllers. This could be as simple as contacting the application vendor for a support statement. For other applications, this may require testing in a lab environment.
For Active Directory dependents, make note if the application/client automatically discovers domain controllers, or if it contains static configuration on domain controllers (using hostnames or IP addresses). For those dependents that are statically configured to find domain controllers, re-configuration may be required when new domain controllers are deployed and old domain controllers are retired.
⎕ List of Known AD Dependents. For Each:
o Is it compatible with New Version of AD/New OS of Domain Controllers?
o Can/will you test?
o How does the dependent discover Domain Controllers? If manually configured make a note so you can manually change it when new DCs are deployed.
Address Changes/New OS default configurations
With respect to any configuration changes (whether they are introduced by you or the new OS defaults), consideration should be made to implementing these changes prior to the introduction of new domain controllers. For example, configure your existing domain controllers with these new configurations to ensure the changes will not negatively impact the environment. This will allow the specific changes and pace of changes to be easily controlled. For specifics of these changes, see the table of OS changes in our previous blog.
Consider Implementing These Configuration Changes (if necessary) on Existing DCs Before the Upgrade
⎕ Disable the Storage of LMHash
⎕ Turn on SMB signing
⎕ Disable the Computer Browser Service
⎕ Increment LMCompatibilityLevel to (at least) 3.
⎕ Enable DFS Site-Costed Referrals
⎕ Remove NullSessionShares and trim NullSessionPipes
⎕ Enable EDNS0
⎕ Limit NSPI Connections (requires 2008 DCs or higher)
⎕ Disable NT4Crypto (requires 2008 DCs, or higher)
⎕ Disable DES encryption (requires 2008 DCs, or higher)
⎕ Adopt new RPC dynamic port Range
Database Upgrade (ADPREP)
One of the first milestones in the upgrade process is upgrading the database using what’s known as ADPREP. This is required before any new DCs (with the new OS version) are deployed. The ADPREP process historically was a stand-alone executable, but has recently been integrated into the domain controller promotion process (as of Windows Server 2012). Now you can either run ADPREP by itself, or as part of promoting the first DC. Regardless of the option you choose, upgrading the database is irreversible. Thus, it is strongly recommended to test the ADPREP process and to ensure there is a documented and tested Active Directory forest-recovery plan in place. This will ensure a smooth production AD database upgrade.
⎕ Do you have a Forest Recovery Plan?
⎕ Is it (recently) tested?
⎕ Have you tested ADREP/Database Upgrade in you lab and/or recovery environment.
Deploying New Domain Controllers
The next milestone in the upgrade process, is the deployment of domain controllers running the new operating system. Prior to deploying the first new domain controller, considerations must be made to determine where, how many and how quickly the new domain controllers will be deployed. Also, administrators must be prepared to manage the new operating system. Additionally, decisions must be made when applications/clients with static configurations will be (re)targeted to the new domain controller(s). Monitoring should be in place to discover any problems with health or client compatibility. Finally, don’t forget that FSMO roles will need to be moved to the new DCs and forest time synchronization configured to follow the new forest root PDC.
⎕ Decide sequencing for introduction of new DCs.
⎕ When/how will you (re)target applications/clients that statically find DCs?
⎕ When/how will you move the FSMO roles to the new DCs?
⎕ Remember to keep checking health during these changes.
Retiring Domain Controllers
As new domain controllers are deployed, old domain controllers will be retired. To avoid potential issues care must be taken to ensure a smooth transition. This will include, for example, migrating other services that are hosted on existing domain controllers to alternate locations, and re-targeting clients/applications that are manually configured to use specific domain controllers.
⎕ Which applications/services (DHCP,IAS/Radius,etc.) need to be migrated from your existing DCs?
⎕ Do you need to retain IP addresses and/or hostnames? If so, when/how will you move these to the new DCs?
⎕ Remember to keep checking health during these changes.
When/how will Upgrading Domain and Forest Functional Levels
Once all domain controllers in a domain/forest are running a new OS, the domain or forest functional level can be raised. Prior to doing so, the domain/forest recovery plan should be reviewed and re-tested. Once functional levels have been raised, new features may be implemented such as DFSR for SYSVOL replication or the Active Directory Recycle Bin.