How to resolve AD FS 3.0 WAP sign in 'Error 503: Service unavailable'

For those expecting a blog post on how to resolve a “Service Unavailable: error 503” for ADFS 3.0; quick, how to and easy fix to move on. Well, this isn’t that kind of post. (If that’s all you want, skip to the title Solution lower down).

What this post is about is two topics today. Topic no. 1 is frustration and topic no. 2 is one of my mantras. So lets begin with a quick vent and some release of frustration.

I’ve just deployed Windows Server 2012 R2 in Azure. To be accurate, I just deployed 7 x Windows Server 2012 R2 servers in Azure compute. Its a small amount of servers. I won’t bore you with the details of how I simply went via the Azure portal and provisioned them. No Chef, no Puppet or Azure CLI here. Just KISS! (keep it simple stupid).

The instances deployed are as of a certain date, as shown below is this brilliant screenshot:

What this means is, taken from Azure directly is: Multiple versions of the image are available. As a best practice, consider selecting the latest version.

Here’s where the venting of frustration comes out. I work with Microsoft products all day, everyday (even though I use a Macbook Pro as my work laptop) and I’ve been doing so for the last decade of my IT professional career. So I like Microsoft. However, I have a love / hate relationship. I don’t love to hate Microsoft, but it certainly feels that way at times.

It would be great to expect that when you deploy a Windows Server 2012 R2 instance running an image version from June 25th, that’s less than a month ago (at the time of writing this), that the image would have updates, patches, fixes, and general resolution to the near endless problems with roles, features and Windows core components. That’s what you’d expect. That’s what you’d think. That’s what I expected and what I though. WRONG!

Let’s not spoil the surprise, even though it’s rather obvious, and lets move on to topic no. 2 for today’s blog: mantras. I have a list of mantras I live by. I wake up everyday at 5.30am, make my morning cappuccino and sit with my journal. I’ve written down most of my mantras as I feel it not only keeps me moving forward, but good to put pen to paper and work out a mindset and methodology to live by.

One of my top three mantras is “iron will; never quit”. If i set my mind to something, if I put my energy into doing or creating something, I never want to either fail or not full fill what I set out to do. Whether that be getting through a project at work and successfully deploying ADFS 3.0 infrastructure, or trying to win at football (or soccer if you’re that inclined) when I hit a brick wall, when things are not going to plan I stop and say to myself: iron will; never quit. Iron will; never quit. IRON WILL; NEVER QUIT.

Solution

When I was faced with ADFS 3.0 not working, after checking every aspect of every component on Windows Server, the internal network, the external network and Azure services, I hit the brick wall. I was sure that I had checked everything and all was working. However, what I also did was “assumed”. Assumptions are like ninja’s. Ninja’s can strike without notice, just like when you assume something. Ninja’s also have the ability to kick your ass and frustrate you beyond belief. Exactly like an assumption.

I knew that there’s some faults with out of the box Web Application Proxy on Windows Server 2012. I mean, why would a core Windows role work out of the box? Even more so, the assumption that the fix that was released in April of 2015 would be applied to a Windows instance with a date of June 2015.

To resolve the issue: apply Windows updates (all Windows updates including important updates and optional updates, I had a total of 15 important Windows updates + 60 optional security etc updates), that dating back much earlier than April of 2015. Once I applied all updates to the Web Application Proxy servers (I even did it to my ADFS 3.0 pair) and restarted all the servers. VOILA! All was working.