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

  • 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

  • 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

  • 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

  • Get a 90 day trial copy of Windows 7 Enterprise

    Still not sure about taking the Windows 7 plunge in your company? Get a fully functional 90-day evaluation copy here.

    Guidelines on usage:

    • Protect your PC and data. Be sure to back up your data and please don’t test Windows 7 on your primary home or business PC.
    • You have 10 days to activate the product. If not activated within 10 days, the system will shut down once every hour until activated. Unsure on how to activate? Visit our FAQ.
    • The 90-day Trial is the full working version of the Windows 7 Enterprise, the version most of you will be working with in your corporate environment. It will not require a product key (it is embedded with the download).
    • The 90-day Trial will shut down once every hour when you have reached the end of the 90-day evaluation period.
    • The 90-day Trial is offered for a limited time and in limited quantity. The download will be available through March 31, 2010, while supplies last.
    • After the 90-day Trial expires, if you wish to continue to use Windows 7 Enterprise, please note that you will be required to purchase and perform a clean installation of Windows 7, including drivers and applications. Please keep this in mind; Windows 7 Enterprise is not available through retail channels.
    • Technical details/updates/questions: Please review our FAQ or visit the Windows 7 support forum.
    • Stay informed. You can keep up with general technical information and news by following the Springboard Series blog. Want technical guidance, tips, and tools? Visit the Springboard Series on TechNet.
    • Keep your PC updated: Be sure to turn on automatic updates in Windows Update in case we publish updates for the 90-day Trial.
    • Microsoft Partners-: Learn more about Windows 7 on the Microsoft Partner Portal.

    Still not sure after that? Seek medical attention, there's something wrong with you.

    :)

    Ned "get some!" 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

  • 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 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