Thanks for your response Jonathan! Some great detail there.
A quick follow-up on some of the questions:
2) Good details regarding communication with Outlook. But I think creating a script which launches via Scheduled tasks which then picks up message contents via an intermediate INI file or through some kind of listening code is beyond the reach of most administrators. Unless Microsoft provides some guidance/sample code to support this approach, I think most admins will simply end up elevating Outlook. However, if COM is as strict as you say it is, elevation of Outlook may not be the end of the world. I think another valid approach would be to find a third-party e-mail package that isn’t quite so strict. I assume that if I am elevating a tool it would still be able to communicate with any application operating at the user level – such as a third-party e-mail product.
3) Yes, I’ve seen the Consent vs. Credentials security settings before, but that is not a very friendly solution. The problem is that the consent approach is great for 98% of a user’s experience – particularly when they have legacy apps that need local admin rights in order to run. It’s just that remaining 2% where there is no way to elevate to another admin account at all. It wouldn’t be very nice if we make someone suffer 98% of the time by forcing credentials just to make the remaining 2% possible. There are two things that I would like to see change – either of which would greatly improve my situation. One would be to offer a button on the consent prompt such as “enter credentials” so that the user can choose to enter credentials for another account for only the 2% of the time when it is required. I also really miss the “Run As…” option on the context menu. As discussed, the “Run as administrator…” prompt has its limitations.
Currently, most of our administrators have resorted to using the RUN AS command from a CMD window in order to get their work done. It’s funny to have this beautiful OS, but to spend all our time in a black DOS screen. This problem would go away if we could get a RUN AS on the context menu (I just might try to write one).
While I’ve got your ear, I’d love it if you would explain to everyone the behavior of the Windows Explorer (file manager). It clearly doesn’t follow the usual application elevation rules. We now use the “Launch folder windows in a separate process” option to allow us to elevate Explorer, but even with that option it will not allow us to elevate to another admin account. If we travel to a user’s desk, it is not possible to elevate Explorer with an admin account and perform functions reserved for administrators. In fact, Explorer is downright misleading on the whole subject. If we try to manage files in the System32 folder with a user account, Explorer will prompt for all sorts of credentials and things as if it will elevate us, but in the end we don’t get what we need. Either nothing happens or we get messages unrelated to what is really happening. This has been very frustrating and has cost many people time as they scratch their heads trying to figure out what is happening. What is happening? Could you tell us?
At the moment, the only way we have been able to do our jobs has been to perform things like system32 file management from the DOS prompt. Lately we have actually been finding third-party file management programs on administrator PCs. It was surprising, but actually makes sense. Third-party file managers look like normal applications to Vista and therefore elevates normally. It then becomes possible for administrators to do a lot of their work without resorting to a DOS CMD window.
Thanks for your time Jonathan, it is much appreciated,