Saturday 15 August 2015

Windows OS lost it's product code/activation status

Ever had the problem where your Windows OS lost it's activation status and product code? Well I have, its happened a few times but were easily fixed by using slmgr and the -ipk switch to reinstall the KMS client key or MAK key... Except this one stubborn server...

One of our servers had lost it's activation status and dropped it's product code. We tried the usual slmgr -ipk to reinstall the product code but that didn't work. Also tried the slmgr -upk, slmgr -cpk, slmgr -ato to no success. There was a slmgr switch that looked very promising, slmgr -rilc which should reinstall all the last known good keys. rebooting the server and trying to activate afterwards still didn't work...

Out of some obscure corner in Google I managed to find something that actually worked.

  DISM /Online /Cleanup-Image /RestoreHealth

This apparently fixed a component store corruption (which probably was something to do with the Software Protection service). I then ran a sfc /scannow for good measure (probably not needed). Bounced the server and all was good.

The product code was showing up and we could then use slmgr /ipk to reinstall the KMS client and get our server activated. Remember to keep your servers happy, when they aren't all sorts of weird stuff goes down!


TLDR; Use 'DISM /Online /Cleanup-Image /RestoreHealth' to fix the component store corruption which broke the activation process.

Sunday 9 August 2015

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!

Friday 7 August 2015

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.