Office 365 Smart Links!!!

21/8/2015 UPDATE: Added in a forced redirect to the portal landing page smart link.

We have been using Office 36 smart links for a while on our client sites (they want things simple!). I had a look into this a few years ago and managed to get the smart links working to all the tabs that are usually required in Office 365. 

One of our clients had complained that the smart links no longer worked (I double checked these and there was an intermittent failure). Double backing on my research I found that something happened recently that stopped the old smart links from initiating properly.

If you are here, you probably know that the smart links pointed you to your federation service for SSO then redirected you back to the wreply address in the smart link itself. Here is an example of the old smart links that recently broke:

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<SSO FQDN>&wreply=https:%2F%2F<Tenant ID>-my%2Esharepoint%2Ecom%2F%5Flayouts%2F15%2FMySite%2Easpx?MySiteRedirect=AllDocuments

<SSO FQDN>, e.g. sso.yourdomain.com, idp.yourdomain.com

The link above, if correctly populated would initiate a Single Sign On to federation service then take you into your OneDrive for Business page.

This link no longer worked. After some testing and remembering that something obscure about portal redirection for a custom themed portal page, I figured out the new smart links! The <SSO FQDN> needed to be changed to <Domain Name>. Once updated, it started working again :) success!

Here is a list of my currently working smart links. Just populate it with your required domain name and Office 365 Tenant ID.

<SSO FQDN>: e.g. sso.yourdomain.com, idp.yourdomain.com

<Domain Name>: e.g. yourdomain.com, microsoft.com

<Tenant ID>: e.g. myoffice365tenant.onmicrosoft.com - the bold part if your tenant ID

Office 365 Portal

https://<SSO FQDN>/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline

Forced redirect to portal landing page
https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<Domain Name>&wreply=https:%2F%2Fportal.office.com%2Flanding.aspx%3Ftarget%3D%252fHome

Outlook

outlook.com/owa/<Domain Name>

OneDrive for Business

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<Domain Name>&wreply=https:%2F%2F<Tenant ID>-my%2Esharepoint%2Ecom%2F%5Flayouts%2F15%2FMySite%2Easpx?MySiteRedirect=AllDocuments

Sites

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<Domain Name>&wreply=https:%2F%2F<Tenant ID>-my%2Esharepoint%2Ecom%2F%5Flayouts%2F15%2FMySite%2Easpx?MySiteRedirect=AllSites

Personal SPO/Newsfeed

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<Domain Name>&wreply=https:%2F%2F<Tenant ID>-my%2Esharepoint%2Ecom%2Fdefault%2Easpx

Happy smart linking!

Office 2016 for OSX not signing in/activating with and Office 365 account

Hey all, just had a recent problem with our OSX clients being unable to activate the latest Office 2016 suite with their Office 365 accounts. I had seen this problem before but there are so many other variables to look into when trying to fix sign in problems.

Your first step should be the https://testconnectivity.microsoft.com/ website which is good for determining most problems with your setup.

I thought this may have been an infrastructure problem where the ADFS 2.0 server was not updated with the latest Roll Up. Apparently that was not the case this time round.

Another problem would have been the time, but no problem there! Time was perfectly in sync.

Just having a wonder around and I found something that was interesting. Apparently Forms Based Authentication needed to be turned on for the intranet domain in ADFS 3.0. It was working perfectly well before but it looks like something had changed with how Office 2016 on Mac was trying to authenticate.

The problem is indicated with this error on the OSX client:

And these errors show up in the ADFS 3.0 logs:

Error AD FS 364
Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Once you enable Forms Based Authentication for the Intranet this problem should disappear! Only minor problem with this is that it's not truly single sign on as you are still prompted for credentials inside the domain.

To enable Forms Based Authentication open your ADFS 3.0 server management console > Authentication Policies > Edit Global Settings then enable Forms Based Authentication for the Intranet,

Hope that helps :)


TLDR; Enabled Forms Based Authentication for the Intranet on the ADFS 3.0 management console.

ADFS 3.0 Errors 100, 102, 277

Problem Description

ADFS service starting but when you open the ADFS Management console you get the error:

ADMIN0017: An exception occurred while connection to the configuration service. The configuration service URL 'net.tcp//localhost:1500/policy' may be incorrect or  the  AD FS x.0 Windows Service is not running

You also get errors similar to the above while trying to execute PowerShell commands for ADFS.

You will also get ADFS errors 100, 102 and 277 in Event Viewer.


Resolution

The issue is with the ADFS service config file at:

%WINDIR%\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config

Someone may have made a change to the switchValue parameter for server traces. This value is case sensitive. In this case, the value was set to 'off' when it should have been 'Off'. Another value is 'Verbose'. Fix the switchValue parameter and restart the ADFS service.