Hi folks, Ned here again. This week we talk GUI metadata cleanup, your useless manager (attributes), USMT abandonment and weight issues, the meaning of the DFSR nothing state, and the usual “other stuff.”

• Metadata cleanup when moving DCs
• The Manager and ManagedBy attributes
• Overriding USMT duplication when rerouting
• The DFSR uninitialized state
• Blocking most - but not all - folder contents with USMT
• Other stuff

Question

TechNet says if you use DSA.MSC to delete a DCs computer object, the metadata cleanup process is started. Will a metadata cleanup start if you move the DC computer object from the "Domain Controllers" OU to another OU? I was reading this here "...the metadata is automatically cleaned up when a domain controller account is removed from the Domain Controllers organizational unit (OU)." 

Answer

You only trigger the metadata cleanup when the DC computer object is deleted. You can move it to another OU (although we really wish you wouldn’t) and cleanup won’t occur. Here I have a domain with three DCs. I move one, then I force replication between all DCs in the forest, and restart that moved DC.

He’s fine afterwards – still replicating, still in the DC group, not metadata cleaned. Of course, he’s no longer applying the Default Domain Controller policy and is now getting all kinds of weird OU policy, but that’s a different problem!

Question

Do the manager and managedBy attributes in AD do anything, other than for the Exchange global address list info?

Answer

For groups, managedBy is an administrative convenience to designate “group admins”. When set like below, whatever principal listed in managedBy gets permission to update a group’s membership (the actual security is updated on the group’s AD object to allow this).

So when you populate this:

This happens under the covers:

This is done by DSA.MSC, DSAC.EXE, and perhaps other tools; it is not some special function of the DC.

In Win2008 and later managedBy also became the way you delegated local administration on an RODC, allowing branch admins to install patches, manage shares, etc. (http://technet.microsoft.com/en-us/library/cc755310(WS.10).aspx). 

Undocumented Bonus Alert:

On the RODC, this is updating the RepairAdmin registry value within RODCRoles:

Totally Documented Non-Bonus Not-Alert:

You can use NTDSUTIL.EXE LOCAL ROLES to add accounts to other roles and they are stored here based on their well-known RID. See this goo.

ManagedBy is also often used as an inventory marker by companies to denote which business unit run certain computers. It could perhaps be useful in an ADFS/Claims-aware scenario (“everyone who reports to Bob gets to access the team fantasy football league pool”), but I’ve not tried.

I don’t know of any pure AD security usage for the manager attribute; I’ve only seen it used for the GAL and HR apps as a way to build organizational chains, like you mentioned earlier.

Question

The documentation on “Rerouting files and folders” mentions that the XML will migrate the contents of the source folder to the destination folder. What we have observed in our lab is that it also makes a copy of the folder’s contents in the destination folder. For instance, if I have a folder C:\TestFolder with a few files I tell USMT to migrate them to the CSIDL_PERSONAL (i.e. “My Documents”) folder of each user, it makes a copy of the contents into each user’s Documents folder and also migrates the C:\TestFolder folder to destination computer in the same c:\ location. Is this the expected behavior and is there a way to avoid the duplication?

Answer

This is expected, because of migdocs.xml. It is making sure the folder contents on the root of the drive are copied as part of MigXmlHelper.GenerateDocPatterns. To override this, you need additional custom XML that runs in the SYSTEM context and blocks that special folder you are redirecting to all users:

<component type="Documents" context="System">

    <displayName>Exclude folder and override migdocs.xml</displayName>

    <role role="Data">

      <rules>

        <unconditionalExclude>

          <objectSet>

            <pattern type="File"> C:\testfolder\* [*]</pattern>

          </objectSet>

        </unconditionalExclude>

      </rules>

    </role>

  </component>

</migration>

That will result the testfolder contents copying to every user profile Documents folder and not copying to c:\testfolder on the destination.

It’s very rare for anyone to do this, that’s why the behavior isn’t well documented. Mainly because it uses up a ton of additional drive space duplicating all those files. This is what miguser.xml used to do by default, which is why that XML file was deprecated – people kept running out of disk space.

Question

What does the DFSR replicated folder “Uninitialized” state mean? From: http://msdn.microsoft.com/en-us/library/bb540026(v=VS.85).aspx. The others seem self-explanatory or are well documented in that article.

Answer

State 0 (Uninitialized) has no real meaning; it is a state placeholder so that we have some point of reference instead of NULL or blank. It is expected when you first configure a replicated folder that has not yet been detected by DFSR polling due to AD replication latency or timing.

Question

I'm in the process of USMT customization and have run into an issue where I need to block most of a folder’s contents from migrating, but still include one specific file. This is an issue for us because we'd like to use the MigDocs.XML file - our users have a habit of storing data outside of their profiles. This particular case deals with Oracle's tnsnames.ora file located in C:\Oracle\network\admin.To use the MigDocs.XML file and not migrate C:\Oracle\*, I'd have to use an unconditional exclude. But then I wouldn't be able to migrate the tnsnames.ora file. Any suggestions?

Answer

This is tricky because you’re doing the opposite of what USMT was designed for (it wants to granularly exclude and grossly include). I can think of three options:

• [Most recommended] Determine the known files/file types that exist in the oracle folder and specifically unconditionalExclude those with [sna.foo] and [*.bar], leaving only the tnsnames.ora to migrate through “omission of exclusion”. I’d imagine there aren’t too many file types in that folder and that they are fairly predictable. This also has the good side effect of not nuking any non-oracle files someone saved there in a fit of usery’ness.
• [Sort of recommended] Use a batch file to run USMT. That batch file copies the tnsnames.ora file after you run scanstate, and puts it in the store folder. Another batch file that runs loadstate copies it out of the store folder back to that path on the destination computer.
• [Not recommended] You can edit the actual migdocs.xml and add an explicit exclude rule in the MigDocSystem component that excludes c:\Oracle\*[*]. The two rules (implicit include generated by GenerateDocPatterns and your explicit exclude rule) have the same specificity and in that case the exclude should win. This negates the include created by GenerateDocPatterns. Now with a clean slate you can have an explicit include in another component that migrates that inner folder with the tnsnames.ora file. For example:

So even though my oracle folder is like this:

My actual migration store gets only this:

I call this “not recommended” because it is very difficult to version control the included XML files in USMT and you end up with thousands of instances of USMT running dozens of different version of the factory XML files. Eventually, somebody screws one up, but no one knows that the default XML is now tainted. I’ve seen support cases where the customer had been troubleshooting this for weeks before they finally broken down and called us, so because of that, so I still recommend the other two options. If you go this route make sure you carefully track the edited migdocs.xml files and rename them so there is less confusion.

If possible, use some version control software to check XML in and out – there are plenty of free ones out there or you can throw us some cash for TFS if you like what you see in the trial. There also also hosting companies that will run TFS for you, for a monthly per-seat fee, if you just want this for a project like your Windows 7 rollout. It may sound like overkill but trust me – delaying your rollout for a month because some bozo decided to monkey with the xml is not cool. You’re writing migration code, you need to treat it with the same seriousness that you’d give C++.

Naturally, these all work for any folder/file combination. That was an awesome question.

Oh, I just thought of a fourth option: switch to SQL server.

Other Stuff

Are you new to your organization, or new to the IT field? Maybe your annual review could have gone better? Here’s useful advice from Eric Brechner, an MS veteran and Principal Dev Manager; you may have read his book Hard Code. He usually only posts once a month, but each article is phenomenal, even when you disagree with him. Here’s a sample:

The new guy
http://blogs.msdn.com/b/eric_brechner/archive/2010/04/01/the-new-guy.aspx

You're no bargain either
http://blogs.msdn.com/b/eric_brechner/archive/2011/03/01/you-re-no-bargain-either.aspx

I messed up
http://blogs.msdn.com/b/eric_brechner/archive/2010/08/01/i-messed-up.aspx

Individual leadership
http://blogs.msdn.com/b/eric_brechner/archive/2011/01/01/individual-leadership.aspx

Controlling your boss for fun and profit
http://blogs.msdn.com/b/eric_brechner/archive/2005/08/01/august-1-2005-controlling-your-boss-for-fun-and-profit.aspx

Superfan Mark Morowczynski points out that he already pwned the Internet before last week’s tip on using NETSH.EXE for captures, and that I owe him royalties. In lieu of money, I’ll push his blog a bit. When he can be bothered to write, he generates great stuff. Infrequent PFE bloggers are like corrupt politicians – expected, and full of excuses. Oh, and they both claim way too much on their expense reports.

A few months back, some of us moved to a different location in the building for a project. I came to say hi, and I found this on the common area whiteboard:

All done with love, I’m sure. If the Keebler reference doesn’t make sense, go here.

University of Virginia survived their College World Series elimination game last night, so my wife can breathe easy… until tonight, where they play the Gamecocks, who beat them on Tuesday. She’s a Wahoo Cavalier by way of graduate school. I moved to North Carolina in 2000 and found that Southerners take their college sports very seriously. When UNC loses a basketball game, my sister-in-law acts as if someone died.

And yes, I said their. My wife tells me that no matter how long I live here, no matter how assimilated I become, no matter how many grits I eat: I will always be a damyankee. Since everyone in Chicago thinks I’m a redneck now, I have no citizenship and I’m thinking of forming my own country. I’ve already picked out my state bird:

The noble vulture

Have a nice weekend folks.

- Ned “carpetbag full of cookies” Pyle

Hi folks, Sean Wright here for my final post. So, you have AGPM installed, but your Domain Admins continue using GPMC to create, delete, and modify Group Policy. You’ve asked nicely, but that hasn’t had much effect. Now you want to make your point, and prevent your Domain Admins from managing Group Policy the wrong way. You decide to deny Domain Administrators the rights to modify Group Policy Objects (GPOs) through any means save the AGPM console. It may seem like a good idea, but let me explain how your time is better spent elsewhere.

First, let’s cover the concept of a domain administrator. The domain admin is the most trusted and unrestricted user account in the domain. The domain admin can do anything in the domain and can give themselves permissions that make anything possible. The domain admin is the "Domain Overlord" if you will. Go ahead, laugh maniacally now, I’ll wait.

The very notion that you want to deny something to a Domain Admin is a foreign concept. You don’t deny them anything. They deny rights to others. Windows and Active Directory are built upon this fundamental concept, which brings us to our next section.

Why you’re wasting your time:

Active Directory is tailored to Domain Admins being all-powerful. No matter what you do to restrict their rights, they can simply change it back at will. You can make it difficult, which might discourage them… but a determined admin can undo anything you change.

You now have a new admin on the team, and during his troubleshooting “Random Group Policy Problem #5”, they receive an access denied error when managing policy through GPMC. They should be using AGPM, and the fact that they are unaware of this is a whole other issue. Most admins take access denied errors as a bad thing-- after all, they are an admin; so, they may start fixing the environment by changing permissions.

If you contact Microsoft Support for a Group Policy related issue, we will likely return the permissions to defaults before proceeding with troubleshooting. We do not recommend this scenario, because you can't prevent a domain administrator from being an domain administrator, and your efforts can be so easily undone.

If you modify permissions on policy folders within SYSVOL, you’re going to trigger replication for every file and folder that is changed. In large environments with many policies, that can be a significant network traffic surge.

Most importantly, Microsoft has not tested this scenario, so you may introduce unforeseen problems to your environment by attempting it.

What you should do instead:

The advice I give to every customer who force domain admins into AGPM is Education. You can’t prevent a domain admin from doing something if they are determined. If you can’t trust your domain admins to do the right thing, and do it the right way, then they should not be a domain admins. That said, I suggest educating administrators by teaching them about AGPM and its benefits. Explain why they should only use AGPM manage policy, and you will likely see them consciously decide to go the extra mile to do things the correct way.

Recently, I had a customer insist AGPM was incomplete, because it did not have this restrictive functionality built-in. The developers did not intend for AGPM to restrict admins. It was designed to provide benefits that make troubleshooting and administration of policy more manageable.

If you’re still reading, and are determined to try this in spite of my recommendations against it:

Editing existing Group Policy object

During installation, in an effort to make things easier, some customers simply add the AGPM service account to the Domain Administrators group. Since we’re about to prevent domain admins from accessing production GPOs, you’ll want to read over the AGPM Least Privilege scenario and make sure you have successfully implemented this before you proceed.

1. We’ll need to remove any Administrative users or groups from the “Group Policy Creator Owners” group. You can do this through Active Directory Users and Computers.

2. If it’s not already there, make sure you add the AGPM service account to ”Group Policy Creator Owners”

3. Open the Group Policy Management Console (GPMC.msc) and find the Group Policy Objects container. The Delegation tab shows a list of users/groups that have the ability to create new GPOs in the domain. You can try to remove Domain Admins from this location, but alas, it won’t let you.

Note: This is a safety feature, designed to prevent you from accidentally removing all rights to create GPOs.

What you can do, is prevent your domain admins from editing the existing GPOs.

4. Within GPMC, expand the Group Policy Objects container and find the Default Domain Controllers Policy.

5. Select the Default Domain Controllers GPO and go to the Delegation tab.

6. Remove the Domain Administrators and Enterprise Administrators groups from the delegation list.

7. Make sure the list contains SYSTEM with full control, and ENTERPRISE DOMAIN CONTROLLERS and the Authenticated Users entries with Read permissions (at least).

8. Repeat steps 5 through 7 for every GPO currently in your environment.

This makes your existing GPOs resistant (but not immune) to your administrator’s editorial charms.

9. Next, open GPMC with your AGPM Administrator account and go to the AGPM console.

10. Click on the Production Delegation tab and remove Domain Administrators and Enterprise Administrators from this location. This tab within the AGPM console determines the permissions AGPM assigns to controlled GPOs when they are deployed to production using AGPM. Making this change prevents all of the hard work you just did in the section above from going to waste.

Don’t worry that the list isn’t complete. We need to add Authenticated Users and the AGPM service account to production GPOs.

Control Group Policy object links

So far, we’ve removed the domain admin’s ability to edit existing GPOs, but they can still create new GPOs and link new and existing GPOs to OUs. In order to prevent these actions, we need to explicitly deny specific rights related to Group Policy.

1. Open GPMC and click on the domain node that contains the name of your domain.

2. Click Delegation and click Advanced.

3. On the domain’s security dialog box, click Advanced to open the Advanced Security Settings dialog.

4. Click Add button to add a new entry.

5. Type Domain Admins and then click Check Names. Click OK to show the Permission Entry dialog.

6. Click Properties.

7. Select the Deny check box next to the permissions Write gPLink and Write gPOptions.

8. Click OK on all dialogs until you return to GPMC.

9. Check the permissions by right-clicking the node with the name of the domain. Notice the menu items Create a GPO in this domain, and Link it here… ; Link an Existing GPO… ; and Block Inheritance are unavailable. Additionally, the menu items Enforced and Link Enabled are unavailable on existing GPO links.

10. You will need to repeat steps 1-9 for every OU in your domain. This change is also needed for any newly created OUs. It might seem easier to set these deny permissions at the domain level and let inheritance propagate the settings down to existing and new OUs, it doesn’t work. When an OU is created in Active Directory, permissions are explicitly defined at the OU level. When you set an explicit deny permission at the domain level, inheritance applies an implicit deny at the OU level. An explicit deny wins over an explicit allow; however, an explicit allow wins over an implicit deny.

Note: There is also an option to change the default permissions applied to new OUs as they are created. This option modifies the schema, so use caution when modifying any value in the schema. The defaultSecurityDescriptor attribute is in SDDL format, so I recommend you configure one OU with the correct security settings and copy the value. This prevents having to manually set the permissions as new OUs are created in the future.

No new GPOs for You

So far, we removed the domain admin’s right to edit existing GPOs, and their rights to link new GPOs to existing OUs in the domain. Also, we removed their right to edit the GPOptions such as link and enforced states. The last step is to prevent a domain admin from creating new GPOs in the domain’s Group Policy Objects container.

1. Open ADSIEdit.msc. Right-click the ADSI Edit node in the navigation pane and then click Connect to…

2. Configure the Connections Settings dialog similar to the following image. Click OK.

3. In the navigation pane, expand the Default naming context until you find the following container: CN=Policies,CN=System,DC=domain,DC=com.

4. Right-click CN=Policies and then click Properties.Click the Security tab.

5. Click Advanced to open the Advanced Security Settings dialog. Add an entry for Domain Admins,and deny the permission to create or delete groupPolicyContainer objects.

This last step makes Create menu item unavailable within GPMC when creating a new Group Policy Objects. The Delete menu item remains available for GPOs; however, attempting a delete results with an access denied error.

An Imperfect Solution:

Many aspects of this scenario require periodic administrative attention that certainly increases management costs.. In addition, domain admins can undo this partially or in total. This can increases the difficultly that comes with troubleshooting.

Group Policy was designed to be managed by domain administrators. Attempting to hack a solution can cause its fair share of administrative burden (even when it’s working correctly). Why? Because any domain admin can undo the solution with relative ease, making it a monumental waste of time and provides a false sense of security. Since Microsoft does not recommend this scenario, we advise everyone to use AGPM as a beneficial tool and educate your staff. When they are familiar with it, and have it as readily available as GPMC, they will be more likely to do the right thing by using the AGPM to manage GPOs.

And the real solution? Have some consequences when admins choose not to use AGPM. That will straighten people out in a hurry. If your domain admin can't follow simples rules, like use AGPM, the imagine what other dangers lurk behind your back.

Sean "Don't Taz Me Bro" Wright

[Editor’s note: this was Sean’s last post – he left us for greener pastures last week. Good luck man, I hope you can get a chuckle out of your new colleagues with your famous photoshopping – Ned]

Hi folks, Ned here again. This week we talk about 10 reasons not to use list object access dsheuristics, USMT trivia nuggets, poor man’s DFSDIAG, how to get network captures without installing a network capture tool, and some other random goo. Oh yeah, and friggin’ Smurfs.

• The downsides to List Object Access dsheuristics
• USMT differential scanning
• DFSN diagnostic tools for Win2003
• USMT hotfix KB2023591 OS compatibility
• Getting network captures without Netmon or Wireshark, on Win7/R2
• Other stuff

Question

We’re thinking about using List Object Access dsheuristics mode to control people seeing data in Active Directory. Are there any downsides to this?

Answer

There are a few – here are at least ten in no particular order (thanks to PFE Matt Reynolds for some of these, although he may never realize it):

1. This can greatly increase the number of access check calls that are made, and can have a significant negative effect on performance.
2. This will require a huge amount of work and ongoing maintenance. You will need to create and look after – forever - selective “views” for admins, help desks, service accounts, etc.
3. This was designed more for hosted “multi-tenant solutions” that are very specialized.
4. Microsoft applications are not generally tested with this setting.
5. If you can find a third party vendor that tests this, I will have a heart attack and die from shock. If you can then find a vendor that is willing to change their code if you run into problems, I will then rise from the grave and eat my own pants.
6. It’s very difficult to test how well apps are handling this, as it’s designed to “omit data”. That could have all sorts of weird effects on apps expecting to see certain built-in or “always available” objects.
7. Active Directory is a… directory. It’s designed to share info. Specific sensitive attribute data can always be marked confidential and that’s probably really what you want here.
8. Doing this is one of the least useful security measures in a whole litany of things that you probably haven’t implemented – encrypting your LDAP traffic, using IPSEC everywhere, using two-factor smart cards for all user access, encrypting all drives, preventing physical removal of computers. Or making sure your web servers don’t allow ancient SQL injection attacks. Focus!
9. This makes you unique. You don’t want to be unique.
10. Just because you can do something does not mean you should do something. We provide an option to format your hard drive as well.

Strangely, two people asked about this in the past few weeks.

Question

Can USMT perform “incremental” or “differential” scans into a store? We have a lot of data to capture and it may take awhile, especially when going to a remote store. We’d like to do it in phases if possible.

Answer

Sorry, no. USMT completely deletes the destination store contents when you start a scanstate (this is why you have to specify /o if the store already exists). If you perform a hardlink migration though, you are not copying data and it will scan much faster than a classic store.

If you have to use a remote compressed classic store and you’re worried about reliability, run your scanstate to a local store location on the disk, then copy that store folder to a network location afterwards. Make sure you calculate space estimations to ensure you are not going to run out of disk, naturally.

Question

I don’t have any Win2008 servers – so I cannot use DFSDIAG.EXE – but I’d like to report on their DFS Namespace health. Are there other tools?

Answer

File Services Management Pack for System Center Operations Manager 2007
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14307

That will monitor health of Win2003 DFSN very well indeed. You can also use DFSDIAG via RSAT on Vista and Win7 clients; why do I suspect that you’re looking for a more… frugal… option, though? ;-P

The old DFSUTIL.EXE tool will stand in for DFSDIAG in a pinch, but it requires you to both run more commands and interpret the results carefully. It’s not going to spend much time explaining what’s wrong, so much as show you what it thinks is configured and let you decide if that’s wrong or not. Some of the more useful commands:

dfsutil.exe /root:<dfs name> /view /verbose

dfsutil.exe /server:<root server> /view

dfsutil.exe /domain:<domain> /view

dfsutil /sitename:<root server or dc or target or client>

dfsutil /root: <dfs name> /sitecosting /display

dfsutil /root: <dfs name> /insite /display

dfsutil /root: <dfs name> /targetfailback /display

dfsutil /root: <dfs name> /targetpriority /server:<target> /display

dfsutil.exe /root:<dfs name> /checkblob

dfsutil /viewdfsdirs:<volume name>

Coolish

Oops

No complaining, we released DFSDIAG two OSes ago and you’re on a dying one. Plus we wrote it for a reason!

Question

The USMT hotfix KB2023591 only lists downloads for Windows 7/Windows Server 2008 R2.

Is there a version for older operating systems?

Answer

USMT 4.0 only cares that you run it against a client OS SKU, and that it be XP or later. The download is a CAB file and doesn’t have any OS checking for installation, only scanstate and loadstate enforce the OS. If you dig into the nugget of that main KB at the bottom you will see only:

The reason it lists the OS on the download page is it has to say something, and USMT is built from the Windows 7/R2 source tree. So there you go.

Awesome Technique for Win7/2008 R2 Network Captures

Not a question, but a cool method that is too small to rate a full blog post: if you need to get a network capture on a Windows 7 or Windows Server 2008 R2 computer and you do not have or want Netmon installed, you can use NETSH.EXE. From an elevated CMD prompt run:

netsh trace start capture=yes tracefile=c:\yourcapture.etl

Do whatever you needed to do

netsh trace stop

Boom – network capture, written in ETL format.

Open that file in Netmon 3.4 and you get all the usual capture info, plus other conversation and process info. AND other cool stuff – open the CAB file it created and you find a bunch of useful files with IP info, firewall event logs, applied group policies, driver versions, and more. All the goo I gather manually when I am getting a capture. Sweet!

Thanks to Tim “Mighty” Quinn for demoing this here.

Other Stuff

A few years ago TechNet Magazine stopped printing paper copy and switched to a web-only format. I lost track of them after that, but this weekend, I started going through their online versions from 2010 and 2011. It turns out there’s good stuff I’d been missing. Here are a few cherry picked articles; feel free to point out some other favorites in the Comments:

Windows Confidential: Testing, Testing (Raymond Chen)
http://technet.microsoft.com/en-us/magazine/gg675933.aspx

An interesting explanation of what Beta used to mean, and what it means now, from a Principal SDE who has been developing Windows since the Tithonian age. Heck, his blog is ready to collect Social Security.

Troubleshooting 201: Ask the Right Questions (Stephanie Krieger)
http://technet.microsoft.com/en-us/magazine/ff955771.aspx

How to be an effective troubleshooter. Don’t stop reading just because the author is an Office expert; it’s applicable across all aspects of IT. A truly excellent article that should be required reading for new admins.

Toolbox (Greg Steen)
http://technet.microsoft.com/en-us/magazine/ff628337.aspx?sdmr=toolbox&sdmi=columns

Unlike me, these folks can recommend useful third party utilities. It’s a monthly column and some of these are pretty slick.

Windows PowerShell: HTML Reports in PowerShell (Don Jones)
http://technet.microsoft.com/en-us/magazine/hh127059.aspx

An easy technique to take harsh text output and turn it into fluffy HTML. Perfect for punching up reporting to show your manager with zero extra effort, leaving more time for you to work on real issues. Or, you know, see your children grow up. Cat’s in the cradle and the silvaaaaah spoooon…

Using Kerberos for SharePoint Authentication (Pav Cherny)
http://technet.microsoft.com/en-us/magazine/ee914605.aspx

Yes please! If you have a friend that admins SharePoint, share this with them. In fact, bribe them to follow it. Whatever it takes. NTLM is the Devil and SharePoint feeds him a jalapenos.

The Daily Mail was granted a “rare and remarkable” interview with Bill Gates last week. It’s a very interesting read.

Remember when I said yesterday that it sucks to use the Internet in Australia and Canada? Well it sucks in other places too… The article isn’t what I’d call “complete” (it misses 98% of the world and doesn’t include my gigantic US ISP, Time Warner, for example – TW doesn’t care if I download 5 TB or 5KB, as fast and as often as I like, as long as I pay on time; I use Sprint for my phone for the very same reason – flat rate unlimited data without metering rules). A nifty piece – I recommend the comments.

Why, Andalusia? Whyyyyyyyyyyy!?!?!?!?! I mean, I expect this from Belgium… Maybe Platformas knows.

Have a nice weekend folks.

- Ned “those dudes totally smurfed their smurf up” Pyle

Hi folks, Ned here again. We introduced the AD Administrative Center in Windows Server 2008 R2 to much fanfare. Wait, I mean we told no one and for good measure, we left the old AD Users and Computers tool in-place. Then we continued referencing it in all our documentation.

And people say we're a marketing company.

I've talked previously about using ADAC as a replacement for acctinfo.dll. Today I run through some of the hidden coolness that ADAC brings to the table as well as techniques that make using it easier. If you're never used this utility, make sure you review the requirements and if you don't have any Windows Server 2008 R2 DCs, install the AD Management Gateway and its updates on at least one of your older DCs in each domain. ADAC is included in RSAT.

I am going to demo as much as possible, so I hope you have some bandwidth this month, oppressed serfs Canucks and Aussies. Since this is me, I'll also show you how to work around some ADAC limitations - this isn’t a sales pitch. To make things interesting, I am using one of my more complex forests where I test the ADRAP tools.

Fire up DSAC.EXE and follow along.

ADAC isn't ADUC

The first lesson is "do not fight the interface". Don’t try to make ADAC into AD Users and Computers simply because that's what you’re used to. ADUC wants to click everywhere, expanding trees of data. It's also has short-term memory loss - every time you restart it you have to set it up all over again.

ADAC realizes that you probably stick to a few areas most of the time. So rather than heading to the Tree View tab right away to start drilling down, like this:

… instead, consider using navigation nodes to add areas you are frequently accessing. In my case here, the Users container is an obvious choice:

This pins that container in the navigation pane so that I don’t have to click around next time.

It's even more useful if I use many deeply nested OU structures in the domain. For example, rather than clicking all the way into this hierarchy each time:

I can instead pin the areas I plan to visit that week for a project:

Nice! It even preserves the visual hierarchy for me. Notice another thing here - ADAC keeps the last three areas I visited in the recent view list under that domain. Even if I had not pinned that OU, I'd still get it free if I kept returning to it:

Once you open one of those users, you don't have to dig through a dozen tabs for commonly used attributes. The important stuff is right up front.

For a real-world example of how this does not suck, see this article. The old tabs are down there in the extensions section still, if you need them:

A lot of people have a lot of domains

One thing AD Users and Computers isn’t very good at is scale: it can only show you one domain at a time, requiring you to open multiple dialogs or create your own custom MMC console.

In ADAC, it’s no sweat - just insert any domains you want using Add Navigation Nodes again:

I can add other navigation nodes for those domains without adding the domains themselves too. Each domain gets that three-entry "recently used" list too. I'm also free to move the pinned nodes up and down the list with the right-click menu, if I have OCD. For instance, if I want the Users and Computers container from three domains, it's nothing to have them readily available, in the order I want:

Come on now, you have to admit that is slick, right?

Always look for the nubbin arrow

Scattered around the UI are little arrows that allow you to hide and expose various data views. For instance, you can give yourself more real estate by hiding the navigation pane:

Or see a user's logon information:

Or hide a bunch of sections in groups that you don't usually care about, leaving the one you constantly examine:

Note: It's not really called the nubbin arrow except by Mike Stephens and me. Join our cool gang!

Views and Search are better than Find

AD Users and Computers is an MMC snap-in: this means a UI designed for NT 4.0. When it lets you search, you are limited to the Find menu, which lets you return data, but not preserve it. After closing each search, ADUC's moron brain forgets what you just asked, like a binary pothead.

ADAC came after the birth of search and in a time where AD is now ubiquitous and huge. That means everywhere you go, it wants to help you search rather than browse. Moreover, it wants to remember things you found useful. If I am looking at my Users container, the Filter menu is right there beckoning:

It lets me do quick and reasonable searches without a complicated menu system:

As well as create complex queries for common attributes:

Then save those queries for later, for use within any spot in the forest:

I can also use global search. And I do mean global - for example, I can search all my domains at once and not be limited to Global Catalog lookups that are often missing less-travelled attributes:

For example here, I use ambiguous name resolution to find all objects called Administrator - note how this automatically wildcards.

Not bad, but I want only users that are going to have their passwords expire in the next month. Moreover, I've been trying to improve my LDAP query skills when scripting. No sweat, I can do it the easy way then convert it to LDAP:

Or maybe I let ADAC do the hard work of things like date range calculation:

Then I take that query:

And modify it to do what I want. Like only show me groups modified in the past three days:

Neato - on demand quasi-auditing.

A few tricks of the trade

Return to defaults

If you want to zero out the ADAC console and get an out of box experience, there's no menu or button. However, if you delete this folder, you delete the whole cache of settings:

%appdata%\IsolatedStorage\StrongName.um0icba0dwq40nfvuftw3i5jvholhn3k

ADAC will be slow to start the next time you run it (just as it was the first time you ever ran it) but it will be quick again after that.

The Management List

Have some really ginormous containers? If you navigate into one using ADAC, you will see an error like this:

"The number of items in this container exceeds the maximum number blah blah blah…"

The error tells you what to do - just change the "Management List" options. Right! So… ehhh… where is the management list? You have to hit the ALT key to expose that menu. Argh…

Then you can set the turned object count as low as 2000 or as high as 100000. If you have to do this though, you need to work on organizing your objects better.

Just think "Explorer"

In many ways, we designed ADAC like 7's Windows Explorer. It has a breadcrumb bar, a refresh button, and forward/back buttons.

It lets you use the address bar to quickly navigate and browse, with minimal real estate usage.

The buttons offer a history:

It has an obvious and "international" refresh button - very handy. ADUC made you learn weird habits like F5, which may seem natural to you now, but isn't not very friendly for new admins.

That new Explorer probably took some getting used to but once you had them, returning to XP seems like visiting the dusty hometown you left years ago: Quaint. Inefficient. Boring. Having used the new one for a few years now, ADAC should be more intuitive.

Sum Up

I'm not here to argue against AD Users and Computers; it has its advantages (I miss the Copy… menu). And it's certainly familiar after 11 years of use. However, the AD Administrative Center deserves a place at any domain admins' table and can make your life easier once you know where to look. Try it for a week and see for yourself. If you come back to ADUC, it's ok - we already cashed your check.

Until next time.

- Ned "Ok, maybe 'fun' was a stretch" Pyle

Hey folks, Ned here again. This weekend our blog backend was upgraded and since then, we’ve not gotten any emails that were sent through the Contact page, nor are we seeing alerts on Comments that let us know you posted. We’ve pushed this to the blog support folks and they are looking into it, but I wanted to make sure you understand we are not ignoring you.

Update: And it's working again!

Ned “Web 2.0 is seriously lame” Pyle

Hi Folks, Ned here again. Remember how a month ago, I said Vista SP1 support was ending on July 12, 2011? Well, it’s still ending on July 12, 2011. Make sure you have SP2 fully deployed or just finishing up, as we are down to the wire.

• Download Vista SP2 (x86 version)
• Download Vista SP2 (x64 version)

Macht schnell!!!

- Ned “Ich spreche kein Deutsch” Pyle

Hello all, Jonathan here again. Today, I want to address a question that we see regularly. As customers upgrade Active Directory, and they inevitably reach the point where they are ready to change the Domain or Forest Functional Level, they sometimes become fraught. Why is this necessary? What does this mean? What’s going to happen? How can this change be undone?

What Does That Button Do?

Before these question can be properly addressed, if must first be understood exactly what purposes the Domain and Forest Functional Levels serve. Each new version of Active Directory on Windows Server incorporates new features that can only be taken advantage of when all domain controllers (DC) in either the domain or forest have been upgraded to the same version. For example, Windows Server 2008 R2 introduces the AD Recycle Bin, a feature that allows the Administrator to restore deleted objects from Active Directory. In order to support this new feature, changes were made in the way that delete operations are performed in Active Directory, changes that are only understood and adhered to by DCs running on Windows Server 2008 R2. In mixed domains, containing both Windows Server 2008 R2 DCs as well as DCs on earlier versions of Windows, the AD Recycle Bin experience would be inconsistent as deleted objects may or may not be recoverable depending on the DC on which the delete operation occurred. To prevent this, a mechanism is needed by which certain new features remain disabled until all DCs in the domain, or forest, have been upgraded to the minimum OS level needed to support them.

After upgrading all DCs in the domain, or forest, the Administrator is able to raise the Functional Level, and this Level acts as a flag informing the DCs, and other components as well, that certain features can now be enabled. You'll find a complete list of Active Directory features that have a dependency on the Domain or Forest Functional Level here:

Appendix of Functional Level Features
http://technet.microsoft.com/en-us/library/cc771132(WS.10).aspx

There are two important restrictions of the Domain or Forest Functional Level to understand, and once they are, these restrictions are obvious. Once the Functional Level has been upgraded, new DCs on running on downlevel versions of Windows Server cannot be added to the domain or forest. The problems that might arise when installing downlevel DCs become pronounced with new features that change the way objects are replicated (i.e. Linked Value Replication). To prevent these issues from arising, a new DC must be at the same level, or greater, than the functional level of the domain or forest.

The second restriction, for which there is a limited exception on Windows Server 2008 R2, is that once upgraded, the Domain or Forest Functional Level cannot later be downgraded. The only purpose that having such ability would serve would be so that downlevel DCs could be added to the domain. As has already been shown, this is generally a bad idea.

Starting in Windows Server 2008 R2, however, you do have a limited ability to lower the Domain or Forest Functional Levels. The Windows Server 2008 R2 Domain or Forest Functional level can be lowered to Windows Server 2008, and no lower, if and only if none of the Active Directory features that require a Windows Server 2008 R2 Functional Level has been activated. You can find details on this behavior - and how to revert the Domain or Forest Functional Level - here.

What Happens Next?

Another common question: what impact does changing the Domain or Forest Functional Level have on enterprise applications like Exchange or Lync, or on third party applications? First, new features that rely on the Functional Level are generally limited to Active Directory itself. For example, objects may replicate in a new and different way, aiding in the efficiency of replication or increasing the capabilities of the DCs. There are exceptions that have nothing to do with Active Directory, such as allowing NTFRS replacement by DFSR to replicate SYSVOL, but there is a dependency on the version of the operating system. Regardless, changing the Domain or Forest Functional Level should have no impact on an application that depends on Active Directory.

Let's fall back on a metaphor. Imagine that Active Directory is just a big room. You don't actually know what is in the room, but you do know that if you pass something into the room through a slot in the locked door you will get something returned to you that you could use. When you change the Domain or Forest Functional Level, what you can pass in through that slot does not change, and what is returned to you will continue to be what you expect to see. Perhaps some new slots added to the door through which you pass in different things, and get back different things, but that is the extent of any change. How Active Directory actually processes the stuff you pass in to produce the stuff you get back, what happens behind that locked door, really isn't relevant to you.

If you carry this metaphor forward into the real world, if an application like Exchange uses Active Directory to store its objects, or to perform various operations, none of that functionality should be affected if the Domain or Forest Functional Mode changes. In fact, if your applications are also written to take advantage of new features introduced in Active Directory, you may find that the capabilities of your applications increase when the Level changes.

The answer to the question about the impact of changing the Domain or Forest Functional Level is there should be no impact. If you still have concerns about any third party applications, then you should contact the vendor to find out if they tested the product at the proposed Level, and if so, with what result. The general expectation, however, should be that nothing will change. Besides, you do test your applications against proposed changes to your production AD, do you not? Discuss any issues with the vendor before engaging Microsoft Support.

Where’s the Undo Button?

Even after all this, however, there is a great concern about the change being irreversible, so that you must have a rollback plan just in case something unforeseen and catastrophic occurs to Active Directory. This is another common question, and there is a supported mechanism to restore the Domain or Forest Functional Level. You take a System State back up of one DC in each domain in the forest. To recover, flatten all the DCs in the forest, restore one for each domain from the backup, and then DCPROMO the rest back into their respective domains. This is a Forest Restore, and the steps are outlined in detail in the following guide:

Planning for Active Directory Forest Recovery
http://technet.microsoft.com/en-us/library/planning-active-directory-forest-recovery(WS.10).aspx

By the way, do you know how often we’ve had to help a customer perform a complete forest restore because something catastrophic happened when they raised the Domain or Forest Functional Level? Never.

Best Practices

What can be done prior to making this change to ensure that you have as few issues as possible? Actually, there are some best practices here that you can follow:

1. Verify that all DCs in the domain are, at a minimum, at the OS version to which you will raise the functional level. Yes… I know this sounds obvious, but you’d be surprised. What about that DC that you decommissioned but for which you failed to perform metadata cleanup? Yes, this does happen.
Another good one that is not so obvious is the Lost and Found container in the Configuration container. Is there an NTDS Settings object in there for some downlevel DC? If so, that will block raising the Domain Functional Level, so you’d better clean that up.

2. Verify that Active Directory is replicating properly to all DCs. The Domain and Forest Functional Levels are essentially just attributes in Active Directory. The Domain Functional Level for all domains must be properly replicated before you’ll be able to raise the Forest Functional level. This practice also addresses the question of how long one should wait to raise the Forest Functional Level after you’ve raised the Domain Functional Level for all the domains in the forest. Well…what is your end-to-end replication latency? How long does it take a change to replicate to all the DCs in the forest? Well, there’s your answer.

Best practices are covered in the following article:

322692 How to raise Active Directory domain and forest functional levels
http://support.microsoft.com/default.aspx?scid=kb;EN-US;322692

There, you’ll find some tools you can use to properly inventory your DCs, and validate your end-to-end replication.

Update: Woo, we found an app that breaks! It has a hotfix though (thanks Paolo!). Mkae sure you install this everywhere if you are using .Net 3.5 applications that implement the DomainMode enumeration function.

FIX: "The requested mode is invalid" error message when you run a managed application that uses the .NET Framework 3.5 SP1 or an earlier version to access a Windows Server 2008 R2 domain or forest  
http://support.microsoft.com/kb/2260240

Conclusion

To summarize, the Domain or Forest Functional Levels are flags that tell Active Directory and other Windows components that all DCs in the domain or forest are at a certain minimal level. When that occurs, new features that require a minimum OS on all DCs are enabled and can be leveraged by the Administrator. Older functionality is still supported so any applications or services that used those functions will continue to work as before -- queries will be answered, domain or forest trusts will still be valid, and all should remain right with the world. This projection is supported by over eleven years of customer issues, not one of which involves a case where changing the Domain or Forest Functional Level was directly responsible as the root cause of any issue. In fact, there are only cases of a Domain or Forest Functional Level increase failing because the prerequisites had not been met; overwhelmingly, these cases end with the customer's Active Directory being successfully upgraded.

If you want to read more about Domain or Forest Functional Levels, review the following documentation:

What Are Active Directory Functional Levels?
http://technet.microsoft.com/en-us/library/cc787290(WS.10).aspx

Functional Levels Background Information
http://technet.microsoft.com/en-us/library/cc738038(WS.10).aspx

Jonathan “Con-Function Junction” Stephens