Whenever people talk about “migrating to the latest version of Windows”, I always like to clarify whether they are talking about moving their application servers to the latest version, and/or their Active Director to the latest version as there’s a huge difference. To move from say Windows 2003 as a file server to Windows 2008 R2 as a fileserver, that’s just a shift of an operating system. Organizations frequently upgrade their operating system when they install a new application, so they may have had Windows Server 2003 as their base operating system on their Exchange 2003 servers, and as the organization migrates to Exchange 2010, they install Windows 2008 R2 as the base operating system that E2010 will run on.
Upgrading the Active Directory is something that organizations don’t do as frequently as it does require the upgrading of the operating system of ALL of the organization’s domain controllers, which for large enterprises could take weeks to get around to all of the global catalog servers and domain controllers in the organization. And there’s that fear of “biting the bullet” and making the shift to a new version of AD as the whole “schema update” thing can be a scarey concept for many. A lot of that fear was instilled in us back when we went from Windows NT4 to Active Directory in the early days where the whole “you don’t want to have to update your schema too often” was mentioned early on, however in reality, organizations do update their schema sometimes in the middle fo the day without really thinking about it. As an example, any organization upgrading to Exchange 2007 Service Pack 2 actually perform a schema update, something that is in E2007 SP2 to update the schema to support the extensions needed for Exchange 2010. Or organizations that properly implement System Center Configuration Manager 2007 update their schema to support the tighter integration of SCCM into Active Directory. And the biggest challenge with updating the schema as part of updating to the latest version of Active Directory is that it happens all at once, you can’t “stage” the update. Once you update the schema, it happens immediately and there’s no simple “undo” button…
However, with a little due diligence of checking vendor support for Active Directory, it’s a relatively simple upgrade. The key we have found is that AD updates rarely if never impact applications unless the application itself actually updates the schema. So if you have a Web server, fileserver, print server, terminal server, or the like that does NOT update the schema when installed, then those apps (never) have an impact when updating a version of Active Directory (I put “never” in parenthesis because I’ve NEVER seen the problem in the past, but always hate to say “never” as testing is critical to make sure things work as planned). The apps that are impacted by AD updates are applications that require a schema update to be installed like Exchange, Distributed File System (DFS), System Center Configuration Mgr, Office Communications Server 2007, Cisco Unity voicemail, etc.
When performing an AD Update, backing up one of the global catalog servers helps to protect AD to have a “rollback” option. An AD rollback is basically recovering AD from a backup or snapshot and bringing AD back to where it was last working. Doing an AD rollback is beyond the scope of this article, but effectively it requires turning off ALL copies of Active Directory and restoring or re-inserting an unaffected copy of AD, reattaching workstations / servers, and bringing AD back to the state it was before the failure.
As for upgrading to Active Directroy 2008 R2, as I mentioned in earlier posts, no one really “has” to migrate to AD/2008 or AD/2008 R2 for any of the current products, so things like Exchange 2010, SharePoint 2010, etc do NOT require AD/2008 (or 2008 R2). We have a LOT of customers who are happily running AD/2003 in Native Mode with all of the latest and greatest products running. However, for those who want enhancements in AD, the biggies in Active Directory 2008 R2 are:
· The Recycle Bin (effectively allows you to simply recover deleted objects in AD, so if you fat finger delete a user object or accidentally overwrite an AD group, you can simply go to the recycle bin and undelete stuff…).
· Offline Domain Join which allows you to pre-stage create a computer account in AD, dump an XML file and then when you install Windows 7 on the computer you can run a DJoin command on the Windows 7 and “join” the domain on that Win7 computer without the Win7 computer even being attached to the network! That way you can build systems in the lab and “join them” to AD without actually / physically connecting the computers to AD.
· Something that I’m still excited about that’s in AD/2008 is Fine Grain Password Policies. In AD/2003 you could only have 1 password policy per domain (upper case, complex password, change every 30-days, etc had to be the SAME for everyone in the domain). With Fine Grain Passwords added to AD/2008 (and carried over to AD/2008 R2) you can now set password policies “per group” so you can have folks in HR or Accounting change their passwords every 30-days to please the regulators, and field support and sales people can change their passwords say ever 90-days or something. All done by groups, really slick!!!
A few technical tasks pulll from my book "Windows Server 2008 R2 Unleashed" that I cut/pasted here that relate to the latest version of Active Directory:
Restoring Deleted AD DS Objects Using the Active Directory Recyle Bin
One of the most significant additions to Windows Server 2008 R2’s implementation of AD DS is the Active Directory Recycle Bin. A Windows Server 2008 R2 Active Directory forest and domain now allows for the recovery of deleted OUs, users, groups, or other AD objects. There are a few prerequisites that must be satisfied, however, before the AD Recycle Bin can be enabled:
The AD DS forest and domain must be in Windows Server 2008 R2 functional level.
When restoring objects, the OU in which they previously existed must first be restored. If the object resided in a nested OU structure, the top-level OU must first be restored, followed by the next highest child OU, and so on.
Membership in the Enterprise Administrators group is required to enable the AD Recycle Bin.
The process of enabling the AD Recycle Bin is nonreversible.
Enabling the AD Recycle Bin
To enable the Active Directory Recycle Bin, perform the following steps:
1. Click Start, All Programs, Administrative Tools. Right-click on Active Directory Module for Windows PowerShell and then click Run As Administrator.
2. From the PowerShell prompt, type the following command:
"Enable-ADOptionalFeature –Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=companyabc,DC=com' –Scope ForestOrConfigurationSet –Target 'companyabc.com'"
Replace companyabc.com and DC=companyabc,DC=com with the appropriate name of the domain where the AD Recycle Bin will be enabled.
3. When prompted, type Y to confirm and press Enter.
4. To validate that the Recycle Bin is enabled, go to the CN=Partitions container, using an editor such as ADSIEdit. In the details pane, find the msDSEnabledFeature attribute, and confirm that the value includes the Recycle Bin target domain name that you typed in step 2.
Recovering Deleted Items Using the AD Recycle Bin
Deleted objects can be restored using the LDP.exe utility, or they can be recovered using Windows PowerShell. PowerShell offers a much more straightforward approach to recovery of deleted items, and is recommended in most cases.
To recover a deleted object, use the Get-ADObject cmdlet from the Active Directory Module for Windows PowerShell, being sure to open the module using the Run As Administrator option. Get-ADObject can be used to find objects, which can then be recovered using the Restore-ADObject cmdlet. For example, the following syntax recovers a deleted user account for user Zachary Sefanov:
Get-ADObject –Filter {displayName –eq "Zachary Sefanov"} –IncludeDeletedObjects | Restore-ADObject
For more information about these cmdlets, type Get-Help Get-AdObject of Get-Help Restore-ADObject from PowerShell.
Restarting AD DS on a Domain Controller
Windows Server 2008 originally introduced new capabilities to start or stop directory services running on a domain controller without having to shut it down.
This allows administrators to perform maintenance or recovery on the Active Directory database without having to reboot into Directory Services Restore Mode.
In addition to allowing for maintenance and recovery, turning off the domain controller functionality on an AD DC essentially turns that domain controller into a member server, allowing for a server to be quickly brought out of DC mode if necessary. Microsoft has also removed the need for local Administrators on the DC to have Domain Admin rights as well, which improves overall security in places where administration of the DC server is required, but full Domain Admin rights are not needed.
To take a Windows Server 2008 R2 DC offline, perform the following steps:
1. Open up the Services MMC (Start, All Programs, Administrative Tools, Services).
2. From the Services MMC, select the Active Directory Domain Services service. Right-click it and choose Stop.
3. When prompted that stopping AD DS will stop other associated services such as DNS, DFS, Kerberos, and Intersite Messaging, choose Yes to continue.
4. To restart AD DS, right-click the AD DS service and choose Start. Start the Intersite Messaging Service and Kerberos Key Distribution Center service as well.
Implementing Multiple Password Policies per Domain
Another Windows Server 2008 addition to AD DS is the ability to implement granular password policies across a single domain. Previously, this was only an option with third-party password change utilities installed on the domain controllers in a forest. With Windows Server 2008 or Windows Server 2008 R2, administrators can define which users have more complex password policies, and which will be able to use more lenient policies.
There are a few key points to this technology that must be understood before implementing it. These points are listed as follows:
Domain mode must be set to Windows Server 2008 or Windows Server 2008 R2 level, which means that all DCs in the domain must be running Windows Server 2008 R2 or RTM.
Fine-grained password policies always win over a domain password policy.
Password policies can be applied to groups, but they must be global security groups.
Fine-grained password policies applied to a user always win over settings applied to a group.
The Password Settings Objects (PSOs) are stored in the Password Settings Container in AD (that is, CN=Password Settings Container,CN=System,DC=companyabc,DC=com).
Only one set of password policies can apply to a user. If multiple password policies are applied, the policy with the lower number precedence wins.
To create a custom password policy for a specific user, a Password Settings Object (PSO) must be created using the ADSIEdit tool, which is used for low-level changes to AD DS or AD LDS directory objects and attributes.
CAUTION
ADSIEdit is a very powerful, low-level directory editor, and great care should be taken when using it. Be extremely cautious using the editor, especially when deleting objects, as ADSIEdit could easily delete entire portions of an AD tree with a single keystroke if care is not taken.
The version of ADSIEdit included with Windows Server 2008 RTM/R2 provides for a crude wizard that allows for PSOs to be created. The wizard automates the creation of a PSO, and allows for specific attributes to be set on the PSO that are related to password policies. The attributes that are prompted for creation by the wizard. All attributes must be entered in the proper format for a PSO to be created. Note that only the attribute msDSPSOAppliesTo is not prompted by the wizard, and must be entered in manually.