ThinApp Microsoft Office 2010

A customer recently asked me to deploy Microsoft Office 2010 (KMS Licensed) to their 64 bit Windows 7 VDI desktops and so, after a little work, I was able to get a working ThinApp package. As an added difficulty, we are using a Floating Pool and so have redirected the users’ %appdata% to a file share on an SMB2 NAS device (so we’ve disabled SMB2 in Windows 7 until a ThinApp release where this doesn’t cause issues). Here are the steps that I followed, mostly taken from the excellent blog entry that VMware put together (http://blogs.vmware.com/thinapp/2011/02/quick-start-guide-for-deploying-office-2010-using-thinapp-461.html). I began this procedure with ThinApp 4.6.1, moved to 4.6.2 and have now run it with 4.7.

1) Prepare a clean capture machine. I use 32 bit Windows XP for my capture machine and have come across licensing issues when capturing on Windows 7 32 bit.

2) Perform the prescan

3) Install Microsoft Office, selecting a Custom Install and (people recommend ensuring that it doesn’t activate; I haven’t seen problems with an activated Office install but I’m sure that they can happen).

4) Ensure that all options are set to “Run From My Computer” and complete the install

5) Install Project and/or Visio the same way, if anyone in your environment will use these applications. Right now, there is a bug with the Office Software Protection Platform service that prevents Office applications from multiple ThinApp packages from running concurrently (or a ThinApp packaged Office from running when Office is natively installed).

6) Run an Office application (I usually use Word) and disable updates.

7) Perform the postscan and name the project accordingly. There’s no need to build the project yet.

8) Clean up the project capture directory. There’s a lot of files that, as far as I can tell, are not needed in the package. A build of all captured files is about 4.2 GB large (without compression); after this cleanup process, that size is shrunk to about 1.5 GB (without compression). Here is the cleanup process that I followed:

a. First, you need to make a backup of some executables that the applications reference as icon repositories, otherwise your file icons within the package will not display correctly (that took me a while to figure out!). I did this backup with the following Robocopy command (make sure that your source path has quotes around it and you may need to rename %systemroot% since that’s a system variable):

i. Robocopy “C:\temp\Installer” /IF *icons.exe /IF *icon.exe /S /FP

b. Second, I copied all of the fonts from the package’s %Fonts% directory and installed them natively in my parent image (since every desktop is entitled to MS Office). Loading fonts can take a while, so this step allows me to delete the %Fonts% directory and improve the package’s load time.

c. Once those steps were completed, I deleted the following folders:

i. %Fonts%

ii. %Cookies%

iii. %History%

iv. %Internet Cache%

v. The contents of %drive_C%\MSOCache\Users\

vi. The contents of %systemroot%\Installer

d. I then copied the files/folders that were copied in step 8.a back into %systemroot%\Installer (so that those *icons.exe files will be back where the office applications expect them to be)

9) As per VMware’s instructions, you’ll want to make two registry edits. Just append the specified text to the appropriate registry file:

a. HKEY_CURRENT_USER.txt

i. isolation_writecopy HKEY_CURRENT_USER\Environment

Value=ALLUSERSPROFILE

REG_SZ~%Common AppData%

b. HKEY_LOCAL_MACHINE.txt

i. isolation_full HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Search\Preferences

Value=PreventIndexingOutlook

REG_DWORD=#01#00#00#00

10) You should also move the OfficeSoftwareProtectionPlatform folder from %drive_C%\Documents and Settings\All Users\Microsoft\ to %Common AppData%\Microsoft\

11) Edit your Package.ini file to include whatever launch restrictions you need. I’ve created Active Directory groups for Visio and for Project and put “PermittedGroups” entries under the Entry Points for each of those applications.

a. I like to include the “ProcessExternalNameBehavior=Original” line in the [BuildOptions] section so that I can see the specific processes that are running (instead of a generic Microsoft Word 2010.exe process name).

b. I suggest that you don’t enable the Wow64=0 line, as that seems to prevent the ThinApp from creating print jobs.

12) Build your package.

There are a few Group Policy settings that I’ve found helpful in my desktop pool, specific to Office. You may need to install the Office 2010 Administrative Template files from Microsoft in order to set these policies. They can currently be downloaded from http://www.microsoft.com/download/en/details.aspx?id=18968, but we all know how Microsoft likes to move things around.

1) It can take a bit for Group Policy to apply to a desktop, especially if you are doing any Folder Redirection. For this reason, I’ve disabled Asynchronous Logon Scripts. This adds about 30 seconds to my logon (which is unfortunate), but ensures that all Group Policy is applied successfully to the desktop. I’m experimenting with methods to allow Asynchronous Logon Scripts, but for now they’re disabled (this is primarily for my %appdata% folder redirection)

a. Enable: Computer Configuration\Policies\Administrative Templates\System/Logon\Always wait for the network at computer startup and logon

2) Even though Outlook will save the user’s settings to their persistent Sandbox, we’d still rather not harass them for configuration prompts when they first log in. You can set Outlook to silently auto-configure based on the currently logged in user with the following policy:

a. Enable: User Configuration\Policies\Administrative Templates\Microsoft Outlook 2010/Account Settings/Exchange\Automatically configure profile based on Active Directory Primary SMTP address

3) Outlook can have some performance issues if it is maintaining a local OST file (especially if that OST file is redirected to a file share, which wasn’t even supported in older versions of Outlook and is only tentatively supported now). If nothing else, using a floating desktop pool will require that the system recreate its OST file every time the user logs in, which can be a time and resource intensive operation. I disable Cached Exchange Mode with the following policies:

a. Enable: User Configuration\Policies\Administrative Templates\Microsoft Outlook 2010/Account Settings/Exchange\Do not allow an OST file to be created

b. Disable: User Configuration\Policies\Administrative Templates\Microsoft Outlook 2010/Account Settings/Exchange/Cached Exchange Mode\Cached Exchange Mode

c. Disable: User Configuration\Policies\Administrative Templates\Microsoft Outlook 2010/Account Settings/Exchange/Cached Exchange Mode\Use Cached Exchange Mode for new and existing Outlook profiles

Update (5/2012): I noticed that the icon for PowerPoint is not preserved by step 8.a.  I later made a post specifically about File Type Icons not Displaying in a ThinApp, please reference that post for details about how to discover exactly which files are in use.  If you're feeling lazy, just skip step 8.c.vi and leave all of those Installer folders there.  It'll add a few hundred megs to your package size, but you'll have all of your icon files without needing to dig around.