I don't think there is a way to do this reliably with built-in Windows tools. However, BackupAssist allows you to use multiple USB disks with Windows Server Backup in the same way that one might use multiple tapes, e.g. for rotating offsite backups. It also will automatically "safely remove" USB disks when a backup job is complete, so that the person responsible for taking the USB disks offsite doesn't need administrative access to the server.

I'm rather disappointed that I ran into this fairly serious problem 2 years after this question was posted - and this was on a new install of Windows 2012 Essentials with (I think) all updates installed.

Fortunately, a HotFix was released last year: http://support.microsoft.com/kb/2833738

This worked for me. I was able to add a new disk to backup with the command:

WBADMIN ENABLE BACKUP -addtarget:{DISKGUID}

Before installing the HotFix, I was getting the "The system cannot find the path specified." error.

Use a PowerShell script to run WBADMIN as an alternative to creating a backup schedule with the Windows Server Backup GUI. You can use Windows Task Scheduler to run your script. There is no functional difference between a backup created from a script or command line using the WBADMIN command and those created by the GUI-generated backups.

Here is a PowerShell 3.0 script I use to create backups using WBADMIN on Server 2012. It searches for backup target disks using their volume GUID as I usually don't assign drive letters to my backup drives:

# Configuration
$BackupTargetDiskGUID_A = "\\?\Volume{c61d486a-c007-4070-a5a0-24924fe735f6}\"
$BackupTargetDiskGUID_B = "\\?\Volume{e0a09f69-3be6-11e4-942b-001e676ec6a8}\"
$BackupTargetDiskGUID_C = "\\?\Volume{4bb968a7-93f6-11e2-918e-001e6725c7e0}\"


# Get the Disk GUIDs (DeviceID) of all attached volumes.
# Step through all attached volumes.
$TargetDiskGUID = $null
:VolumeForeachLoop foreach ($Volume in Get-WmiObject -Class Win32_Volume | Where-Object {$_.DeviceID -like "\\?\*"})
{
    # Match the first backup disk
    Switch ($Volume.DeviceID)
    {
        $BackupTargetDiskGUID_A
        {
            $TargetDiskGUID = $Volume.DeviceID
            break VolumeForeachLoop
        }

        $BackupTargetDiskGUID_B
        {
            $TargetDiskGUID = $Volume.DeviceID
            break VolumeForeachLoop
        }

        $BackupTargetDiskGUID_C
        {
            $TargetDiskGUID = $Volume.DeviceID
            break VolumeForeachLoop
        }


    }
}


If ($TargetDiskGUID)
{

    # Run the backup
    # The -include and -exclude switches accept comma delimited paths individually inclosed in quotes without trailing backslashes
    wbadmin start backup -backuptarget:$TargetDiskGUID -quiet -vssCopy -allCritical -systemState --% -include:"D:" -exclude:"D:\Non-Backed Up Data"
}
Else
{
    "No backup disk found."
}

The WSB GUI creates a special backup policy, which once created, demands that backup targets be added to the policy before a scheduled backup will be written to said drive. Unfortunately, Windows Server Backup as exposed through the GUI is completely broken in Server 2012. Unless you have all backup destination drives connected to the machine*, you cannot do the following:

1. Add backup target disk
2. Remove a backup target disk
3. Modify the backup selections (!)

Unless Microsoft fixes this, scripting WBADMIN in my opinion is the only way to continue using WSB on Server 2012.

_{*Murphy's Law also states this is the best time for a building fire since the source data and all backups are in the same place at the same time.}

You have to eliminate the variable of the drives being quietly rejected for being detected as removable media.

Windows Backup for all of its age is constrained with virtues from the mid 1990's, it doesn't like target drives smaller than 1GB and by default refuses to backup images of the %systemdrive% (C:) to removable media. Windows schizophrenically treats removable media with disdain and acceptance and fails to properly log the reasons. You can install Windows even before Windows 8 onto USB media but try to perform particular functions such as Windows Update or windows Backup and other mechanisms rejects itself the way a body can reject a transplanted organ.

The removable drives would benefit from the XPEFilterDriver, it is an implementation of the Hitachi CompactFlash driver for those old mini hard drives that were actually shrunk down into a type II CF card and even made little grinding sounds, the drivers inf file is modified with your removable drives bus and device identifier then substituted as the driver. The XP community realized this years ago after CF cards had grown in size and speed (300x at a minimum is recommended since it seems to perform comparably to a 7,200 RPM EIDE drive) and started lego'ing decent cards into things like the [Addonics CF/SATA adapters][1] and you could build an SSD for a fraction of the cost SSD's used to cost.

Windows is terrible about accurately reporting removable device errors since it handles them scizohphrenically, I mean that officially and until Windows 8 or unless you installed an XPe server and adopted all the constraints of it, Microsoft rejected the idea of installing traditional fat, professional or ultimate version of any windows on USB despite the communities proof of concept and evidence of increased performance but they weren't adequately preventing it from being done since setup.exe would still succeed on installing and booting. But other features such as using it as a backup drive, or even the basic ability use disk manager to just format it as USB were patently rejected, things like successfully using Windows Update would fail without adequate error reporting (but went away if the same build and installation ghosted to a traditional hard drive detected as a fixed disk) because of some ambiguous programmatic rejection of removable media.

The steps are straightforward and "The Island" of hosts that offer the XPEfilter can seem to move, I'm not implying this is "rapidshareware" or piratebay stuff, hardly, but there is a compact and often sub 500kb zip file called "XPEFilterDriver" and "HitachiMicrofilter" that is pervasive across the web and has a cfadisk.sys and cfadisk.inf file.

Hopefully, and it seems likely, that you've already done something like this before and if you're a 2012 server box buster I bet you've had to with the drivers from Microsoft's update catalog when installing "unsupported drivers" that seem to work just fine and dandy anyway.

Obtain it and use any of the instructions from any of the sites you prefer but they'll all tell you to copy your current removable media's device ID and insert into the drivers line of the inf file ( I'm not a spot capable of just demoing this for you but it won't do too much good since the device entry is unique to every USB disk and yours will be different than mine).

From device manager (devmgmgt.msc) and after the USB drive has been inserted because its just easier but not absolutely necessary if you know how to do this directly from the registry

locate the removable drive and upgrade the driver and select the Have a disk options, locate your modified cfadisk.inf file, (you're allowed to consolidate all of your USB drives into one INF file) and select the list of disks displayed after choosing your customized INF.

Accept the warnings about lack of signing and unknown and all that, those are the same warnings presented when I install Windows 8 or server 2012 drivers from Microsoft's update catalog web site.

Since these are removable USB drives, you won't have to reboot despite the warnings to do so, but you might have to safely eject the hardware and reinsert to see the driver go into effect. Sometimes I've succeeded by just stopping the disk from device manager and re-enabling it but not always and I wish I could differentiate the success rate based on manufacturer, type or version of Windows but it seems uncertain which drives will successfully reload the new driver without being removed.

I have a feeling that the GUID changes after formatting.

You could therefore run wbadmin get disks again after formatting and then run WBADMIN ENABLE BACKUP -addtarget:"{DISKGUID}" again..

I ran into this. 2 options:

1. attach all of your backup disks to the server and then run the scheduling wizard.
2. change the drive letter of the desired external drive once attached.

This solution arrives a bit late, but hopefully anyone searching can use this.

This solution is quite simple and it worked for me.

Given that you have now got a volume with no letter but with a label of something like SERVER_2013_10_11 12:34 Disk_02 (after trying and failing to add a volume via the gui or command line) just

• open the Disk manager tool
• Assign a letter to the volume (lets say its D:)
• This will mean that you can see it from the OS once again.
• From the command line do WBADMIN ENABLE BACKUP -addtarget:D:

it won't reformat the disk but should include it and, hopefully, just work on the next pass.