OneDrive for Business 'Authentication Protocol Not Supported'

by Ed Sparks

OneDrive for Business (ODB) has become a major selling point of the Office 365 cloud platform for small and medium business, particularly as the service moved to virtually unlimited storage, and many of the limitations that remained from its SharePoint based architecture have been removed or improved upon.

Unfortunately, an ongoing low point of the experience has been the sync client.  Based on outdated technology Microsoft acquired from the disaster that was Ray Ozzie and his Groove product, it has gone through a myriad of name changes and tweaks, none of which ever seemed to solve the problems.  It would often throw errors and most egregiously in this era of Ultrabooks and small SSD drives, had no selective sync capability.

Thankfully, Microsoft is finally turning a corner with the overall reliability and functionality of ODB, and is at last merging and improving the client experience with the Next Generation Sync Client. However, this client is still only in 'First Release' stage, remains unavailable for Windows 8.1, and only supports ODB itself, not other SharePoint libraries.  They've indicated all of these will be solved in the 'first quarter 2016' so here's hoping.  If you're using only ODB and on Windows 7 or 10, we highly recommend using the Next Gen client.

However, for those on 8.1 or with more complex needs the (previous gen?) OneDrive for Business client remains the only choice, complete with bugs.  One of the most frequent glitches we see - and there appears to be no consistency as to why it shows up or when - is the dreaded Unsupported Server message

The server you are trying to access is using an authentication protocol which is not supported by this version of Office

This often happens for users when they first logon and the OneDrive for Business client launches, but can also occur when setting up a sync for the first time.  It's our hunch that this is related to TLS changes Microsoft made on the server side as part of discontinuing old ciphers and encryption, but there's never been any good communication or clarity from them on what changed.  More frustratingly, there's also been no useful instructions from them on how to fix this.

We've therefore put together the following steps gleaned from numerous forum posts and tests that this consistently fixes the problem, albeit with a bit of work.

  1. Shut down the OneDrive for Business Desktop Client (dark blue cloud icon), by right clicking and choosing Exit.  This sometimes causes the client to crash, and then restart itself and perform recovery steps (which won't work).  If so, simply repeat the Exit step and it should close correctly.

  2. Close all Office 2013 or 2016 desktop applications - Word, Excel, etc.

  3. Remove the following folders from the user's profile

    c:\users\<username>\appadata\local\microsoft\office\16.0\OfficeFileCache (if it exists) c:\users\<username>\appadata\local\microsoft\office\15.0\OfficeFileCache (if it exists)

    These folders will be automatically recreated by a repair, and the applications.

  4. Open Control Panel, and search for and open Credential Manager.  Under the Windows Credentials section, find an remove any Generic Credentials related to the Office 365 account in question.  These will be in the format
    or similar
  5. In Control Panel / Programs and Features, find the Microsoft Office 365 Business or ProPlus install, then Right Click and choose Change.
  6. Select an Online Repair and click Repair.  
  7. When the Online Repair is complete, click Start and search for OneDrive for Business desktop client, and open it.
  8. OneDrive for Business should ask for the Office 365 account logon and password information, and then proceed to sync correctly.

Offline Files Service Crashing/Unavailable

by Ed Sparks

A common scenario that bites many a company that extensively uses Windows imaging for deployments, is that Offline Files completely melts down after a newly imaged system is setup.

This will show up in the event logs as the Offline Files service being unable to start, Folder Redirection breaking etc.  The first sign is usually a system event log error like

Windows could not start the Offline Files service.
Error 3: The system cannot find the path specified.

The best resolution is to make sure the reference system (where you took the image from) always has Offline Files disabled before the image is taken, in addition to Sysprep being run.

However, if you've already taken an and applied an image and have a broken system, then thankfully the fix is simple.  Just set a registry key to reset ("Format") the Offline Files ("Client side cache") database.  On Windows 7 and 8, this can be easily done by running the following from an Administrative command line:

REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v FormatDatabase /t REG_DWORD /d 1 /f

Reboot the computer, and the Offline Files database will be reset and recreated.  Offline Files should start normally, and things like Folder Redirection and the like will follow.


Offline Files, Folder Redirection and DFS are some of the most complex to configure Microsoft technologies with an enormous amount of gotchas and hotfixes.  It's one of our most frequently requested support items from customers.   We've developed a great deal of expertise and best practices around these and will be posting an article soon detailing our findings.

In the meantime, why not contact us to help today!

The shockingly easy way to hack or reset a forgotten Windows password

by Ed Sparks

This trick has been around for years, and long assumed fixed.  Surprisingly, while recently investigating a related issue we discovered this one is still going strong in Windows 7 and 8 (along with Vista, where it originated).

Image Courtesy Icone-gif

Image Courtesy Icone-gif

In what has become known as the "Utilman Trick," if you are able to physically access a system and boot from a Windows install or recovery disk, you can quickly change a file, reboot into the original Windows install and with a few clicks change the password of any account.  You can also create new accounts, and perform all order of administrative management.

While Bitlocker, or physically denying access to the system will obviously solve this, it's shocking that this continues to exist.

The details, and simple process are well documented here at Technibble, among hundreds of other places.

Here it is in a nutshell:

1. Recovery Boot

cd windows\system32
ren utilman.exe utilman.exe.bak
copy cmd.exe utilman.exe

2. Normal boot

net user administrator newpassword

Yes, really!

Generate custom, self-signed, long-expiry certificates on Windows

by Ed Sparks

We recently were introduced to a great utility that a Microsoft IIS Team employee maintains called SelfSSL7.   This is an upgraded version of the old SelfSSL tool that used to ship as part of the IIS Resource Kit.

Self-signed certificates have a myriad of useful purposes for internal uses in testing and staging environment, but are an awful pain to deal with using the (almost completely lacking) internal tools. 

SelfSSL7 to the rescue! 

Thomas has all the details at his blog below, but in a nutshell you simply download the tool, unzip and run from a command line.

For example, to create a self-signed certificate for a web server with a 5 year expiry and automatically export the whole thing to a PFX file for safe keeping, all while adding it to the local computer store and binding it to an IIS site automatically - simply execute the following at an elevated command prompt:

selfssl7 /k 2048 /v 1825 /x /f c:\SelfSSL7\my-5-year-cert.pfx /i

There is no step 2!

Such a time saver! 



Goodbye imageX, hello DISM for Windows 8 Imaging and Deployment

by Ed Sparks
This article seems to be getting a tremendous amount of traffic!
Leave a comment with any suggestions or questions you might have about Windows 8 deployment.  Contact us for help with your project too!

A quick note for those starting to work with Windows 8 deployment, or just playing around with images.

ImageX has been flagged by Microsoft as a deprecated utility, and has been replaced with DISM - Deployment Image Servicing and Management.  Catchy.  There's no Metro/Windows-8/Store-style/Technologywithoutaname version, though.

The good news is that DISM is an excellent replacement and has matured quite a bit since ImageX, while still keeping most of the same command structure.

In our testing it has proven much quicker and more reliable, and is built into Windows 8, Server 2012 and PE 4.

There's even PowerShell commandlets to do all sorts of useful things.

Find out more by running from an Administrative command prompt:

dism /?

Our one-liner quick and dirty capture/deploy commands for a standard Windows install is as follows:

1. Plug in a large USB drive 

2. Boot into Windows PE 4 (here's how)

3. At the command prompt find out the drive letter of your USB drive (e: in the example below) then execute:

dism /Capture-Image /ImageFile:d:\my-windows-partition.wim /CaptureDir:e:\ /Name:"My Windows Partition"

To then place this image on a new drive or rebuild, do the opposite,  again while booted into PE 4

dism /Apply-Image /ImageFile:d:\my-windows-partition.wim /index:1 /ApplyDir:C:\


Further reading:

Fix L2TP and PPTP VPNs on Windows Vista/7/8/2008/R2/2012

by Ed Sparks

Update 1: PPTP Broken? Read our latest article!

Update 2: Even more VPN grief - this time with Windows 8/8.1 Metro and PPTP.  See this article for the solution to "Error 850: The Extensible Authentication Protocol type required..."


For "security reasons" Microsoft somewhat broke the implementation for L2TP/IPSec (and in some cases PPTP) VPNs in Windows Vista/7/2008 R2.  This was due to an architectural change made in these OS versions to disable NAT Traversal functionality for these protocols by default.

This means that while your old XP machine or iPhone will connect, your brand new Windows 7 or 8 system will spin its wheels hopelessly and eventually error out.  Strange, non-obvious and questionable default choice, in our opinion.  You know you are likely experiencing this issue if you try to connect with L2TP and get errors numbers such as 800, 794 or 809.

Thankfully you can bring back the old behaviour with a couple of changes: a registry key and a Hotfix. 

On your Windows Vista, 7 or 8 client machine change or add the following registry item:


New DWORD (32-bit) Value:AssumeUDPEncapsulationContextOnSendRule 
Set the value to 2

This allows the client or server to be behind a NAT firewall.

Reboot after making the change, and retry the connection.  If there's still issues, you may have to apply the following Hotfix:

You cannot establish an IPsec tunnel to a computer that is running Windows 7 or Windows Server 2008 R2 through a NAT device

Better still?  Start using SSTP VPNs which will work through virtually any NAT or Firewall device much more consistently, and only requires a cheap or free public SSL certificate.  

This article has more information, and a link to Microsoft's extensive VPN guide.