First published on TechNet on Sep 14, 2012
Hi all, Ned here again with that thing we call love. Blog! I mean blog. I have a ton to talk about now that I have moved to the monthly format, and I recommend you switch to WIFI if you’re on your phone.
This round I answer your questions on:
I will bury you!
Is there a way to associate a “new” domain controller with an “existing” domain controller account in Active Directory? I.e. if I have a DC that is dead and has to be replaced, I have to metadata clean the old DC out before I promote a replacement DC with the same name.
You can “reinstall” DCs, attaching an existing objects that were not removed by demotion/MD cleanup. In Windows Server 2012 this is detected and handled by the AD DS config wizard right after you choose a replica DC and get to the DC Options page, or with the Install-AddsDomainController cmdlet using the -AllowDomainControllerReinstall argument.
If using an older operating system, no such luck (this actually existed in dcpromo.exe /unattend in 2008 R2, but didn't work AFAIK). You should use DSA.MSC or NTDSUTIL to metadata cleanup that old domain controller before promoting its replacement.
I’ve read in the past – from you - that DFSR using SYSVOL supports the change notification flag on AD DS replication links or connection objects. Is this true? I am finding very inconsistent behavior.
Not really (and I updated my old writing on this – yes, Ned can be wrong).
DFSR always replicates immediately and continuously with its own internal change notification, as long as the schedule is open; these scheduled windows are in 15 minute blocks and are assigned on the AD DS connection objects.
If the current time matches an open block, you replicate continuously (as fast as possible, sending DFSR change notifications) until that block closes.
If the next block is closed, you wait for 15 minutes, sending no updates at all. If that next block had also been open, you continue replicating at max speed. Therefore, to replicate with change notification, set the connection objects to use a fully opened window. For example:
To make DFSR SYSVOL slower, you must close the replication schedule windows on the connections. But since the historical scenario is a desire to make group policy/script replication faster - and since it is better that SYSVOL beat AD DS, since SYSVOL contains files called once AD DS is updated - this scenario is less likely or important. Not to mention that ideally, SYSVOL is pretty static.
I was using the new graphical Fine Grained Password Policy in Windows Server 2012 AD Administrative Center. I realized that it lets me set a minimum password length of 255 characters.
When I edit group policy in GPMC, it doesn’t let me set a minimum of more than 14 characters!
Did I find a bug?
Nope. The original reason around the 14 character password was to force users to set a 15 character password and force the removal of LM password hashes (which is sort of silly at this point, as we have a security setting called Do not store LAN Manager hash value on next password change that makes this moot and is enabled by default in our later operating systems). The security policy editor enforces the 14 character limit, but this is not the actual limit. You can use ADSIEDIT to change it, for example, and that will work.
The true maximum limit in Active Directory for your password is 255 unicode characters and that’s what ADAC is enforcing. But many pieces of Windows software limit you to 127 character passwords, or even fewer; for example, the NET USE command: if you set a password to 254 characters and then attempt to map a drive with NET USE, it ignores the other characters beyond 127 and you always receive “unknown user name or bad password.” So be careful here.
It goes without saying that if you are requiring a minimum password length of even 25 characters, you are going to need awesome users :-D. Time for smartcard logons, dudes and dudettes; there is no way your users are going to remember passwords that long and it will be on Post-It notes all over their cubicles. Try teaching them passphrases. Riiiiiiiiight.
Totally unrelated note: the second password shown here is exactly 127 characters:
I am using USMT 4.0 and running scanstate on a computer with multiple fixed hard drives, like C:, D:, E:. I want to migrate to new Windows 7 machines that only have a C: drive. Do I need to create a custom XML file?
I could have sworn I wrote something up on this before but darned if I can find it. The short answer is – use migdocs.xml and it will all magically work. The long answer and demonstration of behavior is:
1. I have a computer with C: and D: fixed drives (OS is unimportant, USMT 4.0 or later).
2. On the C: drive I have two custom folders, each with a custom file.
3. On the D: drive I have two custom folders, each with a custom file.
4. One of the folders is named the same on both drives, with a file that is named the same in that folder, but contains different contents.
5. Then you scanstate with no hardlinks (e.g. scanstate c:\store /i:migdocs.xml /c /o )
6. Then you go to a machine with only a C: drive (in my repro I was lazy and just deleted my D: drive) and copy the store over.
7. Run loadstate (e.g. loadstate c:\store /i:migdocs.xml /c )
8. Note how the folders on D: are migrated into C:, merging the folders and creating renamed copies of files when there are duplications:
Where does Active Directory get computer specific information like Operating System, Service Pack level, etc., for computer accounts that are joined to the domain? I'm guessing WMI but I'm also wondering how often it checks.
AD gets it from attributes ( for example ).
AD relies on the individual Windows computers to take care of it – such as when joining the domain, being upgraded, being service packed, or after reboot. Nothing in AD confirms it or maintains outside those “client” processes, so if I change my OS version info using ADSIEDIT, that's the OS as far as AD is concerned and it's not going to change back unless the Windows computer makes it happen. Which it will!
Here I change a Win2008 R2 server to use nomenclature similar to our Linux and Apple competitors:
And here it is after I reboot that computer:
That would be a good band name, now that I think about it.
I’d like to add a DFSR file replication filter but I have hundreds of RFs and don’t want to click around Dfsmgmt.msc for days. Is there a way to set this globally for entire replication groups?
Not per se; DFSR file filters are set on each replicated folder in Active Directory.
But setting it via a Windows PowerShell loop is not hard. For example, in Win2008 R2, where I imported the activedirectory module - here I am (destructively!) setting a filter to match the defaults plus add a new extension on all RFs in this domain:
Is there a way to export and import the DFS Replication configuration the way we do for DFSN? It seems like no but I want to make sure I am not missing anything.
DFSRADMIN LIST shows the configuration and there are a couple export/import commands for scheduling. But overall this is going to be a semi-manual process for you unless they write their own tool or scripts. Ultimately, it’s all just LDAP data, after all – this is how frs2dfsr.exe works.
Once you list and inventory everything, the DFSRADMIN BULK command is useful to recreate things accurately.
Does USMT migrate Internet Explorer Autocomplete Settings?
I really should make you figure this out for yourself … but I am feeling pleasant today. These settings are all here:
Hint hint – Process Monitor is always your friend with custom USMT coding
Looking at the USMT 5.0 replacement manifest:
I see that we do get the \Internet Explorer\and all sub-data (including Main and DomainSuggestion) for those specific registry values with no exclusions. We also get the Explorer\Autocomplete in that same manifest, likewise without exclusion.
Ditto. We grab all this as well.
I have read that Windows Server 2008 R2 has the following documented and supported DFSR limits:
The following list provides a set of scalability guidelines that have been tested by Microsoft on Windows Server 2008 R2 and Windows Server 2008:
- Size of all replicated files on a server: 10 terabytes.
- Number of replicated files on a volume: 8 million.
- Maximum file size: 64 gigabytes.
What happens if I exceed these limits? Should I ever consider exceeding these limits? I want to use much more than these limits!
(Asked by half a zillion customers in the past few weeks)
With more than 10TB or 8 million files, the support will only be best effort (i.e. you can open a support case and we will attempt to assist, but they may reach a point where have to say “this configuration is not supported” and we cannot assist further). If you need us to fully support more end-to-end, you need a solution different than Win2008 R2 DFSR.
To exceed the 10TB limit – which again, is not supported nor recommended – seriously consider:
Actually, just read Warren’s common DFSR mistakes post 10 times . Then read it 10 more times.
Hmm… I recommend all these even when under 10TB…
I hate you, Justin
Speaking of the ridiculous group I work with, this what you get when Steve Taylor wants to boost team morale on a Friday:
Couldn’t they just have the bass player record one looped note?
Canada, what the heck happened?!
I mean… Norway? NORWAY IN THE SUMMER GAMES? They eat pickled herring and go sledding in June! I’ll grant that if you switch to medal count, you’re a respectable 13th. Good work, America’s Hat.
In other news bound to depress canucks, the NHL is about to close up shop yet again. Check out this hilarious article courtesy of Mark .
I am heading out to Redmond next week to teach a couple days of Certified DS Master, then on to San Francisco and Sydney to vacate and yammer even more. I’ll be back in a few weeks; Jonathan will answer your questions in the meantime and I think Mike has posts aplenty to share. When I return – and maybe before – I will have some interesting news to share.
See you in a few weeks.
- Ned “don’t make me take off my shoe” Pyle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.