By
Published
Apr 04 2019 06:00 PM
1,825
Views
First published on TechNet on Jun 24, 2011
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.”
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)."
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!
Do the manager and managedBy attributes in AD do anything, other than for the Exchange global address list info?
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).
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 ).
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.
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?
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:
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.
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.
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.
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?
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:
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 .
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:
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:
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:
Have a nice weekend folks.
- Ned “carpetbag full of cookies” Pyle
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-fo...
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