Blog - Title

May, 2009

  • RSAT Release Candidate for Windows 7... ehh... Release Candidate

    Ned here again. The Remote Server Administration Tools (RSAT) have been released for Win7 RC. Grab them from:

    Here are the installation requirements:

    Supported Operating Systems: Windows 7
    Remote Server Administration Tools for Windows 7 RC can be installed on computers that are running the Professional, Enterprise, or Ultimate editions of Windows 7 RC.

    Remote Server Administration Tools for Windows 7 RC runs on both x86- and x64-based editions of Windows 7 RC, and can be used to manage roles and features that are running on either the Server Core or full installation options of the x64-based Windows Server 2008 R2 operating system. Remote management is also supported for some roles and features that run on Windows Server 2008 or Windows Server 2003.

    Remote Server Administration Tools for Windows 7 RC should not be installed on a computer that is running the Windows Server 2003 Administration Tools Pack or Windows 2000 Server® Administration Tools Pack. Remove all versions of Administration Tools Pack or Remote Server Administration Tools for Windows Vista SP1 from the computer before you install Remote Server Administration Tools for Windows 7 RC.

    Only one copy at a time of Remote Server Administration Tools for Windows 7 RC can be installed on a computer. Before you install a new package, remove any existing copies of Remote Server Administration Tools for Windows 7 RC. This includes any copies that are in different languages.

    And as if you didn't already know, Client and Server OS RC's are out and available to all...

    As always, feel free to post issues or questions in our Comments section below.

    - Ned Pyle

  • Five common questions about AdminSdHolder and SDProp

    Ned here again. After a few years of supporting Active Directory, nearly everyone runs into an issue with AdminSdHolder. This object and its AD worker code is used by Domain Controllers to protect high-privilege accounts from inadvertent modification – i.e. if an administrator account was moved into an OU that was being maintained by an delegated OU admin, it makes sure the high-privilege permissions are not stripped away. You can probably think of a few reasons why allowing a member of Enterprise Admins to be monkeyed with is a Bad Thing™.

    Anyhoo, the way this works is there’s a special object located at:


    Any security descriptors for those groups listed on that object are re-stamped on the user object members every 60 minutes. So you may have run into this where you had made some custom ACL changes on your Administrator user that was a member of some OU, then found an hour later that your changes had disappeared. All by design, all well-and-good. There is also the related SDProp code, which computes and fixes up group memberships for Administrative groups. Both tasks operate only on the PDC Emulator.

    So here are the questions Microsoft gets asked most commonly about this system, and where we haven’t always done the best job documenting answers – until now. :-)

    Question: How does the AdminSdHolder operation determine whether or not to ACL an account?

    Answer: It is based on transitively expanding the list of (possibly nested) protected groups. The attribute AdminCount was originally used only as an optimization to improve performance, since it was assumed that regardless of group membership, AdminCount being 1 should trigger protection. However from repro's on Windows Server 2003 and source code review, it appears this is no longer enough to actually trigger the AdminSdHolder operation all on its own.

    When a Security Principal is a member of a protected group its Security Descriptor is stamped with the SD of the AdminSDHolder Object for that domain. Also the Security Principal's adminCount attribute is set to value 1. If the SD of the security principal in question already matches the SD of the AdminSDHolder Object, the object is left untouched. Consequently its adminCount value could potentially remain 0. So using AdminCount is a pure mark of whether or not a user is protected is not always a good idea – the group membership is the key.

    Question: What is AdminCount, and why is it not being decremented to ‘0’ or ‘<not set>’ when I remove a user from a Protected Group?

    Answer: AdminCount is an attribute on the user account that is set to 1 on any users being protected by AdminSdHolder. When protected, the user gets this attribute set and the security inheritance bit is removed from their account.

    The reason AdminCount isn’t set back to 0 when the user is removed from a protected group is that you told us not to! A survey of customers early on in Windows 2000's design found that they favored deleting a user account after its high-privilege rights were revoked, as the account could have created explicit backdoors before having its rights stripped. Therefore the DC does not remove the AdminCount attribute entry, as it is assumed that the account is going to be disabled or deleted.

    If for some reason you didn’t want to get rid of that account after ‘de-admining’ it, you must manually set back to allowing inheritance and set AdminCount to 0, usually through ADSIEDIT.MSC..

    Question: Is it possible to make AdminSDHolder code run more or less frequently? What about SDProp?

    Answer: Yes, with a big caveat.

    To change the frequency of AdminSdHolder in SDPRop, set the following through regedit:

    "AdminSDProtectFrequency"= <something>

    The value is a DWORD and you can set a range from 60 to 7200 decimal (it's in seconds). By setting it to 60 you would override the default 60 minute wait time and it would fire every minute. By setting to 7200 it would run every 2 hours.

    Note that lowering the default is NOT recommended except for lab testing due to the potential LSASS performance ramifications in a large environment. I.e. doing this could cause your DC’s processor to spike to very high sustained levels and drastically hurt you.

    You can cause SDProp to run once ‘right now’ by using the steps in KB 251343 to execute FixUpInheritance.

    Question: Is there a way to warn administrators that a user being manipulated is covered under AdminSDHolder and SDProp? How do we stop Admins from doing ‘bad’ stuff like this?

    Answer: Nope, you just gotta know.

    As to how you stop Administrators from doing theoretically ‘bad’ stuff – with great power comes great responsibility; AdminSDHolder can only protect you so far from yourself. This is similar to customers who ask us ‘how do I keep administrators from reading all the files on the network?’ The answer is: you cannot. Trust your administrators, bond your administrators, or get different administrators.

    Question: Where are all the best articles on AdminSdHolder and related… stuff?


    • Description and Update of the Active Directory AdminSDHolder Object - KB 232199.
    • Delegated permissions are not available and inheritance is automatically disabled - KB 817433.
    • How To Delegate the Unlock Account Right (which is often why you run into this) – KB 294952.
    • AdminSdHolder Open Specification Document - AdminSDHolder.
    • Michael B. Smith has an excellent and very readable article on his blog here.

    And that’s that.

    - Ned ‘Turboprop’ Pyle

  • Temporary User Profiles and the Citrix ICA Client

    Howdy folks, Scott Goad again to talk about an issue that I thought you might find useful.

    I recently worked with a customer who opened a case for an intermittent profile issue. Windows XP workstations would not load the local profile, resulting in the user receiving a temporary profile. The issue seemed to happen when a user logged off and then needed to log back into the workstation, resulting in the temporary profile.

    We started the usual troubleshooting steps for working on this type of profile load problems. We enabled USERENV debug logging (more on that here). The customer readily enabled the logging and proceeded to reproduce the issue. They were able to gather a problematic log along with a saved copy of MSINFO32, which grabs the processes running and their associated Process ID. This is useful to identify what process is running, which is recorded in the USERENV log. The USERENV log did show a problem:

    USERENV(350.354) 10:32:02:454 Local Existing Profile Image is reachable
    USERENV(350.354) 10:32:02:454 Local profile name is <C:\Documents and Settings\**********>
    USERENV(350.354) 10:32:02:454 RestoreUserProfile:  No central profile.  Attempting to load local profile.
    USERENV(350.354) 10:32:02:485 MyRegLoadKey:  Failed to load subkey <S-1-5-21-*********-1284227242-725345543-121116>, error =32
    USERENV(350.354) 10:32:02:485 MyRegLoadKey: Returning 00000020
    USERENV(350.354) 10:32:02:501 RestoreUserProfile:  MyRegLoadKey returned FALSE.
    USERENV(350.354) 10:32:02:501 ReportError: Impersonating user.
    USERENV(350.354) 10:32:02:501 ReportError: Logging Error <Windows cannot load the locally stored profile. Possible causes of this error include insufficient security rights or a corrupt local profile. If this problem persists, contact your network administrator.

    DETAIL - The process cannot access the file because it is being used by another process.

    USERENV(350.354) 10:32:02:501 ErrorDialogEx: Calling DialogBoxParam
    USERENV(350.354) 10:32:02:501 ErrorDlgProc:: DialogBoxParam

    At this point we knew the problem was an issue with WINLOGON trying to load the profile, but couldn’t because another process was holding a file hostage within the profile. The USERENV log will tell us what process is being called, but here 350 (hexadecimal for 848) is WINLOGON:


    This was good to know, but not helpful as to why the profile could not be loaded. The next step in the troubleshooting process was to get a Process Monitor trace of the issue. This provided a bit of a challenge, since this happens at logon. We used Process Monitor and enabled boot logging, which started a trace in the background. The customer had to restart the workstation for the logging to start, and try to reproduce the problem.

    When the problem was reproduced, USERENV logged the following 1508 event in the Application Log:


    Now we knew what to look for in the Process Monitor trace, so we cracked the PML file open and set a few filters. After filtering the trace, we saw where the problem resides. We started with including the path of UsrClass.dat and also to exclude RESULT is SUCCESS. This showed the problem, which is a SHARING VIOLATION. Here is a screenshot of the trace, with the surrounding events displayed (removing the RESULT is SUCCESS filter):

    The culprit process in this trace appears to be SSONSVR.exe. The details can be seen here:




    At this point we engaged Citrix and looked into the issue. This has been documented as a known problem with the 10.200 release of the Citrix ICA client, and is fixed in a future release. Citrix has documented the issue in their knowledge center, and a link is detailed below.

    The issue presents itself in Windows XP (all current service packs) where prefetch loads SSONSVR.exe into memory to enhance boot time performance. This is causing a race condition with WINLOGON and SSONSVR trying to both access the profile, resulting in the SHARING VIOLATION.

    The customer was in the process of rolling out the 10.200 version of Citrix ICA Client, so they decided to go with disabling prefetch for the SSONSVR.exe process, as outlined in KB 969100, by deleting the SSONSVR*.pf from %SYSTEMROOT%\prefetch directory at logoff.


    969100 When you log on to a Windows XP-based computer that is running version 10.200 of the Citrix ICA client, Windows XP may create a user profile instead of loading your cached profile;EN-US;969100

    Citrix Knowledge Center – User Client Computer Profile is not Loaded Properly when Single Sign-on is Enabled -

    221833 How to enable user environment debug logging in retail builds of Windows;EN-US;221833

    Understanding How to Read USERENV logs – AskDS Blog by Mark Ramey

    Process Monitor v2.04


    Until next time,

    Scott “Scooter” Goad

  • Understanding Password Policies

    Hey everybody, its Randy again to discuss Password Policies. I recently had a case that required excruciating detail of how Password Complexity is calculated and I will now take that opportunity to discuss some interesting facts. I need to begin this discussion by directing you to the Account Lockout Best Practices Whitepaper. This paper explains all the meanings of the various password policy settings that can be defined in the domain group policy.

    Most of these settings are pretty self explanatory. If you open your default domain policy and editAccount Lockout Policy, you will see that we have several settings listed.

    Enforce Password History: When changing your password, will you be required to use a different password than previous passwords and how many previous passwords are remembered. One additional note to Password History is that it is not case sensitive. See example below:

    - For uniqueness comparison, a new password must be at least one character different than the passwords in history, with the exception that upper and lower letters do NOT count.

    That is, if “Password1” is in password history then the following will be unique since there is at least 1 character different.

    Password2 (due to 2).

    Passw0rd1 (due to numeral “0” instead of o).

    Password[ (due to symbol “[” instead of 1).

    But following will NOT be unique since upper and lower letters are the same.




    Minimum Password Length, Maximum Password Age, and Minimum Password Age are all self-explanatory and are well explained in the Account Lockout Best Practices Whitepaper.

    Password Complexity: When changing a password, you will be required to use a password that meets the domain password complexity requirements. In Windows NT, this was controlled by an add-on password filter named passfilt.dll. A password filter is a procedure that is called during the password change request. LSA (Local Security Authority) will take the incoming password change request and load the password filter and then perform whatever task the filter has defined. You can make a password filter do just about anything, but typically it is used for password synchronization between separate platforms or a series of validations to confirm that a password change meets the company requirements. It is possible to create your own password filters as well, if you’re handy with C++. In Windows 2000 and later password complexity policies are now coded directly into the operating system as part of LSA, but the complexity requirements remain the same. You can find articles on MSDN with simplified explanations of these grammar checks, hopefully the information below will provide more detail:

    From this Microsoft TechNet article, I found the following discrepancies in our documentation:

    If this policy is enabled, passwords must meet the following minimum requirements when they are changed or created:

    From this Technet article:
    1. Not contain significant portions of the user's account name or full name.

    We look at the entire Account Name and the Full Name. We ensure that the Password does not contain the entire name of either. We also parse through the Account Name and Full Name for delimiters: commas, periods, dashes/hyphens, underscores, spaces, pound-signs and tabs. If any are found, the Account Name or Full Name are split and all sections are verified not to be included in the password. We do not check for any character or any three characters in succession.

    From this Technet article:
    2. Be at least six characters in length.

    Password complexity does NOT check password length.

    From this Technet article:
    3. Contain characters from three of the following four categories:

    English uppercase characters (A through Z)
    English lowercase characters (a through z)
    Base 10 digits (0 through 9)
    Non-alphabetic characters (for example, !, $, #, %)

    It is three of 5 categories. The four categories listed above and a catch-all category of any Unicode character that does not fall under the above four categories. This fifth category can be regionally specific.

    Complexity requirements are enforced when passwords are changed or created.

     The last setting, Store Passwords using reversible encryption, should never be used with a specific need. It is just available for compatibility with legacy apps using CHAP authentication. If you have an application or remote access policy requiring this setting then update it or replace it. You are essentially storing your passwords in plaintext.

    I just touched on a couple of points here, but the Account Lockout Best Practices Whitepaper is filled with a lot of really good information. I can’t leave without dropping some Windows 2008 science on you. So here is a tidbit of information on Fine-Grained Password Policies:

    One big concern from customers of Windows Server 2003 was that you could only set Password Policy at one location in the domain and the only way to separate these policies in your organization was to create separate domains. This has changed with Windows 2008 and Fine-Grained Password Policy. With Fine-Grained Password Policy, you can create different Password Settings Objects (PSO) and assign these PSOs to security groups in your organization. A PSO is simply a Password Policy stored in Active Directory to hold all the defined settings of that Password Policy. You can then associate the PSO to the security groups that you want to adhere to these settings. Here is a good step-by-step to setting this up in your 2008 domain.

    [Editors note: We are working to get that TechNet article with the incorrect info (and any others like it) hunted down and fixed.]

    - Randy Turner

  • Now we're multilingual

    Translate this page

    Ned here. The invite finally came through, and AskDS now supports a built-in MS Translation widget. It's linked on the left column (scroll down a bit). Simply select your native language and the blog will magically turn from English to Spanish, German, French, Italian, Russian, Polish, Chinese, Dutch, Japanese, Korean, Portuguese, or Arabic. Probably with occasionally hilarious mistranslations, but overall hopefully quite accurate and helpful. 


    - Ned Pyle

  • ADMT 3.1 and Windows Server 2008 R2

    Hello All,

    UPDATE June 19 2010 - stop reading and go here:


    There’s a known issue with installing Active Directory Migration Tool (ADMT) v3.1 onto a Windows Server 2008 R2 computers that I want to bring to everyone’s attention. At this time it has been acknowledged that version 3.1 (which does require Windows Server 2008) returns the following error when attempting to install it onto R2:

    "ADMT must be installed on Windows Server 2008"

    This issue also occurs with Windows 2008 machines that previously had ADMT installed, and then upgraded to Windows 2008 R2. ADMT will no longer function correctly and returns the same error as detailed above. Microsoft is aware of the issue and diligently working on a resolution. Please stay tuned for further details and updates.

    I’d also like to take this opportunity to ask that you send me any future feature suggestions and requests for the tool, as I’ve been asked to present results of the “voice of the customer”. The ADMT development group would like to hear from our customers on how we could make the product better. Please feel free to post comments or email your recommendations and suggestions in what you’d like to see in a later release of ADMT.

    Happy migrating!

    -Jason Fournerat

  • SYSVOL migration from FRS to DFSR - Whitepaper Released

    Ned here. It's done, it's out, come get it, stop yelling at me! :-)

    SYSVOL Replication Migration Guide: FRS to DFS Replication (TechNet Version)
    SYSVOL Replication Migration Guide: FRS to DFS Replication (Word Doc Version)

    Be sure to also run through some of these (possibly) useful accompanying pieces:

    Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style
    DFSR SYSVOL Migration FAQ: Useful trivia that may save your follicles
    KB968733 (hotfix for migration under certain RODC scenarios)
    KB967326 (hotfix for migration under disjoint name space scenarios)

    - Ned 'Yes, my middle name is DFSR' Pyle

  • Event ID 22 on a Windows 2008 Terminal Services Licensing Server

    Hi all, Akhlesh here. Recently I’ve seen a few cases where the customers were getting event ID 22 on their Windows 2008 Terminal Services Licensing server (TSLS):

    Log Name: System
    Source: Microsoft-Windows-TerminalServices-Licensing
    Event ID: 22
    Task Category: None
    Level: Warning
    Keywords: Classic
    User: N/A
    The Terminal Services license server "TS licensing server name" does not have any
    Terminal Services client access licenses (TS CALs) installed and registered with
    the Microsoft Clearinghouse for product "Windows Server 2003 - Terminal Server Per
    Device CAL Token". Therefore, the Terminal Services license server cannot issue TS
    CALs of the type "Windows Server 2003 - Terminal Server Per Device CAL Token" to
    the terminal server "IP of a TS". To resolve this problem, install additional TS
    CALs as required.

    Before I talk about the cause and resolution of this event, please follow the steps given below and make sure that the given conditions are true in your scenario*:

    • Your Windows 2008 TSLS is activated. How to Activate a Terminal Services License Server?
    • Terminal Services Licensing service is running on that TSLS.
    • Your Windows 2008 TSLS is a member of "Terminal Services License Servers" group in the Active Directory.
    • Your Windows 2008 TSLS is listed in the site in AD sites and services (if it is a DC).
    • The Terminal Server listed in the event is able to access your Windows 2008 TSLS i.e. TSLS discovery process is working fine and we are able to open TSLS snap-in from the Terminal Server. If you are using a GPO to publish the TSLS, make sure that the GPO is getting applied on that Terminal Server.
    • Please check and make sure that the users are able to connect to the Terminal Server listed in the event.
    • Please check and make sure that we have enough CALs available on the Windows 2008 TSLS and those CALs are getting issued to the clients

    *If all the points given above are true in your case, you can ignore this event.

    Now, let’s discuss why this warning event is still getting logged on that TSLS even when all the points discussed above are true in your scenario:

    It looks like your TSLS is working the way it should. You are getting the event because of client machines which took TS CALs from a Windows 2003 TS Licensing Server which has been decommissioned in your domain. At the renewal time of the CALs for those clients, the TS forwarded the requests to the new w2k8 TSLS. The new TSLS didn’t find the references of those clients in its database so it couldn’t renew the CALs, therefore a warning event was resulted.

    But after that it must have issued CALs to those clients (assuming that we have enough CALs available). This event is showing the IP of the TS because TS will interact with TSLS on client's behalf for the issuance of the TS CAL.

    The event will stop occurring once TS CALs on all the clients will be renewed. To prove this theory, you can take a client machine for which the CALs is about to expire in the next few days. Then connect to a w2k3 TS, see if you get an event on w2k8 TSLS. Then check the list of issued CALs and see if that client is listed on the new TSLS or not.

    - Akhlesh Sharma