WP 8.1 error: “We can’t connect to OneDrive to back up”

A few weeks back, apparently my Lumia 930 stopped backing up with the above error- it’s looking like the OneDrive backup (OneDrive > Options > Device Backups) may have become correupted. I deleted the backup for the 930, ran a fresh backup and it failed, but during the failure it switched off settings backup on the phone. I switched it back on, and now the 930 is showing up as a backup device in OneDrive. It hasn’t finished yet, but there is a backup for that device showing up in OneDrive with todays timestamp on it…

UPDATE: backup still failed, but device and OneDrive think it backed up. ?

UPDATE 22/06/2016 @ 16:44: after chatting to Microsoft a lot of the day, it seems that the problem was having the official twitter app installed- ? They pointed me at:


And although I don’t have Live lockscreen beta, the official twitter app is horrbily slow and unresponsive so I thought maybe that was worth a go (also, the icon was going dark when charging- possibly when backing up- implying it was unusable at this time, which made me think there might be an issue with it). Uninstalled twitter (still have tweetium), and have now had two successfull backups work without a problem.


Unable to browse network in Server 2012 R2 recovery mode (optical media boot)

This was a weird one (maybe still is). Trying to “repair” a server from a bare-metal backup on a network share.

Boot into recovery mode off the ISO image, go into troubleshooting command prompt and try to set a LAN address. Nothing. Read a few comments on TechNet social, run “wpeinit” then re-run all the netsh stuff, nothing.

Reboot the server, run wpeinit immediately then try out the netsh stuff- this seems to work. This is not very good, MS. In a DR situation, you just want to boot your servers back up and recover them, not fight with the PE recovery environment.

When Server 2012 DeDuplication goes bad

This is a really weird one.

Our old SAN was really struggling with space despite having EMC DeDuplication switched on, so I commissioned a Server 2012 guest on some new SAN storage, and started serving files through this guest off a dynamic VHDX file (sat on another chunk of the same storage). Because our old SAN used NDMP backups, I had to use RoboCopy to migrate the data which is slow but did the job. The reason for the intermediate VHDX is simply for portability- we could pick it up off the SAN and dump it on any Windows server (even stand-alone), whereas obviously anything stored directly on the SAN would need to be connected up to servers on the iSCSI network. The VHDX file is connected to the guest on a SCSI bus as this enables hot-removal unlike the IDE buses.

We’d also been waiting for Backup Exec 2010 R3 SP3, as this was the first release of 2010 that at least enabled the agent to work on Server 2012.

This was all good so far; RoboCopy had- as expected- kept all the NTFS permissions correct so it was just a case of sharing the folders out. As both shares now also sat on the same volume, I though Windows Server 2012 DeDuplication could really get to work by DeDuping across the shares, which previously hadn’t been possible due to the configuration. The DeDupe process started slowly but I didn’t think anything of this, because the Celerra took ages to fully DeDupe all its volumes. I reasoned that this should be fine as it was the Hyper-V guest doing the DeDuplication; I presumed that the guest should see the VHDX as just another block of storage rather than trying to DeDuplicate the VHDX file from a host machine.

This is where it all went a bit strange. Nobody had complained about access speeds or anything, yet Backup Exec was taking absolutely ages to back up this volume (I did some rough maths and figured out it would actually never complete a full backup inside a week, compared to “just” taking 48 hours or so previously). Then it turned out that actually, it was doing full backups in less than an hour because it wasn’t actually doing full backups.

This is when it became apparent that there is a clash between the presentation layer of Server 2012 (what I would normally refer to as the Explorer shell, but this is Core), DeDuplication and dynamic VHDX files. The storage system within Windows knows how much actual data is on the volume because it reports x TB used, correctly. DeDuplication seems to go mad and actually un-DeDuplicate everything, so you end up with a space saving of 0bytes (from 11GB… so it’s gone backwards). And the… “explorer” shell goes further and actually loses all reason, reporting insanely small “size on disk” numbers for vast amounts of data (real-world example: 5.1TB of actual data takes up just 37GB on disk. Yeah, right). So to be fair, this is why Backup Exec is being so erratic- it’s asking Windows for the amount of data, and Windows replies that although there’s supposedly 5TB of data, it’s only taking up 37GB on disk.

The fix is currently unknown, as apparently even Microsoft haven’t encountered this one. I’ve stopped the actual DeDupe jobs (even though it’s still enabled against the disk) and set a RoboCopy job off to rehydrate (fingers crossed) everything onto yet another volume (this time pass-through to the new SAN) so that at least we can start getting valid backups. We’re passing information on to Microsoft to see if they can come up with anything, and have discovered that this is perfectly repeatable: enable DeDupe against another (live but non-backed up) dynamic VHDX and the same thing happens, Windows reports the actual amount of data as X but the size on disk as X-a-lot-of-space.

Update 02-NOV-2013: still unresolved. Found a few discrepancies in NTFS permissions but this doesn’t explain much. The data seems to rehydrate onto another volume, but that’s maybe the wrong word as “rehydrate” implies it was deduplicated in the first place, which it wasn’t really. Still, at least we can get some form of backup for now.

Further ForeFront TMG issues

Well done. Microsoft have made it phenomenally difficult to backup ForeFront TMG (actually- in all fairness, I don’t think ISA was very good either). But help is at hand; download the TMGSDK.exe file from


And- after installing- look for a file called “importexport.vbs” (probably located in %programfiles(x86)%\Microsoft Forefront TMG Tools\SDK\samples\Admin). This file can take one of two switches: “e” or “i” (which unsurprisingly stand for “export” and “import”). Also, when you feed it the filename- which can be anything- you must also feed it the full path or it won’t do anything despite appearing to (not prefixing with a drive + path won’t fail, but I couldn’t find the file anywhere so assume it actually just doesn’t create the file…).

At least now you have something you can pass to the windows scheduling service to routinely back up the FFTMG config. I’ve further modified the script to save off to a network location (which is already backed up) rather than the local drive, and it sends a little email out too as a notifier.