First published on TechNet on Sep 03, 2012
Greg Jaworski here again to discuss introducing the first Windows Server 2012 Domain Controller. We will discuss things such as extending the schema, enhancements to the Domain Controller promotion process (it is no longer called dcpromo), and things you should be doing to ensure a smooth upgrade and minimal issues. This will be a two part blog post. In the first part we will cover the GUI way of introducing the first Windows Server 2012 Domain Controller. In the second post we will cover the PowerShell way of doing this and also how you can take a look at your environment before introducing that first Windows Server 2012 Domain Controller.
Premier Field Engineering has significant experience in the area of AD upgrades. Many times we are onsite during various parts of the upgrade process. We also have discussions about upgrades during Active Directory Risk Assessments (ADRAP) and have an entire offering called the Active Directory Upgrade Assessment (ADUA) to assist with the upgrade process. We understand the concerns of upgrades. Many managers and IT people do not like the words irreversible, forest recovery, and no back-out plan. People also tend to not like mission critical applications breaking.
Using the GUI
The first thing you need to do of course is install Windows Server 2012. There are several new installation options. Also while we recommend Server Core you can now move between core and full with just a reboot. We also have the new Minimal Server Interface which will give you core GUI components like Server Manager, but no Internet Explorer or Windows Media Player. So if you would rather get started with full and then move to Server Core or Minimal Server Interface especially on that first Domain Controller you can now do that.
Server Manager looks different however. For the purposes of keeping this blog post somewhat manageable I will not be showing all screen shots. Please see our previous post on Server Manager for more detail on the enhancements there.
Add the Active Directory Domain Services Role. If you run dcpromo.exe you will get a message pointing you to go to Server Manager.
|
You will the choose Active Directory Domain Services. You can also choose DNS Server at this point as well. If you don’t choose this and check the DNS box as in the past we will install the DNS role as part of that process.
|
|
 |
After installation completes you will be prompted to make the server a Domain Controller.
Just like in Windows Server 2008 R2 just installing the role simply copies the bits in the proper location it does not make the machine a Domain Controller. At this point if you click the link you will then start the DC promotion wizard. If you don’t for whatever reason you will be able to do this from Server Manager later.
Once you click that link the Active Directory Domain Services Configuration Wizard will launch.
If there is an issue with the environment that will prevent you from introducing the DC you will get an error message. Instead of this happening at the end of the wizard you will be stopped to address this before you can continue. You will also notice that this message is “inline” so that I can continue on. This is an error message however so we need to address this. If we click show more we will get the standard dialog box with more detail on the error message.
As you can see by the below error message Windows Server 2012 does not support the Windows 2000 FFL. You will need to raise the FFL to Windows Server 2003 or higher to introduce the first Domain Controller. You will not be able to continue on until you address this. For the purposes of this blog I raised the FFL to Windows Server 2003 and continued on.
Now I received another message however this is only a warning and I can continue. In this case the warning is that I can’t introduce an RODC at this point since we did not detect any Windows Server 2008 or higher DCs in the environment. Again we can click on Show more to get additional details.
Now we receive another warning about a DNS delegation.
This message is stating that we can’t update your DNS infrastructure. This might be because you are using a second level domain (ex. contoso.com) and we can’t update the top level domain, you are using non Microsoft DNS, or the account you are using doesn’t have access to do this. So you may need to go back and either create the DNS delegation or update an existing DNS delegation.
We can now choose to Install from Media and we can also choose if we want to do initial replication from a specific DC or allow Windows to pick the DC. This process is site aware and will pick a DC in that site if one is available.
We can choose paths for our database, logs, and SYSVOL. Our guidance has not changed here and like any database we recommend splitting logs and the database on different spindles. You can choose the More about Active Directory paths for additional information.
As you can see in the below screenshot if you have not already prepared the forest/domain the Domain Controller promotion process will do this for you. For those of you who prefer that this not be one integrated step you can still run adprep. We will not be covering this in this post since it has been documented numerous times over the years. There is one notable change however. Adprep no longer needs to be run from a FSMO holder. Adprep is still located on the Windows media if you plan on running it from one of the existing DCs in the environment.
You will get the typical summary page of your selections and then new in Windows Server 2012 we will do a Prerequisites Check. You can also export all of your selections to a PowerShell script.
In Windows Server 2008 R2 you were able to export this to a dcpromo unattend file. In Windows Server 2012 this will be a PowerShell script. As was the case in Windows Server 2008 R2 this script will be specific to what you performed. So in this case this will be adding a Domain Controller to an existing domain which is the most common scenario. If you are creating a new domain or forest then you will have to modify or create a different script. We will use this script when we promote a Domain Controller with PowerShell in part 2 of this blog post.
You can see that we have performed a prerequisites check. This is a new feature in Windows Server 2012 that will make you aware of potential issues or concerns before you complete making the server a Domain Controller. However in many cases this could be too late in the process. If you have been planning the upgrade for months and aren’t aware of these issues then it could make you go back to the planning phase delaying the upgrade by several months. These checks can also be run with Windows PowerShell. We will discuss this in part 2 of this blog post.
Here we are extending the schema. So this is the equivalent of adprep /forestprep.
Now we are running adprep /domainprep.
We have extended the schema and prepared the domain. At the end of the process we are again made aware of potential issues that we may need to address since we now have a new Operating System that has stricter security requirements. The server will then reboot and just like in previous versions of Windows we will now have a Domain Controller and can do whatever checks your organization deems necessary to ensure that everything is running smoothly. We will only do what is exactly necessary so since we did not introduce an RODC the forest was not prepared for Read Only Domain Controllers.
After introduction of the first Windows Server 2012 Domain Controller
So what should you do now that the server has rebooted and is a DC. Well the prerequisites check only really checks things that will specifically impact the introduction of a DC. So the next thing you should do is run the Best Practices Analyzer (BPA) for Active Directory.
Once in Server Manager and you have chosen the AD DS role scroll down and you will see a section called Best Practices Analyzer. You can then go to Tasks and choose to run the BPA scan. This BPA scan can also be run from Windows PowerShell.
The initial filter will only show Warnings and Errors. You can also look at Informational issues as well as issues that Passed.
While many of these are general best practices (time configuration, virtualization…) One you might notice that could be important though is this. This one could break an application or service.
In Windows Server 2008 R2 we disabled DES encryption types for Kerberos by default. This setting is on a DC by DC basis so in that case only Windows Server 2008 R2 and Windows Server 2012 DCs would not allow DES encryption types. So you really need to check in two places for issues that could affect services and other applications that rely on Active Directory. Unfortunately you can’t run the BPA unless the machine is already a Domain Controller so unlike the PowerShell cmdlets earlier in the blog you can’t run this ahead of time. This is why you should have a lab that looks as close to production as possible. This will allow you to flush out these issues prior to introducing new DCs in production.
What don’t we check
The key thing here is that if you are moving from Windows Server 2003 all the way to Windows Server 2012 you need to be aware of the changes and potential issues from Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. If you are moving from Windows Server 2008 R2 then there are less things to worry about of course. Though if you aren’t aware of some of these issues then you will need to address those. Here is an example of a few things the BPA and Prerequisites Checker don’t check. We plan to have a follow up post to provide more detail on this.
· We don’t inventory existing application or services on the DC. If you are using existing hardware and not doing an in place upgrade you need to document what else is on that DC (DHCP, DNS, WINS, CA, IAS, Terminal Services Licensing)
· Since Windows Server 2008 we no longer store the Lan Manager hash (LMHash). If you have old applications or gasp really old versions of Windows you need to address this.
· We don’t check other Microsoft applications or 3 rd party applications. An example from Windows Server 2008 is Live Communications Server 2005 and Office Communications Server 2007. These products had an issue when the schema was extended for Windows Server 2008.
958980 Office Communications Server or Live Communications Server 2005 does not work correctly after you upgrade a domain controller to Windows Server 2008
http://support.microsoft.com/kb/958980/EN-US
· We provide you the warning about NT4Crypto, but we don’t actually look for NT 4.0 machines or trusts. Third party NAS devices, and older implementations of Samba could also be affected.
For Windows Server 2008 and Windows Server 2008 R2 we provided a TechNet article and a fellow PFE Glenn LeCheminant had a running blog post.
http://technet.microsoft.com/en-us/library/ee522994(WS.10).aspx
We plan on doing something similar here.
Summary
So to wrap up part one of this blog post we have covered what it takes to introduce the first Windows Server 2012 Domain Controller using the GUI in your environment. We have also covered using the Best Practices Analyzer after the first Windows Server 2012 Domain Controller is introduced. We then provided a brief summary of some items that are not checked. While we have improved the Domain Controller promotion process and added additional functionality to make you aware of issues you may run into this does not replace proper planning. At the same time we are trying to reduce the “fear” that many have of these tasks. Upgrading your Active Directory provides significant benefits and new features and also keeps you in a supported state. If your Active Directory is still all Windows Server 2003 the time is now to start planning your upgrade. In part two of this blog post we will cover doing this same task using Windows PowerShell. We will also cover how you can do the prerequisite checks ahead of time so that you are well prepared to introduce that first DC and to reduce or remove any “surprises”.
Thanks,
Greg