Vista Compatibility Team Blog : Vista application compatibility XP port

Creating System DSNs on Vista

VistaCompatTeam — Thu, 08 Feb 2007 01:39:04 GMT

As stated in the MSDN article that all Keys under HKLM\Software are virtualized, there is still the HKLM\Software\ODBC\ODBC.INI key (For creating System DSNs) that will NOT be virtualized.

The rationale behind this was that – Creating a System DSN would essentially be a task of an Administrator and so when you write to this location as a Standard User you will get an exception as the Registry entry is marked for no virtualization

To view these settings, in the Command prompt type in

REG FLAGS HKLM\Software\ODBC\ODBC.INI

And this will output ->

HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI

REG_KEY_DONT_VIRTUALIZE: SET

REG_KEY_DONT_SILENT_FAIL: SET

REG_KEY_RECURSE_FLAG: SET

Vineet

Why you don't want to launch a process with a filtered token from a full token

VistaCompatTeam — Wed, 11 Oct 2006 00:40:00 GMT

Our team works extensively with ISVs on Vista application compatibility – porting XP applications to Windows Vista. We frequently get the question "How can I launch a program with a filtered token from a program with a full token?" Although there sure are ways to do this, there is a slight caveat with this scenario. What happens if a standard user is logged in and the program that requires admin privileges is launched? You will get the credentials dialog so that an administrator (e.g. member of the administrators group) can provide credentials for the program to run. The classic example is a child that wants to install a program but doesn't have the permissions to do so. In this scenario, a parent comes over, provides credentials to install the program and the child can then use it.

But what happens if from the elevated process launched by the parent, the secondary process is started under a filtered token? We have a process running with a filtered admin token of the parent running in the child's session and desktop. This possibly leads to all kinds of confusion (for example, program settings and documents go to the parent's folder, etc.) Clearly not a desired scenario. So what should we do?

One should have a small bootstrapper program running as the logged in user. From the bootstrapper, the elevated process can be launched for example with ShellExecute (the program either has to be manifested with requestedExecutionLevel or runLevel verb has to be specified). When the elevated process is done, the bootstrapper can then launch the second program with the reduced privileges of the logged-in user. In case the logged-in user is member of Administrators, all is well. In case she's just a standard user, all is well too.

Maarten

Command line application with manifest asInvoker

VistaCompatTeam — Fri, 06 Oct 2006 01:22:00 GMT

The recommendation for command line applications is to use requestedExecutionLevel=asInvoker in the manifest. If you would mark your console application as “requireAdministrator” (or “highestAvailable” and you are a member of the administrators group) and launch it from a filtered token prompt, you will see a new console window popping up. All the output will go to that console and when your app is done the window will disappear. Hardly useful if you need to see the output.

The reason for this is that command line applications share the UI with the cmd.exe console that hosts the command line app. Since we can’t change the token mid-flight we have to open a new console if the launched application requires a full administrator and the token of the original prompt is the filtered admin token.

So the guidance is to mark your application with asInvoker in the manifest. If you need to perform tasks in the application that require admin privileges, you can check with IsUserAnAdmin() or GetTokenInformation whether you have those privileges. If you don’t, you can prompt the user to launch the application from an elevated command prompt. Chkdsk.exe is a nice example on how it should be done.

Maarten

CoCreateInstanceAsAdmin or CreateElevatedComObject sample

VistaCompatTeam — Fri, 29 Sep 2006 00:05:00 GMT

The COM elevation moniker is one of the three recommended ways to have a user application do tasks that require admin privileges. The UAC document from September 2006 refers to it as the Admin COM Object model under the section “Key Decisions for Designing Administrator-Only Applications”.

Apparently CoCreateInstanceAsAdmin from the SDK documentation has been rebranded as CreateElevatedComObject in the UAC doc. I have a sample with an ATL component and a console client attached that show this working. (Disclaimer: It is for demo purposes only and the code does not do any error or exception handling.)

The only changes I had to make was in the two rgs files. In order to make the inproc COM component run in the dllhost.exe surrogate, I had to add this to MyElevatedCOM.rgs:

val DllSurrogate = s ''

I also had to add this to the MyElevated.rgs file to make it both Elevation capable and MUI aware respectively:

Elevation

{

val Enabled = d 1

}

val LocalizedString = s '@%MODULE%,-101'

Finally to match up the LocalizedString entry with an entry from the resource, I added a new string in the String table with a matching entry of 101.

The client side is literally copied from the SDK docs.

[updated]

If you try to launch this application from a real standard user (so not a filtered admin), you will get an E_ACCESSDENIED on the actual method call. In order to get around this you will need to give the interactive user access permission to the COM component.

Steps:

Launch COM+ explorer (start, run, dcomcnfg)
Navigate to Component Services\Computers\My Computer\DCOM Config and get to MyElevatedCOM (for this demo app that is)
Select Properties and go to security tab.
Under Access Permissions, select the Customize button radio button and click Edit.
Click Add. Change the "locations" to the local machine.
Enter "Interactive" and OK out of all the dialogs.

If you need to script this you can use DCOMPERM from the platform SDK.

Maarten