Blog - Title

November, 2009

  • Implementing Content Freshness protection in DFSR

    Hi all, Ned here again. Starting in Windows Server 2008 and continuing in Windows Server 2008 R2, DFSR supports a protective mechanism called “Content Freshness”. Today I’ll discuss this protection, how to implement it, and what to do when it swings into operation.

    Background

    Content Freshness is an admin-defined setting that you can set on a per-computer basis when using DFSR on Win2008 or Win2008 R2 – it does not exist on Windows Server 2003 R2. The DFSR database has a record for each Replicated Folder (RF) called CONTENT_SET_RECORD. This record contains a timestamp called “LastConnected”. We store this record on a per-Replicated-Folder basis because it’s possible for a replicated folder to be current when it’s connected to other members in that replication group. At the same time, another replicated folder can be stale because it is not connected with other members in its replication group. Every day, DFSR updates this timestamp to show the opportunity for replication occurred. When attempting replication for an RF between computers, the DFSR service checks if the last time replication was allowed is older than the freshness date. If the last-allowed-replicated date is newer, it replicates. If it’s not, we block replication.

    By now, you’re asking yourself “why would I want to block replication.” Good question. DFSR has a JET database just like Active Directory, and it uses multi-master replication just like AD. This means that it must implement tombstones to deleted items to replicate. When a file is deleted in DFSR, the local database records the deletion as a tombstone in the database – a logical deletion. After 60 days DFSR garbage collects the record from the database and it is truly gone – a physical deletion. Online defragmentation of the database can now reclaim that whitespace. The 60 days allows all the replication partners to learn about the deletion and act on it.

    And herein lays the problem. If a DFSR server cannot replicate an RF for more than 60 days, but then replication is allowed later, it can replicate out old deletions for files that are actually live or replicate out stale data and overwrite existing files. If you’ve ever worked on an Active Directory “lingering object” issue, you have seen what can happen when a DC that was offline for months is brought back up. This is why Strict Replication Consistency was invented for AD – Content Freshness protection is the same thing.

    Being “unable to replicate” can mean any one of these scenarios:

    • Disabling the replication connections.
    • Deleting the replication connections (either one-way or in both directions).
    • Stopping the DFSR service.
    • Closing the schedule (i.e. setting “no replication”)
    • Keeping the server shut off.

    This whole content freshness idea is novel enough that we went to the trouble of applying for a patent on it.

    Implementing Content Freshness Protection

    Content Freshness protection is not enabled by default. To turn it on you simply modify the DfsrMachineConfig setting for MaxOfflineTimeInDays on each DFSR server with:

    wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=<some value>

    The recommendation is to set the value to 60:

    wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60

    Remember, this has to be done on all DFSR servers, as this change only affects the computer itself. This value is not stored in a central AD location, but instead in the DfsrMachineConfig.XML file that resides in the hidden operating system folder “%systemdrive%\system volume information\dfsr\config”:

    image

    You can also view your existing MaxOfflineTimeInDays with:

    wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    Remember, by default this protection is OFF and be assumed to be zero if there are no entries in the DfsrMachineConfig.xml.

    Note: Sharp-eyed admins may notice that we actually have an AD attribute stamped on every Replication Group called ms-DFSR-TombstoneExpiryInMin that appears to control tombstone lifetime. It even has the value - in minutes - for 60 days. Sorry to disappoint you, but this attribute is never read by DFSR and changing it has no effect – tombstone lifetime garbage collection is always hard-coded to 60 days in the service and cannot be changed.

    Protection in Action

    Let’s see how all this works. My repro environment:

    • A pair of Windows Server 2008 R2 computers named 2008r2-fresh-01 and 2008r2-fresh-02
    • Replicating in a Replication Group named “RG1”
    • Using a Replicated Folder named “RF1”
    • Keeping a few user files in sync.
    • MaxOfflineTimeInDays set to 60 on 2008r2-fresh-02

    Important note: I am going to simulate the offline time by rolling clocks forward. Never ever do this in production – this is for testing and demonstration purposes only. Also, I only set MaxOfflineTimeInDays on one server – you would do this on all servers.

    So here’s my data:

    image

    Now I stop DFSR on 2008r2-fresh-02 and roll time forward to January 1st, 2010 on both servers - about 75 days from this writing. I then make a few changes on 2008r2-fresh-02.

    image

    And then I start the DFSR service back up on 2008r2-fresh-02.

    • My changed files do not replicate out
    • New files do not replicate in

    I now have this event:

    Log Name:      DFS Replication
    Source:        DFSR
    Date:          1/1/2010 3:37:14 PM
    Event ID:      4012
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      2008r2-fresh-02.blueyonderairlines.com
    Description:
    The DFS Replication service stopped replication on the replicated folder at local path c:\rf1. It has been disconnected from other partners for 76 days, which is longer than the MaxOfflineTimeInDays parameter. Because of this, DFS Replication considers this data to be stale, and will replace it with data from other members of the replication group during the next replication. DFS Replication will move the stale files to the local Conflict folder. No user action is required.
    Additional Information:
    Error: 9061 (The replicated folder has been offline for too long.)
    Replicated Folder Name: rf1
    Replicated Folder ID: 5856C18F-CA72-4D2D-9D89-4CC1D8042D86
    Replication Group Name: rg1
    Replication Group ID: BC5976EF-997E-4149-819D-57193F21EC76
    Member ID: FAEC4B17-E81F-4036-AAD9-78AA46814606

    Note: this event has incorrect wording. The first two sentences in the description are good, but the following sentences are wrong. DFSR does not self-correct this situation, it does not move files into the ConflictAndDeleted folder, and you, the user, have actions you need to take. More on this later.

    The DFSR Debug logs will show (edited for brevity):

    20100101 15:37:14.410 1008 CSMG 5504 [WARN] ContentSetManager::CheckContentSetState This replicated folder has not connected to other partners for a long time. lastOnlineTime: [*** Logger Runtime Error:-114757888 ***]

    20100101 15:37:14.410 1008 CSMG 7492 [ERROR] ContentSetManager::Initialize Failed to initialize ContentSetManager csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} csName:rf1 Error:

    + [Error:9061(0x2365) ContentSetManager::CheckContentSetState contentsetmanager.cpp:5596 1008 C The replicated folder has been offline for too long.]

    20100101 15:37:14.410 1008 CSMG 7972 ContentSetManager::Run csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} csName:rf1 state:InitialBuilding

    20100101 15:37:14.504 1948 SRTR 957 [WARN] SERVER_EstablishSession Failed to establish a replicated folder session. connId:{5E05AE2A-6117-4206-B745-7785DB316F74} csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} Error:

    + [Error:9028(0x2344) UpstreamTransport::EstablishSession upstreamtransport.cpp:808 1948 C The content set was not found]

    The state of the replicated folder will be “In Error” – i.e. set to 5:

    wmic.exe /namespace:\\root\microsoftdfs path DfsrReplicatedFolderInfo get ReplicationGroupName,ReplicatedFolderName,State

    ReplicatedFolderName   ReplicationGroupName   State
    rf1                               rg1                               5

    The above is Content Freshness protection in action. It is protecting your DFSR environment from sending divergent data out to the rest of your working servers.

    Recovering DFSR from Content Protection

    Important note: Before repairing the blocked replication, get a backup of the data on the affected server and its partners. Failure to do will tempt Murphy's Law to disastrous new heights. Understand that by following these steps below, any DFSR data that was on this server and never replicated will be moved to PreExisting and/or ConflictAndDeleted - this server goes through non-authoritative sync again and loses all conflicts with other DFSR servers. You have been warned!!!

    Also, whatever is being done to stop replication from working needs to be ironed out - whether it is leaving the service off for months on end or not having any connections. Otherwise this is just going to happen again.

    To get things back in order, do the following:

    1. Start DFSMGMT.MSC on the affected server.

    2. On any affected replication groups this server is a member of, select the computer on the Membership tab and "Disable" it.

    image

    3. Accept the warning prompt.

    image

    4. If the reason for replication never occurring was the schedule being set to "no replication" on the RG or RF, or no bi-directional connections being place between servers, fix that situation now.

    5. Force AD Replication and verify it has converged.

    6. On the affected server, run:

    DFSRDIAG.EXE POLLAD

    7. Wait for the 4008 and 4114 events being written to the DFSR event log to confirm that the replicated folder(s) are no longer being replicated.

    8. In DFSMGMT.MSC, "Enable" the replication again on the affected replicated folders for that server.

    9. Force AD replication and POLLAD again.

    The server goes through non-authoritative initial sync, as if it was setup the first time. All matching data is unchanged and does not replicate. Any files on the server that do not exist on its authoritative partner are moved to the PreExisting folder. Any files on the server that have been changed locally are moved to the ConflictAndDeleted folder and the authoritative server's copy is replicated inbound.

    The Sum Up

    Content Freshness protection is a good thing and putting it in place may someday save you some real pain. Trust me – we work cases here where Content Freshness being enabled would have stopped huge problems. All it takes is Windows Server 2008 or later, and a few moments of your time.

    - Ned “Kool and the Gang” Pyle

  • Auditing Password and Account Lockout Policy on Windows Server 2008 and R2

    Ned here again. Let’s talk about auditing your domain for changes made to Password and Account Lockout policies. Frankly, it’s a real pain in the neck to figure out Password and Account Lockout auditing and there are legacy architectural decisions behind how this all works, so I’ll make sure to cover all the bases. This also includes auditing your Fine Grain Password policies (FGPP), for you bleeding-edge types.

    Understanding how these policies work

    We use Password and Account Lockout policies to control domain authentication. Password policies set requirements for things like password length, complexity, and maximum age. Account Lockout policies control lockout threshold and duration, and are very popular with The Devil.

    There are two types of Password and Account Lockout policies in a domain:

    • Domain-wide – Introduced in Windows NT and set in Active Directory through domain security policy.
    • Fine Grained – Introduced in Windows Server 2008 and set in AD through manual means like ADSIEDIT or AD PowerShell. It configures settings on a user or group-membership basis, and there can be as many as you like.

    Domain-based policy, while being set through security policy, is actually written to attributes on the root of the domain. ADSIEdit shows this object using the distinguished name of the domain name. This odd location results from providing NT 4.0 compatibility. Since NT 4.0 could not apply group policy, we had to store these values somewhere and answer requests about the settings in an NT fashion.

    image

    On the other hand, Fine Grained policies write to their own location. Windows stores each policy as a leaf object.

    image

    When you edit your built-in Default Domain password policy, you are actually editing:

    \\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

    All your settings are in this format:

    [System Access]
    MinimumPasswordAge = 0
    MaximumPasswordAge = 60
    MinimumPasswordLength = 8
    PasswordComplexity = 1
    PasswordHistorySize = 4
    LockoutBadCount = 50
    ResetLockoutCount = 30
    LockoutDuration = 30
    RequireLogonToChangePassword = 0
    ForceLogoffWhenHourExpire = 0
    ClearTextPassword = 0
    LSAAnonymousNameLookup = 0

    When DC applies this security policy during the five minute group policy refresh, the DC stamps these settings on the domainDNS object. And voila, you have your policies in place. But think about that – the DC stamps these settings in place when applying computer policy. Who do you think will be listed as the user in your audit event logs? That’s right – the DC itself. And that’s where this blog post comes in. :-)

    Auditing Domain-Wide Policy

    There are three main things you need to do to see domain-wide password and account lockout setting changes, but they differ slightly by OS:

    1. Put an auditing entry on the “Policies” container. Enabling auditing for EVERYONE on the “CN=Policies,CN=System,DC=<your domain>” container causes auditing to track all writes, deletes, and permission modifications. The audit event shows the user modifying group policy in general. Obviously, this is useful for more than just password policy changes – “Hey, who set this policy to push a Domo-Kun wallpaper out to all the computers?”

    image

    2. Enable subcategory auditing for:

        a. “Authentication Policy Change” (if using Windows Server 2008 R2 DC’s).

        b. “Other Account Management Events” (if using Windows Server 2008 DC’s).

    3. Enable subcategory auditing for “Directory Service Changes”.

        Note: In Windows Server 2008 R2, granular subcategory auditing is available through GPMC.

    image

    In Windows Server 2008, you need to use the script provided in KB921469.

    After enabling auditing, Windows then generates security audit events for anyone editing domain-wide security policy for passwords and account lockouts:

    1.    An event 5136 will be written that shows the versionNumber attribute of the policy being raised:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          10/24/2009 3:04:17 PM
    Event ID:      5136
    Task Category: Directory Service Changes
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      2008r2-f-01.contoso.com
    Description:
    A directory service object was modified.
    Subject:
        Security ID:        CONTOSO\Administrator
        Account Name:        Administrator
        Account Domain:        CONTOSO

        Logon ID:        0x1e936

    Directory Service:
        Name:    contoso.com
        Type:    Active Directory Domain Services
    Object:
        DN:    CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=POLICIES,CN=SYSTEM,DC=CONTOSO,DC=COM
        GUID:    CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com
        Class:    groupPolicyContainer
    Attribute:
        LDAP Display Name:    versionNumber
        Syntax (OID):    2.5.5.9
        Value:    121

     

     

    Note: The event ID shows the name of the user that modified the policy – every policy edit raises the version number. Now we know to go look at the policy and that someone changed it.

    2. Windows writes a follow-up event (event id 4739) for each type of change – lockout policy or password policy. For example:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          10/24/2009 3:01:28 PM
    Event ID:      4739
    Task Category: Authentication Policy Change
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      2008r2-f-01.contoso.com
    Description:
    Domain Policy was changed.

    Change Type:        Lockout Policy modified

    Subject:
        Security ID:        SYSTEM
        Account Name:        2008R2-F-01$
        Account Domain:        CONTOSO
        Logon ID:        0x3e7

    Domain:
        Domain Name:        CONTOSO
        Domain ID:        CONTOSO\

    Changed Attributes:
        Min. Password Age:    -
        Max. Password Age:    -
        Force Logoff:        -
        Lockout Threshold:    500
        Lockout Observation Window:   
        Lockout Duration:   
        Password Properties:   
        Min. Password Length:   
        Password History Length:   
        Machine Account Quota:   
        Mixed Domain Mode:   
        Domain Behavior Version:   
        OEM Information:    -

    ====

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          10/24/2009 3:04:23 PM
    Event ID:      4739
    Task Category: Authentication Policy Change
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      2008r2-f-01.contoso.com
    Description:
    Domain Policy was changed.

    Change Type:        Password Policy modified

    Subject:
        Security ID:        SYSTEM
        Account Name:        2008R2-F-01$
        Account Domain:        CONTOSO
        Logon ID:        0x3e7

    Domain:
        Domain Name:        CONTOSO
        Domain ID:        CONTOSO\

    Changed Attributes:
        Min. Password Age:    -
        Max. Password Age:    -
        Force Logoff:        -
        Lockout Threshold:    -
        Lockout Observation Window:    -
        Lockout Duration:    -
        Password Properties:    -
        Min. Password Length:    5
        Password History Length:    -
        Machine Account Quota:    -
        Mixed Domain Mode:    -
        Domain Behavior Version:    -
        OEM Information:    -

    Notice the account name is the DC itself. This event, while useful, needs to be correlated with the 5136 event to see what changed. And even then, these events can sometimes be difficult to understand – what is a “password property” after all? (it’s for complexity being turned on or off). You should probably use these events as a notification to go examine the actual policies in GPMC.

    You’re probably asking yourself why I didn’t just audit the actual domain root object and skip using the “Authentication Policy Change” and “Other Account Management Events”. This is another of the vagaries of security policy auditing – it doesn’t work. Simply auditing the “DC=domain,DC=com” object does not return any information about password or lockout changes. Go figure.

    Auditing Fine-Grained Policy

    Auditing FGPP is simpler and the data is easier to read. FGPP does not contain intermediate security policy settings. Creating and modifying these policies directly edits the objects in Active Directory. You can create or modify FGPP using PowerShell, LDP, LDIFDE, or ADSIEDIT. This means there’s no layer between doing work on your behalf. Also, your audit events are clean and self-evident.

    1. Put an auditing entry on the “Password Settings Container” container. Enabling auditing for EVERYONE on the “CN=Password Settings Container,CN=System,DC=<your domain>” object causes Windows to track all users who write, delete, and modify permissions on any FGPPs.

    image

    2. Enable subcategory auditing for “Directory Service Changes” (see previous section for steps).

    After enabling auditing, Windows generates a security audit event for anyone editing FGPPs for each change made. Also, the audit event includes the new value and the value prior to the change:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          10/24/2009 4:20:54 PM
    Event ID:      5136
    Task Category: Directory Service Changes
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      2008r2-f-01.contoso.com
    Description:
    A directory service object was modified.
    Subject:
        Security ID:        CONTOSO\RobGreene
        Account Name:        RobGreene
        Account Domain:        CONTOSO

        Logon ID:        0x1e936

    Directory Service:
        Name:    contoso.com
        Type:    Active Directory Domain Services
    Object:
        DN:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
        GUID:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
        Class:    msDS-PasswordSettings
    Attribute:
        LDAP Display Name:    msDS-PasswordComplexityEnabled
        Syntax (OID):    2.5.5.8
        Value:    TRUE
    Operation:
        Type:    Value Deleted
        Correlation ID:    {6afa8930-85cd-44d9-828b-9cc3c1b5a8b9}
        Application Correlation ID:    -

    ===

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          10/24/2009 4:20:54 PM
    Event ID:      5136
    Task Category: Directory Service Changes
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      2008r2-f-01.contoso.com
    Description:
    A directory service object was modified.
    Subject:
        Security ID:        CONTOSO\RobGreene
        Account Name:        RobGreene
        Account Domain:        CONTOSO

        Logon ID:        0x1e936

    Directory Service:
        Name:    contoso.com
        Type:    Active Directory Domain Services
    Object:
        DN:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
        GUID:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
        Class:    msDS-PasswordSettings
    Attribute:
        LDAP Display Name:    msDS-PasswordComplexityEnabled
        Syntax (OID):    2.5.5.8
        Value:    FALSE
    Operation:
        Type:    Value Added
        Correlation ID:    {6afa8930-85cd-44d9-828b-9cc3c1b5a8b9}
        Application Correlation ID:    -

    Here I can see the user RobGreene logged on and changed the password complexity requirements from TRUE to FALSE. I knew it! Rob Greene, always breaking my stuff…

    See Edie, I told you I’d write a blog post on this. :-)

    - Ned “the chiropractor” Pyle

  • Group Policy Preferences Logging and Windows 7

    Hi all, Mike here again. Back in July of 2007, I posted a blog explaining how to enable Group Policy Preferences debug logging using RSAT. As a refresher, Group Policy Preferences debug logging is enabled through Group Policy administrative templates. Many customers experienced a problem when trying to enable the logging using RSAT and Windows Vista: the policy settings did not exist. You’ll experience the same behavior when using Windows 7 RSAT.

    clip_image002
    Figure 1 Windows 7 RSAT View

    The Group Policy Preferences administrative template is not included with Windows 7; however, it is included in Windows Server 2008 R2. The simply solution is copy the ADMX and ADML files from Windows Server 2008 R2 to the Windows 7 computer. Or, you can copy the files from this blog post. The procedure remains the same as it was from Windows Vista. Check out the blog from July 2007 for the detailed procedures.

    clip_image004
    Figure 2 Windows 2008 R2 GPMC view

    Note: There are some subtle differences between the Vista and Windows 7 Group Policy Preferences administrative templates—no change in functionality—but many string names have changed in the ADL file. Do not try to mix and match the ADMX from one version of Windows with the ADML of another.

    Mike “Neebler-Treehouse builder” Stephens

  • Understanding USMT 4.0 Behavior with UEL and UE

    Ned here again, reporting live from the tree. Today I am going to explain an expected behavior with USMT 4.0 when using the /UEL and /UE switches. These have been causing some confusion as mass migrations to Windows 7 have commenced.

    Background

    The UEL option in USMT is used to exclude user profiles based on their last logon date. You can exclude by number of days, by a specific cutoff date, or just any currently logged on users. The UE option allows you to exclude user profiles from being migrated based on their name. It supports wildcards and domain versus local users. For example:

    Exclude any users named “administrator”:

    SCANSTATE.EXE /ue:*\administrator

    Exclude any Contoso domain users named like “admin”:

    SCANSTATE.EXE /ue:contoso\admin*

    Exclude any profiles that haven’t been logged on in more than 60 days:

    SCANSTATE.EXE /uel:60

    Exclude any profiles that haven’t been logged on since July 1, 2009:

    SCANSTATE.EXE /uel:2009/07/01

    An administrator migrating XP and Vista computers to Windows 7 can use these options to make sure crusty old accounts and special users – such as the local administrator or a service account – are not migrated.

    So far so good? Here comes the confusing bit.

    Behavior

    USMT has a ton of internal rules that control what it does when options are overlapped. UEL and UE both do similar things – they exclude user profiles. What you might expect is that if you specify both settings, any users specified by UE are excluded, and then any other profiles that are older than UEL are also ignored.

    You’d be expecting incorrectly.

    USMT precedence does not always merge settings – it overrides settings. In this case, using UEL and UE together results in UE being completely ignored. So if a user has logged on within the UEL timeframe - even if they are excluded by UE - they are considered part of the gathered migration units. This behavior is by design.

    It certainly makes more sense to me that UE should take precedence. After all, as an Administrator, I know the users that I want to block from the migration. And, I also know that ancient accounts are not worth migrating; no one is using them. So I’d probably want my specific users excluded as well as any generic moldy oldies too.

    Workarounds

    All hope is not lost though. I have two workarounds for you, depending on the OS from which you are migrating.

    XP

    First, use the DELPROF.EXE utility on Windows XP to purge old user profiles prior to running the USMT SCANSTATE. This is a free download that allows you to specify the number of days to consider a profile valid, and delete any older ones. Using DELPROF, in a batch script with SCANSTATE, gets you the needed functionality. For example, here I am going to quietly delete any profiles older than 30 days, then USMT will exclude any users named “administrator”:

    DELPROF.EXE /q /i /d:30
    SCANSTATE.EXE /ue:*\administrator <additional USMT command-line>

    Vista or later

    If you’re migrating from Windows Vista, there’s a group policy you can use to automatically delete old profiles. By enabling “Delete user profiles older than a specified number of days on system restart” you get the same effect as DELPROF on XP – any profiles older than your specified days are removed automagically during the computer startup. By putting this policy in place before you start migrating computers, you can run your SCANSTATE with just the UE option. Remember that the client computer must be restarted for this policy to run.

    Important note: Make sure you have installed SP2 or hotfix KB945122 before deploying this group policy!

    You can read more about this group policy here. For the folks that like pictures:

    image

    All Operating Systems

    Use different settings in the Scanstate versus Loadstate phases. So if you used:

      scanstate [options] /uel:14

    and

      loadstate [options] /ue:*\something
      <or>
     loadstate [options] /ue:something\*


    Then you would get the desired result. The downside to this workaround is that you would be unncessarily gathering data and possibly making the scanstate run much longer/be much larger.

    Wrap Up

    Hopefully this helps clear things up for you on migrating with USMT. It’s interesting to note that this behavior exists with USMT 3.01 as well, but since Vista could be upgraded directly from XP, most folks never ran into the problem. Removing extraneous profiles prior to running a USMT migration is always a good idea – it makes the migration faster and less error prone. So using DELPROF or Group Policy can be considered a best practice.

    For plenty more info on using USMT 4.0 to migrate computers, I recommend:

    Ned “what are you waiting for, go deploy Win7” Pyle

  • I Hate Mondays

    The lesson here is if you go on vacation for a week, make sure your boss is gone too. Otherwise he will do this to your cubicle:

     Ned 016-small

    HPIM1393-smallNed 021-small 

    Ned 019-small

    Which just goes to show how important a manager’s time really is, of course. Ah well, at least I got some cookies.

     HPIM1396-small

    I hate you Mike.

    - Ned “Neebler Elf” Pyle

  • New Directory Services KB Articles/Blogs 11/23-11/28

    KB

    970536

    Setspn.exe support tool update for Windows Server 2003

    977510

    Authentication fails when an external client tries to log on to a Windows Server 2008 server by using a read-only domain controller in a perimeter network

    977564

    Error message on a domain controller that is running Windows Server 2008: "The client-side extension could not remove user policy settings for 'Domain Name {GUID}' because it failed with error code '0x8007000d The data is invalid.'"

    977748

    A hotfix is available to update the Daylight Saving Time for the Fiji Standard Time time zone for the year 2009 for Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2-based computers

    977511

    About the DFS Namespaces service and its configuration data on a computer that is running Windows Server 2003 or Windows Server 2008

    974674

    Description of the Windows NT Backup Restore Utility for Windows 7 and for Windows Server 2008 R2

    Blogs

    Redirecting Well Known Containers (CN=Users; CN=Computers etc.)

    No Frames Captured Due to Disk Quota

    You Don’t Have to Be An Administrator to Run Remote PowerShell Commands

    userPassword

  • New Directory Services KB Articles/Blogs 11/1-11/21

    Sorry for the lack of posts the last two weeks. I was away on vacation. Now back to our regularly scheduled program. Happy Thanksgiving!

    KB

    976618

    You experience performance issues in applications and services when the system file cache consumes most of the physical RAM

    954371

    The Remote Desktop Web Connection client does not work after you upgrade to Windows Vista Service Pack 1

    976470

    The "Date and Time" window shows "Date out of range" error message

    977518

    You receive DFSR event ID 2212, and DFSR stops after you restart Windows Server 2008

    975697

    An LDAP client authentication request fails when the Digest-MD5 SASL subsequent authentication mechanism is used

    975696

    The Account Name, Account Domain, and Security ID fields are not populated in event ID 5136 for "Directory Service Changes" on a computer that is running Windows Server 2008

    975566

    SceCli 1202 events are logged every time Computer Group Policy settings are refreshed on a computer that is running Windows Server 2008 or Windows Vista

    977519

    Description of security events in Windows 7 and in Windows Server 2008 R2

    977513

    Error message when you try to use the "runas" command, the "Run as Administrator" option, or the "Run as a different user" option after you upgrade from Windows Server 2003 or from Windows Server 2008 to Windows Server 2008 R2: "Access is denied"

    977158

    DNS updates may be incorrectly reported as failed when you use a third-party DNS server application for DNS registration on a computer that is running Windows Server 2008 R2 or Windows 7

    977321

    The security principals and the services that use only DES encryption for Kerberos authentication are incompatible with the default settings on a computer that is running Windows 7 or Windows Server 2008 R2

    976918

    Server applications may be incompatible with default behavior of authentication protocols by Windows 7 clients

    974405

    Description of Windows Identity Foundation

    Blogs

    Auditing Password and Account Lockout Policy on Windows Server 2008 and R2

    Implementing Content Freshness protection in DFSR

    Group Policy Preferences Logging and Windows 7

    Identity Roadmap Presentation at PDC09

    Group Policy Automation Engine wins Editor's Choice Gold!

    Restore of an object or subtree

    WireShark 1.2.4 is available…

    Haiku for Fun and Prizes

    BitLocker to Go Reader – now available for download

    Windows 7 DirectAccess Explained

    Thrive Live! Migrating Windows XP to Windows 7 Using Windows Easy Transfer and USMT

    When You Can't Save Frames From the UI

    I Can Do That With 1 Line of PowerShell: Installed Software

    Tips & Tricks #2 – CMD: Command Prompt from here

    Interesting Question from Customer at Teched Europe 2009

    Recovering your files in Windows 7

    Tips & Tricks #1 – UAC: Shortcut key using mouse and/or keyboard

    Using AD-Powershell to protect OUs from accidental deletion

    Remote Desktop Services: Announcements

    Per User CAL Reporting Script

    Migrating your local users, local groups and memberships from the SAM into AD

    djoin.exe not a Powershell command

    Out-of-Band Releases of PowerShell v2 are out

    Viewing and Comparing IE Security Zone Settings - enhanced

    Correction for Group Policy Settings added to Windows 2008

    How to revert the forest functional level in Windows Server 2008 R2

    Announcing the launch of Remote Desktop Services Script Center to ease management

    Group Policy Cmdlets in Windows PowerShell Released!

    Just Me … and my Profile … (Part 2)

    RDP 7 for Windows XP and Windows Vista - now available for download

    Windows Management Framework: PowerShell 2.0 & WinRM 2.0 are available

    Group Policy Preferences : Colorful and Mysteriously Powerful, just like Windows 7

    Win7 issue reporting on Software Restriction Policies

    Accessing Replication Metadata using ADPowerShell

  • New Directory Services KB Articles/Blogs 10/25-10/31

    KB

    975830

    The memory usage of the Dns.exe process keeps increasing after you install hotfix 941672 on a computer that is running Windows Server 2003 SP2 and that has the DNS server role installed

    972622

    The Active Directory Application Mode index may become corrupted if you search the instance by using the LDAP virtual list view control

    975792

    Numeric host names cannot be resolved on a computer that is running Windows Vista or Windows Server 2008

    969371

    Error message when you run a command at the Command Prompt window in Windows Server 2008 Server Core: "The specified service does not exist as an installed Service"

    975943

    Error code when an application uses the CredSSP if the authenticated user account is a member of many security groups on a computer that is running Windows Vista or Windows Server 2008: "0x80090329"

    976921

    A DFSR propagation report logs the following error on a Windows Server 2008 domain controller: "Cannot open test file on the member The network path was not found."

    976922

    The "Run only allowed Windows applications" Group Policy setting displays no entries on a computer that is running Windows Vista, Windows Server 2008, or Windows 7

    968929

    Description of the Windows Management Framework on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008

    974522

    A LDAP simple bind action fails on a domain controller that is running Windows Server 2008 if the distinguished name of the user account exceeds 256 characters

    976427

    Computers that are running Windows 7 or Windows Server 2008 R2 stop responding at a black screen if a screen saver is enabled

    977110

    How to select time zone for countries or regions that are not listed in Windows time zone list

    Blogs

    Explanation of the Remote Desktop Services CAL Upgrade behavior in Windows Server 2003 and Windows Server 2008

    DFS Referrals and IPv6: Outta site!

    How to Decommission an ADAM/ADLDS server and Add Additional Servers

    Using ADMT 3.1 to migrate to Windows Server 2008 R2 domains

    Learn more about system image backup

    Quick, Dirty, Super-Useful Scripting

    Remote Desktop Load Simulation Toolset

    DNSSEC Security Guide – update now available

    Free MS Press ebook: Introducing Windows Server 2008 R2

    Snapshot recovery tool strikes back

    Cross post: Terminal Server 2003 issues with Group Policy Preferences History Folder

    Announcing the availability of Remote Desktop Connection 7.0 for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2

    Update: Free P2V tool: Disk2Vhd.exe – Command line support

    Cool new tool for comparing IE Zone Security Settings

    Powershell v2 is yours!

    Windows Management Framework is here!

    New DirectAccess documentation is now available

    Optional configuration for the DFS Replication Management Pack

    Windows 7 - Do I need to change my Active Directory for new Group Policy features?

    Configuring the DFS Replication Management Pack

    Scalable Networking Pack revisited for 2008