Blog - Title

July, 2010

  • Friday Mail Sack: Saturday Edition

    Ned here. As you may have noticed, it is not Friday. You may also have noticed that this post is awesome and packed with many weeks of delayed content goodness. This notice may extend to the fact that I have no life. You notice a lot, don’t you smarty?


    I cannot imagine someone looking less like Sherlock Holmes than this goober.

    This week I talk about AD scalability, DC usage, DFSR, DFSN, USMT, old user accounts, and angry networking. If you don’t see your question here it may just be in the backlog; don’t worry, I’ll get to it. Just kidding, your question stunk. And there is no Santa Claus.

    The game is afoot!


    I was reviewing Active Directory Maximum Limits – Scalability and noticed that it says the maximum number of a DC’s a domain can contain is 1200 when using FRS for SYSVOL. Did that number change in Windows Server 2008 when DFSR could be used for SYSVOL?


    A quick clarification: it’s the recommended maximum. The number 1200 is not some buffer in FRS that prevents further DC’s from being added; it was the largest number you could add before we decided that recovering a damaged SYSVOL became impractically hard. I’d also say from personal experience that this is a grossly inflated number – you try recovering a damaged FRS from a “mere” 200 DC’s and see what I mean.

    Bottom line, this number is pulled from thin air. DFSR does not have a maximum number for SYSVOL either. Code review shows no reasonable limits and customer experiences go much higher. Repairing a damaged DFSR SYSVOL would go faster and be easier; not to mention it’s much less likely to be damaged in the first place due to improved reliability.


    Are there any improvements in AD bridgehead servers in Windows Server 2008 R2?


    Yes, and we recently published them in a nicely hidden spot. Check:

    Bridgehead Server Selection

    For the first time true probabilistic load-balancing was introduced for RWDC’s (the RODC’s got some of this code in Win2008). Connections and load are kept evenly distributed across all bridgeheads. This is a big deal in larger environments – we believe there is no longer any need to mess with ADLB.EXE.

    The load-balancing doesn’t factor in hardware, just DC nodes. There is no forest functional level requirement, so you can coexist with 2008 and 2003, but those older OS’ don’t know about this new system. The more 2008 R2 DCs you use, the better the system will be in terms of load balancing. The KCC can still leave unbalanced connections if DCs go offline.  The KCC doesn’t rebalance automatically when they come back up, as the unbalanced configuration that relies on DCs that haven’t gone offline is likely better than the balanced one that relied on machines that did go offline. You can manually force the load-balancing algorithm by deleting the inbound intersite connections for a DC or site and running the repadmin /kcc command (or deleting the connections then simply waiting for the KCC to run automatically within 15 minutes). We recommend upgrading your main hub site DC’s to Win2008 R2 first so that they can start evenly load-balancing with their out-of-site branch partners more efficiently. And heck, hubs are easier DC’s to upgrade, right? They’re just down the hall…


    When I choose to disable a DFSR membership though the management snap-in (DFSMGMT.MSC), I get a very scary message:


    The part that scares me is “The shared folder that is published in the namespace will be removed from the namespace as well”. I want to disable the membership and stop using DFSR on this folder, but I don’t want the DFS Namespace folder target to stop being shared. Possible?


    Yes, but you must use DFSRADMIN.EXE instead. For example:

    dfsradmin membership set /RFName:Test-RG-RF /RGName:Test-RG /MemName:opa\win2008x64DC2 /MembershipEnabled:false

    When this runs you will be warned that it will NOT remove the sharing of the folder through DFS:


    If you add /FORCE to your dfsradmin command it will remove the DFSR membership but leave DFSN untouched.

    Critical note: It’s seriously dangerous to do this as you are letting users continue to access data that is not being replicated anymore; if they are allowed to modify that data, and if you later re-enable this membership, all of their changes are going to be wiped out. You will be triggering a non-authoritative sync, after all. This is only reasonably safe if the replicated folder was using Read Only DFSR or if the share is marked only for READ permissions. This is why the GUI tries to talk you out of it and also remove the DFSN link to the folder.


    Why can’t my child domain admin authorize a DHCP server that’s a member of his same child domain?


    I’ll give you a hint: where does the CN=DhcpRoot object live in the forest?


    I have heard that moving a DC to a child OU under the default Domain Controllers OU is not supported by Microsoft. Is it is possible, and any supporting arguments for or against doing this.


    It’s supported but not recommended - bad things happen when developers assume an object will always be in the same spot. Some examples:

    978994  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

    833436  "The current DC is not in the domain controller's OU" error message when you run the Dcdiag tool;EN-US;833436

    And so on. We periodically find bugs and fix them without much argument. More often it’s third parties that really get bent out of shape. Too many of their developers test using a domain built with DCPROMO using “next next next next done – now don’t touch it!”. They may not be as accommodating about a fix, so if you design this you are likely to need to un-design it someday.

    The real question you have to ask yourself is: why do you feel the need to move the DC’s? Because you must, or because you can? I’ve never had a customer successfully convince me of the former case. You can try in the comments if you like, I welcome all comers. Don't say "because I need differnet policies applies to different computers" because you can use security groups (global or domain local) to do that, or WMI filters.


    I’m using USMT 4.0 with the /MD switch to migrate to a new domain. But if the mapped users do not exist in the new domain, the migration fails with “Fatal error 71” and these log entries:

    2010-06-29 17:59:35, Info  [0x000000] User CONTOSO\NED maps to FABRIKAM\NED
    2010-06-29 17:59:35, Info  [0x000000] Adding domain account CONTOSO\NED
    2010-06-29 17:59:35, Info  [0x0803b2] Adding user CONTOSO\NED
    2010-06-29 17:59:35, Info  [0x000000] Failed.[gle=0x00000091]
    2010-06-29 17:59:35, Info  [0x000000] A Windows Win32 API error occurred
       Windows error 1332 description: No mapping between account names and security IDs was done.[gle=0x00000091]
    2010-06-29 17:59:35, Info  [0x000000] Windows Error 1332 description: No mapping between account names and security IDs was done.
    2010-06-29 17:59:35, Info  [0x000000] Entering MigCloseCurrentStore method

    Is there a way to ignore this error? Using /C does not appear to work, and the <ErrorControl> element in config.xml is confusing.


    This is expected behavior and by design. As workarounds:

    1. Don’t migrate accounts that you have no intention of creating a new user for in the new domain (use /UEL or /UE).


    2. If you are going to use them, pre-create the accounts. It’s not like the migrated profiles will be useful if they have no accounts.


    3. Don’t hold it that way. Wait, that was Steve Jobs’ answer.


    Your rubber band phone does not go with my hipster glasses. And I look better in a turtleneck than you.

    The reason /C does not work is the error is fatal, and /C is only for non-fatal errors:

    The reason <ErrorControl> is confusing here is because it’s not relevant. Take a closer look at the syntax ( It’s for fine-tuned error handling of file and registry errors, not issues with the built-in command-line.


    What is Microsoft's best practice for where and how many DNS servers exist? What about for configuring DNS client settings on DC’s and members?


    It depends on who you ask. :-) We in MS have been arguing this amongst ourselves for 11 years now. Here are the general guidelines that the Microsoft AD and Networking Support teams give to customers, based on our not inconsiderable experience with customers and their CritSits:

    1. If a DC is hosting DNS, it should point to itself at least somewhere in the client list of DNS servers.
    2. If at all possible on a DC, client DNS should point to another DNS server as primary and itself as secondary or tertiary. It should not point to self as primary due to various DNS islanding and performance issues that can occur. (This is where the arguments usually start)
    3. When referencing a DNS server on itself, a DNS client should always use a loopback address and not a real IP address.
    4. Unless there is a valid reason not to that you can concretely explain with more pros than cons, all DC’s in a domain should be running DNS and hosting at least their own DNS zone; all DC’s in the forest should be hosting the _MSDCS zones. This is default when DNS is configured on a new Win2003 or later forest’s DC’s. (Lots more arguments here).
    5. DC’s should have at least two DNS client entries.
    6. Clients should have these DNS servers specified via DHCP or by deploying via group policy/group policy preferences, to avoid admin errors; both of those scenarios allow you to align your clients with subnets, and therefore specific DNS servers. Having all the clients & members point to the same one or two DNS servers will eventually lead to an outage and a conversation with us and your manager. If every DC is a DNS server, clients can be fine-tuned to keep their traffic as local as possible and DNS will be highly available with special work or maintenance. It also means that branch offices can survive WAN outages and keep working, if they have local DC’s running DNS.
    7. We don’t care if you use Windows or 3rd party DNS. It’s no skin off our nose: you already paid us for the DC’s and we certainly don’t need you to buy DNS-only Windows servers. But we won’t be able to assist you with your BIND server, and their free product’s support is not free.
    8. (Other things I didn’t say that are people’s pet peeves, leading to even more arguments).

    There are plans afoot to consolidate all this info, expand it, and get our message consistent and consolidated. This has started in the Windows Server 2008 R2 BPA for DNS. We also recently released a new namespace planning site that explains and prevents some design pitfalls:

    DNS Namespace Planning Solution Center

    And we offer this great guide and portal site:

    Creating a DNS Infrastructure Design

    DNS Portal

    Now flame on.


    You aren’t using conditional forwarders? I don’t even know you anymore…


    We're moving to Windows 2008 R2 DC’s and I'm wondering what is the best attribute is to determine unused user accounts? I've read the TechNet article here about “msDS-LastSuccessfulInteractiveLogonTime” and your blog here about “LastLogontimeStamp”. We're interested in completeness rather than up to the minute accuracy. Is using the msDS-LastSuccessfulInteractiveLogonTime attribute going to give complete results? Is one better to use than the other?


    The problem with msDS-LastSuccessfulInteractiveLogonTime and its associated group policy “Display information about previous logons during user logon” is that they are going to only work for users logging on from Vista or later OS’s through CTRL+ALT+DEL (CredUI) and "Run As" operations (either through the Shell or with RUNAS.EXE). If there are accounts (like services, applications, etc) using creds elsewhere, this attribute will not be updated.

    So for example, here I just logged in to some member computer using CTRL+ALT+DEL at the main logon screen, and logged on:


    And here I then mapped a drive to another computer from that same client I just logged onto:


    No difference; the value was not updated. I certainly logged on over there, but not interactively.

    Also, using this policy changes the user logon experience pretty dramatically:


    It’s designed more for high security environments where the end user would read this and say ‘What the… I didn’t log in yesterday. Haxors, call out the SWAT team!”. Mission Impossible movie stuff, where end users actually know what security and logons are. In reality the user will just click OK without reading, the same way they do when asked if they would like to install some malware. And you know the extra step will tick off some DB VP. This is really only valuable when your users are trained and cognizant about security – then it becomes very powerful indeed.

    So sticking with the old Warren way is still valid. This was a great question, most folks don’t know about this new setting.


    Finally, we are still hiring full time employees here in DS support. We have not been overwhelmed with inquiries – so much for the great recession – so please send us your resume and come join us.


    It's like working here.


    Ok, more like here.

    You won’t be bored.

    - Ned “founded upon the observation of trifles” Pyle

  • Post-Graduate AD Studies

    Hello world, Ned here again. I was out of the office late last week so there was no mail sack; Jonathan pretended like he was going to do one but he lied. He’ll try to claim that things got “busy” and there were “customers” who wanted “their issues fixed” or some other nonsense, but we all know it was due to him daydreaming about bubble baths.

    Too weird?

    Anyway, what with the hiring we’re doing now, a month ago I promised you some further reading around how you can amp up your Active Directory skills. Rather than burying it in another mail sack, I figured I’d lay it all out here in one spot. If you feel like you need to fill in the cracks on your directory service knowledge, here’s what we force feed our new hires:

    Core Technology Reading

    If you read nothing else, read these core pieces. While they are Win2003/XP specific, that’s still at least 75% of the business install base and highly relevant. For the most part things don’t change that much architecturally between versions either (ignoring GP and User Profiles). They give you the fundamentals to build on later.

    Active Directory Collection
    Active Directory Replication Model
    Active Directory Replication Topology
    DNS Technical Reference
    Group Policy
    Interactive Logon
    Kerberos Authentication Technical Reference
    Public Key Infrastructure (PKI)
    TCP/IP Technical Reference
    User Profiles

    Post Graduate Technology Reading

    Then we get to the more advanced subjects, the specific features added in later models, and the things that will take you into rarefied air. Much of this is Windows Server 2008 and later too, so if you haven’t started rolling out our later OS this will get you ready. If you can get through these, you’re ready to run AD in the environments with 100,000+ computers. And as I always tell people, if you know how something works, you can troubleshoot any kind of problem – even if the issue has never seen seen before.

    Active Directory Domain Services in the Perimeter Network
    Active Directory and Active Directory Domain Services Port Requirements
    Active Directory Schema
    ADMT Guide: Migrating and Restructuring Active Directory Domains
    AD DS Design Guide
    CA Certificates
    Certificate Services
    Core Group Policy Technical Reference
    Designing a Group Policy Infrastructure
    DFS Replication: Frequently Asked Questions (FAQ)
    Distributed File System (DFS)
    DNS Support for Active Directory
    Domain and Forest Trusts Technical Reference
    File Replication Service FRS
    Global Catalog Technical Reference 
    Group Policy Components
    Group Policy Management Console
    Group Policy Object Editor
    Logon and Authentication Technologies
    Managed Service Accounts
    Managing Roaming User Data Deployment Guide
    Operations Masters Technical Reference
    Read-Only Domain Controller Planning and Deployment Guide
    Running Domain Controllers in Hyper-V
    Security Auditing
    Security Compliance Manager
    Security Identifiers Technical Reference
    Security Descriptors and Access Control Lists Technical Reference
    Security Principals Technical Reference
    Staging Group Policy Deployments
    SYSVOL Replication Migration Guide: FRS to DFS Replication
    User Account Control Technical Reference
    What's New in Active Directory Domain Services in Win2008
    What's New in Active Directory Domain Services in Win2008 R2
    Windows Smart Card Technical Reference
    Windows Time Service Technical Reference
    WINS Technical Reference

    Lab Materials

    You can use these free trial editions below in order to do live repros of all this, and repros are highly suggested. Especially with the use of Netmon 3.4 to see how things look on the wire and learn how we troubleshoot here – with network captures. Running these in Hyper-V, in Virtualbox, etc. will also make the materials more understandable.

    As an alternative, for a few hundred bucks you can get the amazingly packed TechNet or MSDN subscriptions that provide you with copies of so much MS software it’s ridiculous; way better than using trialware. Check those out here:

    Thanks to the Blue Devil Demon* who reminded me to do this. :-)

    Ned “nutty professor” Pyle

    * Apologies to Coach K and the ghost of Ray Meyer. I've been away from Chicago too long, it seems. Maybe I really am no longer a 'damyankee', as my wife puts it?

  • Friday Mail Sack: Newfie from the Grave Edition

    Heya, Ned here again. Since this another of those catch up mail sacks, there’s plenty of interesting stuff to discuss. Today we talk NSPI, DFSR, USMT, NT 4.0 (!!!), Win2008/R2 AD upgrades, Black Hat 2010, and Irish people who live on icebergs.

    Faith and Begorrah!


    A vendor told me that I need to follow KB2019948 to raise the number of “NSPI max sessions per user” from 50 to 10,000 for their product to work. Am I setting myself up for failure?


    Starting in Windows Server 2008 global catalogs are limited to 50 concurrent NSPI connections per user from messaging applications. That is because previous experience with letting apps use unlimited connections has been unpleasant. :) So when your vendor tells you to do this, they are putting you in the position where your DC’s will be allocating a huge number of memory pages to handle what amounts to a denial of service attack caused by a poorly written app that does not know how to re-use sessions correctly.

    We wrote an article you can use to confirm this is your issue (BlackBerry Enterprise Server currently does this and yikes, Outlook 2007 did at some point too! There are probably others):

    949469    NSPI connections to a Windows 2008-based domain controller may cause MAPI client applications to fail with an error code: "MAPI_E_LOGON_FAILED";EN-US;949469

    The real answer is to fix the calling application so that it doesn’t behave this way. As a grotesque bandage, you can use the registry change on your GC’s. Make sure these DC’s are x64 OS and not memory bound before you start, as it’s likely to hurt. Try raising the value in increments before going to something astronomical like 10,000 – it may be that significantly fewer are needed per user and the vendor was pulling that number out of their butt. It’s not like they will be the ones on the phone with you all night when the DC tanks, right?


    I have recently started deploying Windows Server 2008 R2 as part of a large DFSR infrastructure. When I use the DFS Management (DFSMGMT.MSC) snap-in on the old Win2008 and Win2003 servers to examine my RG’s, the new RG’s don’t show up. Even when I select “Add replication groups to display” and hit the “Show replication groups” button I don’t see the new RG’s. What’s up?


    We have had some changes in the DFSMGMT snap-in that intentionally lead to behaviors like these. For example:

    Here’s Win2008 R2:


    and here’s Win2003 R2:

    See the difference? The missing RG names gives a clue. :)

    This is because the msDFSR-Version attribute on the RG gets set to “3.0” when creating an RG with clustered memberships or an RG containing read-only memberships. Since a Win2003 or Win2008 server cannot correctly manage those new model RG’s, their snap-in is not allowed to see it.

    In both cases this is only at creation time; if you go back later and do stuff with cluster or RO, then the version may not necessarily be updated and you can end up with 2003/2008 seeing stuff they cannot manage. For that reason I recommend you avoid managing DFSR with anything but the latest DFSMGMT.MSC. The snap-ins just can’t really coexist effectively. There’s never likely to be a backport because – why bother? The only way to have the problem is to already have the solution.


    Is there a way with USMT 4.0 to take a bunch of files scattered around the computer and put them into one central destination folder during loadstate? For example, PST files?


    Sure thing, USMT supports a concept called “rerouting” that relies on an XML element called “locationModify”. Here’s an example:

    <migration urlid="<a href="">
      <component type="Documents" context="System">
    All .pst files to a single folder
        <role role="Data">
                <script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>
    <!-- Migrates all the .pst files in the store to the C:\PSTFiles folder during LoadState -->
            <locationModify script="MigXmlHelper.Move('C:\PSTFiles')">
                <script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>

    The <locationModify> element allows you to choose from the MigXmlHelpers of RelativeMove, Move, and ExactMove. Move is typically the best option as it just preserves the old source folder structure under the new parent folder to which you redirected . ExactMove is less desirable as it will flatten out the source directory structure, which means you then need to explore the <merge> element and decide how you want to handle conflicts. Those could involve various levels of precedence (where some files will be overwritten permanently) or simply renaming files with (1), (2), etc added to the tail. Pretty gross. I don’t recommend it and your users will not appreciate it. RelativeMove allows you to take from one known spot in the scanstate and move to another new known spot in the loadstate.


    I’m running into some weird issues with pre-seeding DFSR using robocopy with Win2008 and Win2008 R2, even when following your instructions from an old post. It looks like my hashes are not matching as I’m seeing a lot of conflicts. I also remember you saying that there will be a new article on pre-seeding coming?


    1. Make sure you install these QFE version that fixes several problems with ACL’s and other elements not correctly copying in 2008/2008R2 – all file elements are used by DFSR to calculate the SHA-1 hash, so anything being different (including security) will conflict the file:

    973776  The security configuration information, such as the ACL, is not copied if a backup operator uses the Robocopy.exe utility together with the /B option to copy a file on a computer that is running Windows Vista or Windows Server 2008;EN-US;973776

    979808    "Robocopy /B" does not copy the security information such as ACL in Windows 7 and in Windows Server 2008 R2;EN-US;979808

    2. Here’s my recommended robocopy syntax.  You will want to ensure that the base folder (where copying from and to) have the same security and inheritance settings prior to copying, of course.

    3. If you are using Windows Server 2008 R2 (or have a Win7 computer lying around), you can use the updated version of DFSRDIAG.EXE that supports the FILEHASH command. It will allow you to test and see if your pre-seeding was done correctly before continuing:

    C:\>dfsrdiag.exe filehash
    Command "FileHash" or "Hash" Help:
       Displays a hash value identical to that computed by the DFS Replication
       service for the specified file or folder
       Usage: DFSRDIAG FileHash </FilePath:filepath>

       </FilePath> or </Path>
         File full path name
         Example: /FilePath:d:\directory\filename.ext

    It only works on a per-file basis, so it’s either for “spot checking” or you’d have to script it to crawl everything (probably overkill). So you could do your pre-seeding test, then use this to check how it went on some files:

    dfsrdiag filehash /path:\\srv1\rf\somefile.txt
    dfsrdiag filehash /path:\\srv2\rf\somefile.txt

    If the hashes fit, you must acquit!

    Still working on the full blog post, sorry. It’s big and requires a lot of repro and validation, just needs more time – but it had that nice screenshot for you. :)


    1. Can a Windows NT 4.0 member join a Windows Server 2008 R2 domain?
    2. Can Windows7/2008 R2 join an NT 4.0 domain?
    3. Can I create a two-way or outbound trust between an NT 4.0 PDC and Windows Server 2008 R2 PDCE?

    Short Snarky Answer

    1. Yes, but good grief, really!?!
    2. No.
    3. Heck no.

    Long Helpful Answer

    1. If you enable the AllowNt4Crypto Netlogon setting and all the other ridiculously insecure settings required for NT 4.0 below you will be good to go. At least until you get hacked due to using a 15 year old OS that has not gotten a security hotfix in half a decade.

      823659    Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments;EN-US;823659

      942564    The Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default;EN-US;942564
    2. Windows 7 and 2008 R2 computers cannot join NT 4.0 domains due to fundamental security changes. No, this will not change. No, there is no workaround.  

      940268    Error message when you try to join a Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2-based computer to a Windows NT 4.0 domain: "Logon failure: unknown user name or bad password";EN-US;940268

    3. Windows Server 2008 R2 PDCE’s cannot create an outbound or two-way trusts to NT 4.0 due to fundamental security changes . We have a specific article in mind for this right now, but the KB942564 was updated to reflect this also. No, this will not change. No, there is no workaround.  

    The real solution here is to stop expending all this energy to be insecure and keep ancient systems running. You obviously have newer model OS’s in the environment, just go whole hog. Upgrade, migrate or toss your NT 4.0 environments. Windows 2000 support just ended, for goodness sake, and it was 5 years younger than NT 4.0! For every one customer that tells me they need an NT 4.0 domain for some application to run (which no one ever actually checks to see if that’s true, because they secretly know it is not true), the other nineteen admit that they just haven’t bothered out of sheer inertia.

    Let me try this another way – go here: This is the list of all Microsoft security bulletins in the past seven years. For five of those years, NT 4.0 has not gotten a single hotfix. Windows 2000 – remember, not supported now either – has gotten 174 security updates in the past four years alone. If you think your NT 4.0 environment is not totally compromised, it’s only because you keep it locked in an underwater vault with piranha fish and you keep the servers turned off. It’s an OS based on using NTLM’s challenge response security, which people are still gleefully attacking with new vectors.

    You need Kerberos.


    We use a lot of firewalls between network segments inside our environment. We have deployed DFSR and it works like a champ, replicating without issues. But when I try to gather a health report for a computer that is behind a firewall, it fails with an RPC error. My event log shows:

    Error Event Source: DCOM
    Event Category: None
    Event ID: 10006
    Date: 7/15/2010
    Time: 2:51:52 PM
    User: N/A
    Description: DCOM got error "The RPC server is unavailable."


    If replication is working with the firewall but health reports are not, it sounds like DCOM/WMI traffic is being filtered out. Make sure the firewalls are not blocking or filtering the DCOM traffic specifically; a later model firewall that supports packet inspection may be deciding to block the DCOM types of traffic based on some rule. A double-sided network capture is how you will figure this out – the computer running MMC will connect remotely to DCOM over port 135, get back a response packet that (internally) states the remote port for subsequent connections, then the MMC will connect to that port for all subsequent conversations. If that port is blocked, no report.

    For example here I connect to port 135 (DCOM/EPM), get a response packet that contains the new dynamic listening port to connect for DCOM – that port happens to be 55158 (but will differ every time). I then connect to that remote port in order to get a health diagnostic output using the IServerHealthReport call. If you create a double-sided network capture, you will likely see the first conversation fail, and if it succeeds, the subsequent conversation will be failing. Failing due the firewall dropping the packets and them never appearing on the remote host – that’s why you must use double-sided.

    Click me


    I know USMT cannot migrate local printers, but can it migrate TCP-port connected printers?


    No, and for the same reason: those printers are not mapped to a print server that can send you a device driver and they are (technically) also a local printer. Dirty secret time: USMT doesn’t really migrate network printers, it just migrates these two registry keys:


    So if your printer is in those keys, USMT is win – and the only kind that live there are mapped network printers. When you first logon and access the printer on your newly restored computer, Windows will just download the driver for you and away you go. Considering that you are in the middle of this big migration, now would be a good time to get rid of these old (wrong?) ways of connecting printers. Windows 7 has plenty of options for printer deployment through group policy, group policy preferences, and you can even make the right printers appear based on the user’s location. For example, here’s what I see when I add a printer here at my desk – all I see are the printers in my little building on the nearest network. Not the ones across the street, not the ones I cannot use, not the ones I have no business seeing. Do this right and most users will only see printers within 50 feet of them. :)


    To quote from the book of Bourdain: That does not suck.


    What are the best documents for planning, deploying, and completing a forest upgrade from Win2000/2003 to Win2008/2008R2? [Asked at least 10 times a week – Ned]



    Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains

    If you are planning a domain upgrade, this should be your new homepage until the operation is complete. It is fantastic documentation with checklists, guides, known issues, recommended hotfixes, and best practices. It’s the bee’s knees, the wasp’s elbows, and the caterpillar's feets.



    Moving on to other things not directly sack-related…

    There are a couple of interesting takeaways from Black Hat US 2010 this week:

    • We announced our new Coordinated Vulnerability Disclosure process. Adobe is onboard already, hopefully more to come.
    • These folks claim they have a workable attack on Kerberos smart card logons. Except that we’ve had a way to prevent the attack for three years, starting in Vista using Strict KDC Validation – so that kinda takes the wind out of their sails. You can read more about how to make sure you are protected here and here and soon here. Pretty amazing also that this is the first time – that I’ve heard of, at least – in 11 years of MS Kerberos smart cards that anyone was talking attacks past the theoretical stage.
    • Of 102 topics, 10 are directly around Microsoft and Windows attacks. 48 are around web, java, and browser attacks. How much attention are you giving your end-to-end web security?
    • 10 topics were also around attacking iPhones and Google apps. How much attention are you giving those products in your environment? They are now as interesting to penetrate as all of Windows, according to Black Hat.
    • 5 topics on cloud computing attacks. Look for that number to double next year, and then double again the year after. Bet on it, buddy.

    Finally, remember my old boss Mike O’Reilly? Yes, that guy that made the Keebler tree and who was the manager in charge of this blog and whom I worked with for 6 years. Out of the blue he sends me this email today – using his caveman Newfie mental gymnastics:


    I never ever read the Askds blog when I worked there.  I was reading it today and just realized that you are funny. 

    What a guy. Have a nice weekend folks,

    - Ned “I have 3 bosses, Bob” Pyle

  • Goodbye Windows 2000

    On April 9, 1999 the first Windows 2000 Active Directory domain went online in Redmond Washington. Microsoft’s first truly enterprise operating system had been born.


    After 11 years and countless follow-up OS versions, Windows 2000 retired today and it is no longer supported. It will live on only in our memories… and as a steel space goat, hell bent on revenge.


    If you still have Windows 2000 in your environment and just felt your left arm go numb while reading this, you might want to visit the Win2000 migration solution center:

    - Ned “what do I do with this old MCSE certification now?” Pyle

  • No Friday mail sack

    Ned here again. This week has been hecklacious and I did not find time for the Sack. Actually I’m still in the office at 8:15PM on a Friday with no end in sight. I might be able to pull off a “Sunday Mail Sack”. Or maybe Tuesday. We’ll see.

    Go enjoy some sunshine, you need the vitamin D. Like me here… sort of.


    - Ned “why don’t some of you go on vacation and stop calling, dangit?!?!” Pyle

  • Service Pack 1 Beta out for Windows 7 and Windows Server 2008 R2

    Ned here again. You may have missed this on Monday, but the Beta version of Service Pack 1 for Win7/2008R2 was publically released. Besides offering the usual bevy of hotfixes and security update rollups, SP1 also offers servers two big new features: Hyper-V Dynamic Memory and RemoteFX.

    Download Windows 7 and Windows Server 2008 R2 Service Pack 1 (SP1) Beta here

    Dynamic Memory Technical Overview whitepaper

    Remote Desktop Services Datasheet

    But those features are the just ones the Marketing people want to broadcast from their secret tower made of Swarovski crystal skulls.


    Yep, Office clipart. Seriously, we need to start drug testing over there.

    There are a variety of other new features being evaluated here, plus many fixes. Make sure you check out this download site:

    Documentation for Windows 7 and Windows Server 2008 R2 Service Pack 1 Beta (KB976932)

    It includes the following three docs:


    If you read the “notable changes” doc you will find these other improvements:

    • Enhancements to scalability and high availability when using DirectAccess
    • Support for Managed Service Accounts (MSAs) in secure branch office scenarios
    • Support for increased volume of authentication traffic on domain controllers connected to high-latency networks
    • Enhancements to Failover Clustering with Storage
    • Additional support for communication with third-party federation services
    • Enhanced support for additional identities in RRAS and IPsec
    • Support for Advanced Vector Extensions (AVX)
    • Other stuff that sounds kinda boring.

    Finally, I want to make sure you are clear on the support model: No formal product support is available from Microsoft for this beta product. If you want to report things or get some informal, best effort, forum-only support, visit:

    If you are the EULA reading type, we reiterate this again. Special note should be made of the fact that we do not want you installing this in your production environments at all – only test. I’m serious about this and you should be too; your boss is going to be impressed if you say you are testing SP1; if you need to reinstall a DC that is now dead from a beta service pack, I doubt you will get that bonus.





    Feel free to send us comments, we can always pass them along to the beta team – it includes our very own Mike Stephens! Just don’t ask when the final version will be released, we don’t know.

    Have fun testing!

    - Ned “I prefer Pandora Chamilia” Pyle

  • Reminder: Windows 2000 Support ends July 13 (and other lifecycle stuff for 2003, XP, SfU)

    Ned here again. If you’ve been under a rock for the past year, here it is one more time:

    Windows 2000 support ends on July 13, 2010

    That is just a week from now. For more info on how to upgrade, migrate, and otherwise remove the last traces of Win2000 from your environment, make sure you head here immediately:

    Other major milestones on July 13th include:

    • Windows Server 2003 enters extended support
    • Windows XP SP2 (i.e. without SP3 installed) support ends
    • Windows Services for UNIX 2.0 support ends

    For more info on what mainstream, extended, and end of support policies mean, make sure you review:

    This is your final warning. The next time I post on this it’s to say goodbye to the venerable operating system that launched Active Directory more than a decade ago.

    - Ned “lonesome trail” Pyle

  • ADMT 3.2: Common Installation Issues

    Hello folks, Ned here again. ADMT 3.2 was released a few weeks ago and we have a decent understanding of common installation issues that you might run into. Hopefully this helps you unblock or prevents you from blocking in the first place someday. One of these is headed to a KB near you as it’s too tricky to figure out and people are likely to hit it even when doing everything “right” otherwise.


    SQL Server 2008 SP1 install returns error "Invoke or BeginInvoke cannot be called on a control unit until the window handle has been created.."


    ADMT 3.2 requires SQL Server 2005 Express with SP3 or SQL Server Express 2008 with SP1, and when attempting to install ADMT you are given a link to the 2008 version. However, when attempting to install this download on Windows Server 2008 R2, the installation fails with:

    "SQL Server Setup Failure.
    SQL Server Setup has encountered the following error:
    Invoke or BeginInvoke cannot be called on a control unit until the window handle has been created.."



    This error is purely within SQL Express 2008 and is not really to do with ADMT 3.2. The issue is fixed in "Cumulative update package 4 for SQL Server 2008".

    Unhelpfully, this error is identified in KB975055 as being only for Windows 7 and that it was fixed by SP1 - both incorrect. The issue does affect Win2008 R2 and is only fixed by the cumulative update.


    Before installing SQL Server Express 2008 with SP1 (which will fail), first install:

    Cumulative update package 4 for SQL Server 2008

    Once this is installed (can even be installed without SQL being installed at all) then you can install SQL Server Express 2008 with SP1 without errors, and then you can install ADMT 3.2 and point to this instance.

    More Information

    It's perfectly alright to instead use SQL Express 2005 SP3 instead of SQL Express 2008 SP1. It will install and run fine on Win2008 R2, and since you are using SQL Express anyway, it's not like you were customizing anything or trying to use existing infrastructure.

    ADMT 3.2 install error "admtinst.exe is not a valid Win32 application"


    When attempting to install ADMT 3.2, you receive error:

    “Admtinst.exe is not a valid Win32 application"



    You are attempting to install ADMT 3.2 anywhere but on Windows Server 2008 R2.


    ADMT 3.2 can only be installed on Windows Server 2008 R2. Don’t fight it!

    More Information

    This is by design behavior.


    ADMT 3.2 install error "The Active Directory Migration Tool v3.1 must be installed on Windows Server 2008."


    When installing ADMT 3.2, you get error:

    “The Active Directory Migration Tool v3.1 must be installed on Windows Server 2008.”



    You are installing ADMT 3.2 on a Windows 7 computer.


    ADMT 3.2 can only be installed on Windows Server 2008 R2. I really mean it!

    More Information

    Sigh… an old error string got referenced here by mistake. The block is intentional and expected, however. If you try to install on a Windows Server 2008 R2 core server, it will also say “v3.1” incorrectly.


    ADMT 3.2 error "Unable to connect" when connecting to a remote SQL instance


    When installing ADMT 3.2 you are prompted with the Database Selection screen:


    If you enter a remote “server\instance”, the following error is always returned:

    "Unable to connect to 'server\instance', please ensure the SQL Server hosting this instance is running and connections can be made to this instance. [DBNETLIB][ConnectionOpen (Connect().]SQL Server does not exist or access denied."


    If you use a local instance of SQL running on the computer, no issues.


    The remote instance is running SQL Server Express edition (2005 SP3 or 2008 SP1, it doesn't matter). ADMT is not allowed to connect to remote SQL Express instances. Even if configuration work is done on the Express instance to allow remote connections, the error will then change to:

    "The specified instance is hosted on a SQL Server version that is not supported. Use SQL Server 2005 or SQL Server 2008. We recommend you install the latest SQL Server service packs. If you are using SQL Server 2005 Express Edition, you must install SP3 or later. If you are using SQL Server 2008 Express Edition, you must install SP1 or later. Only local installations are supported for SQL Server Express Editions."


    Note: this is the same error you would get trying to use an unsupported version of SQL, such as SQL 2008 R2 or SQL 2000.


    If you want to use multiple ADMT 3.2 consoles to connect to a single remote SQL instance, that instance must be running SQL Server 2005 or 2008, and not an Express edition.

    More Information

    This behavior is by design. The requirement is also documented in the ADMT 3.2 migration guide (, in section "Installing ADMT v3.2":

    ADMT v3.2 requires a preconfigured instance of SQL Server for its underlying data store. You should use SQL Server Express. When you use one of the following versions of SQL Server Express, ADMT installation enforces the following service pack requirements:
    SQL Server 2005 Express must be installed with Service Pack 3 (SP3) or later.
    SQL Server 2008 Express must be installed with Service Pack 1 (SP1) or later.
    If you use SQL Server Express, the ADMT console must be installed and run locally on the server that hosts the SQL Server Express database instance.
    As an option, you can use full versions of SQL Server 2005 or SQL Server 2008. In this case, you can install and run the ADMT console on a remote computer, and you can run multiple ADMT consoles on different remote computers. If you use a full version of SQL Server, ADMT installation does not enforce any service pack requirements.

    ADMT 3.2 installation incomplete, console error "cannot open database "ADMT" requested by the login"


    When installing ADMT 3.2 on a Windows Server 2008 R2 domain controller and using a SQL Express 2008 with SP1 instance, the installation completes without errors.

    However, the “Active Directory Migration tool Installation Wizard” completion screen (like below) is not shown:


    Instead, the completion screen is blank (like below):


    When then attempting to run the ADMT console, you receive error:

    "Active Directory Migration Tool
    Unable to check for failed actions. :DBManager.IManageDB.1 : Cannot open database "ADMT" requested by the login. The logon failed."


    The MMC console then displays:

    "MMC could not create the snap-in.
    MMC could not create the snap-in. The snap-in might not have been installed correctly.
    Name: Active Directory Migration Tool
    CLSID: {E1975D70-3F8E-11D3-99EE-00C04F39BD92}"


    On Windows Server 2008 R2 member servers there are no issues. When using SQL Express 2005 SP3 there are no issues on DC's or member servers.


    A code defect in ADMT's interoperability with SQL Express 2008 SP1 on DC's where the expected "SQLServerMSSQLUser$ComputerName$InstanceName" group is not created. This is required by ADMT to configure specific permissions during the ADMT install and allows the ADMT database to be created in the SQL instance. ADMT does not expect the group to be missing, which leads to the blank dialog and an incomplete installation.

    I also wrote a KB on this and it’s coming soon.


    Workaround 1:

    The standard practice is to install ADMT on a member computer in the target domain. Install SQL Express 2008 SP1 on a Windows 2008 R2 member server in the target domain and then install ADMT 3.2 onto that same member server.

    Workaround 2:

    If you have a requirement to install ADMT 3.2 on a domain controller in order to use command-line or scripted user migrations with SID History, install SQL 2008 SP1 (non-Express edition) on a Windows Server 2008 R2 member server in the target domain and select that remote instance when installing ADMT 3.2 on the DC. Alternatively, you can install SQL Express 2005 SP3 on the DC.

    Workaround 3:

    If you have a requirement to install ADMT 3.2 and SQL Express 2008 SP1 on the same DC, use the following steps on target domain DC:

    1. Install Cumulative Update Package 4 for SQL Server 2008 on the DC -
    2. Install SQL Express 2008 SP1 on the DC - Note the SQL Instance name created during the install (default is SQLEXPRESS).
    3. Create a domain local group with the format of "SQLServerMSSQLUser$<DCComputerName>$<InstanceName>". For example, if the DC is named "DC1" and the SQL instance was "SQLEXPRESS" you would run the following command in an admin-elevated CMD prompt:


    4. Retrieve the SQL service SID by using the SC.EXE command with the name of the SQL service instance. For example, if the SQL instance was "SQLEXPRESS" you would run the following command in an admin-elevated CMD prompt and note the returned SERVICE SID value:


    5. In the Windows directory, create the "ADMT" subfolderfolder and a further subfolder of "Data". For example you would run the following command in an admin-elevated CMD prompt:

      MD %SystemRoot%\ADMT\Data

    6. Using the SID retrieved in Step 4, set FULL CONTROL permissions on the %SystemRoot%\ADMT\Data folder. For example, if the SID returned in Step 4 was "S-1-5-80-3880006512-4290199581-3569869737-363123133" you would run the following command in an admin-elevated CMD prompt:

      ICACLS %systemroot%\ADMT\Data /grant *S-1-5-80-3880006512-4290199581-3569869737-363123133:F

    7. Install ADMT 3.2 on the DC while selecting the local SQL Express 2008 instance.

    Wrap Up

    That’s everything we’re aware of currently. Like I said above, I have a KB coming shortly for the last issue mentioned, but it’s basically a copy of the above without pretty pictures. The ADMT migration guide will also be updated and (for the short term) the FWLINK that ADMT 3.2 points to when it sends you to a SQL install is going to be sending people to SQL Express 2005 SP3.

    - Ned “admit!” Pyle