Dealing with PST Files

Chances are, if you read my site, you also read the Exchange team blog.  This means you’ve seen the PST Capture Tool!  I’ve had a chance to work with this tool for a little while now and have found it to be a delight!PST File

“PSTs are bad M’kay?“

This is a line we’ve all recited a time or two (ok maybe not exactly that line), but do we even know why?  Are we just parrots, or do we actually have a reason for condemning this hugely prolific file format?

Let’s start by acknowledging that PST files aren’t all bad.  M’kay?  If you run Outlook at home, or if you use IMAP/POP-based accounts (Gmail, Hotmail, etc) at work, using a PST file can actually be a good idea.  While it is possible to direct internet mail to the Exchange mailbox, this would create several problems:

    • Wasting expensive Exchange disk space
    • Potential violation of company policies
    • Internet mail is now subject to corporate retention (and discovery!) policies
    • Makes moving to a job more painful
    • etc.

AutoArchive Group Policy Settings

I’d even go so far as to say you might want to use PST files for archiving corporate email!  If you run a small shop – or a big one that isn’t subject to any retention policies.  A group policy configuring AutoArchive (and a note to your users) might be a good way to implement spring cleaning in your Exchange data stores.

See, PST files actually can serve a purpose!

Then there is the other side of the coin:

In most situations, PST files represent unmanaged storage of email.  For someone who is charged with administering an email environment, this means we aren’t able to do our job.  If users begin to rely on something that we aren’t taking care of; what happens when it breaks?  We’ve all had the uncomfortable task of telling someone we can’t get their data back at least once in our careers.  It doesn’t make for fun times.

More important than our comfort; many organizations are subject to regulations which require them to turn email data over to the courts upon request.  A judge wont want to hear your sob story about how PST files aren’t searchable, and how you’re going to have to look across the whole network by hand to find that email thread.

I recently completed an Exchange 2010 deployment for a government organization that was subject to such legislation.  Once we activated the Personal Archive for their users, they decided to put the kibosh on PST files.  To enforce this, we laid out a three phased approach:

  1. Prevent the users from making new PST files
  2. Prevent the users from adding content to existing PST files
  3. Use the abovementioned PST Capture Tool to import PSTs as necessary

The first two steps were quite simple to accomplish.  Outlook reads a registry value called PSTDisableGrow (REG_DWORD).  We deployed a GPO to implement this as follows:

Outlook 2003 HKCU\Software\Microsoft\Office\11.0\Outlook\PST\
Outlook 2007 HKCU\Software\Microsoft\Office\12.0\Outlook\PST\
Outlook 2010 HKCU\Software\Microsoft\Office\14.0\Outlook\PST\

Set PSTDisableGrow to “1” (without the quotes).  This will allow users to mount PST files in Outlook, but it will not allow any new content to be placed within.  Don’t worry about overkill here.  I used a single GPO for all 3 settings.  Outlook version X doesn’t care about extra registry settings in Outlook Y’s key.

PSTDisableGrow has some siblings; read more about DisablePST, DisableCrossAccountCopy and DisableCopyToFileSystem here.

That’s all for now, have a great week!

EDIT: Be sure to also check out this relevant blog post by the Microsoft Exchange product group: Deep Sixing PST Files

How to Set Windows 7’s Login Wallpaper with Group Policies

With Windows XP, you could set your own login background colors and/or wallpaper by modifying the values found in the following registry location: [HKEY_USERS\.DEFAULT\Control Panel\Desktop].
Windows 7 no longer reads this registry key.  Instead you’ve got to complete the multi-step process described in this article.
Login Background for Windows XP
While the steps to set a login wallpaper are not complicated, one challenging limitation is the fact your background wallpaper needs to reside on the workstation’s hard drive.  Interestingly, this is not true for the user’s wallpaper, as there are GPO settings to point to a network location.
So when I had a customer ask me to set their login wallpaper, I had to think of how I wanted to accomplish their request.  We could possibly write a script, and as much “fun” as that might be, I’d rather use something more controlled.  Something that would allow me to easily change the configuration later as well as be decipherable to the customer after I leave.
The answer?  Group Policy – Preferences, that is!
So before we jump in to the Group Policy Management Console (GPMC), let’s identify what we’re trying to do.  If you haven’t already, you may wish to read the above link, otherwise you’re about to be lost.
We want our policy to:
  1. Copy our wallpaper file to the user’s workstation.
  2. Instruct Windows to use our file instead of the default %WinDir%\System32\oobe\background.bmp file.
With the new (ok they aren’t that new anymore) Group Policy Preferences that Windows 7 has built-in, we can copy our wallpaper to the user’s computer, while reserving the right to pull it off if the computer leaves the scope of the GPO.  To copy files, open GPMC and follow these steps:
1. Navigate to: Computer Configuration\Preferences\Windows Settings\Files clip_image001
2. Right-click the “Files” node and select:

New > File
clip_image002
3. Select Replace

4. Type in the UNC path for your source file.
     •In my example I used:
\\Srv1\Share\CompanyLogo.jpg
     •Remember this file needs to be <256K
     •Also understand the permissions on this share need to allow the workstation’s computer account READ. If you leave the usual “Authenticated Users” you’ll be fine.
5. For the Destination File, type this exact text (without the quotes, and no line breaks):
“%windir%\system32\oobe\info\backgrounds\backgrounddefault.jpg
clip_image003
6. Click the “Common” tab

7. Select “Remove this item when it is no longer applied”. This will ensure your file is removed if:
     •The GPO is deleted or disabled
     •The workstation is moved to another OU where the policy is not linked
     •The policy is filtered out
     •You update your policy to send a new wallpaper file
clip_image004
8. Optionally: Select Item-level targeting to specify only Windows 7 computers. This will ensure your file isn’t sent to versions of Windows that wouldn’t make use of it anyway. clip_image005
Now we need to instruct Windows to render this image when the login screen is displayed.  If you read the above article, you’ll remember the OEMBackground registry key.  The good news is, we don’t need that key because there is actually a setting to enable it in GPMC already.
In the same Group Policy Object, navigate to:
Computer Configuration\Policies\Administrative Templates\System\Logon.
Once there, select “Always use custom logon background” and set it to “Enabled”.  This has the same effect of setting the registry manually.
image
Once you’ve completed these steps, close the Group Policy Management Editor and link your policy to an OU – you’re done!
This policy may take two refresh cycles (e.g. reboots) to take effect.  This is because the wallpaper file is not yet present when the “always use custom logon background” setting is first applied.  But once the file has completed copying you’ll see your image at logon.
If you would like to consider multiple screen resolutions, please consult this link.
Before we close, I should point out, this can work for Server 2008 R2 as well.  I have not tested with Vista or Server 2008.
Finally, here are some geeky, but not too over the top wallpapers:  Smile
Login Background for Windows 7