First published on TechNet on Aug 19, 2011
Hiya folks, Ned back with a palette-cleansing Mail Sack after this monstrosity . This week we talk about:
Let’s get swimmy-headed.
I'm curious to get your feedback on custom AD Schema extensions – those that are created "in house" for a specific need. What is the overall Microsoft stance on the topic? Should we do it, or use AD LDS? We have an app we’re designing and want to do this the “right” way.
It’s always “safer” to use AD/LDS - as it’s easier to throw that away and start over - but as long as you follow our best practices, we don’t get too bent out of shape if you extend your schema. That’s what it’s there for. The critical piece is that you get your base OID from ISO , or barring that, generate one using our safe script . You can also use proxy accounts to tie AD and ADLDS together , the way that we always intended but which never really caught on.
Some of the best practices:
The tricky part of extending your AD schema is no matter how carefully you do it, some millet-for-brains vendor may not. Then you buy their product and cannot use it, due to duplicate attributes or classes. It’s a lot simpler to fix an AD/LDS schema than your AD forest schema.
Hold payment on the vendor’s check until you are sure it works in your lab.
When we deploy Domain Controllers in our environment (whether its a RWDC or RODC, they all run DNS) we always remove our Root Hints. We do this on our RODCs after the DCPROMO and before the reboot. Is there anyway to remove the Root Hints after the RODC becomes read-only?
There’s nothing special as part of the RODC promotion process itself that would let you do this, as DNS configuration is quite restricted when you let the DC process handle it. You have a couple workarounds:
It’s critically important to note:
We are performing a USMT migration. On the source machine we generate the config.xml file by using the genconfig switch and we specify the migapp.xml file in the command line.
This way we can decide if we want to block certain apps from migrating without changing the migapp.xml.
We have Itunes listed in the xml file as well as the application installed on the machine. But it never gets listed in the config.xml file. I’m missing other applications that TechNet says are supported .
It’s because you have newer, “unsupported” versions of the apps installed – note how the MIGAPP.XML starts each section with a <detect> . For example, here are WinZip and Adobe Reader:
If Adobe Reader 9.X and WinZip 8.*-10.* are installed, they will manifest and migrate:
But if I have the latest Adobe Reader (10.*) and WinZip (15.*) installed, they are not detected and therefore, will not manifest or migrate:
To be more supported by the vendor is to be less supported by USMT as time goes by.
You have several options:
You’ll have this issue even if you don’t generate config.xml file, naturally.
I am looking to replicate a folder under the “Windows” folder via DFSR. I found this article http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx
"When replicating a volume that contains the Windows system folder, DFS Replication recognizes the %WINDIR% folder and does not replicate it.
I was wondering if there is any workaround for this, so we can replicate something under the c:\Windows folder.
There is no way around this – it is by design and very intentional. Replicating something under %windir% makes me think you want to synchronize things like drivers between servers, which is a no-no. If you try, you get this DFSR event:
You cannot use DFSR to replicate %systemroot% folders, except for the special case of SYSVOL on Win2008+ DCs.
And while we’re on the subject: while this does not also check %programfiles%, %ProgramFiles(x86)%, or the hidden %programdata%, replicating those folders is just as likely to cause massive issues, to possibly include an unbootable server if you are especially unlucky. Move your data elsewhere.
After discussing the " DC DNS A Records and Web Servers " question from Friday's Mail Sack with my co-workers, I have a question about that question. Let’s say someone changed their (same as parent folder) A record to point at the Virtual IP of a hardware load balancer. This VIP would serve as a content switch that looks at traffic like this: Are you destined for port 80 or 443? If YES -> redirect traffic to web server If NO -> redirect to 1 of x domain controllers. Is this a viable solution?
The DNS folks and I discussed this option when I was vetting the previous post, and we ultimately decided that it would need some kind of third party device that Microsoft doesn’t make – so we could not speak to its viability, as we had no visibility. In addition, there are legitimate reasons to connect to a DC over web ports – the AD Management Gateway/AD Web Service uses HTTP/HTTPS traffic in order to allow you to use AD PowerShell, for example. So drawing the line would be tricky.
Now I answered on the intornotz so I guess the cat’s out of the bag.
What are the correct settings for DFS Namespace to make client failover occur more quickly? I have tried different cache timeout settings but it always seems to take about 30-45 seconds to get access to files again if a DFS target share goes offline.
The issue isn’t DFSN; it’s the Redirector and SMB. Since you already had a connection to that server, the redirector tries to reconnect to it in case there was only a temporary network outage –it’s just a UNC path to a share at that point. The same happens if you point to a single share on a single server, and take that server offline – Windows Explorer doesn’t instantly give you an error that the server is unavailable. A network capture shows bursts of “retry” SMB traffic from that client until it finally gives up and says the server is not coming back. This behavior dates back to NT:
The caching doesn’t change in this scenario either – nothing has changed for the actual link targets in the referral. When SMB gets tired of trying, you move to the next entry in the cache. I can set my client cache timeout to 5 seconds and still see the Redirector sending out retry SMB packets for 30-45 seconds.
The DFSN client connectivity design isn’t for instant failover; it’s for geographical high availability and closest targeting. If you need instant failover, clustering is the way to go. Since the server and connection never goes away due to cluster magic, your users will not see noticeable delays.
If you want the Mack of all solutions, cluster your DFSN link targets. At the very least, your hardware sales rep will appreciate it; he can now afford that Virage he’s been eyeing…
If I search for an object against an AD LDS instance that I know is in AD DS, I get: Error 0x20D6 No superior reference has been configured for the directory service . The AD LDS Server is joined to the AD DS forest that the object I'm searching for is in (I have an application that needs to be restricted to looking at AD LDS, but also have AD LDS send off objects to AD DS that AD LDS cannot find). I found this article , but it doesn't provide any examples of how to configure a crossRef or superior reference, so I'm a little lost.
You have to configure attribute superiorDnsRoot on the configuration partition crossref object. You can use this technique , but use the AD/LDS config partition path.
That error in AD/LDS instance can also mean:
Very generic as you can see. If the above KB doesn’t work, I suggest opening a support case to let us really dig in.
I’ve been teaching the past few weeks and a number of students commented on my rotating Windows 7 wallpaper of mecha. They were all downloaded from the amazing online art site ConceptRobots . They have thousands of these, in many styles. Check out a small sampling:
We just installed a Coke Freestyle machine at work and it’s seriously cool . I’ve never seen a line at the soda fountain before, and ours are free . You should come see for yourself. Those students admiring my wallpaper were 33 new hires right here in Charlotte.
Like baseball? Add this to your favorites . Not the prettiest site, but if you want amazing details, statistics, and stories, it’s the best.
And finally - I was sitting at a light last week when I noticed this fella. It really sums up my eleven years of living in North Carolina and that my wife is right - I’m still just a damyankee:
Have a great weekend folks.
Ned “the ethernet cable guy” Pyle
Hiya folks, Ned back with a palette-cleansing Mail Sack after this monstrosity . This week we talk about:
- To customize AD schema or not
- DC and root hints
- USMT and the case of the missing apps
- DFSR and %SYSTEMROOT%
- More fun with DC Same As Parent domain zone records
- Speeding up DFSN client failover
- AD/LDS and “No superior reference”
- Stuff that is not work
Let’s get swimmy-headed.
Question
I'm curious to get your feedback on custom AD Schema extensions – those that are created "in house" for a specific need. What is the overall Microsoft stance on the topic? Should we do it, or use AD LDS? We have an app we’re designing and want to do this the “right” way.
Answer
It’s always “safer” to use AD/LDS - as it’s easier to throw that away and start over - but as long as you follow our best practices, we don’t get too bent out of shape if you extend your schema. That’s what it’s there for. The critical piece is that you get your base OID from ISO , or barring that, generate one using our safe script . You can also use proxy accounts to tie AD and ADLDS together , the way that we always intended but which never really caught on.
Some of the best practices:
- http://msdn.microsoft.com/en-us/library/ms676900(v=VS.85).aspx
- http://blogs.technet.com/b/askds/archive/2010/02/12/friday-mail-sack-not-usmt-edition.aspx#oid
- http://blogs.technet.com/b/askds/archive/2010/08/20/friday-mail-sack-scooter-edition.aspx#schema
The tricky part of extending your AD schema is no matter how carefully you do it, some millet-for-brains vendor may not. Then you buy their product and cannot use it, due to duplicate attributes or classes. It’s a lot simpler to fix an AD/LDS schema than your AD forest schema.
Hold payment on the vendor’s check until you are sure it works in your lab.
Question
When we deploy Domain Controllers in our environment (whether its a RWDC or RODC, they all run DNS) we always remove our Root Hints. We do this on our RODCs after the DCPROMO and before the reboot. Is there anyway to remove the Root Hints after the RODC becomes read-only?
Answer
There’s nothing special as part of the RODC promotion process itself that would let you do this, as DNS configuration is quite restricted when you let the DC process handle it. You have a couple workarounds:
1. Configure the root hints via its registry value “isslave”, perhaps run as a batch at the end of promotion. See KB2001154 for more info on configuring this. And no snickering at this Win2008 bug in the comments! Ok, maybe a little.
2. Don’t have the RODC install and configure DNS (in an unattend install, this is “SkipAutoConfigDNS”). Script the DNS installation using DNSCMD to do everything. This seems like overkill, but answers the greater question of controlling RODC+DNS configuration.
It’s critically important to note:
http://support.microsoft.com/kb/818020
Note Microsoft does not support the removal of all root hints from a Microsoft DNS server. A Microsoft DNS server must have at least one root hint. However, you can replace the existing root hints with new root hints. When you replace root hints, the change is permanent, and the old root hints do not reappear. If the DNS server if forwarding, click to select the Do not use recursion for this domain check box on the Forwarders tab in DNS Manager to make sure that the root hints will not be used.
Question
We are performing a USMT migration. On the source machine we generate the config.xml file by using the genconfig switch and we specify the migapp.xml file in the command line.
Scanstate.exe /genconfig:config.xml /i:migapp.xml
This way we can decide if we want to block certain apps from migrating without changing the migapp.xml.
We have Itunes listed in the xml file as well as the application installed on the machine. But it never gets listed in the config.xml file. I’m missing other applications that TechNet says are supported .
Answer
It’s because you have newer, “unsupported” versions of the apps installed – note how the MIGAPP.XML starts each section with a <detect> . For example, here are WinZip and Adobe Reader:
If Adobe Reader 9.X and WinZip 8.*-10.* are installed, they will manifest and migrate:
But if I have the latest Adobe Reader (10.*) and WinZip (15.*) installed, they are not detected and therefore, will not manifest or migrate:
To be more supported by the vendor is to be less supported by USMT as time goes by.
You have several options:
1. Convince the vendor of the USMT-unsupported apps to give you updated migration XML. They submitted the previous version requirements for their own app during the USMTdevelopment process – that’s why so few apps are listed and they are so esoteric: Winzip but not WinRar? RealPlayer but not WinAmp? AD-Aware but not a hundred other anti-spyware apps? Microsoft didn’t create the list.
2. Create a copy of the migapp.xml, add detection elements for those newer versions and update any paths necessary, and validate that they see seem to migrate the right settings. Then migrate using that updated XML instead of the shipping XML and cross your fingers, because you are hoping you got it all right and your vendor is going to support it (Microsoft does not care – again, these are not our settings ).
3. Migrate older versions of the apps, then update them after the fact (included only for completeness’ sake – this is extremely gross)
You’ll have this issue even if you don’t generate config.xml file, naturally.
Question
I am looking to replicate a folder under the “Windows” folder via DFSR. I found this article http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx
"When replicating a volume that contains the Windows system folder, DFS Replication recognizes the %WINDIR% folder and does not replicate it.
I was wondering if there is any workaround for this, so we can replicate something under the c:\Windows folder.
Answer
There is no way around this – it is by design and very intentional. Replicating something under %windir% makes me think you want to synchronize things like drivers between servers, which is a no-no. If you try, you get this DFSR event:
Event ID=6410
Severity=Error
The DFS Replication service failed to initialize replicated folder %2 because
the service detected that one of its working folders overlaps a Windows system
folder. This is an unsupported configuration.
Additional Information:
Overlapped Folder: %3
Replicated Folder: %4
Replicated Folder Name: %5
Replicated Folder ID: %1
Replication Group Name: %6
Replication Group ID: %7
Member ID: %8
System Folder:%9
You cannot use DFSR to replicate %systemroot% folders, except for the special case of SYSVOL on Win2008+ DCs.
And while we’re on the subject: while this does not also check %programfiles%, %ProgramFiles(x86)%, or the hidden %programdata%, replicating those folders is just as likely to cause massive issues, to possibly include an unbootable server if you are especially unlucky. Move your data elsewhere.
Question
After discussing the " DC DNS A Records and Web Servers " question from Friday's Mail Sack with my co-workers, I have a question about that question. Let’s say someone changed their (same as parent folder) A record to point at the Virtual IP of a hardware load balancer. This VIP would serve as a content switch that looks at traffic like this: Are you destined for port 80 or 443? If YES -> redirect traffic to web server If NO -> redirect to 1 of x domain controllers. Is this a viable solution?
Answer
The DNS folks and I discussed this option when I was vetting the previous post, and we ultimately decided that it would need some kind of third party device that Microsoft doesn’t make – so we could not speak to its viability, as we had no visibility. In addition, there are legitimate reasons to connect to a DC over web ports – the AD Management Gateway/AD Web Service uses HTTP/HTTPS traffic in order to allow you to use AD PowerShell, for example. So drawing the line would be tricky.
Now I answered on the intornotz so I guess the cat’s out of the bag.
Question
What are the correct settings for DFS Namespace to make client failover occur more quickly? I have tried different cache timeout settings but it always seems to take about 30-45 seconds to get access to files again if a DFS target share goes offline.
Answer
The issue isn’t DFSN; it’s the Redirector and SMB. Since you already had a connection to that server, the redirector tries to reconnect to it in case there was only a temporary network outage –it’s just a UNC path to a share at that point. The same happens if you point to a single share on a single server, and take that server offline – Windows Explorer doesn’t instantly give you an error that the server is unavailable. A network capture shows bursts of “retry” SMB traffic from that client until it finally gives up and says the server is not coming back. This behavior dates back to NT:
148950 Changing the Windows NT Redirector Time-Out Value
http://support.microsoft.com/default.aspx?scid=kb;EN-US;148950
(This registry value isn’t applicable to later OSes; we decided allowing adjustment caused too many issues)
The caching doesn’t change in this scenario either – nothing has changed for the actual link targets in the referral. When SMB gets tired of trying, you move to the next entry in the cache. I can set my client cache timeout to 5 seconds and still see the Redirector sending out retry SMB packets for 30-45 seconds.
The DFSN client connectivity design isn’t for instant failover; it’s for geographical high availability and closest targeting. If you need instant failover, clustering is the way to go. Since the server and connection never goes away due to cluster magic, your users will not see noticeable delays.
If you want the Mack of all solutions, cluster your DFSN link targets. At the very least, your hardware sales rep will appreciate it; he can now afford that Virage he’s been eyeing…
Question
If I search for an object against an AD LDS instance that I know is in AD DS, I get: Error 0x20D6 No superior reference has been configured for the directory service . The AD LDS Server is joined to the AD DS forest that the object I'm searching for is in (I have an application that needs to be restricted to looking at AD LDS, but also have AD LDS send off objects to AD DS that AD LDS cannot find). I found this article , but it doesn't provide any examples of how to configure a crossRef or superior reference, so I'm a little lost.
Answer
You have to configure attribute superiorDnsRoot on the configuration partition crossref object. You can use this technique , but use the AD/LDS config partition path.
That error in AD/LDS instance can also mean:
- It doesn’t have a matching schema to your AD DS forest. Use the ADSchemaAnalyzer tool to validate this and sync the differences.
- The DN specified is wrong
- You are connecting to an ADAM/ADLDS instance on the wrong port (so lame, I know).
Very generic as you can see. If the above KB doesn’t work, I suggest opening a support case to let us really dig in.
Not work
I’ve been teaching the past few weeks and a number of students commented on my rotating Windows 7 wallpaper of mecha. They were all downloaded from the amazing online art site ConceptRobots . They have thousands of these, in many styles. Check out a small sampling:
Go there only if you have hours to waste
We just installed a Coke Freestyle machine at work and it’s seriously cool . I’ve never seen a line at the soda fountain before, and ours are free . You should come see for yourself. Those students admiring my wallpaper were 33 new hires right here in Charlotte.
Like baseball? Add this to your favorites . Not the prettiest site, but if you want amazing details, statistics, and stories, it’s the best.
And finally - I was sitting at a light last week when I noticed this fella. It really sums up my eleven years of living in North Carolina and that my wife is right - I’m still just a damyankee:
Ford F-150, even though he lives in an affluent suburb – check
Aftermarket U-Haul tow-hitch - check
Vanity plate with Larry the Cable Guy catchphrase – check
Bumper sticker affirming that this is not the smallest pickup he will ever own – check
But the icing on the cake:
He bought the truck from NASCAR racing driver Dale Jarrett . Hells yeah.
Have a great weekend folks.
Ned “the ethernet cable guy” Pyle
Updated Apr 05, 2019
Version 2.0
NedPyle
Microsoft
Microsoft
