Upgrading lab to Server 2016

As Server 2016 is now in GA, I figured I'd have a shot and upgrade my lab from 2012 R2 to 2016.

The majority of the machines were completed as an in-place upgrade.

Before the upgrade:

- AD Server, also holding ADFS and WSUS (server core)
- Applications Server (full fat desktop)
- SQL Server (server core)
- Web Application Proxy (server core)

After the upgrade:

- AD Server (server core)
- ADFS Server (full fat desktop)
- Applications Server (full fat desktop)
- SQL Server (server core)
- Web Application Proxy (server core)

All 2012 R2 boxes were fully patched before upgrading; ADFS was split out onto a seperate box as the upgrade is not capable of an in-place upgrade of this element - the process as documented here is fantastic for migrating this. I still haven't installed WSUS again but I'm planning on rebuilding the SCCM element of my lab anyway, so don't need it yet.

The only snag I've encountered is that when you do the in place upgrade for server core, you need to run Setup with a couple of parameters - /Compat IgnoreWarning - otherwise you just get a blue screen.

The Web Application Proxy server upgraded fine, but the WAP component was left in an invalid state; I just removed it and reinstalled as I was resetting ADFS anyway -- likewise Azure AD Connect needed to be reinstalled and reconnected.

Finally, a disk cleanup frees up space - just run 
dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
although it should be noted this will prevent you reverting the upgrade etc.

Next task is to upgrade the two Hyper-V hosts for my lab ...

Chocolatey and keeping your local feed up to date

For a while now I've been using a combination of Boxstarter and Chocolatey to help me manage and maintain by devices. But one of the snags that I have encountered is ensuring that my local, moderated feed is up to date with the public feed.

You are probably wondering ... why do I bother with a private package feed? Well, two reasons:

- Offline support; I often end up having to rebuild devices while away from home - and hotels don't have great wifi. I travel with a pre-loaded USB key with a copy of my feed (and installers) for just this reason

- Control; I like to keep control of what versions are on my devices and don't particularly like being forced onto the latest and greatest - and I like to ensure all my devices are on the same version ;)

So I wrote a very simple tool to compare my local package feed to the chocolatey public feed; you can find it on GitHub: https://github.com/aneillans/ChocoCompare

And here it is:

No settings found, please specify your repository locations
Chocolatey Repository [https://chocolatey.org/api/v2/] (Please enter to keep):
Local Repository [] (Please enter to keep): D:\Choco\Packages
Checking package 7-Zip (Install); local version is;
remote version is
Checking package Beyond Compare; local version is;
remote version is

Update available for Beyond Compare to
Checking package Boxstarter; local version is 2.8.29;
remote version is 2.8.29

Checking package Boxstarter Bootstrapper Module; local version is 2.8.29;
remote version is 2.8.29
Checking package Boxstarter Chocolatey Module; local version is 2.8.29;
remote version is 2.8.29
Checking package Boxstarter Common Module; local version is 2.8.29; remote version is 2.8.29
Checking package Boxstarter HyperV Module; local version is 2.8.29; remote version is 2.8.29
Checking package Boxstarter WinConfig Module; local version is 2.8.29;
remote version is 2.8.29
Checking package Chocolatey; local version is 0.10.0; remote version is 0.10.1
Update available for Chocolatey to 0.10.1
Checking package ChocolateyGUI; local version is 0.13.2; remote version is 0.13.2
Checking package dashlane; local version is; remote version is
Checking package Fiddler; local version is; remote version is
Checking package Google Chrome; local version is 52.0.2743.116;
remote version is 53.0.2785.116
Update available for Google Chrome to 53.0.2785.116
Checking package Windows Management Framework and PowerShell;
local version is 5.0.10586.20151218; remote version is 5.0.10586.20151218
Checking package RSAT 1.0.5; local version is 1.0.5; remote version is 1.0.5
Checking package SQL Server Management Studio; local version is 13.0.15700.28;
remote version is 13.0.15800.18
Update available for SQL Server Management Studio to 13.0.15800.18
Checking package Sublime Text 3; local version is; remote version is
Checking package Sysinternals; local version is 2016.07.29; remote version is 2016.08.29
Update available for Sysinternals to 2016.08.29
Checking package Visual Studio 2015 Enterprise Update 3; local version is 2015.03.01;
remote version is 2015.03.02

Update available for Visual Studio 2015 Enterprise Update 3 to 2015.03.02
Finished checking packages; there are 6 packages to update.

Building a .NET App and need low cost cloud logging?

One of the most frustrating things with being an app developer is getting log files from the applications you've built and are deployed (although, don't forget, if you are deploying to end users you MUST get their permission!).

Here's an easy, and cost effective, way to get around this problem.

Simply use NLog in your app, then checkout this NLog to Azure Tables extension.


Introduction to Credential Federation

There are many misconceptions and misunderstandings around how credential federation works. This section should outline the (general) practice of federation, as well as detail the transaction flows in an attempt to clarify the technical piece.

For a web application, in a traditional authentication approach you go to the webpage and are prompted by the given application to login. Your details are then checked against details they hold (hopefully securely!). However, this means that you are likely to have a different set of credentials to remember for every service that you use online. For an enterprise, this can pose a challenge not only for the users, but also the administrators when it comes to removing user access when people move on to new pastures.

Federation adds solutions to this by integrating online services with the on premise active directory (or other) identity platform.

The moving parts

Federation Identity Server: This is the server that you, as the enterprise, will deploy on your network and validate the credentials with. This server will also serve up the login prompt to your users so you can usually brand this as needed. Usually only accessible over HTTPS (for obvious reasons I’m sure).

Relying Party: This is the third party that is going to consume the claims that your Federation Identity Server generates. Upon registering, this party will give you a key to use to sign your claims with allowing it to be 100% sure that you sent the claims. You need to take great care of this key, otherwise you might as well hand over your authentication database to whomever has it (they can pretend to be anyone on this party you see).

Claims: A set of attributes that denote things like name, email address, role, etc. – pretty flexible and normally configured as needed by the relying party and generally are attributes from your authentication system. These are cryptographically signed to verify the originator. You’ll probably hear the term SAML around this particular area.

So how does all this work?

The easiest way to explain it is to describe a user’s journey logging on via a federated approach.

1. User visits the federated identity login page for the given cloud application
Sometimes this is the same login they would normally go to, and the application will “detect” they are federated when they enter their username.
2. Web app redirects them to your federated identity server’s login page
3. User logs in
4. Federated identity server validates the identity, and generates claims.
These are often embedded in a response page after login, as a hidden form which is then submitted back to the relying party application
5. User is redirected back to the relying party application where the claims are processed
6. User receives a relying party authentication token as if they had logged in locally

Common myths

Myth: Credentials are transferred to the relying party.
Truth: In most federation claims are sent to the relying party cryptographically signed by a key that is validated by the relying party. This allows it to be confident that only the federated identity server generated the claims it has received and therefore that it can trust them.

Myth: The federation identity server is safe from attack and is not exposed.
Truth: In order to be useful – i.e. contactable – the federation identity server has to be internet accessible – unless you restrict your users to login with federation from specific locations which pretty much renders it useless.

Windows 10 - Remote Desktop - Login Failed

I've been getting an error that has been bugging me recently on my Windows 10 device - a Surface Pro 4 running the Fast Ring Insider build (at this time its Build 14342_rs1_release.160506-1708).

Trying to Remote Desktop to a Windows Server 2008 just wouldn't work -- not matter what combination of credentials I tried, it just failed with a 'Login Failed' error. Oddly, connections to other machines running Server 2012 DID work. I shrugged it off and ignored it until I got time to look at it today - and the fix amazes me.

Simple enable the Firewall exception for Remote Desktop -- fire up firewall.cpl, click allow a program through the firewall, and select Remote Desktop. Reboot, and that's it.

Must be something getting blocked around the authentication or such. But at least that's working again.

Office 365, MDM

I was experimenting with Office 365's offering of InTune last night - and made an interesting discovery.

Don't just enable it. You'll find you lock out your user's devices from accessing resources until you "fix" the policies. The default policy seems to be that any device access a 365 resource must be enrolled into the Organisation's InTune account. Probably not a bad thing, but might not play nicely with companies if you have other MDM's deployed, such as Cisco Meraki or VMWare's AirWatch. Guess I'll need to do a bit more testing here.

To disable the policy and regain access, visit the InTune page at: https://protection.office.com/#/device

Then go to Security Policies, Device Management.

Edit the Default MDM Policy by Office 365.

I think you now have two choices: Disable the Deployment or add an exclusion. Personally I did both until I work things out - Deployment, set to No, and click on the Manage Organisation Wide Device Access Settings to get to the exclusions option (I added the Default group here - which basically disabled intune!).

Office 365, Azure AD and LiveID accounts

Recently a company that I deal with has moved to Office 365 -- this has entailed moving a number of identifies into Microsoft Azure AD (think Active Directory, existing on Azure and usable for SSO activity) and signing up for Office 365 services.

No problem - or so you'd think.

When trying to signin on a Microsoft site with an enrolled Organisation account (that is, an account on the Azure AD), the OLD LiveID was being used intermittently. A quick chat with Microsoft confirmed this -- Organisation and LiveID's can exist on the SAME email address at the same time - surely a situation where it can lead to confusion!

The good news is you can disable / deactive your LiveID to drop back to just using the Org account (where possible at least), but it does mean you have to be careful during the deactivation period to ensure you sign in at the right place (best to use office365.com addresses!).

However, the world gets a bit murky if you are using MSDN it seems: https://www.visualstudio.com/get-started/setup/link-msdn-subscription-to-organizational-account-vs

Am I the only one that can see this being a total nightmare for companies with a large dev population or other LiveID usage?


Surface Pro 4 - Impressions

For the past few weeks I've been using a Surface Pro 4 -- something I picked up just before I headed to San Francisco for Microsoft Build 2016.

Why did I opt for the Surface Pro 4 over the Surface Book? I already have a very functional laptop (an Macbook Pro actually), and I wanted a tablet that was actually a functional device (and I could handwrite on!). The Surface Pro gave me more bang for buck in this regard.

It's even powerful enough to let me play Prison Architect ;) (And, of course, run a small dev lab in HyperV)