by Michael S. Kaplan, published on 2010/03/20 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/03/20/9978451.aspx
No, this is not a log about my misuse of the language of Shakespeare and Chaucer. Or about my use of the words of curse, which has been on the decline recently anyway, thank you!
One of the downsides of working principally on Microsoft technologies is that you find yourself speaking a dialect that not everyone else will readily understand.
This is even worse if you work for Microsoft, since the insulation from all that is not Microsoft will just naturally be thicker.
And if you work for a specific product whose primary focus is on a single version, like Windows, then the shielding can be legion. If you know what I mean.
I'll give you an example.
In Vista a feature was added, a feature that most people feel was made much more useful/usable in Windows 7.
The controversial feature known as UAC (User Account Control?) or LUA (Limited User Access?). Basically a way to keep you from doing things that you can only do as an administrator unless you really intended to do so.
As a choice bit of irony, I found this to be much worse in Vista than Mac OS X but much worse there than in Windows 7. But that is a blog for another day. Or maybe never....
Anyway, I was going to talk about UAC/LUA for a minute.
There are many overt acts that have come up in the past like running the setup for App Locale or installing MSKLC 1.3 or adding a Table Text Service TIP to Windows.
And when you do so, it is either easier or in some cases only possible if you are running from a command prompt that has received this approval from the user -- this approval to be like an administrator type person.
Now what this is generally referred to by the aforementioned subset of people I mentioned as an elevated command prompt.
I have used this phrase many times, as you can see in a simple search here.
Now in almost every case my intent was that people use the simple UI you get by right-clicking a command Prompt shortcut:
You know, the one that says Run as administrator, which will cause there to be an elevated command prompt.
If you click on it, you will be prompted to make sure you really wanted to do that. If you say YES then the command prompt will indicate its "Admin-ness":
Anything you run from within that command prompt will now be run as if you are an administrator. So you can do these varous tasks I was talking about....
I had been calling it an "elevated command prompt" since Vista was called Longhorn so it never occurred to me that people might no know what this meant.
But if you look in the comments to some if those blogs, people often just skipped that bit and proceeded on, not realizing that this step was crucial for the support to work.
It was made a bit harder in the case of Table Text Service Tip installation since it would appear to work but the registry keys were put in a virtual store that was not used for the component. :-(
I don't know what the whole virtual store thing is really supposed to work for, but for these kinds of machine-wide, cross-process, permanent settings, it falls down rather quickly....
In fact, I think it is why good people like Andrew West are having trouble in Windows 7 (see the comments of Can't I pick the candidate list font if I don't speak fluent square box? for context) in some cases...
Anyway, from now on I will recommend to people when I need them to use an elevated command prompt to point to this topic, or even better to give more detailed instructions that don't assume people will know my bizarre dialect of English....
Andrew West on 21 Mar 2010 10:01 AM:
D'oh, my bad -- sure enough when I run an elevated command prompt my input method installs just fine, and to my delight it uses my PUA Tangut font as specified in the source file, so I can actually see what I am typing now. Thanks so much for sorting it all out for me!
Michael S. Kaplan on 21 Mar 2010 11:42 AM:
Dude, this wasn't you -- many people had the same problem. And when I am trying to communicate ideas (which is generally what I do here!) then something not communicated properly is on me. :-)
But I am glad it worked out, and that I learned something too....
Mike Dimmick on 22 Mar 2010 7:30 AM:
The virtual store is meant to work for applications like Sage Accounts which are still writing to files and registry keys in protected areas, and can't be configured not to.
The underlying problem is that the way everyone used Windows Installer was different from how it was intended to be used. Specifically in the area of Custom Actions.
The Master Plan for Windows Installer was that packages would be registered somehow with a directory, 'advertised' to non-admin users by giving dummy icons on their Start Menus or desktops, and that users that needed to use those packages could simply click the advertised icon. The dummy icon leads to Windows Installer which installs the required feature from the advertised package.
Therefore Custom Actions are marked as Impersonated (runs using the user's credentials) or not (running with LocalSystem credentials). In the Master Plan, Impersonated actions don't have admin rights but can tweak the user's profile, while non-impersonated actions can't access the user's profile but can change the system.
In practice, most packages were designed and tested with the assumption that the user runs the package interactively, and has administrative rights. Therefore the impersonated actions *do* have admin rights, on Windows XP/2003 and before.
On Windows Vista and 7, with UAC, the impersonated custom actions get the rights of the token as the installer package was run. That is, if run from a non-elevated program (e.g. Explorer) they don't get admin rights, whereas from an elevated command prompt they *do* get admin rights. If you're having a problem, you need to mark the Custom Action as being non-Impersonated - binary OR the Type value in the CustomAction table with 2048 (msidbCustomActionTypeNoImpersonate).
Many Windows Installer authoring tools use custom actions where they shouldn't (duplicating some built-in feature of Windows Installer) and/or mark them as Impersonated by default. .NET's installer classes are usually configured incorrectly by Visual Studio (at least through 2005). Try to avoid Installer classes - the Windows Installer team's official position is that managed code custom actions are not supported. (WiX now includes Deployment Tools Foundation, a framework for writing custom actions in managed code, that runs the custom action code out-of-process rather than in-process as the Visual Studio installer code does.)
referenced by