Fast forward to today. I was messing around on that system and discovered that I left that one particular GPO in place. I fired up the Group Policy Management tool and removed the link to that GPO, did a gpupdate /force on that system, rebooted and went about my business. A few minutes later, I discovered that GPO was still in effect. I double-checked that the GPO wasn’t linked to that OU anymore, and that inheritance was still blocked, and did another gpupdate /force, but to no avail. A quick check of HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\History showed that yes, the GPO was still being applied.

I did a little head scratching, and then found the answer. As it turns out, after linking the GPO to the other production OUs, I selected the ‘Enforce’ option. By doing that, even after unlinking a GPO from an OU it will continue to be applied. I simply disabled the ‘Enforce’ option, ran yet another gpupdate /force, and all was well.

TL;DR Version: If you unlink a GPO from an OU, update the system, and the GPO is still being applied, disable the ‘Enforce’ option on that policy and do another gpupdate.

I gave the user full rights to the share, and assigned it Owner status as well (all through the Security tab, as standard), and then configured the GPO as appropriate. After rebooting the client computer, however, I checked the Documents folder only to find that it was still pointing at the default location. A quick peek in to Event Viewer revealed the following error:

Failed to apply policy and redirect folder “Documents” to “\serversharefolder”.

Redirection options=0×80009211.

The following error occurred: “Can not create folder “\serversharefolder”".

Error details: “Access is denied.”.

Which was very strange indeed, as a brief check confirmed that yes, the domain user did in fact have full access to both the folder and the share.

Then, something I saw (and stupidly, ignored) when setting up the GPO came back to me. I fired up the GPO editor and and browsed back to the Documents folder redirection section (User ConfigurationPoliciesWindows SettingsFolder Redirection). After double-clicking the Documents option, and then switching to the Settings tab (shown below), I noticed the top two boxes (“Grant User Exclusive Rights to Documents” and “Move the Contents of Documents to the New Location”) were selected by default. Given that this was an ‘Access Denied’ error, I figured one of these two settings must be at fault, so I unchecked them.

After rebooting the client computer, the Documents folder redirected to the Home Drive as expected.

Here’s where it gets stupid, though. On the ‘Target’ tab in the Documents properties window (visible in the screenshot above), if you have the ‘Target folder location’ set to ‘Redirect to the users home directory’, it explicitly adds a note that says “This settings ignores the value of the ‘Grant User Exclusive Rights to Documents’  option on the settings page.

Apparently not, Microsoft. Apparently not.

TL;DR Version: If Folder Redirections aren’t applying correctly, Event Viewer is showing ‘Access Denied’ messages, and you’re using Home Folders specified in the user account, disable ‘Grant User Exclusive Rights to Documents’  option on the settings page of the GPO.

Google Desktop has been in use at our organization long before I started here, however one of the things that’s irked me about it is the lack of official 64-bit support. Specifically, installation is possible on 64-bit editions of Windows, however a flag (specifically, the ‘/force’ flag) is required when running the installer to get it to actually install.

So although I can manually install the app on workstations, it’s a bit of a pain as a lot of the 64-bit machines were missed when they were originally setup. As such, I whipped up a nice little GPO that takes care of everything for me, and has some flexibility for installation detection. There are probably easier ways of doing this, but I was in a rush when I wrote the script, and it works very well.

Instructions

To start, download the Google Desktop Enterprise package. This contains a .ADM file that can be used in both Server 2003 and Server 2008 Group Policy Management consoles. Create a new GPO, and import the .adm in to the User ConfigurationPoliciesAdministrative Templates object (Server 2003 doesn’t have the Policies folder, it just goes right to Administrative Templates). It’s important to do it on the User side rather than the computer side, given the actual installation process.

After the import, it’s important to note that Server 2008 will place the Google object under Classic Administrative Templates (ADM), instead of just in the Administrative Templates folder. Now configure the settings you want for GDE, and you’re almost set.

Here’s the fun part now – the actual installation. Download the Google Desktop Setup file from Google. Because I’m too lazy to make a transform for the .MSI, I dug back in to my DOS knowledge and made a batch file to map a drive to a server with a publically-available share, run the Google Desktop installer from the mapped drive with the /force switch, and then disconnect the drive.

The main advantage to doing this if I want to update the installer with a newer version later, I just have to swap out the file – I don’t have to screw around with transforms again. The script goes as follows:

@ECHO OFF
Color 1F
Title Google Desktop Installer
c:
cd \windows\system32
if exist “gds_installed” GOTO End
ECHO Installing Google Desktop Search
ECHO.
net use x: \\public\installs >nul
start /wait x:\GDE\GoogleDesktopSetup.exe /force /silent
net use x: /delete >nul
echo Installed > gds_installed
exit

:End
ECHO Google Desktop Search already installed! Exiting!
exit

Alter the server name (public in the example) and path to the installer, and then save the file with the .BAT or .CMD extension in the domains scripts folder, or somewhere accessable to users that will be running the script. Remember, users have to have Read and Execute permission to the folder containing the setup executable and the script.

Once saved, add the batch file to the GPO’s logon script (again, under User Configuration). Once done, link the GPO to the Organizational Units (OU’s) that you want GDE installed. Presto! You’re done!

The Script Explained

The very first part makes the window a nice blue with white writing and gives it a title, just in case the user happens to see it (although typically it runs before Explorer loads, and even then it’s usually minimized). Immediately after, it makes sure it’s in the C Drive and changes to the Windows\System32 folder and uses an IF EXIST to see if a file named gde_installed is present. If it is, it uses a GOTO to skip the installation and end the batch job.

If gde_installed isn’t in the system32 folder, it maps \publicinstalls (the globally-available share) to the X Drive, which isn’t used in our organization. It then changes to X:, runs the GDS installer with the /force and /silent flags to install it unattendedly, then it disconnects the X: drive so the users won’t see it, and creates the gde_installed file in the system32 folder.

Details

In the batch file, you’ll note the use of >nul. This simply directs console output into nothingness so the command window, if seen, only shows what I have ECHO‘ed to it. You’ll also notice that the GoogleDesktopSetup.exe program is executed using start /wait. This forces the batch process to wait for the installation to finish before moving on. Without it, it will try to disconnect the X: drive too soon, which will it to prompt the user to forcefully disconnect the drive. As this is a fully automated process, and console output is sent to nul, we don’t want this to happen, hense the /wait flag.

This process is fairly straight forward, with the only potentially annoying portion being the creation of the actual .msi file to install the font. Sure, you can create batch startup scripts that copy the file to the fonts folder and update the registry, but this is a lot cleaner.

To create the .msi package used to install the font, I grabbed a free copy of WinInstall LE. Unfortunately registration with a non-free (read: Hotmail, Gmail, etc… accounts not accepted) email address is required. I tend to create throw-away accounts (eg, a9s6dfa9@my_domain.com) that I promptly delete afterwords. I get enough spam as it is.

Once downloaded and installed, there isn’t that much to do: launch the app, then create a new package by right-clicking on Windows Installer Packages in the top middle and click on New Package. Give it a name and description and you’re ready to start. Expand the package you just created, and you’ll see a new line item called New Feature. Select it, then change the name and description in the right-hand pane. No other changes required.

Next, expand the feature line that you just renamed, and you’ll get another line itm with a GUID (eg, {82B7A2B4-45E8-497A-AFB5-D182960CABF1}) – go ahead and delete it by right-clicking and choosing Delete. Now right-click on your feature and choose Add Files to Feature. Leave the Source line at it’s default value, but change the Target line by pressing the browse button (“…”).  From the list, select [WindowsFolder], then in both the Long folder path and Short folder path boxes add Fonts, so they read “[WindowsFolder]\Fonts” (without the quotes, of course). Now click OK. All we need to do now is add the file, which can be done by clicking the Add File button directly under the Target box. Browse to find your font and click Open. Now click OK, and you’ll see two new GUIDs under your feature.

The last thing we need to do is make this .msi package install without prompting the user. Simply click on the package line (not the feature), and click on the Install Modes tab on the right. Select Install only per machine and check the Show basic user interface only (simple progress and error handling) box.

Now all you need to do is compress the package – this will physically include the font inside the .msi package so that you only need the .msi file itself, rather than the .msi and the font files. To do this, simply select the Windows Installer Package inside WinINSTALL LE (not the feature or the components) and choose ‘Compress’ from the ‘Action’ (or right-click) menu. In the new window, simply press ‘Compress’, and you’re done!

By default, the .msi packages you create with WinInstall LE are located at \<Computer Name>\WinInstallPackages\<Package Name> on the computer you created them. Although the permissions on their share are very relaxed, we want the installer package to be in a high-availability location so that we can be sure the GPO we’ll create in just a short while will always be able to access it. I suggest copying it to \<Domain Controller>\SYSVOL\<Domain Name>\scripts. The guarentees that all of the clients will be able to access it.

Now login in to one of your Domain Controllers and fire up Group Policy Management. Create a new GPO and link it to whatever computer groups you may have, then right-click it and choose Edit. We’ll be working under the Computer Configuration header – if you’re using Server 2008, select Policies, then Software Settings – Server 2003 users just select Software Settings. Now right-click on Software Installation and choose New -> Package. Browse for your .msi package, select it, and choose OK. Selected Assigned, then OK.

You’re done! Just allow time for the GPO to propagate through your domain, and the next time your domain-joined systems reboot the font will be installed.