OneDrive for Business 'Authentication Protocol Not Supported'

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\sp
   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
   MicrosotOffice16_data:SSPI
   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

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

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

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!

SharePoint Large Upload Limits - The Definitive Article

There's a tremendous amount of confusing information on the internet surrounding configuring SharePoint to properly allow large uploads.  Much of the confusion is due to differences in SharePoint versions (2007 ("12"), 2010 ("14") and WSS / Foundation) along with changes Microsoft made to the underlying OS and IIS.

For our sanity - and everyone else's - here's what we've found is truly the only full proper way to make this work consistently across Document Libraries, Lists and everything in between. 

The following example would be to allow 500+MB uploads, and you would need to adjust the numbers to match your needs.  Keep in mind the numbers are (in true Microsoft fashion) in MB in some places, KB in others, and bytes in still others! 

We've also made these steps a fully GUI based affair, as many admins are still uncomfortable about hacking around in config files manually. 

Note: This process applies to SharePoint 2010 or greater on Windows 2008 R2 or newer.  On Windows 2008 (non-R2) manual edits to web.config would be required using the same settings, or download the Configuration Editor as part of the IIS Administration Pack.

1. In Central Administration, under Application Management/Manage Web Applications find the web application to update and select it.  Then from the ribbon choose General Settings.
2. Update the Maximum Upload Size to the desired size – i.e. 512 MB and click OK

Repeat the following steps on EACH Web Front-end Server and for each IIS site representing each SharePoint zone:

1. In IIS Manager navigate to the Sites node and choose the appropriate site representing the chosen SharePoint Web Application
2. Click Advanced Settings in the Action Pane.  Under Connection Limits increase the Connection Time-out to at least 300 seconds and click OK
3. In the middle pane double click on Configuration Editor
4. Under Section, choose system.webserver/security/requestFiltering
5. Expand requestLimits and change the maxAllowedContentLength entry to a value of at least 536870912  (this is in bytes).  Click out of the entry box, then choose Apply in the action pane
6. Under Section  choose system.web/httpruntime
7. Modify the entry maxRequestLength to a value of at least 524288 (this time it's in KB!) and the executionTimeout value to 3600.  Click out of the entry box, then choose Apply in the action pane
8. Open Command Prompt As Administrator and execute
   iisreset
9. Go forth, and upload! 

All of these steps are required to fully and properly support large uploads across libraries and lists.

Does your SharePoint environment need help?  Contact us today.

Image courtesy Techbush

Exchange internal anonymous relay done the right way

UPDATED: May 2017

Allow internal SMTP email relay, bypass the junk filters, and make it all work right the first time.

Update: This guidance is still valid up to and including Exchange 2016, but the steps below refer to Exchange 2010. Newer versions use the same types of permissions, but most operations must be done through Exchange PowerShell.

A common scenario for server admins is allowing internal servers to safely relay anonymous emails for alerts, logs, or internal application notifications through Exchange, and ensure the messages are delivered correctly to users.

Beginning with Exchange 2007 Microsoft made changes which made this a better and more controlled process than previous versions, but also made two confusing and distinct ways to configure: the "Externally secured" method and the "anonymous" method. 

Both have their pluses and minuses, but our recommendation is always the latter, as it makes identifying emails that were submitted anonymously (and therefore potentially untrusted) more obvious. Why? Messages submitted in this fashion will advise Outlook not to resolve the sender address to a Display Name. Rather, it only shows the exact (and often completely random) sender from the host SMTP session's envelope. Equally importantly, using this method the end-to-end anti-junk mail configuration will work correctly across both Exchange and Outlook's various filters. 

Microsoft's provides this Technet article which covers how to configure both methods on the Exchange server, but unfortunately gives no context or explanation as to why an admin would choose one or the other. We've written this article based on our experience and testing, to provide the missing details.

Configuration Guidance for Anonymous Method:
We will follow the steps in the article section Grant the relay permission to anonymous connection

1. In EMC at the Organization/Hub Transport node under the Anti-Spam tab, ensure that the IP Allow List and Content Filter are enabled. These features together actually do the work to make the messages quasi-trusted and stamp the "SCL -1" rating.  Failing to enable both will result in messages not correctly bypassing filters.
   If you don't see these options you might have to run the script to enable Anti-spam features on your server.
    
2. You may use either the EMS or the EMC (Under Server Configuration/Hub Transport node) to create a new Receive Connector and define the appropriate remote networks or hosts that will be able to use this new connection.
   Note: Be sure you don't leave this new connector accepting connections from all IPs, as this is a security risk for mailicious staff or malware that may get lose on your network. All conenctions to Exchange should be secured or from known systems only.
    
3. Next, assign the appropriate AD Permission of Ms-Exch-SMTP-Accept-Any-Recipient via the Exchange Management Shell.  At this point, DO NOT follow the rest of the steps under Configure the Receive connector as externally secured, as this method will not be used.
    
4. Under Server Configuration/Hub Transport switch to the Anti-spam tab. and open the IP Allow List
    
5. Duplicate the list of hosts that you had enabled to send through your new Receive Connector here. This ensures that both server and client-side anti-spam are bypassed, and the X-SCL -1 header is stamped for Outlook's later use.

Email will now be accepted and relayed through your new connector and will always go directly to the Inbox of users in Outlook/OWA. 

Why Not Externally Secured? 
While this method is easier to configure - just click the checkbox in the EMC - it has two negatives. The first is the previously mentioned display name resolving in Outlook (via the AD Permission "ResolveP2")  With this permission Exchange will consider submitted emails to be authenticated (which they're not), and subsequently resolves the SMTP address to a display name if possible. This is a bad practice in our opinion, as it tricks the end-user into believing this is trusted sender.

The second, and more frustrating problem, is that Exchange will not stamp SCL headers into the message, so the Outlook client-side filtering will be applied (if enabled).  As more-often than not server alerts and backup log messages will look very spammy, they will promptly get turfed into the Junk Email folder. As Outlook thinks it is being helpful deciding on its own, rather than looking at what Exchange rated the message, when in fact it's just creating unhappy users and admins.

Further Reading
What happens when you make your new Receive Connector Externally Secured?

This will be granting several rights including the ability to send on behalf of users in the organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default "Externally Secured" permissions are as follows:

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

This is telling Exchange to ignore internal security checks because these servers are trusted, which goes against the ethos of an anonymous relay point.

What happens when you add the Relay Permission instead?
This option grants the minimum amount of required privileges to the Receive Connector for accepting messages from and to anyone, and must be done consciously through the Exchange Shell, rather than clicking a checkbox.

Accepted Domains, Safe Senders List and You
http://blogs.technet.com/b/exchange/archive/2011/07/08/accepted-domains-safe-senders-list-and-you.aspx

Exchange anti-spam myths revealed
http://blogs.technet.com/b/exchange/archive/2009/11/13/exchange-anti-spam-myths-revealed.aspx

The saga of the "Junk Email" Folder - putting the puzzle together
http://www.exchangeinbox.com/article.aspx?i=155

Need your Exchange Server to work day and night, and not worry?
Planning an Office 365 Migration?
Contact us today.

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

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

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:

http://technet.microsoft.com/en-us/library/hh825251.aspx
http://blogs.technet.com/b/heyscriptingguy/archive/2012/09/27/use-the-powershell-dism-cmdlets-to-manage-windows-8.aspx