Monday, 27 June 2011

SBS 2011 Backup Error: Add Destination Drive Failure – Cannot Configure Backup Schedule

We went to add a destination drive to one of our newly migrated to SBS 2011 servers.

When we ran the wizard after plugging in the new backup drive we ended up with the wizard coughing up a generic failure message: Cannot Configure Backup Schedule.

We opened C:\Program Files\Windows Small Business Server\Logs\SBCW.log in NotePad to find:

[6572] 110627.121259.4347: Storage: Terminating error in Set-WBPolicy: System.Exception:
The filename, directory name, or volume label syntax is incorrect ---> Microsoft.SnapIns.Backup.UI.Proxy.BlockLevelBackupException: IBlbEngine::ModifyTemplate failed due to error: The filename, directory name, or volume label syntax is incorrect, (0x8007007b)..

We searched on that error and came up with:

That in turn led us to this Microsoft KB:

We are presented with three options:

  1. Attach the original backup destination.
    • In this case we only have one drive dock so no go.
  2. Remove the original backup destination altogether.
    • Live disk for rotation so no go on this one.
  3. Manually add the new disk using WBAdmin.
    1. This was it.

The how-to from the KB:

  1. Run the following command from an elevated command prompt to determine the Disk Identifier of the new disk:
         wbadmin get disks
  2. Based on the output, locate the disk that will be added to the scheduled backup. Make a note of the Disk Identifier. The output will resemble the following:
    Disk name: xxxxxxxxxxx
    Disk number: x
    Disk identifier: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
    Total space: xxx.xx GB
    Used space : xxx.xx GB
  3. Run the following command to add the new disk to the Scheduled backup.  Use the Disk Identifier from the previous step as the "AddTarget" parameter.
    WBADMIN ENABLE BACKUP -addtarget:{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
  4. When you receive the following prompt, type Y for Yes.

"Do you want to enable scheduled backups with the above settings?"

Now, there were a few more prompts after point 4 that we said Yes to.

Of course the new disk now had the Windows Server Backup label so we changed that using Disk Management. But, the status under the Backup tab in the SBS Console still showed the WSB label.

For now, we have that additional disk in the rotation with our first backup to it successful:

image

We will keep this backup rotation short and introduce another drive at the end of the week so we can bring this one back to the shop and do a test restore. We have not yet needed to restore a backup from a destination that was incorporated into a backup routine via this method as of yet.

We _always_ want to know if a backup is good for a full bare metal restore. The only way to know is to actually restore it! :)

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer

12 comments:

Matt said...

I find this to be such a bug in SBS 2011. A real pain too if you want to use meaningful labels on your backup disks - eg Mon, Tue, Wed etc..

I will be interested to see how your bare metal restore goes. We have tried it and failed dismally.

IanF said...

I have come across the same issue recently. I'm no qualified MS engineer, but install SBS regularly for customers.

By trial and error I have discovered that if you leave the First backup disk you configure connected, and then also connect "disk2" you can add the destination drive in the normal manner. Remove "Disk2" and connect "disk3" and add that destination. All the while leaving "disk1" connected. I always use 5x disks... monday-friday. Perhaps more than is strictly speaking needed, but keeps things simple for the plebs that rotate the drives and take them off site.

Matt said...

I've just retrieved another backup disk from a different customer using SBS 2011 and we are still failing to complete a bare metal recovery using the SBS backup disks.

The restore runs through just fine but the end result is a blank grey "desktop" with a mouse curser.

This has happened for two different servers now and I'm a bit (a lot) concerned by this...especially considering how well we've restored SBS 2008 servers in the past....

I'm very much looking forward to other peoples experiences of SBS 2011 bare metal restores using the in built method..

Philip Elder SBS MVP said...

Matt,

Bare Metal Restore, that is restoring the SBS backup to hardware with a different configuration has never worked for us since SBS 2008.

We can restore the backup to a VM without too much issue or we can restore the backup to a server that is identical to the original, but we are going to ShadowProtect if we want to restore that box to a physical box with a different hardware configuration (especially the RAID controller).

Philip

Matt said...

Hi Phillip,

Thanks for you reply.

I've successfully completed a bare metal recovery to the same and "similar" hardware using the in built solution on a number of occasions with SBS 2008. Sadly, not the case with SBS 2011. Strangely, the way it fails would suggest something other than a hardware discrepency. The restored server appears to boot fine, no errors or BSOD like you'd expect with RAID or driver issues, just a blank desktop and a mouse curser.

We've opened a case with PSS. Let's see how we get on....

Cheers,
Matt

Gary Shell said...

When I tried to add the second drive using the WBADMIN option I initially got a "Bad numeric constant" error. Digging around I found a suggestion that enclosing the drive id number in quotes would remedy this error. Indeed it did!

Gary

Philip Elder SBS MVP said...

Matt,

Please keep us in the loop.

Gary,

I can't recall if we used quotes or not. It seems to me that we did not need to. I will screen capture the next drive addition using this method to verify.

Thanks all,

Philip

Kevin M said...

It's been several months now. Has anyone had any success with a bare metal restore? I'm about to replace the RAID controller on my server and was hoping to to restore it from a backup.

Matt said...

Sometime later and we finally got to the bottom of the "black screen of death" bare metal restore issue.
Firstly, PSS basically told me that it wasn't supported to perform a BMR to different hardware.
Meanwhile, we could not recreate the problem in the lab with a newly built SBS 2011 server. Everytime we restored it was successful - even to different hardware. However, several 2011 servers we have "in the wild" all failed with the aforementioned blank screen and cursor problem. As you can imagine, we had no confidence that a BMR to the ORIGINAL hardware would work on these servers.
In a spare moment last week, I did another search of the web to see if I could find anyone else experiencing the same issue and I stumbled across this:
http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/thread/be28b0a1-9cad-45aa-ad4c-b9e85e3128d2/

Sure enough, we removed the NTBackupRestore utility and performed a backup on a server which previously failed to restore. We restored it perfectly - to different hardware!
Seems MS are in denial this bug even exists. There's no KB article on it and PSS were no help.
I'd class this as a pretty major "caveat" in the SBS2011.

Unknown said...

Dear Matt.

Are you working with David Michaud that is working with Jeff Middleton? Or are you posting on this thread? http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/thread/be28b0a1-9cad-45aa-ad4c-b9e85e3128d2/

You may think I'm talking koolaid here but I've tracking patching related issues for a long time and there's a similar "How can Microsoft miss this - it's soooo obvious" incredulous-ness that occurs there too.
First off, the ntbackup code is not native to the box, it's obviously meant as a temporary measure to get data from an old system (2k3 era) onto a 2k8 and later system. It would be probably wise, therefore to proactively remove it just because it doesn't natively ship on the box.

There is no KB at this time because there's only been one support case (yours) and a few forum posts alerting to this issues. For a KB article to be written by support is has to be proven first. Until there are cases open (and forum posts do not cut it), do not expect a KB documenting this.

MS is not denying this bug exists, MS only knows about this bug because only one person has called in about this case (maybe two if you are not David). They cannot proactively write a KB regarding an issue that they are just now being made aware of?

You can't have the chicken try to cross the road until the road is built in the first place.

I wouldn't class this as a pretty major caveat when it's code that's not normally on the box in the first place, and secondly, give support time to investigate before demanding that they write a KB before they can reproduce it themselves. There may be some unique hardware that you have that is the trigger here. Unless you can repro it on hyperV (aka hardware agnostic), it may be unique to the raid cards or hardware that you deploy. Microsoft is not Apple, they don't limit your hardware choices so sometimes there are unique bugs that track to specific hardware.

So I'm going to ask you to step back a bit and give us time to repro this independently before a KB is written, okay? Ping me at susan-at-msmvps.com please, thanks.

Unknown said...

Dear Matt.

Are you working with David Michaud that is working with Jeff Middleton? Or are you posting on this thread? http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/thread/be28b0a1-9cad-45aa-ad4c-b9e85e3128d2/

You may think I'm talking koolaid here but I've tracking patching related issues for a long time and there's a similar "How can Microsoft miss this - it's soooo obvious" incredulous-ness that occurs there too.
First off, the ntbackup code is not native to the box, it's obviously meant as a temporary measure to get data from an old system (2k3 era) onto a 2k8 and later system. It would be probably wise, therefore to proactively remove it just because it doesn't natively ship on the box.

There is no KB at this time because there's only been one support case (yours) and a few forum posts alerting to this issues. For a KB article to be written by support is has to be proven first. Until there are cases open (and forum posts do not cut it), do not expect a KB documenting this.

MS is not denying this bug exists, MS only knows about this bug because only one person has called in about this case (maybe two if you are not David). They cannot proactively write a KB regarding an issue that they are just now being made aware of?

You can't have the chicken try to cross the road until the road is built in the first place.

I wouldn't class this as a pretty major caveat when it's code that's not normally on the box in the first place, and secondly, give support time to investigate before demanding that they write a KB before they can reproduce it themselves. There may be some unique hardware that you have that is the trigger here. Unless you can repro it on hyperV (aka hardware agnostic), it may be unique to the raid cards or hardware that you deploy. Microsoft is not Apple, they don't limit your hardware choices so sometimes there are unique bugs that track to specific hardware.

So I'm going to ask you to step back a bit and give us time to repro this independently before a KB is written, okay?"

Matt said...

Hi Susan,

If I can park the slightly patronising tone of your response to one side for now, I can appreciate what you’re saying. I know MS have thousands of PSS requests and thousands of patches and Hotfixes to write. I’ve also been working with MS technology long enough to know that it can sometimes be very difficult to get the ear of someone willing to listen when “caveats” like this are discovered. So, no need to defend MS as I fully appreciate their plight…

Despite my understanding, I would argue this is, in my opinion a major caveat. The software in question is fully supported by MS and the recommended solution for W2008R2 servers when restoring *.bkf files. You say it’s meant as a temporary measure but nowhere in the KB974674 article does it mention uninstalling before running a backup. BKF files are still used in the wild and people will still have a use for such a utility. I doubt very much this utility was written purely for people performing migrations.

With regard to it been hardware related, we’ve had the same issue with HP and Intel boxes; SCSI and SATA. The post you refer to actually contains others experiencing the issue with Hyper V servers, so it’s pretty safe to assume it is hardware agnostic. Interestingly, and you might want to pass this on to your MS contacts, if we restore the server brick by brick – that is, install clean OS, restore AD, restore C - the core server functionality is OK; We can logon to the server and access Exchange…

Best Regards,
Matt