For all those pundits whose reaction to Satya Nadella's first public announcement, of nothing less than Office 365 for the iPad, was to say "they couldn't do it until Ballmer had gone", consider this: Almost a year ago now, I was in Redmond at the invitation of the division Nadella headed before he got his crack at the Big Chair, the Server and Tools Business (STB).
The world's grumpiest and most nitpicky press were collected together for a gruelling three-day run through of all the neat stuff in Server 2012 R2, with a distinctly advanced test and trial system all set up in a vast array of VMs for us to break, whinge about, confuse, crash and re-start pretty much continuously.
Not all of it was strictly ready for prime-time. I especially enjoyed the demonstration where a Powershell add on crashed the programmable switch at the top of the rack cabinet it was living in, so that it was no longer possible to get back to that server and fix the buggy script and not all of it was for public consumption back then in 2013, either. On the last day, we walked back into the torture chamber excuse me, the lesson room - to find that every position was equipped with a Surface RT tablet. The good news was, these were ours to keep, and had been burned with the very latest revisions and patches for RT, including Office.
The reason for this became rapidly clear: It wasn't possible to undertake this bit of the lesson as we had all the others, by using our own laptops (yes, really!) because it was a demonstration of the key technology that will underpin all the roaming mobile device access for Office 365: The stack of services and products that go together to make up Azure Active Directory (hereinafter; Azure AD).
Mobile devices, you see, have a schizophrenic existence. The commonly accepted model is that each phone or tablet gets every bit of software from an App Store. You can't join an App Store unless you give the Store operator all your details, and a credit card number. This is ideal for home and personal users, but things start to get painful and overcomplicated once a business wants to roll out mobile devices to employees. Most take the view that the company email system is the arbiter of identity at the lowest common denominator level, since the majority of mobile users will be reasonably familiar with using an email address & password pair as their connection to Exchange Active Sync (EAS).
But that doesn't help with things like App Store control, so that companies can protect against kids borrowing mummy's flashy new toy and racking up savage game download expenses, and it certainly doesn't cope with scenarios provisionally labelled "BYOD", where less-permanent staff are expected to use their own kit, spattered with their own apps and indeed identity, to access company systems.
What I saw in Redmond last May was the Microsoft fix for this problem; a way of extending your old school Windows Domain out into the Azure Cloud, so that devices had the option of signing in with your Domain credentials, instead of an App Store identity. Or as well as an App Store identity; it wasn't entirely clear how the Surfaces were set up nor indeed what part of the mega-network they were talking to. They were certainly signed in with a Microsoft ID two of them in fact, because there was one to unlock the machine itself and then another, lurking under a VPN connection, which allowed the general consumer device into the corporate network.
Our confusion was instructive remember, this is the world's press, 90% of whom are using English as a second language to ask difficult technical questions. This makes the presenters usefully jumpy and means we can get more out of them, often, than they intend to say. On this occasion two questions came out of the polyglot mix: One was, this is very clever and when can we have it (answer: indefinite non-disclosure, so not only can't you have it, you can't write about it either), and the other was: OK so if we can extend our in-house Windows Domain into the Azure cloud, what's the justification for having an on-site DC at all?
That's a fascinating question in and of itself, because if there was ever a system you'd like backed up to the four-nines level of ultimate reliability, it's your Domain Controller. DCs don't take much CPU power these days, either all round an ideal Cloud concept. Microsoft was coy about this aspect of it, because it fits into the part of the Azure/Windows Server product range that cuts up the licences and features of the various different offerings, and also intrudes painfully on the way that server licence sales are driven as much by misunderstanding the feature set, as they are by the opposite.
That is however, a sideshow for super-nerds who are able to worry about these things mainly because their Windows Domain isn't completely knackered. A shockingly large number of older Domain environments manage to stagger on by dint of their admins simply throwing away the Event Log messages arising from broken-ness of one part of the structure or another. While worrying about the feasibility of cloud-based DCs for small to medium businesses is a long reach to get right down to O365 for iPad, the sad truth about business domain maintenance is very likely to present a painful barrier to adoption.
Getting any of these services to link back to a cloud account requires that they are, before the authentication conversations go live, entirely tidy and not prone to any of the nasty iceberg-like collisions or deeply hidden rule relaxation registry keys (google around for "occupancy requirement" to feel the full horror) which tend to surface as the first sign that you too have a broken Active Directory.
There is of course a fix which is trivial if you are a little bit bigger as an operation Enterprise scale customers have no trouble in rolling out another domain sitting in their forest, with no lurking historical nightmares associated and trust relationships which extend back into the less-healthy parts of their infrastructure along with other trusts that roll forward towards Azure AD and thus pass through the user identities in a bucket-brigade of authenticators. Structurally this is not hard to imagine, nor laden with traps for the unwary: But as the number of user seats in the business shrinks, so does the count of servers, and it's spare server capacity (physical, or virual) which allows this kind of cushioning to operate.
I know what Microsoft will say; if you are rolling out enough iPads or Surfaces or Androids for this to be an issue, you ought to be prepared to both spend the money and put the work in. My response is that it is forgetting just how new technologies are taken up in businesses: Not in the calm, carefully argued way that management hierarchies pretend, but rather in little, experimental unauthorised corners of the technology groups informal teams of workplace friends who continually subvert the preceding status quo.
I think Azure AD is going to end up used for other stuff too, and that the O365/iPad launch is just a hook to hang the end of the non-Disclosure period on. The dominant fore Microsoft is responding to here is Dropbox, which could hardly be any further away from concepts like corporate single sign-on. Nonetheless, the perception of Active Directory as one of the safer authenticators, and Azure as a way to extend that globally, is classic Microsoft far-sightedness, which started an awful long time before Steve Ballmer's departure became a reality.
