Before I start this month's column, I just can't resist crowing a bit. Last year, when Microsoft released its online Office product and called it "Office 365," I snarkily asked at a keynote, "So does that mean it won't run on February 29 next year?" -- referring to this year's leap day. And what happened on February 29? That's right . . . a leap year bug crashed Azure. Microsoft folks, you've just got to pay closer attention to my keynotes!
I felt that I had to mention this particular bit of prescience because last month's column demonstrated what might be most the astounding bit of anti-prescience in history. If you didn't read it, I discussed how Windows Phone on a tablet would be great -- and just as we published the piece, Microsoft announced that the company was doing the complete opposite and would instead shoehorn the Windows kernel into tiny, low-RAM, slower-CPU phone devices. But wait, there's more . . . in the flurry of "Consumer Preview" Windows 8 releases, you could be excused for having missed the "Windows 8 Consumer Preview Product Guide for Business," which included this phrase:
"Although the ARM-based version of Windows does not include the same manageability features that are in 32-bit and 64-bit versions, businesses can use these power-saving devices in unmanaged environments."
Decoded, this means that ARM-based tablets will run Windows 8 (which we knew), but they won't be able to join an Active Directory (AD) domain and, of course, this means no Group Policies (which initially seems like the dumbest thing Microsoft could possibly do). When I read that, my first thought was, "Too bad comedian Lewis Black doesn't do routines about technology," as this notion just cries out for one of his sputtering, spittle-flecked, that-man's-gonna-have-a-stroke rants. "Lemme get this straight," I imagine him saying. "Apple comes out with this fantastic iPad device that everybody loves . . . but it's got this Achilles' heel for business users -- it can't be centrally managed, so it's really scary to let business users bring it into the office. Great device, Apple, but bad idea. Oh, but wait, Microsoft says, 'Sure, that was a bad idea, but we can make that even worse -- we'll offer a tablet that isn't as good as an iPad, but it runs Windows . . . only none of the Windows apps businesses use nowadays, and it can't be centrally managed, either!" It's almost like there's this Apple mole in some highly placed position in Microsoft, craftily bringing down The House of Bill from the inside.
So, as I've already observed, Microsoft changed the conversation last month with what I think will ultimately turn out to be a wrongheaded "switcheroo" by saying, "Not only will we not release Mango tablets, we're going to put our new tablet OS (Windows 8) on our phones." Perhaps this month, however, there's a switcheroo that's similar . . . but a great idea.
Maybe we need to reconsider what domain join means and whether it makes sense or not. Maybe the ARMs will lead the way, and maybe the future of enterprise Windows isn't a binary issue of whether a device is domain joined or not. Perhaps the answer in this case really isn't to raise the bridge, but instead to lower the river. When I say that, let's lay out what domain join means, basically:- Trusted central authentication. Your system wants to be able to know who's using it, and that requires authentication. (iPads don't care about this, of course, but I'd hope that most business managers would be leery about letting devices operated by essentially anonymous users onto their network.) Authentication requires databases of users, passwords, and the like, and AD domains are those databases. To get the benefits of centralized authentication, a tablet would have to agree to trust your network's "central authentication servers" -- we know them better as domain controllers -- to authenticate a user. Once that tablet user is established, that user can then easily authenticate to resources inside the organization.
- Acceptance of centralized management via group memberships. In return for being granted access to secure resources in the organizational network, your system agrees to allow domain groups like Domain Admins to assume positions of control (e.g., your system's local Administrators group now contains the Domain Admins group).
- Acceptance of centralized management via Group Policies. Your system contains a bit of client software that knows to retrieve a set of "thou shalt" and "thou shalt not" commands -- we know them as Group Policies -- from a centralized file share containing those Group Policies, and to execute them.
Now, back when the notion of a domain join first appeared in the early 1990s with Windows NT 3.1 (and LAN Manager before it, kind of), the world was different. Nothing like Group Policies existed, few standards for secure authentication existed save for some then-blue-sky ideas about things like certificates (which work now, even if they're still not easy) or biometrics like thumbprints (which turned out to be a fairly bad idea, because for most of us our thumbs are far more important than any data we have). But times have changed, and perhaps our current notion of domain join should change, as well, or perhaps I should say that it already has.
Ever since Exchange 2003 Server SP1, we've been able to sort of join mobile phones to a domain, enabling us to brick a stolen phone with little effort. Windows Server 2008 R2 introduced an alternative to VPNs and traditional logins with DirectAccess, which is a system that's a huge pain to set up, but once in place makes access to corporate resources from mobile devices a much more pleasant experience than with prior VPN, and, furthermore, even offers a level of security such that it's not a terrible idea for non-mobile computers.Perhaps the answer, then, is a variation on one of the many certificate-based access tools to provide authentication to AD, and then, once authenticated, AD would look up a device's group memberships or some sort of "security classification" that would indicate whether or not it would be compelled to accept Group Policies. Taken further, such "need to use Group Policy" might even fall into different classifications ranging from "policies all systems must obey" -- web proxy addresses or the like -- all the way to "policies only those systems accessing high-security resources must obey."
If that doesn't sound useful, then consider this: Windows certificate stores can, of course, hold as many certs as you like. Which means . . . you guessed it . . . a very simple way for a system to be a member of more than one domain -- even domains from different organizations. And which might be a switcheroo worth looking at!
