The REAL reason Microsoft Windows RT devices won't be able to join AD domains.

By now you've probably heard that the final name of the version of Windows 8 that will run on ARM-based systems will be called "Windows RT." (I have no idea what the "RT" stands for or why there's no "8" in the name like the x86 versions.)

By now you've probably heard that the final name of the version of Windows 8 that will run on ARM-based systems will be called "Windows RT." (I have no idea what the "RT" stands for or why there's no "8" in the name like the x86 versions.) Also you've probably heard that Windows RT will not support the ability for the devices to be added to Windows domains.

Windows RT's lack of domain support has launched a firestorm of complaints and speculation, including a conversation on Slashdot suggesting that Microsoft simply ran out of time. Others have suggested that this is the final nail in the coffin that confirms that Windows RT-based tablets will be aimed at the consumer, while x86-based tablets (with their domain-joining capabilities) will be aimed at businesses.

But neither of these is true.

There are several perfectly logical reasons why Windows RT doesn't have (or doesn't need to have) the capability to join an AD domain.

Reason No. 1: "No domain join" does not mean "no way to manage"

First, the whole concept of a domain join is pretty antiquated. Sure, Windows 8 machines will be able to join AD domains hosted by Windows Server 2012 servers—I'm not saying that domain joins won't exist. I'm saying that the concept of a domain join isn't needed in today's world.

Domain joining is a 20 year-old concept when "managing the computer" was the same thing as "managing the user experience." Back in those days you had one computer per user per copy of software. The entire user environment was that single computer. But we live in a different world now. Every day we hear more about how we want to "manage the user, not the device." So if we're not managing the device, who cares if it's in a domain or not?

Nowadays we have virtual applications that we can stream and provide on demand. We have virtual user environments that we can stream on demand. And we have SSL-VPNs and other security scanners that ensure that our users' devices meet some kind of minimal level of functionality.

We also have years of providing a rich user experience to users connecting from their own computers at home—computers that we don't manage at all. So I'd flip this question around—if we can get away without managing the users' devices, why would we want to?

Think about what domain joining does anyway? It lets you push out software, updates, configurations, and patches to devices. Bleh! Who wants to manage devices?

There's a parallel conversation going on in the mobile world right now. People used to be all hopped up on this "Mobile Device Management (MDM)" concept which allowed corporations to takeover and control mobile devices. But now we realize that's pretty old school. Corporations don't want to actually manage the entire devices—they just want to manage the corporate apps and make sure that their data is safe. (Now MDM is evolving into "MAM"—Mobile Application Management.

The same is true with computers. Managing and owning an entire computer? No thanks! I'll just make sure the user can use it to have the apps and data he or she needs. So when it comes to Windows RT, why even bother building in domain join support?

Reason No. 2: Windows RT users don't have the same freewheeling abilities as Windows x86 users

Another thing to keep in mind about Windows RT is that the only way users will be able to install apps on it will be if they download them from the official Windows Store. (Remember the "desktop mode" in Windows RT will not be available for general applications and user-installed apps. Users can only install Windows Metro-style apps from the Windows Store.)

So that right there means that most of the crapware that IT admins need to clean off isn't even going to be an issue on Windows RT. Now combine that with the fact that Blackberries, iOS devices, and Android devices are all manageable via the various MAM products and you realize that Windows RT can be managed in the same way too! So you'll get the benefits of domain management without the hassle of joining a domain. Super!

Reason No. 3: Active Directory isn't about systems management anymore

The final reason Microsoft isn't including AD support in Windows RT is because AD isn't about systems management anymore. The long term direction of AD is for it to be about identity management, single-sign on, federation, and authorization—not about managing systems. (If you want proof of that, look at the capabilities Microsoft implemented with their Azure-based "AD in the cloud." (This is something we talked about on our radio show last week. Here's a video of that segment if you're interested.)

I'm not saying that AD is dead and going away, rather, I'm saying that tomorrow's AD will not the same AD you studied when you got your MCSE ten years ago. The old school on-premise AD was as much about computer accounts, Group Policy, and systems management as it was about user authentication and authorization. And things like federated identity were a joke.

Moving forward, AD will evolve into a cloud-based (on premise or off) user directory, single-sign on, federated identity management platform. And it will have nothing to do with pushing out configurations to freaking Windows PCs. (And, thankfully, it will have nothing to do with pushing out configuration policies to Windows RT devices.)

The bottom line

It was smart for Microsoft not to allow Windows RT devices to join the domain. Domain joins are such antiquated ways of thinking. Good riddance!

(This also means, by the way, that it's possible that corporations will still buy Windows RT-based tablets for their employees, especially given the fact that Windows RT tablets will have an "extended VDA" license built-in.)

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Windows RT (or WOA) is not going to be around for long.

By exploring this new platform (ARM), the Windows teams @MS get a chance to experiment with certain things. They can do stuff they wouldn't be able to do on 'normal' windows (read x86_64 platform), like .. 'remove AD client', 'remove Desktop app', 'lock down Metro .appx rules', 'deploy new cloud-based MDM client'

There's no guarantee that ARM licensees will be able to sustain their market dominance in the handset/table market in the next 4 years or so.

Ivy Bridge will start to put Intel back into the game this year.

In 2014, Haswell will attempt to strike a big blow to ARM licensees.

So ... in line with your opening statement ..... conservative enterprises will stick to Windows 8 and the traditional 'open and unlocked' IT experience. Consumers can decide whether the offering of apps in the Windows Store is sufficient for them or if they need non-Windows Store apps.

In the end, it's a pretty clever move by the Windows team do split WOA from the rest of Windows.

On the one hand it gives them the ability to build competitive features into WOA that will make WOA triumph over iOS and Android in the tablet space, without having to care about that everlasting Windows burden called 'backward compatibility'.

On the other hand, as I've alluded to, if it turns out that ARM's dominance in the handheld/tablet space might decline .... Microsoft will be ready to roll all these new awesome WOA features back into 'normal' Windows and keeping riding the tablet wave with Haswell. :)

Just my .02$


Mary Joe Foley mentioned on the Windows weekly podcast that

RT = Real Time.


Oh and yeah ... by focusing on that whole 'domain-joining' discussion, people are obviously not looking at the bigger picture.

I personally couldn't care less about joining end-points to AD.

Neither do my customers with those 20,000 linux-based IGEL thin clients. Guess what, those end-points have never ever been joined to AD in 10 years!

Those new iPad thingies that everybody started bringing in a couple of years ago ... never seen any of them as computer objects in AD....

Neither are the Android tablets, nor those fancy Mac laptops ....

Get the drift ...???

Anybody who's talking about joining end-points to AD is talking about 'IT control' .... and this is one of the old paradigms is going away ... and if you can't let go of it you will soon be overtaken by your competitors.

On this topic, I highly recommend watching the MMS 2012 session called 'Why We Fail: An Architect’s Journey to the Private Cloud' ... you can find it in the 'Fabric Infrastructure Management' track.

(Login required)


Third and final comment ... :)

THE real reason why you can't join WOA to AD ..... security!!

Corporate managed Windows end-point == trusted end-point because 100% IT control (well, 100% in theory ...)

AD joining this end-point implicitly trusts this end-point. Because the AD joined computer object enables a 100% trust relationship of this end-point with EVERY WINDOWS SERVER in your AD domain/forest.

Employee-owned devices == untrusted end-point because 0% IT control  ( real percentage depending on your MDM/MAM strategy which in general is still not widely deployed at all!)

So, implicitly trusting an untrusted end-point by joining it as an AD computer object and allowing ALL YOUR WINDOWS SERVERS to trust this untrusted end-point == BAD security.

Removing end-points from the AD trust relationship significantly increases your security architecture!


Erm, please feel to correct me, but didn't Brad Anderson at the MMS day 2 keynote tout domain joined for BYOD as a strategy for SCCM extending it's reach to multi platform MDM and native application delivery?


@AppDetective Oh man.. I hope not! Can you give more details there? Domain join seems so severe.. I can't see why you'd need that just for native app delivery?


It is ridiculous to assume "RT" stands for "Real time", as it clearly won't be able to live up to that definition. "WinRT" stands for "Windows Runtime".

Think of the runtime versions of MS Access where it gives you a trimmed down version of the full product which is enough to run existing Access packages, but not necessarily be able to create your own full-featured databases within it.


Yeah I would also be surprised it RT stood for "RealTime." In the OS world, a "real time" OS is a very specific thing, and WinRT isn't that! :)



Anderson explained that "even not-domain-joined devices can be trusted." Microsoft's management solutions can use Active Directory to confirm the device.

The device becomes "domain trusted," he explained, adding that "through Azure and Azure Active Directory, you can authenticate via Windows Intune." Azure Active Directory will link up with Active Directory in a Windows environment.


@Rahvintzu Thanks for that. I interpret that as code for MDM/MAM capabilities managed on diverse endpoints with inTune or SCCM via AD and AD as the bridge from on premise to Azure. I think it's the wrong model, as it assumes that everything will use AD. What happens if an app doesn't use AD that I want to use, or I acquire a company that doesn't want to or have ADFS etc. Typical vertical MS only view of the world.


@rahvintzu: very interesting. would be good to have some more details on that. Especially as the quotes aren't very specific whether Anderson was talking about Directory Services or Federation Services. Big, big differences in the trust models between those two.


@Appdetective, for those other apps an MS centric cloud approach would be to use Access Control Services (a feature of Azure AD),

@ Christoph, Apologies that extract was taken from a blog, I live in Australia and cant easily make MMS. That said i believe it would be: Federation Services - Azure AD (via  Access Control Services) - Intune.



Thanks heaps for the links!

After I posted my comment I already found some information myself that kinda got me the idea that your excerpts from Anderson's quotes were referring to the new Intune beta.

I'm going to dig into this stuff a little bit if time allows.


I recommend flipping through the slides of session CD-B350

Very good deep-dive into the new Intune features.

A few quotes:

"Windows Intune leverages Windows Azure Active Directory infrastructure for user management"

"Single sign-on can be set up with ADFS 2.0"

"User Device Affinity (UDA) can be established through Windows Intune"


@rahvintzu Thank you again. Seems from this that this implies that the 'cloud app' has to reside on Azure but federating ID from other sources is possible.

Assuming I understanding this correctly, I am left polishing my helmet wondering what about non Azure apps. I have no way to use other solutions to enable access to multiple app types. Yet more vertical stack lock in from Microsoft. Ughh, I hope my understanding is incorrect.


@Appdetective, Developed application doesn't need to be hosted on Azure.

Quote (Pre Req):

ACS is compatible with any modern web platform, including .NET, PHP, Python, Java, and Ruby. ACS can be accessed from applications that run on almost any operating system or platform that can perform HTTPS operations.



Here is a database compatible with Windows Runtime: