Ned here again. Beginning in Windows Server 2008 R2, Active Directory supports an optional AD Recycle Bin that can be enabled forest-wide. This means that instead of requiring a System State backup and an authoritative subtree restore, a deleted DNS zone can now be recovered on the fly. However, due to how the DNS service "gracefully" deletes, recovering a DNS zone requires more steps than a normal AD recycle bin operation.

Before you roll with this article, make sure you have gone through my article here on AD Recycle Bin:

The AD Recycle Bin: Understanding, Implementing, Best Practices, and Troubleshooting

Note: All PowerShell lines are wrapped; they are single lines of text in reality.

Restoring a deleted AD integrated zone

Below are the steps to recover a deleted zone and all of its records. In this example the deleted zone was called "ohnoes.contoso.com" and it existed in the Forest DNS Application partition of the forest “graphicdesigninstitute.com”. In your scenario you will need to identify the zone name and partition that hosted it before continuing, as you will be feeding those to PowerShell. 

1. Start PowerShell as an AD admin with rights to all of DNS in that partition (preferably an Enterprise Admin) on a DC that hosted the zone and is authoritative for it.

2. Load the AD modules with:

Import-Module ActiveDirectory

3. Validate that the deleted zone exists in the Deleted Objects container with the following sample PowerShell command:

get-adobject -filter 'isdeleted -eq $true -and msds-lastKnownRdn -eq "..Deleted-ohnoes.contoso.com"' -includedeletedobjects -searchbase "DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com" -property *

Note: the zone name was changed by the DNS service to start with "..-Deleted-", which is expected behavior. This behavior means that when you are using this command to validate the deleted zone you will need to prepend whatever the old zone name was with this "..Deleted-" string. Also note that in this sample, the deleted zone is in the forest DNS zones partition of a completely different naming context, just to make it interesting.

4. Restore the deleted zone with:

get-adobject -filter 'isdeleted -eq $true -and msds-lastKnownRdn -eq "..Deleted-ohnoes.contoso.com"' -includedeletedobjects -searchbase "DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com" | restore-adobject

Note: the main changes in syntax now are removing the "-property *" argument and pipelining the output of get-adobject to restore-adobject.

5. Restore all child “DNSnode” objects of the recovered zone with:

get-adobject -filter 'isdeleted -eq $true -and lastKnownParent -eq "DC=..Deleted-ohnoes.contoso.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com"' -includedeletedobjects -searchbase "DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com" | restore-adobject

Note: the "msds-lastKnownRdn" has now been removed and replaced by "lastKnownParent", which is now pointed to the recovered (but still mangled) version of the domain zone. All objects with that as a previous parent will be restored to their old location. Because DNS stores all of its node values as flattened leaf objects, the structure of deleted records will be perfectly recovered.

6. Rename the recovered zone back to its old name with:

rename-adobject "DC=..Deleted-ohnoes.contoso.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=graphicdesigninstitute,DC=com" -newname "ohnoes.contoso.com"

Note: the rename operation here is just being told to remove the old "..Deleted-" string from the name of the zone. I’m using PowerShell to be consistent but you could just use ADSIEDIT.MSC at this point, we’re done with the fancy bits.

7. Restart the DNS service or wait for it to figure out the zone has recovered (I usually had to restart the service in repros, but then once it worked by itself for some reason – maybe a timing issue; a service restart is likely your best bet). The zone will load without issues and contain all of its recovered records.

Special notes

If the deleted zone was the delegated _msdcs zone (or both the primary zone and delegated _msdcs zone were deleted and you now need to get the _msdcs zone back):

a. First restore the primary zone and all of its contents like above.

b. Then restore the _msdcs zone like in step 4 (with no contents).

c. Next, restore all the remaining deleted _msdcs records using the lastKnownParent DN which will now be the real un-mangled domain name of that zone. When done in this order, everything will come back together delegated and working correctly.

d. Rename it like in step 6.

Note: If you failed to do step c before renaming the zone because you want to recover select records, the recovered zone will fail to load. The DNS snap-in will display the zone but selecting the zone will report “the zone data is corrupt”. This error occurs because the “@” record is missing. If this record was not restored prior to the rename simply rename the zone back to “..Deleted-“, restore the “@” record, rename the zone once more and restart the DNS Server service. I am intentionally not giving a PowerShell example here as I want you to try all this out in your lab, and this will get you past the “copy and paste” phase of following the article. The key to the recycle bin is getting your feet wet before you have the disaster!

A couple more points

• If the zones were deleted outside of DNS (i.e. not using DNS tools) then the renaming steps will be unnecessary and you can just restore it normally. If that happens someone was really being a goof ball.
• The AD Recycle Bin can only recover DNS zones that were AD-integrated; if the zones were Standard Primary and stored in the old flat file format, I cannot help you.
• I have no idea why DNS has this mangling behavior and asking around the Networking team didn’t give me any clues. I suspect it is similar to the reasoning behind the “inProgress” zone renaming that occurs when a zone is converted from standard primary to AD Integrated, in order to somehow make the zone invalid prior to deletion, but… it’s being deleted, so who could care? Meh. If someone really desperately has to know, ping me in Comments and I’ll see about a code review at some point. Maybe.

As always, you can also “just” run an authoritative subtree restore with your backups and ntdsutil.exe also. If you think my steps looked painful, you should see those. KB’s don’t get much longer.

- Ned “let’s go back to WINS” Pyle

KB Articles

Blogs

Post-Graduate AD Studies - Ned Pyle
Friday Mail Sack: Newfie from the Grave Edition - Ned Pyle
Parsing an AuditPol.exe Report with Windows PowerShell 2.0
More powershell & group policy
Best Practice: Group Policy Design Guidelines – Part 2
Troubleshooting errors with Adprep.exe
Using Color Rules to Show Direction
Remote Desktop Services Migration Guide is now available

KB Articles

Only one new KB article of interest this week:

Blogs

Mike here and today I want to answer a common customer request—how to force users to logoff at the end of the day. The scenario requires a bit of an explanation, so let’s get started.

Let’s recognize the value of forcing users to logoff at the end of their work day, rather than simply allowing them to lock their computer. Locking their computer leaves many processes running. Running processes keep files open. Open files may introduce problems with synchronizing user data with Offline Files, home folders and distributing user content to other replica targets. Also, roaming user profiles are updated only at logoff (with the exception of Windows 7 background upload of the ntuser.dat, which must be turned on through policy). Allowing users to remain logged on after hours provides little benefit (aside from people like Ned, who does not sleep for fear of clowns may eat him).

Everybody floats down here…

We force an after hour logoff using two Group Policy Preference Scheduled Task items. We’ll configure the items from a Windows Server 2008 R2 computer. Our targeted client computers are Windows 7 and Windows Vista. The typical business work day begins around 8am and ends between 5 and 6 pm. For this scenario, we’ll presume our workday ends at 5 pm. Our first scheduled task notifies the user the computer will shut down in 15 minutes. The second scheduled task actually shutdowns the computer.

Notify the user

We use the first scheduled task to notify the user they will be logged off in 15 minutes. This gives the user a reasonable amount of time to save their work. Ideally, users will save their work and logoff or shut down the computer within this allow time (once they understand their computer will log them off regardless). Our Group Policy Preference items target users; so, we’ll open GPMC and create a new Scheduled Task (Windows Vista or later) preference item.

We use the Update action for the Preference item and name the item DisplayLogoffMessage. The Update action creates the new scheduled task if it does not exist, or updates an existing task with the current configuration. Under the Security option select %LogonDomain\LogonUser% and select Run only when user is logged on.

Next, we need to configure when the event triggers. For this scenario, we want the event to trigger daily, at 5 pm. Also, ensure the status for the task is set to Enabled. Next, we’ll configure the action that occurs when the event triggers.

Select Display a message for the action. Type Afterhours Logoff in the Title box. In the Message box, type Windows will logoff your session in 15 minutes. Please save your work. Click OK.

Force the logoff

We’ve notified the user. Now we need actually force the logoff. We’ll use a new Schedule Task (Windows Vista or later) preference item.

We’ll configure the General tab similar to the previous preference item. We’ll use Update for the Action. The Name and Description can vary; however, understand that name is the criterion used to determine if the scheduled task exists on the applying computer. The only change we’ll make in the Triggers configuration is the time. We should configure this preference item should start at 5:15 pm.

The Action for our new preference item is going to Start a program. The program we’ll use is LOGOFF.EXE, which is included with Windows and resides in the System folder. We represent this by using a Group Policy Preference variable. In the Program/script: box, type %SystemDir%\logoff.exe. The LOGOFF.EXE program does not require any arguments.

We should have two Scheduled Task Preference item. The DisplayLogoffMessage should be ordered first and the Force_afterhours_logoff should be second. The only remaining configuration is to link the Group Policy object hosting these preference items to a point in Active Directory so it applies to user objects.

On to the client

Users on Windows 7 computers will process the above settings without any additional configuration. However, Windows Vista computers, including those running Service Pack 1 need the latest Group Policy Preference Client Side Extension (http://support.microsoft.com/kb/974266).

At 5 pm, the scheduled task triggers Windows to display a message to the user.

Fifteen minutes after the message, Windows will then end all the running applications and log off the user.

This is actually the hardest part of the scenario. However, there is one additional configuration we must perform on the user account to complete the solution.

We need to configure Logon Hours for the user. The Logon Hours should be configured to prevent the user from logging on the computer after we’ve forcefully logged them out. In this scenario, we forcefully log off the user at 5:15 pm; however, we’ve configured their user account so their logon hours deny them from logging on past 5 pm. Windows prevents the logon and displays a message to the user explaining they are not allowed to logon at this time.

Conclusion

The scenario explains how to administratively force a user session logoff to your environment. If users are members of the local Administrators group, then all bets are off. The only way to prevent an administrator from doing something is not to make them an administrator.

Alternatively, you can slightly modify this scenario to force a computer shutdown rather than a user logoff. Windows includes SHUTDOWN.EXE, with a variety of command arguments. This may be the most optimal form of power management because a powered down computer uses the least amount of energy. Also, forcing shutdowns will force users to save their work before leaving, which helps with making sure centralized backups have the most current and accurate user data.

Mike “Nice Marmot” Stephens

Ned here. Today I talk about the importance of the included USMT component manifests and how things can get gross when they are not available to Scanstate and Loadstate.

Here’s you

1. You are using USMT 4.0 to migrate from XP to Windows 7.
2. You run scanstate on XP and it appears to work fine (no unexpected errors to console or logs).
3. You run loadstate on Win7 and it appears to work fine (no unexpected errors to console or logs).
4. A zillion system settings are not migrated, so the user does not get their mapped printers and drives, shell settings, RAS settings, favorites, regional settings, etc; all the stuff here: 

• Accessibility settings
• Address book
• Command-prompt settings
• Desktop wallpaper
• EFS files
• Favorites
• Folder options
• Fonts
• Group membership.
• Windows Internet Explorer® settings
• Microsoft® Open Database Connectivity (ODBC) settings
• Mouse and keyboard settings
• Network drive mapping
• Network printer mapping
• Offline files
• Phone and modem options
• RAS connection and phone book (.pbk) files
• Regional settings
• Remote Access
• Taskbar settings
• Windows Mail.
• Microsoft Outlook Express Mail (.dbx) files are migrated from Windows XP.
• Windows Media Player
• Windows Rights Management

    5.   Everyone runs around screaming.

What’s Up?

The problem is that USMT cannot locate the folder containing the migration manifest files. There are two of these included with USMT 4:

DlManifests
ReplacementManifests

Here’s what will happen if they are not present:

• If running scanstate and loadstate with a full migration on XP and going to Vista/Windows 7 and you were missing the DLManifests folder, none of these settings I described earlier will migrate. Your log will show:

[0x000000] Downlevel Manifests folder is not present. System component settings will not be gathered.

• If running scanstate /genconfig without the DlManifests or ReplacementManifests folders, your config.xml file will not have any WindowsComponents settings in it at all and will only contain the ErrorControl entries, like so:

<?xml version="1.0" encoding="UTF-8"?>

<Configuration>

  <Applications/>

  <Documents/>

  <WindowsComponents/>

  <Policies>

    <ErrorControl>

      <!--   Example:

 

          <fileError>

            <nonFatal errorCode="33">* [*]</nonFatal>

            <fatal errorCode="any">C:\Users\* [*]</fatal>

          </fileError>

          <registryError>

            <nonFatal errorCode="5">* [*]</nonFatal>

          </registryError>

      -->

    </ErrorControl>

    <HardLinkStoreControl>

      <!--   Example:

 

          <fileLocked>

            <createHardLink>c:\Users\* [*]</createHardLink>

            <errorHardLink>C:\* [*]</errorHardLink>

          </fileLocked>

      -->

    </HardLinkStoreControl>

  </Policies>

  <ProfileControl>

    <!--   Example (local group mapping):

 

          <localGroups>

            <mappings>

              <changeGroup from="Administrators" to="Users" appliesTo="MigratedUsers">

                <include>

                  <pattern>DomainName1\Username</pattern>

                </include>

                <exclude>

                  <pattern>DomainName2\Username</pattern>

                </exclude>

              </changeGroup>

            </mappings>

          </localGroups>

         

      -->

    <!--   Example (domain and user mapping):

 

          <domains>

            <domain from="Domain1" to="Domain2"/>

          </domains>

         

          <users>

            <user from="Domain1\User1" to="Domain2\User2"/>

          </users>

         

      -->

  </ProfileControl>

</Configuration>

• If running scanstate and loadstate from Vista/7 to Vista/7, you may see various settings not work or other niggles not behaving as expected. Your log will show:

[0x000000] The ReplacementManifests folder used to service system component manifests is not present. OS settings migration will be done with system component manifests installed onto the system.

This is because these manifests are included by the component owners to handle special scenarios within migration, so you are falling back to using the manifests included in the OS for upgrades (which uses some of the same underlying USMT engine code). Your mileage may vary. A lot.

Nevermind that, what do I do?

The folders are often missing due to administrative misadventure – i.e. someone forgot to copy them and only copied the base files included in the USMT main folder. If you make sure they are present in the USMT working folder, you will be good to go. They were included for good reason reason and USMT is only tested with those files being included, so definitely do not intentionally discard them.

There are also a few reasons why they might not accidentally be found, based on how USMT was shelled. Both SCCM and MDT have bugs on this that are described and worked around:

• MDT bug with workaround - 
• SCCM bug with workaround

I’m not sure if those folks have plans to fix these permanently or what, the KB’s don’t indicate.

Note: Micheal Niehaus let me know offline that MDT is fixed in MDT 2010 Update 1 and the KB just needs to be update to reflect this. Thanks Michael. :-)

That’s all for now.

- Ned “precious fontses!!!” Pyle

Our excellent colleague Keith Combs found this movie created by Microsoft Learning.  It is both hilarious and sometimes frighteningly true. Really…

To avoid being in a movie yourself:

• Get trained
• Get certified
• Study hard

Then come and get it.

- Ned “I was the jacket guy in my interview” Pyle

Well, my wife complained one too many times about the old blog image. Now it’s a nice soothing blue with a more worldwide bend, plus some updated “artwork” courtesy of Visio and MS Paint (sorry for cutting you off Australia & New Zealand, sacrifices had to be made to the pixel gods). I also updated our About page to reflect modern times, such as how we’re support for ADFS and AppLocker. Obviously, no mail sack this week; things were just too busy and a lot of questions were repeats. I do have a new DFSR series in the works that I believe many of you will find useful, look for that to start soon. I believe Jonathan has some more PKI things underway as well.

Enough of work. Here’s some stuff that has nothing to do with pleasing your boss:

Ned “back on duty” Pyle

KB Articles

There are several articles below that are related to support of Single Label Domains, Disjointed Namespaces and Discontiguous Namespaces.  These will soon be linked to the DNS Namespace Planning Solution Center.  More on that here.

Blogs