Friday Mail Sack: Peevish Nediquette Edition

Friday Mail Sack: Peevish Nediquette Edition

  • Comments 3
  • Likes

Hi folks, Ned here again. This week I talk about Vista’s hidden AD schema, SYSVOL migration mission control, kick-starting cached logon performance, USMT c'est la vie, foul-mouthed NetBIOS, DFSR do-over, and the usual random goo. 


If someone has run the 2008 beta schema that was included the Vista RTM DVD - taking the AD Schema to wacky version 39 - are they hosed or can they install Windows Server 2008 or 2008 R2’s schema upgrades without issues?


You can upgrade your schema to 44 (Win2008) or 47 (Win2008 R2) without issue. And if this a production domain, do so immediately. The 39 schema was never supported!





If you compare the sch32.ldf-sch39.ldf schema files that came with the Vista RTM media and the ones on Windows Server 2008 R2 SP1 media, the only difference is sch34.ldf. That contained one extra attribute called ms-DS-Seniority-Index that was not shipped with Windows Server 2008:

dn: CN=ms-DS-Seniority-Index,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaAdd
objectClass: attributeSchema
ldapDisplayName: msDS-SeniorityIndex
adminDisplayName: ms-DS-Seniority-Index
adminDescription: Contains the seniority index as applied by the organization where the person works.
attributeId: 1.2.840.113556.1.4.1947
omSyntax: 2
isSingleValued: TRUE
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 1KV7zpDwQUeswxXiyVVV2g==
attributeSecurityGuid:: VAGN5Pi80RGHAgDAT7lgUA==
mapiID: 35996
showInAdvancedViewOnly: TRUE
systemFlags: 16

Fortunately, it used a proper registered MS OID so there is no extra likelihood of conflict in the future. If someone argues that you are using a non-standard schema that may someday cause adprep to fail and require you to migrate forests, I say “wait until that day comes and don’t worry about it for now.” It’s been years and no one has complained yet. Besides, your schema contains hundreds of attributes that were included and never used. Heck, even by Win2008, when we were on our third iteration and knew better, we still included dozens of new attributes that went nowhere.


Should I wait to migrate my SYSVOL from FRS to DFSR after deploying all Win2008 R2 DCs, or just go for it now that I have Windows Server 2008 DCs and 2008 domain functional level?


I recommend you go for it now - the tendency is to have more DCs over time. Fewer DCs to migrate cuts down on the time, simplifies your life, and makes a smooth migration more likely. And it’s one less thing hanging over your head in your Win2008 R2 upgrade cycle.

Hotfixes that will matter to Win2008 SP2:

KB978994 Error message when you try to migrate the SYSVOL share from the FRS to the DFSR service in a Windows Server 2008 domain: "The parameter is incorrect" -;EN-US;978994

KB2286715 A SYSVOL share migration from FRS to the DFS Replication service stops responding at the Start state in Windows Server 2008 -;en-US;2286715

KB972105 All files are conflicted on all domain controllers except the PDC Emulator when a DFSR migration of the SYSVOL share reaches the Redirected state in Windows Server 2008 or in Windows Server 2008 R2 -

If you decide to wait to R2, you still need KB972105 unless you install SP1. If you deploy Win2008 R2 RODCs without SP1, make sure you also install KB2401600 and KB976655.

Or just use our handy master KB for all of the above.


I know Windows caches user logon credentials so the user can log on when the domain isn't available (like laptops that employees take home each night). Is there a way to speed up the time it takes Windows before cached logon credentials kick in, so the users can logon faster when not connected to the corporate network?


Make sure the computer has no network connection at all. If there’s any network (even some crummy home network) the client will try for a short while to get to a DC, as he has no way to know that this network is nonsense. You can try this out yourself by unplugging a desktop or shutting the WIFI antenna off on a laptop, then restarting and trying to logon – it will be lightning fast.


If using USMT to migrate from XP to Windows 7, are different installed MUI (language packs) supported?


As long as the localized versions of the OS are the same, you’re supported– i.e. we don’t care if you go from EN-US to EN-US, with one running the French MUI and the other the Italian MUI. Heck, we even migrate the regional settings as part of config.xml*. But if one really was French localized and the other Italian, that’s not supported.

* See:

<component displayname="Date, Time, Language and Region" migrate="yes" ID="date_time_language_and_region">

<component displayname="Regional Language Options" migrate="yes" ID="date_time_language_and_region\regional_language_options">

<component displayname="Microsoft-Windows-TextServicesFramework-Migration-DL" migrate="yes" ID=""/>

<component displayname="Microsoft-Windows-MUI-Settings-DL" migrate="yes" ID=""/>

<component displayname="Microsoft-Windows-International-Core-DL" migrate="yes" ID=""/>


As far as how well we do this, I have no experience to impart. I have never heard of any issues and found no support cases, but this would be a seriously rare operation…


If Win2008+ DFS Replication tries to replicate open files and 16 of them are locked at once, would DFSR cease to replicate any further until at least one unlocked?


No, those files are skipped and retried. DFSR will retry after one second, two seconds, four seconds, up to twelve times with a maximum timeout of 5 minutes between each retry. DFSR will then stop retrying that file for 10 minutes and re-enter the same retry cycle infinitely. The DFSR events are throttled and the events doesn’t match the actual number of retries.
Locked files definitely have a negative effect – all these retries aren’t free – but you will not completely block behind 16 files through bad luck.


I was reading KB2491951, which states that you cannot install Exchange 2010 SP1 if “the NetBIOS domain name of a domain controller contains an Ampersand (&) character.”

Is it possible for a DC to have an ampersand in its name? Or am I confusing the issue?


The KB terminology is misleading (that’s being fixed). It refers to Exchange 2010 SP1 installation failure if the domain’s NetBIOS name contains an ampersand. Not the DC itself.

Since Windows 2000 SP1, you have not been able to name a computer with an ampersand. Trying to will give you variations on this error:


Prior to that, you could use many wacky characters in the name, as WINS and NetBIOS name resolution don’t care. If you managed to do that and then started using DNS, we changed the characters to hyphens (dashes) when registering A records in order to comply with RFC 952.

For what it’s worth, NetBIOS domain names can contain unicode characters, numbers, and the symbols:

! @ # $ % ^ & ' ) ( - _ { } ~

They cannot contain symbols:

\ / : * ? " < > | .

Check out my drunken good-for-nothin’ domain, ya’ll!


If you examine the workaround, Exchange would have this problem with a user samAccountName that contains an ampersand too - and this is valid:


That’s why Exchange has to write that KB. Windows NT has been doing this since 1992 (and LAN Manager since the 80s) . Nah nah nah, we were here first! Not that you’d want to use these weird characters anyways.

Other Random Goo

How responsible is your facial hair? I’m currently Unsavory.

Via superfan Mark Morowczynski, courtesy of genius Matt McInerney and Pixelspread. Click it twice! 

Looks like VMware went and shot itself in the foot.

Attack of the Show got a tour of Microsoft that’s worth watching. I mainly clicked it to stare at Jessica Chobot, but then there were some crazy things shared – like Skinput (at 2:00) and another video showing new Kinect tech. They both illustrate a bit of campus paradise too, for those interested.

We began enabling TechNet and MSDN Profile achievements yesterday. You can see these by hovering over a user’s ID on a webpage. Turns out they will be retroactive to 2002, so it will take at least two weeks to grovel the (billions of!!!) data points. Pretty cool, check yourself out:

It might encourage better pictures too, Artem…


There are a million “email efficiency” lists on the internoob. They say things like “only check email twice a day” or “use lots of folders to organize your inbox.” Never mind that if you're only checking email twice a day, you're ignoring your primary communication channel for 7 hours out of 8. Or that Outlook and Gmail proved years ago that email folders are inferior to a good search routine.

Most of these lists are reheated leftovers. But the latest so-called tip I see is the poorly-defined “don’t send ‘thank you’ emails” rule. This is supposed to make you more efficient, but what it really says is that you are an ungrateful clod, who's too important to spend five seconds on someone who took time to help you. Would you walk up to a colleague, ask them a question, listen to their answer, then turn and walk away without saying a word? Of course not, you aren’t a freak. Why then is it ok in email, where someone answered your question with much more effort than talking? They stopped, read your mail, considered your question, wrote a response, made sure it was not egregiously misspelled, then sent it. They're left wondering if you got the mail, if you accidentally deleted it, or if you didn’t understand it and are too embarrassed to admit it. Maybe to the detriment of a customer or your company.

Naturally, I am not saying “reply to every single email with a thank you”; you don’t need to ACK every SYN. But if you ask someone for info, the least you can do is tell them it resolved your issue and give them a “thnx”. Who knows, you might even accidentally brighten someone’s lousy day. And wouldn’t that be civilized…

Until next time.

Ned “Miss Manners with a machinegun” Pyle

  • Is that drunken domain name available for purchase? :)

    - "Fight the facial hair power Chad"

  • :-D

    What, you don't like the chin warmers, food savers, or cheek fur?

  • Thanks Ned, great insights as always.