Another reminder to change your passwords, setup Multi-Factor Authentication

by Ed Sparks

Widely reported in the tech media, but well handled and addressed by the company itself, the scope of the recent Cloudflare data leak is somewhat staggering, as the service is so widely used.

A Github page is currently tracking sites affected by the issue, and there's some big names on the list. In fact the list is so long, we recommend changing your passwords on most important sites, and, if not already configured, taking this as an opportunity to setup a password manager and multi-factor authentication.  All of the major services support this now, and Microsoft and Google both have great apps to simplify the process.

We recommend Dashlane and LastPass password managers, and a quick browser search will find detailed information on how to setup two-factor/multi-factor authentication at all the major sites.

Stay safe!

Now with more padlock

by Ed Sparks

We're pleased to report that starting today, our site has now switched to HTTPS.

As has become an industry best-practice, all pages will now be loaded securely via TLS, and any existing links to pages will automatically be redirected to the secure version.

With hacking an ever increasing threat, visiting us over HTTPS site rather than regular old HTTP protects you against many malicious activities, and is an insurance the content has not been altered.

Microsoft Azure and Office 365 Canadian Region Datacenters Now Live

by Ed Sparks

An announcement we've all been waiting to hear finally happened today. Microsoft has indicated that they have launched the Canadian datacenters, which are located in Toronto and Quebec City. 

We look forward to moving all of our Canadian-based clients to this new infrastructure, and all of the new opportunities it will bring for industries that were previously blocked from using Microsoft's cloud services.

Following up from our announcements of new datacenter regions in Japan, Australia and India over the last 18 months, today we are announcing the general availability of a new Office 365 datacenter region in Canada. The new datacenter region adds in-country data residency, failover and disaster recovery for core customer data at rest to customers in Canada. Canadian customers continue to have access to the full breadth of productivity and collaboration services available in Office 365 today.

The full announcement is available here.

Contact us today for assistance with your Exchange, SharePoint or VM cloud migration.

Exchange ActiveSync iOS and Android User Agent Strings

by Ed Sparks

Updated: September 2019

iOS devices unfortunately do not register with ActiveSync or other tools with a logical clear human readable version number. Instead, they show up with strings like "Apple-iPhone3C1/902.206"  

Obviously, this makes discovery and reporting difficult.  To help ourselves, and the community at large, we now maintain this list of hardware and iOS versions for Apple gear.

Hardware Versions:

iPod2C1 = iPod Touch 2
iPod3C1 = iPod Touch 3
iPod4C1 = iPod Touch 4
iPod5C1 = iPod Touch 5

iPad1C1 = iPad 
iPad2C1 = iPad 2 WIFI 
iPad2C2 = iPad 2 WIFI + 3G 
iPad2C3 = iPad 2 WIFI + 3G CDMA 
iPad2C4 = iPad Mini - WIFI 
iPad2C5 = iPad Mini - WIFI + LTE
iPad3C1 = The New iPad (iPad 3)- WIFI
iPad3C2 = The New iPad (iPad 3) - WIFI + LTE 
iPad3C3 = iPad with Retina Display (iPad 4) - WIFI 
iPad3C4 = iPad with Retina Display (iPad 4) - WIFI + LTE  
iPad4C1 = iPad Air - WIFI 
iPad4C2 = iPad Air - WIFI + LTE 
iPad4C4 = iPad Mini with Retina Display - WIFI
iPad4C5 = iPad Mini with Retina Display - WIFI + LTE
iPad5C1 = iPad Mini 4 - WIFI
iPad5C2 = iPad Mini 4 - WIFI + LTE
iPad5C3 - iPad Air 2 - WIFI
iPad5C4 = iPad Air 2 = WIFI + LTE
iPad6C3 = iPad Pro (9.7") - WIFI
iPad6C4 = iPad Pro (9.7") - WIFI + LTE
iPad6C7 = iPad Pro (12.9") - WIFI
iPad6C8 = iPad Pro (12.9") - WIFI + LTE
iPad6C12 = iPad (9.7") 2017 - WIFI
iPad7C1 = iPad Pro (12.9") WIFI 2nd Gen
iPad7C2 = iPad Pro (12.9") WIFI + LTE 2nd Gen
iPad7C3 = iPad Pro (10.5") WIFI 2nd Gen
iPad7C4 = iPad Pro (10.5") WIFI + LTE 2nd Gen

iPhone1C2 = iPhone 3G 
iPhone2C1 = iPhone 3GS
iPhone3C1 = iPhone 4 GSM
iPhone3C2 = iPhone4 GSM
iPhone3C3 = iPhone 4 CDMA
iPhone4C1 = iPhone 4S
iPhone5C1 = iPhone 5 GSM/LTE
iPhone5C2 = iPhone 5 CDMA USA/China 
iPhone5C3 = iPhone 5C GSM/CDMA/Americas
iPhone5C4 = iPhone 5C Europe/Asia
iPhone6C1 = iPhone 5S GSM/CDMA/Americas
iPhone6C2 = iPhone 5S Europe/Asia
iPhone7C1 = iPhone 6 Plus
iPhone7C2 = iPhone 6
iPhone8C1 = iPhone 6S
iPhone8C2 = iPhone 6S Plus
iPhone8C4 = iPhone SE
iPhone9C1 = iPhone 7
iPhone9C2 = iPhone 7 Plus
iPhone9C3 = iPhone 7
iPhone9C4 = iPhone 7 Plus  
iPhone10C1 = iPhone 8
iPhone10C2 = iPhone 8 Plus 
iPhone10C3 = iPhone X 
iPhone10C4 = iPhone 8 
iPhone10C5 = iPhone 8 Plus 
iPhone10C6 = iPhone X
iPhone11C2 = iPhone XS
iPhone11C6 = iPhone XS Max
iphone11C8 = iPhone XR

iPhone OS Versions:

508.11 = 2.2.1
701.341 = 3.0
701.400 = 3.0.1 
703.144 = 3.1 
704.11 = 3.1.2 
705.18 = 3.1.3  
702.367 = 3.2 (original iPad only) 
702.405 = 3.2.1 (original iPad only) 
702.500 = 3.2.2 (original iPad only) 

From this point forward, iPhone OS was renamed iOS.

iOS Versions:

801.293 = 4.0
801.306 = 4.0.1
801.400 = 4.0.2
802.117 = 4.1
802.118 = 4.1 
803.148 = 4.2.1 
803.14800001 = 4.2.1 
805.128 = 4.2.5 
805.200 = 4.2.6 
805.303 = 4.2.7 
805.401 = 4.2.8 
805.501 = 4.2.9 
805.600 = 4.2.10 
806.190 = 4.3 
806.191 = 4.3 
807.4 = 4.3.1 
808.7 = 4.3.2 
808.8 = 4.3.2 
810.2 = 4.3.3 
810.3 = 4.3.3 
811.2 = 4.3.4 
812.1 = 4.3.5
901.334 = 5.0 
901.40x = 5.0.1 
902.17x = 5.1 
902.206 = 5.1.1 
1001.40x = 6.0 
1001.52x = 6.0.1
1002.14x= 6.1 
1002.146 = 6.1.2 
1002.329 = 6.1.3 
1002.350 = 6.1.3  
1101.465 = 7.0 
1102.511 = 7.0.3 
1102.55400001 = 7.0.4 
1102.601 = 7.0.5 
1102.651 = 7.0.6 
1104.167 = 7.1 
1104.169 = 7.1 
1104.201 = 7.1.1 
1104.257 = 7.1.2 
1201.365 = 8.0 
1201.366 = 8.0.1 
1201.405 = 8.0.2 
1202.410/411 = 8.1 
1202.435/436 = 8.1.1 
1202.440/445 = 8.1.2 
1202.466 = 8.1.3 
1204.508 = 8.2 
1206.69 = 8.3 
1208.143 = 8.4 
1208.321 = 8.4.1  
1301.4xxxxxx = 9.0 betas 
1301.342 = 9.0 (older devices) 
1301.344 = 9.0 
1301.402 = 9.0.1 (older devices) 
1301.404 = 9.0.1 
1301.452 = 9.0.2 
1302.143 = 9.1 
1303.075 = 9.2 
1304.15= 9.2.1 
1305.5234xxxx = 9.3 betas 
1305.234 = 9.3 
1305.328 = 9.3.1 
1306.69 = 9.3.2 
1306.72 = 9.3.2 (iPad Pro only) 
1307.34 = 9.3.3 
1307.35 = 9.3.4 
1307.36 = 9.3.5 (important security fix)
1305.5xxx = 10.0 betas 
1401.403 = 10.0.1 
1401.456 = 10.0.2 
1402.72 = 10.1 
1402.100 = 10.1.1 
1403.92 = 10.2 
1404.27 = 10.2.1 
1405.277 = 10.3 
1405.304 = 10.3.1 
1406.89 = 10.3.2 
1406.8089 = 10.3.2 (iPad Pro) 
1407.60 = 10.3.3  
1501.5xxx = 11.0 betas 
1501.372 = 11.0 
1501.402 = 11.0.1 
1501.421 = 11.0.2  
1501.432 = 11.0.3 
1502.5xx = 11.1 betas
1502.93 = 11.1 
1502.150 = 11.1.1 
1502.202 = 11.1.2 
1503.5xx = 11.2 betas 
1503.114 = 11.2 
1503.153 = 11.2.1 
1503.202 = 11.2.2 
1504.60 = 11.2.5 
1504.100 = 11.2.6 
1505.216 = 11.3 
1505.302 = 11.3.1  
1506.79 = 11.4 
1507.77 = 11.4.1
1601.5xx = 12.0 betas
1601.366 = 12.0 
1601.405 = 12.0.1
1602.5xx = 12.1 betas
1602.92 = 12.1
1603.50 = 12.1.1
1604.39 = 12.1.3 
1604.57 = 12.1.4
1605.5xx = 12.2 betas
1605.227 = 12.2 
1606.5xx = 12.3 betas
1606.156 = 12.3
1606.203 = 12.3.1
1607.5xx = 12.4 betas
1607.77 = 12.4
1607.102 = 12.4.1 (current)

1701.55x = 13.0 betas

We've also had requests for some Android agents - particularly Samsung - which are proving equally as annoying to decipher.

Samsung encodes the Android OS version number at the end of their string, with zero padding.

SAMSUNG-SGH-I337M/101.403 indicates Android 4.3 
SAMSUNG-SGH-I317M/100.40102 indicates Android 4.1.2 etc.

So with that knowledge, now what?

Thankfully Ben over at One Simple Script has created a great new version of his reporting script that will parse the IIS ActiveSync logs and report all the versions in use on a server.

Get the script and more information here.

Office 365 / Azure AD Password Synchronization Security

by Ed Sparks

We are often asked by customers how secure it really is to synchronize their passwords to and from Azure AD, be it standalone or as part of Office 365.

Our short answer:

The passwords themselves are never sent over the wire in either direction. In all cases only password hashes are sent.

The longer answer is easily derived and supported both from TechNet articles and various third-party sites. The key take-away is that only the hashes are ever retrieved, additional encryption applied, and then that is sent to Azure AD or back.  The passwords themselves are never used or sent.

From TechNet:

The Active Directory Domain Service stores passwords in form of a hash value representation of the actual user password. The Password hash cannot be used to login to your on-premises network. It is also designed so that it cannot be reversed in order to gain access to the user’s plain text password. To synchronize a password, the Directory Sync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to the Azure Active Directory Authentication service.

When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services.

Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment.

From A Third-Party

An independent company that makes SharePoint and Office 365 tools also performed their own analysis, down to the packet capture level. What they found was:

The hash over the wire that is captured is not an MD4 hash of clear text password. It is a secure PBKDF2 key derived from SHA256 hash of the MD4 hash (derived from crypto API documented at per RFC 2898.

Read more at their blog post:

Overall we're very confident using this functionality at our customer deployments, and Microsoft have created a well thought out and secure implementation.

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.

Windows 8 Unexpectedly Closes Explorer Windows

by Ed Sparks

A strange quirk noted at several customer sites recently - and apparently fairly widely reported - is users with Windows 8.1 or 10 experiencing their File Explorer windows disappearing in the middle of using their system.

The cause is due to newly introduced behaviour in Group Policy Preferences (GPP)  for Drive Mappings.  Prior to Windows 8.1, GPP Drive Mappings would only get added or updated at logon.  Now, the preferences will apply whenever the Group Policy Background Refresh cycle occurs.

A side effect of this new behaviour is that any Drive Mappings that are configured with an action of Delete or Replace will cause File Explorer to disconnect the drive (and thus handles to any open files!) and then recreate the drive mapping.  While it does this, it kills the actual opened window for any folders on that drive.  It happens quickly, so many users don't notice any other symptoms except their File Explorer windows disappearing, along with occasional inability in open files.

While it's understandable why Microsoft implemented this improvement to allow on-the-fly changes to Drive Mappings, this is poor default behaviour and not obvious to users.  Even a warning popup would be nice.

The trick to resolve? Make sure the only action for GPP Drive Mappings you use is Update.  The good news is this action works in almost all scenarios, including if a user were to map the same drive letter to some other resource themselves (while at home, for example). In this instance, the GPP will override their mapping.  Update also creates a new mapping if it doesn't exist before (which isn't clear from the name 'update')

Of note, this issue obviously only affects corporate users, as home users don't normally use Group Policy.  If you're seeing this on a non-domain machine, let us know in the comments.

Side Note:  Love the 1990s era WIndows XP UI that still exists in Group Policy, Microsoft