My personal opinion is Microsoft shouldn’t have been forced to release this. If you FORCE a choice for a web browser, you should also force a choice for every single application that comes with Windows.

Additionally, I fail to see why people should be forced to pick from a number of free products. Perhaps a better option would be for Microsoft to allow third parties to produce branded versions of Windows and then users can make their initial choices at the point of purchase.

This, of course, assumes a level of knowledge of the end users so questions like “where have all my favourites gone?” don’t happen…

Anyway, this was supposed to be a vaguely technical post and not a rant.

So, as a systems administrator, how do you block this update?

If you are using an internal update server such as WSUS or SCCM (which I love), then you have the simple option of not approving the update for release.

Otherwise, Microsoft have released a KB article showing a simple registry key that can be set to prevent the Browser Choice screen running – KB2019411.

So, as a sysadmin, how do you implement this?

Well, you can custom roll a Group Policy to set this as a preference on your client machines. I’ve written some GPOs before, but in this case I’ll simply direct you to this blog post by Christoffer Steding where you can download his version.

However, in my opinion, a much more graceful group policy to set is a software restriction policy. This has been documented by The Angry Technician.

I found very very minimal documentation on how to do this, it was so sketchy that I was almost afraid to try this.
We only have a single Exchange 2003 Standard server, and I believe that its a little bit simpler if you have Enterprise or more Exchange servers. So, for those of you in the same boat, here’s how to do it.

First, and I cannot stress this enough, make sure that your Mailbox Store is such that “This database can be overwritten by a restore” is NOT checked. You should probably make sure that your Public Folder Store is set the same. Just in case.

Now, right click on the server and select New -> Recovery Storage Group. Create the logs and system paths in locations that have sufficient space to hold the .edb and .stm files for your restore.

Right click on the Recovery Storage Group (RSG) and select “Add Database to Recover”. Select the Mailbox store.
Make sure that this store is not mounted (not your live store – you can leave that running), and that it is set to allow overwrites by restores. I believe this is the default.

Now, on your Backup software (we use Veritas BackupExec), browse to the Information Store and select only the mailbox store to be recovered, not the Public Folder Store. Make sure that in your options you select that this is the last backup to restore and not to mount the store when finished. Run the restore. For me this was the scary bit. The documentation was lacking the phrase “Don’t worry, Exchange knows to make sure the restore will go to the Recovery Storage Group, NOT the live Mailbox Store”

Once the restore is complete, mount the store in the RSG. If Exchange thinks that there are still further restores to occur, you can use eseutil /cc <Path to Restore.env directory> to finalise the store and allow it to be mounted.

Now you can use exmerge to dump out the mailbox(es) from the RSG to a PST file. Unless the useraccount has been removed from AD.
If the user account has been removed, then you have to recreate the account. Before you do that, check the exmerge.log file as it will tell you the GUID of the mailboxes that it can’t find accounts for. You have to go through to the point of selecting mailboxes to action for that information to be written.

The lines in Exmerge.log will appear something like this:
[11:39:13] Error! Cannot identify the user with the msExchMailboxGuid \C1\A7\98\CE\B8\CF5J\99\E1\B1\28\8C\7D\EFj. The legacyExchangeDN is /O=COMPANY/OU=EXCHANGE ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=AUSER.

Note the almost but not quite hex pattern listed. This is the important bit.
Each mailbox has a hex guid. Each mail enabled user has a property which gives their mailbox guid. You need to convert this to proper hex.

 \\C1\\A7\\98\\CE\\B8\\CF5J\\99\\E1\\B1\\28\\8C\\7D\\EFj

First, break out the couplets from each group

 C1 A7 98 CE B8 CF  5  J 99 E1 B1 28 8C 7D EF  j

Only the first two characters in any grouping are Hex, any following characters should be treated individually (Note that the 5 and J (case IS important) have been split.)
Now, take any non-hex characters and get the hex value for that ASCII character from http://www.asciitable.com/ :

 C1 A7 98 CE B8 CF  5  J 99 E1 B1 28 8C 7D EF  j
 C1 A7 98 CE B8 CF 35 4A 99 E1 B1 28 8C 7D EF 6A

UPDATE: If the leading \ is missing, treat the first group as individual ascii characters!
UPDATE2: I’ve written a tool to do this for you!

Now you need to use a tool such as ADSIEdit.msc to change the msExchMailboxGuid property on the recreated user account. Synchronise your domain controllers and run ExMerge again, this time the mailbox should be available to dump out, complete with the items from the Dumpster (if the user killed everything in their mailbox before leaving the company).