Windows XP Favourites Redirection – ADMX files

One of the major disadvantages of still running XP in production is its lack of Internet Explorer Favourites directory redirection. If your users frequently roam between computers, the usual workaround is to enable Roaming Profiles to have the favourites roam with them. This usually works, until Windows Vista or 7 is introduced into the environment.

The newer Microsoft operating systems from Vista onwards do not support the old, legacy format of the XP profile. Instead, users logging on to a modern OS for the first time will be given a new roaming profile with “.V2″ appended to their username in the roaming profile share. This is the version 2 profile, used by Vista up and totally isolated from the XP profile, including total isolation of the data it contains. In a phased roll-out of the newer Microsoft operating systems, you must follow best practices by using folder redirection to redirect user data on all systems to a common network location. This removes the data from the profiles, maintains consistency and ensures the user experience is the same on all network stations, without concerns over which OS is installed and therefore which profile and data the user will have access to. Plus, roaming profiles are just too slow for storing lots of user data anyway.

Unfortunately, Windows XP does not support redirection of the Favourites directory; this support was added in Windows Vista. One workaround I have seen is the built-in Vista redirection configured to redirect user favourites folders on newer systems to the legacy XP roaming profile share. This works, but it’s not particularly clean; redirecting data to a profile share rather than a user (home folder) share just isn’t right. It also causes data loss issues if a user’s profile must be reset; I work by the principle that only disposable data – stuff the users could live without – should be put into a user’s profile for precisely this reason.

Implementing Favourites redirection in Windows XP is a logical alternative; it isn’t particularly difficult either. I developed the following ADMX files to supplement the older ADM solutions which are available through a search on a popular web search engine. With 2008 or 2008 R2 Domain Controllers, the ADMX format is available for your use and I would highly suggest you make use of it. ADMX is XML-based and much, much easier to use than the legacy ADM language.

XPFavouritesRedirect.admx

<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="customFavorites" namespace="Microsoft.Policies.Favorites" />
    <using prefix="inetres" namespace="Microsoft.Policies.InternetExplorer" />
  </policyNamespaces>
  <resources minRequiredRevision="1.0" />
  <supportedOn>
    <definitions>
      <definition name="SUPPORTED_IE5" displayName="$(string.SUPPORTED_IE5)" />
    </definitions>
  </supportedOn>
  <policies>
    <policy name="IE_Favorites" class="User" displayName="$(string.IE_Favorites)" explainText="$(string.IE_Favorites_Location_Explain)" presentation="$(presentation.IE_Favorites)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders">
      <parentCategory ref="inetres:InternetExplorer" />
      <supportedOn ref="SUPPORTED_IE5" />
      <elements>
        <text id="IE_Favorites_Location" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" valueName="Favorites" required="true" expandable="true" />
      </elements>
    </policy>
  </policies>
</policyDefinitions>

XPFavouritesRedirect.adml (name this the same as the ADMX file and dump it in the language folder in your PolicyDefinitions directory)

<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName>
  </displayName>
  <description>
  </description>
  <resources>
    <stringTable>
      <string id="IE_Favorites">Location of Internet Explorer Favorites</string>
      <string id="IE_Favorites_Location">The path to the favorites folder</string>
      <string id="IE_Favorites_Location_Explain">Specify the path to the location of your Favorites folder. This is stored in an expandable registry string value, so you can use environment variables, such as %HomeDrive%%HomePath%.</string>
      <string id="IE_Favorites_Location_Tip1">Specify the UNC path to the favorites location</string>
      <string id="InternetExplorer">Internet Explorer</string>
      <string id="SUPPORTED_IE5">at least Internet Explorer v5.01</string>
    </stringTable>
    <presentationTable>
      <presentation id="IE_Favorites">
        <textBox refId="IE_Favorites_Location">
          <label>Path:</label>
          <defaultValue>
          </defaultValue>
        </textBox>
      </presentation>
    </presentationTable>
  </resources>
</policyDefinitionResources>

The above is standard ADMX/ADML format which can be dumped in the correct locations of your Central Store (if you don’t have one, why not? Set one up, otherwise you will need to store them in the local store on each DC). In the GP Editor, it will appear as a policy in the standard Internet Explorer area under the User Configuration / Windows Components node.

The Favourites registry value in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders is of type REG_EXPAND_SZ. The ADMX implements this with the expandable=”true” syntax, meaning from your perspective, you can specify environment variables in the GPO and these will be properly expanded by the system to their full paths. I personally use %HomeDrive%%HomePath%\Favourites to direct them to a subfolder of the user’s defined home folder location in their Active Directory user account properties.

This does not move any existing Favourites out of the profile and into the redirected location. However; this is fairly easy to script in a logon script or one-time operation. For new users, the Favourites directory will be created automatically, assuming the home drive exists, the user has permissions, quota is not fully used and so on.

It is a good idea to set the XP Favourites redirection policy in its own GPO object, then apply a WMI condition to filter the policy to XP/2003 and older systems only. Windows Vista and above support native redirection of Favourites, so you should use a separate, WMI filtered policy for Vista+ computers to redirect their Favourites to the same location as defined for XP clients.

APC Powerchute vs. Windows Power Management

I was recently trialling APC Powerchute on a small SBS 2008 server, attempting to maintain some automated shutdown while also gleaning some stats on how frequently the UPS was intervening. I’ve used the software before, but this time it refused to play ball; I saw the stats, but it never shut the server down on power failure. Not good; I’d rather know the data was safe than be told how many times it wasn’t safe.

So, I reverted to the fallback option. An APC UPS (the USB connected ones, not sure about serial) can run under Windows’ power management, being configured and monitored in exactly the same way a battery in a laptop would. Thus, they truly are plug-and-play; some less reputable brands require their own monitoring software and aren’t nearly as effective in my experience.

Alas, uninstalling the software never restored Windows Power Management. I waited… rebooted… checked control panel… nothing. No mention of a battery in the power options and the power meter icon was disabled in the task tray. I’d lost all shutdown functionality from the UPS. Yet again, a routine job involving a computer turned in to a match of man vs. machine.

The fix was surprisingly simple, didn’t involve edits to the registry (which I fear when it comes to drivers and hardware and critical things like power) — but unintuitive:

1. Open Device Manager, expand Batteries, locate the UPS and uninstall it. Be sure to uninstall the driver too when asked
2. Wait a few minutes for that to complete, then on the Action menu, hit Scan for hardware changes
3. Sure enough, the UPS was detected again, the drivers installed fresh and my power icon in the task tray immediately restored

It would appear APC Powerchute doesn’t fully tidy up after itself.

What’s new in Windows Server Backup R2?

The upcoming Windows Server 2008 R2 has a wealth of new features and improvements over the original 2008 release. One such improvement is in the built-in backup tool, Windows Server Backup.

Some History of Server Backup

In the early Windows 2000/2003 days, Microsoft’s entire line of products included a basic backup utility called NTBackup. This tool allowed administrators to configure simple backups for their servers, and was aimed primarily at those deploying servers in small to medium-sized business environments. It included technologies from Veritas, the company who originally developed Symantec Backup Exec.

The original release of Windows Server 2008 sparked an outcry when it was discovered NTBackup was replaced with a new Microsoft technology, Windows Server Backup. This tool was both an improvement and a set-back in backup technology; it supported backing up to Virtual Hard Disk (VHD) files (which can be mounted by Microsoft’s Virtual Server or Hyper-V for recovery of data), but it didn’t have support for backing up individual files/directories, or for backing up to a network share using its Graphical User Interface (GUI). Workarounds were available for continuing to support NTBackup on this OS, but they were not supported.

Networked Backup

Windows Server Backup now has support for configuring a scheduled backup to a network share via the GUI. Previously, you were required to run a manual batch command to use this feature — which led to a loss of fidelity in your backup procedure. As shown in the screenshot, the ‘Backup Schedule’ wizard, linked from the ‘Actions’ pane to the right of the backup console, now includes this much awaited ‘Backup up to a shared network folder’ option.

Windows Server Backup R2 allows backups to shared folders via the GUI

Unfortunately, functionality has been improved but there has been no improvement if you were intending to deploy any advanced backup programme which retains multiple copies. Selecting the Shared Folder option in the wizard prompts a warning to appear, indicating you can only store one copy of a shared backup when placing them on the network. This is a significant difference to harnessing the built-in backup-to-disk technology, where multiple backups are kept and only overwritten when the disk is full.

Shared Folder Backups Warning

Many companies deploying network backup are doing so as part of a larger backup scheme, which may later duplicate the backup to tape or hard disk for off-site storage. Anyone deploying shared network backup via this technique as their main backup should remember that it will allow a full server recovery, but won’t help in situations where documents created and destroyed 3 weeks ago need to be recovered; they will long since have been overwritten.

Granular File Backup

The original Windows Server Backup release only allowed the backup of server volumes – it was not possible to be granular in what files or folders you wished to backup. In 2008 R2, NTBackup support for specifying individual files/folders has been restored — for both once-only backups (started using the ‘Backup Once’ command and for scheduled jobs.

The backup wizard prompts you for the type of configuration to start a backup for. You can choose the recommended “Full Server” option, which includes all hard disk volumes and critical data required for a recovery, or you can choose the “Custom” option. Selecting “Custom” allows you to specify a list of files and folders to include in the backup, using a standard Windows Explorer view.

The "Custom" option unlocks granular backup of files/folders on your server

You can select only the files/folders you need to backup

Unfortunately, a Scheduled Backup job only permits one job to be configured at a time; you cannot configure multiple jobs to backup different data at different times, for example. This task still needs to be done using the Command Line Tools/Powershell cmdlets and Task Scheduler.

System State

The ability to take a System State backup using the GUI has now been added – this was only available via the Command Line in the original release. This is selected as an item after picking the “Custom” option in the backup wizard.

System State backups are not supported in the GUI

System State backups are useful backups to have; they contain a copy of all the critical system files and of any Active Directory database information. For Administrators of Domain Controller (DC) servers, this option allows you to take a backup of all the critical files needed to recover Active Directory in an emergency, without delving into scripting your backup jobs.

Also added for the System State is the ability to take a backup via the Command Line or the GUI to a remote network share. The command wbadmin start systemstatebackup -backupTarget:\\server\share will no longer fail but actually proceed to create a backup of the server to the remote file share.

Bare Metal Recovery

The installation of Windows Server 2008 R2 (or a Windows 7 client, incidentally) automatically creates a reserved partition – the “System Reserved” partition – which is usually just a few hundred megabytes in size. This partition contains the Windows Recovery Environment (WinRE), and can be used to boot the server in the event the Operating System becomes corrupt or otherwise fails to boot.

In the previous file selection screenshots, you will notice there is a new option – “Bare Metal Recovery” – which can be selected as a type of backup. This option is very similar to the -allCritical command on most Windows Server Backup Command Line tools in both the original and the R2 release, and akin to the ASR option in NTBackup.

A Bare Metal Recovery takes a copy of all the files needed to recover the whole server to its state at the time of backup, including most of its configuration. This type of backup is sure to get your server running again in the event of a disaster, although it isn’t guaranteed to include any of your critical data. If you do a “Custom” backup job, ensure you include the “Bare Metal Recovery” option as well as a backup of your important files and network shares.

Conclusion

Although Windows Server Backup R2 is not perfect, it continues to satisfy the requirements of smaller businesses who cannot or do not wish to invest in enterprise products. The recent enhancements discussed here can form a valuable backup plan for small businesses.

For the enterprise customer, or someone wishing to backup large amounts of data from multiple servers, Symantec Backup Exec, Acronis TrueImage or Microsoft System Center Data Protection Manager are much better choices for giving more control over backups and allow tape-based backups. However, for low levels of data and single server deployments, Windows Server Backup continues to impress with a wealth of new features in this latest release.

I originally posted this article on Experts Exchange

Where do I put my ADMX files?

Note (4th May 2012): As this post proves to be ever popular, I have updated it to account for new developments and to provide a more general method of storing your ADMX files, especially on large networks. Please check out the new post: ADMX files, where to put them, and you – take 2.

ADMX files are the new form of ADM files, the format which defines what Group Policy settings set what registry changes when they are applied. With Microsoft’s move to XML-based file formats and alongside their release of the new Office 2007 file extensions (DOCX, XLSX, PPTX etc.) the ADM format was also upgraded to ADMX.

People familiar with ADM files would remember that in order to have Group Policy Editor read the ADM file and add the settings to the policy, they would need to Add the template. However, for ADMX files, you cannot add them via the Add/Remove Template wizard in Group Policy Editor, because they do not appear as an option to add.

Windows reads the ADMX files on the system from a pre-defined location, and that location is the only location on the system where you should place the ADMX files. It is %systemroot%\PolicyDefinitions, where %systemroot% is normally C:\WINDOWS.

Any ADML files you receive with the ADMX files should be placed into a subfolder within PolicyDefinitions, named after their MUI ID. For example, a en-US ADML file would be placed into the directory %systemroot%\PolicyDefinitions\en-US.

Once you have stored your ADMX files in their respective locations, it is simply a matter of restarting Group Policy Management Console for the files to appear in the Group Policy Editor.

It should be noted that any form of ADM/ADMX file only needs to be present on the machine where the policies are edited from. It does not need to be present on every machine on the network. The ADMX files simply link the GUI of the GPO Editor with the appropriate registry settings to make; the registry settings are simply stored and processed at each client where the GPO applies.