Friday, January 27, 2012

Error 0x800F0A12 Installing SP1 on Windows 2008 R2 Veeam System

I ran into a little issue trying to update my Windows 2008 R2 system that serves as my Veeam Backup server.  It did not matter whether I tried the SP1 install from WSUS distribution or the full download from Microsoft, it always ended fairly quickly with the error 0x800F0A12.

A little searching turned up this article on the website.  Following the guidance in the article it became clear the issue was due to disabled auto-mounting of volumes.  If your Veeam server directly access your SAN VMFS volumes, disabling auto-mounting of volumes is a critical step to keep Windows from squashing your VMFS volumes while still allowing Veeam to directly pull data from them.  I performed the following steps as resolution:

  1. Disable any Veeam jobs scheduled to start in the next 90-120 minutes.
  2. Removed all iSCSI Targets and Favorites from the Microsoft iSCSI initiator.  If you have a vendor specific tool be sure to check it as well (Equallogic HIT, etc).
  3. Disabled network access between the Veeam server and the iSCSI san - not taking any risks here.
  4. Followed the article's guidance and ran: mountvol /E to enable auto-mounting of volumes, then rebooted
  5. Installed SP1, Reboot
  6. Ran mountvol /N to disable auto-mounting of volumes, then rebooted
  7. Re-established iSCSI network connectivity
  8. Added back iSCSI Initiator configurations
  9. Verified Veeam could access VMFS volumes (test job)
  10. Re-Enabled all previously disabled Veeam jobs.
If you have any concern about using mountvol versus diskpart to disable / enable automount, they do the same thing.  Check this thread for the details and critical registry key to validate the claim.

Stumble Upon Toolbar

Tuesday, January 3, 2012

Fix Disappearing Windows 7 Desktop Shortcuts

Case of the Houdini Shortcuts
Since moving to Windows 7, a few users in the office have reported many of their desktop shortcuts would periodically disappear.  These reports would come in after users had been working offsite.  The effected users often had more than 10 desktop shortcuts to files out on the network.

Mystery Revealed
Some searching around led me to two resources that answered what was happening and largely how to adjust it.  MS KB978980 explained what was happening at a high level and how to prevent it manually.  Basically the system scheduled task "Scheduled" will delete broken desktop shortcuts of the currently logged in user whenever it finds more than four of them on the Desktop.  The MS fix is to have four or fewer such shortcuts, or disable Computer Maintenance - manually.  So users with more than four shortcuts to network resources would power up offsite, not using VPN, and the Schedule task would eventually fire off (1:00AM by default) and make their shortcuts disappear - pretty good trick.

Make it Stop
So with a manual fix in hand, I sought options to automate this for all machines.  Further searching turned up this blog post by Alex Verboon (@alexverboon) detailing where in Group Policy the needed changes could be made, but there was a problem.  From a 2008 R2 Domain controller, the setting/folder Alex described (Specifically "Scheduled Maintenance") was not present, another stumble.

I proceeded to fire up Group Policy Management on a Windows 7 SP1 system with RSAT installed hoping connecting from a client class system would reveal the Scheduled Maintenance settings.  I was rewarded with the "Scheduled Maintenance" folder and setting that Alex described.

A short bit of testing later and success.  No longer did my batch of test desktop shortcuts disappear with the PC disconnected from the network and manually invoking the "Scheduled" scheduled task.  A side effect of the Group Policy change is the "broken" shortcuts are reported in Action Center as "Broken Shortcuts".  If a user subsequently clicks on this in Action Center - poof - the shortcuts will be removed!  If you so wish, Action Center can be disabled via GPO also.

Stumble Upon Toolbar