Thursday, August 11, 2011

Fix Outlook "Can't Create File" Issue By Purging The Outlook Secure Temp Folder With A VBScript

The Outlook Secure Temp Folder

Every time you open or preview an attachment in Outlook, a copy of the file is cached to your Outlook Secure Temp Folder. The Outlook Secure Temp Folder is a directory with a randomly generated name, whose path you can obtain by viewing the OutlookSecureTempFolder string value under HKCU\Software\Microsoft\Office\[Version]\Outlook\Security in your registry. The files written to this folder are supposed to be automatically deleted once the messages associated with them are closed, but this does not always happen as expected. Residual file copies can be left behind in the secure temp folder for a number of different reasons, such as an unexpected closure of Outlook while attachments remain open. However, I've found that files are often orphaned in this directory just from viewing them with the built-in attachment previewer. Over time, these files can begin to cause attachment viewing problems.

Outlook "Can't Create File" Error

Outlook users who frequently receive e-mail messages containing attachments with identical names may find that they eventually begin receiving error messages when attempting to open these attachments. Let's say that you receive a daily sales report entitled SalesReport.pdf. Every time you open this file, Outlook attempts to cache a copy of it to your Secure Temp Folder, as described above. If a previously orphaned file exists with the same name, Outlook attempts to create the file by adding a number to the end of the file name, and sequentially incrementing it until there is no naming conflict with other files in the Temp directory. Upon viewing your temp directory, you may see multiple copies of the report named as follows: SalesReport.pdf, SalesReport (2).pdf, SalesReport (3).pdf, etc. Issues seem to crop up when the number of similarly named files in the directory approaches 100. Once this threshold is reached, Outlook begins to deny users the ability to open attached files with the same name, because it will no longer increment the file name, and therefore cannot create a cached copy of the data to open locally. The result is an error message similar to the following: "Can't create file: SalesReport.pdf. Right-click the folder you want to create the file in, and then click Properties on the shortcut menu to check your permissions for the folder". This cryptic message is both frustrating and confusing to most end-users, and tends to cause quite a bit of disdain when time-sensitive documents are involved.

Purging the Outlook Secure Temp Folder

The solution to the "Can't create file" error is to purge the contents of your Outlook Secure Temp Folder. Once the orphaned files in this directory are removed, Outlook can once again create cached copies of e-mail attachments on your local machine for opening. The temp folder can be purged manually by navigating to its path as indicated in the registry (HKCU\Software\Microsoft\Office\[Version]\Outlook\Security\OutlookSecureTempFolder) and deleting all existing files, or you can use the OutlookTempFolderPurge.vbs script that I've posted below to do this for you:

If you are running multiple versions of Office/Outlook, the script will clear the contents of all temp folder instances. By default, the script notifies you upon completion of any errors encountered, but this behavior can be altered by setting the "InformUser" variable to "False" (without the quotes) where indicated. You can simply run this script on-demand every time the problem occurs. If you wish to be more proactive, you can also place it in your startup folder, or include it in a logon script for your users, so that the data is purged with every subsequent logon.

Tuesday, August 9, 2011

Downloading & Installing Orca.exe

What is Orca?

Orca.exe is an msi database editor included with the Windows SDK. This powerful tool allows you to create and edit installer packages, merge modules, and transform files. Its functionality is crucial for customizing installer packages deployed via GPOs in Active Directory.

How Do I Download And Install Orca?

Orca.exe is indispensible to many enterprise administrators, but can be tough to find. There is no (official) direct download link available for Orca.exe. Instead, you must obtain the latest version of the Windows SDK to get it. If you've already installed the Windows SDK on your machine, or if you've installed a program that it is bundled with (such as Visual Studio), then you should already have the Orca.msi installer file on your local box. Look for it in C:\Program Files\Microsoft SDKs\Windows\[Version]\bin, or do a quick search of your computer for Orca.msi. If you still need to acquire the installer, you may download the latest Windows SDK for free from the Microsoft Download Site. I recommend downloading the ISO version of the SDK so that you do not have to install the entire thing just to get Orca. Once you have the ISO copy of the SDK appropriate for your chipset, follow these steps to extract and install Orca:

  1. Mount the .iso using virtual drive software such as Virtual Clone Drive
  2. Navigate to Setup\WinSDKTools, and open cab1.cab
  3. Locate and extract WinSDK_Orca_Msi... to whatever local folder you'd like
  4. Add ".msi" to the end of the file name
  5. Use the resulting .msi file to install Orca

Once it is installed, you will see a new "Edit with Orca" context menu option when right-clicking msi files.

Thursday, August 4, 2011

Bypassing AES Zone Checks In A .VBS Logon Script

Attachment Execution Services (AES)

Beginning with Windows XP SP2, Microsoft included a security feature known as Attachment Execution Services (AES) in its operating systems. For any executable file invoked via the ShellExecute() API, AES attempts to determine what zone the attachment originated from (Internet, Local Intranet, Trusted Sites, or Restricted Sites), and then applies security restrictions accordingly. The behavior of this feature can be adjusted via Internet Explorer's Internet Options. To change it, open Internet Explorer and go to Tools > Internet Options, and then select the "Security" tab. From there, select the zone you wish to modify the behavior for, and click the "Custom Level" button. Scroll down to the "Miscellaneous" section, and locate the "Launching applications and unsafe files" option. You may then choose either "Disable", "Enable", or "Prompt".

The Open File - Security Warning

You can observe the effects of AES by attempting to launch an executable attachment from an internet resource, or by navigating to the UNC path of an executable file on your network by using the FQDN of the server it resides on, and launching the file. In the case of the latter, you receive an "Open File - Security Warning" prompt. Why do you receive this warning despite having enabled the "Launching applications and unsafe files" option for the Local Intranet zone? This occurs because the FQDN is assumed to be a reference to an internet resource, hence the settings for the Internet zone are applied instead. You will notice that navigating to the same executable by using only the server's hostname in its UNC path (without the domain suffix), you can then launch the file, and bypass the security warning. This allows the program to execute uninterrupted.

Logon Script Considerations

Most administrators prefer to keep all of their logon scripts in a central location, and typically store this repository in the NETLOGON folder, so that it is replicated across their domain controllers. Another common practice is to create a single VBScript file, which in turn launches any other executables required during logon, and subsequently assign this master logon script to all users. It seems logical then to launch those executables from the master script (usually invoking either the Run() or Exec() method of a WScipt.Shell object) by referencing the UNC paths of the executables using the domain root FQDN (i.e. \\mydomain.com\NETLOGON\Script.vbs). This ensures that any future decom of a DC will not affect the execution of an end-user's logon script. However, this also opens up the possibility for AES to interfere with the proper execution of your script. Since AES will perceive the UNC path as an internet resource due to the presence of your domain's FQDN, it may prevent all or part of it from running.

Temporarily Bypassing AES Zone Checks

You can get around this AES interruption issue by temporarily disabling zone checks at the beginning of your script, and then re-enabling them prior to its termination. This is done by manipulating the SEE_MASK_NOZONECHECKS process environment variable. Setting SEE_MASK_NOZONECHECKS to 1 disables zone checking. Conversely, removing the variable re-enables this behavior. For an example of disabling and re-enabling zone checks, please see the VBScript code snippet below:

Please note that it is very important not to leave zone checking disabled, as this presents a HUGE security risk. For more information regarding AES and the SEE_MASK_NOZONECHECKS environment variable, please refer to KB article 889815.

Wednesday, August 3, 2011

Automatically Create Outlook Profile During Logon With A VBScript

The Problem

A common annoyance facing many administrators and helpdesk personnel is the need to configure an Outlook (MAPI) profile for their end-users every time they log on to a new machine for the first time. The issue becomes less predominant when user accounts are configured with roaming profiles, but nonetheless, configuring Outlook settings every time a new user is added to the domain, or after every subsequent profile reset can quickly become an administrative burden. Beginning with Outlook 2007, Microsoft tried to mitigate this problem by attempting to auto-discover the user's mailbox on an Exchange Server in your org, but even clicking "Next" and "Finish" seems to be out of the technical scope of most users, and often warrants a call to the helpdesk. Moreover, you may wish to forego Cached Exchange Mode, which is enabled by default.

The Solution

You can overcome this monotonous waste of time by using a simple VBScript to check the HKCU registry hive for the presence of an end-user's Outlook (MAPI) profile when they log on to a machine. If no profile is found, you can then import a custom .prf file containing all of the necessary configuration settings for your environment.

Choosing A Tool To Generate The .PRF

The tool you choose to configure your custom .prf should depend on the diversity of Outlook clients on your network. If you have the good fortune of consistent refresh cycles, your client PCs may all be running Office 2007 and above, in which case you may use the Office Customization Tool included in the Admin folder on the installation media for all volume-licensed copies of Office 2007/2010. However, if your environment is more typical of many SMEs, you likely have some workstations loaded with Office 2003 or XP, and some with Office 2007 or 2010. If this is the case, you should use the Custom Installation Wizard included with the Resource Kit Tools for Office 2003 or XP, whichever is the lowest active version in your environment. I will gear these instructions towards the ork for 2003, because that seems to be the lowest common denominator in most cases. Note that Outlook is backwards-compatible with .prf files created in all previous versions, dating back to Office XP. Please obtain the appropriate tool from the Microsoft Download Center by choosing from one of the following links:

Creating The Custom .PRF

Once you've downloaded and installed the Office 2003 Resource Kit Tools, locate installation media for Office 2003, because you will need to point to the [OfficeEdition][Version].msi in order to utilize the tool. For example, the installer for Office 2003 Professional is PRO11.msi, and is located in the root folder of the installation media. Perform the following steps to generate your custom .prf file:

  1. Open the Custom Installation Wizard, and point it to the appropriate installer file
  2. Select "Create a new MST file" and then click "Next"
  3. Click the drop-down box in the upper-right corner of the CIW window, and skip to step 17, which is titled "Outlook: Configure Default Profile"
  4. Select the "New Profile" option, and specify the name of the profile to be created (I HIGHLY recommend using the default profile name of "Outlook")
  5. Click "Next"
  6. Click "Configure an Exchange Server connection" (Note: the %UserName% environment variable, which is filled in for the "User Name" field by default, will resolve to the username of the person who logs on and imports this .prf)
  7. Specify the name of your Exchange Server in the "Exchange Server" field (Tip: create an alias (CNAME) record on your DNS server that resolves to Exchange, and specify the alias in this field. If you migrate Exchange in the future, you can simply change the CNAME record to resolve to your new host, keeping the functionality of your import script intact)
  8. Configure the desired settings for Cached Exchange Mode, and then click "Next"
  9. Click "Next" to skip the "Add Accounts" step, unless you wish to configure additional accounts
  10. Click the "Export Profile Settings..." button, and save your custom .prf
  11. Close the Custom Installation Wizard
  12. Open the .prf in a text editor, such as notepad, and review all settings; make changes as required (Note: detailed information regarding these settings can be found here)
  13. Copy your custom .prf to a network location accessible by all applicable users
VBScript To Automatically Import The .PRF

Copy the following VBScript code, paste it into a text editor (such as notepad), and save the file as CreateOutlookProfile.vbs:

Now, edit CreateOutlookProfile.vbs, and fill in the appropriate values for the PRFLocation and ProfileName variables at the top of the script. Set PRFLocation to the UNC path where you copied your custom .prf, and set ProfileName to the profile name that you assigned when generating your .prf. If you followed my recommendation above, the ProfileName should be "Outlook". Be sure to leave the quotation marks around these values, as they must be string literals. Save the changes you've made, and then assign this as a logon script via your preferred method. I suggest either using a GPO, or launching from within another script that you've already deployed.