Death of a killer app

The headlines may soon read "Microsoft gives death sentence to killer app.".

That's right: an application used by millions has been given the boot. This application is used today on Windows 98, Windows 2000, Windows XP and Windows Server 2003. It's very ability to provide services across these platforms has been part of its longstanding appeal. In recent years, Microsoft has de-emphasized it - covering up its UI is different ways. Now Windows Vista has killed it.

What is this mystery application? How did its death come about? And - more importantly - what does it mean to you? It's NetMeeting. Used by millions for that peer-to-peer meeting in an ad-hoc fashion. Used by millions of others in its more recent branding as the app hidden behind the smoke and mirrors in things like Windows Messenger, Office Communicator, and others. That's right: Do you ever hit that "share application" button in one of those tools? If so, you use NetMeeting even if you didn't know it. As for how it died, that's best left to the consipiracy theorists. However, here's a couple of reasons I've heard from various places:

• The code was too old and broken to be easily brought forward into Windows Vista
• It competes with a forthcoming fee-based Microsoft product and had to be dropped
• It couldn't be retrofitted for IPv6 and the new driver model on Vista

If any of those are accurate, it's most likely a fortuitous accident. However, that's what people are saying.

More important than the why question is the "what now?" question. How are people to do any real time collaboration between say a Windows XP machine and a Vista machine? It's impossible; at least using in-box tools. If you want true peer-to-peer like NetMeeting gave you, you need to find a third-party product. Be sure to add the project costs for evaluating, selecting, purchasing, and deploying such a product into the mix for cost-justifying any planned upgrades to Windows Vista. As most people understand, putting in a new OS doesn't happen overnight (unless you have a company of 10 people in which case it just might). So the reality is that people who collaborate freely today will not be able to once one of them is "upgraded" to Vista. In fact, this feature deprecation has the potential to delay (perhaps indefinitely) the adoption of Windows Vista in many corporations.

In this case the jaded, "Where do you want to go today?" seems to be a rhetorical question. Instead, Microsoft's taking you where they want you to go - into a brave new world where you have to spend money to collaborate.

LUA, UAP, and the restricted token

Is your token chokin'?
With Windows Vista, you now have UAP or "User Access Protection", sometimes known as PA or "Protected Admin". What does this mean in a practical sense? Well, for instance let's say you take a domain account (or a new local account) and place it in the Administrators group. With all prior versions of Windows based on Windows NT, that would be it - that user would be an Administrator when they logged on and could install all the spyware and trojan horses they wanted. When they clicked on "<SomeFamousPersons>Boobs.jpg.exe", it could do anything it wanted to the system. The least likely thing it would do is display what it sounds like it would in the title, right? Now, your account won't really BE an admin - at least not all the time.

A different style of logon
The login process now creates two tokens. The normal one that in our sample case would have granted admin rights (this one is held onto by the kernel and used when you need to elevate), and a new token - based on the standard one - that is used for UAP. This new token has the Administrators group set as a restricted group or "deny only". So if you run "whoami /groups", you'll see "BUILTIN\Administrators S-1-5-32-544 Group used for deny only" (I chopped a bit of extra text out of that to simplify it, but it's clear that the token has been restricted. If you were to then run a command prompt elevated (by right-clicking the shortcut for the command prompt and choosing "elevate"), you'd get a different token. Run the "whoami /groups" again and you'll see that you now have "BUILTIN\Administrators S-1-5-32-544 Mandatory Group, Enabled by default, Enabled Group". As you can see - a different token.

All of the whining on the newsgroups and other places on the net that reduce to "my account is supposed to be an admin, but it can't do anything" are about either bugs or design elements with UAP and the restricted token. Take for example control panel applets. By the time we see final versions of Vista, the built in control panel applets will either prompt for elevation immediately when they are opened (if they have to; generally if all of their functions are administrative), or they will be re-factored to seperate any admin-required functions from their "per user" functions and will show a lock symbol and button to "enable" the admin functions. You'll need to click the lock and either hit ConsentUI (for users who are in the Administrators group but have the restricted token; this is just a "is it OK to do admin things" dialog), or hit CredUI (this is for folks who are not admins; they can then enter alternate credentials if they have them in order to elevate).

I know today there are a huge number of scenarios where this just isn't implemented yet, or doesn't work. Many are due to "we haven't gotten to that yet", while others are just plain bugs. One of the first things I happened to encounter was when I logged on as a standard user, then needed to do some administrative work. I used my trusty method of starting a command prompt as the standard user, executing "runas /u:\ cmd.exe". When I got my new command prompt, it should have admin rights since that domain account is my admin one and is in the administrators group. When I tried to run something that was on the standard user's desktop (by CD \users\...) I got access denied! But I was an Admin! Not anymore, Vista says. My runas had activated my restricted token. Not the most usable thing; the only reason I had done the runas was to get credentials that had admin rights. This, and other scenarios are ones that we need to see fixed before Vista RTM's. Today, with UAP on the only account that never gets a restricted token is the builtin adminstrator account. That one, in our environment - following best practices, is scrambled. Both the name of the account and the password are 25 random characters and nobody knows them. No escrowing them, nothing. Domain accounts are used for all admin tasks.

Come on Microsoft; step up to the plate and get these scenarios working.

Those of you who managed to get through my previous posts know that I was working on the ability of my service to be able to use WTSQueryUserToken to get the user's token so that it can execute code on behalf of the user. This works (finally). Anybody care to guess which token is retrieved in this way? The restricted one? The regular one? Well, I've tried it - and it is the restricted one. So if the user is an administrator, they won't really be until they've hit ConsentUI and agreed that your code can perform administrative tasks.