Thursday 30 July 2015

ActiveSync not working through Web Application Proxy after certificate renewal

I've recently had a hairy problem with a ActiveSync on Exchange 2010. Funnily enough this happened after a certificate renewal...

Just some background on this so you know where I'm coming from. Our client had decommissioned Forefront TMG (may it rest in peace/pieces) and was in need of a reverse proxy server. Luckily they had an ADFS 3.0 server setup for Office 365 domain federation so we made use of the Web Application Proxy.

Initially the transition worked great! Everything was hunky-dory, everything just worked.

Then came a notification for a certificate renewal... Cert gets renewed, applied to services, and tested for everything except ActiveSync... (bad oversight, this is now in my to check list when working with certificates).

A few weeks later after the renewal the problem becomes more apparent as people actually used the ActiveSync (funnily enough it took them that long to realise this). Wondering what went wrong I tried running through an ActiveSync setup on an Android phone and iPhone... neither worked. Then I tried on a Windows Phone... a miracle, it worked! But why not on the others?!?! Started testing 3rd party clients, Outlook for Android failed while the Nine mail client worked... More anger and frustration ensues...

Thinking it could possibly be something to do with Exchange, I patched it to CU9 in hopes that this would automagically correct the problem. No kudos. After taking a break and freshening up my thinking I eliminated the web application proxy from the equation by directing requests directly to the Exchange server, and wah-lah, ActiveSync is working! Put the requests back through the web proxy and sad faces, not working.

This left the web application proxy server as the culprit. After doing some Google-fu something interesting popped up. This command:

  netsh http show sslcert

Running this it returned something that was gone, a certificate bound to 0.0.0.0:443 that no longer existed! Find the binding with the bad certificate and make a note of the appid as you'll need to rebind the port with this appid.

To fix this I removed the binding for 0.0.0.0:443

  netsh http delete sslcert ipport=0.0.0.0:443

Then recreate the binding with:

  netsh http add sslcert ipport=0.0.0.0:443 appid={xxxx} certhash=xxxx

xxxx is the GUID of the appid and certhash is the thumbprint of the new certificate.

I had some problem in getting this to execute so I completed the same command inside the netsh CLI.

Once bound the ActiveSync started working on Android and iPhone with the native mail clients.

My life was spared - mail could now be had on mobile devices for all!


TLDR: Remove old SSL binding that references an old/removed certificate then re-create the SSL binding with the new certificate.

Office 365 - User has no rights to their own OneDrive for Business library

This is the second time that I have seen this weird problem with OneDrive for Business for our Office 365 clients. The affected user will have access to view the folder but will not have any permissions to create, upload or view anything in their OneDrive for Business.

When checking the permissions on their user profile in SharePoint Admin, this is all correctly set which makes this even more - strange... 

To resolve this problem you will need to access the user's user profile. To get there browse to:

SharePoint Admin -> User Profiles -> Manage User Profiles, then search for the affected user. Hover over the user profile that you need to correct then click on the drop down arrow and then Manage site collection owners. Change the Primary Site Collection Administrator and Site Collection Administrators to another account (preferably the account you are using to administer Office 365). Make sure that the affected user is NOT listed for any roles. Once done, apply the change. Then go back into the Manage site collection owners again and change the roles back to the affected user.

This should fix the problem that should never have happened in the first place! 


TLDR: In SharePoint Admin; change the affected users user profile site collection admins to another user and make sure the affected user has no roles. Then change the site collection admin roles back to the affected user.