Active Directory Recycling Bin
Microsoft expects this feature to have a major effect on disaster recovery planning for AD, the majority of which is focused around accidentally deleted objects. As many of you know, when an object is deleted in Active Directory, it becomes tombstoned so that most of its attributes (such as group memberships) are stripped away. Recovery of these objects has traditionally been very difficult, and while admins can use third-party tools to retrieve the lost attributes, it usually requires a certain amount of downtime and resources.
The AD Recycling Bin in R2, however, is designed to simplify this recovery process and hopefully solve a lot of those issues. It works pretty much like the old familiar desktop recycling bin, in that when an object is deleted in Active Directory, it doesn’t vanish — it’s just moved into the bin as a deleted object. The key here though is that unlike with tombstoned objects, the deleted object retains all the pertinent attributes it had in AD.
For example, say you had an organizational unit that contained a number of other OUs, each of which had say, five users. If you accidentally delete the top level OU, all of the info within goes with it. However, if you simply restore that top level from the Recycling Bin, all of its attributes come back as well.
Now keep in mind that R2 doesn’t do away with the tombstone lifetime altogether. The Recycling Bin is just the first level of protection. All deleted objects are placed in the Recycling Bin initially for 180 days by default, after which they are then placed into a tombstoned state for another 180 days before vanishing completely. Both these time periods can be adjusted as well, which could be of help to those in larger organizations.
Active Directory Administrative Center (ADAC)
Microsoft is basically on the road toward replacing AD Users and Computers with this new feature. It apparently comes in response to feedback from users regarding the three main AD tools – AD Users and Computers, AD Sites and Services and AD Domains and Trust – and how frustrating it can be at times to use each one along with a bunch of command line tools in order to perform more complex tasks.
Basically, the idea behind ADAC is to simplify things by pulling everything into one tool. ADAC is built on PowerShell 2.0 (the whole ‘PowerShell over GUI’ concept that we saw with Exchange 2007). This means that as you perform tasks in ADAC, the tool is actually performing PowerShell commands on the backend for you.
Incidentally, there have been a ton of new PowerShell cmdlets created around Active Directory for R2, geared toward a number of common AD tasks, such as migrating certain AD domains, dumping objects from the directory, etc. This is just the beginning too, as Graham said the company plans to leverage PowerShell even further with the next OS release following R2.
Offline Domain Join
This one is pretty straightforward. Offline Domain Join was created for those who are responsible for deploying desktops, as it allows for offline desktop deployment while staying connected to AD. This is mainly geared toward large environments with several levels of protection, which can make desktop deployment difficult if those security measures result in a lack of connection to Active Directory.
The idea here is that you can pre-stage domain accounts in AD, then export those account properties and import them into your automated desktop deployment process (via Sysprep, for example). When desktops are deployed via these tools, they are then automatically joined to the domain using the offline AD credentials, so the next time they connect to the network, they then become a full member of Active Directory.
Managed Service Accounts
Managed Service Accounts is designed to protect applications from going down due to authentication failures. The main idea is to ensure that those Active Directory accounts that are solely used to authenticate services running on app servers or other member servers don’t accidentally become locked out, disabled, etc.
Basically, admins who feel that the normal built-in accounts that are used for service authentication on most servers don’t provide enough service isolation, this tool is designed for you.
The Managed Service Accounts feature is designed to give administrators the isolation and password management they need, so that they don’t have to worry about apps going down due to authentication failures. According to Graham, it does this by providing password management to those service accounts so that the passwords are changed automatically, with the hopes of not only reducing the amount of instances in which apps go down, but also the time it takes for admins to get them back up and running.
Those are most of the big changes in AD to be aware of with Windows Server 2008 R2. There have also been some changes made to AD Lightweight Directory Services (ADAM in Windows Server 2008), which I hope to post on later this week.
Comments