In the whitepaper Launch your application from session 0 to session 1 using a service helper application” an application was launched by the service which had the privileges of the local system account. The advantage of such an approach was the ability to use an UI to perform high privilege tasks across any user account. It also facilitated writing to the HKLM section of the registry which could be read across all user accounts. This can also be done by designing an application which can communicate with a service through RPC to achieve the desired result.

In the whitepaper Launch your application from session 0 to session 1 using a service helper application” an application was launched by the service which had the privileges of the local system account. The advantage of such an approach was the ability to use an UI to perform high privilege tasks across any user account. It also facilitated writing to the HKLM section of the registry which could be read across all user accounts. This can also be done by designing an application which can communicate with a service through RPC to achieve the desired result.


This article focuses on the Administrator account of Vista for administrative applications. It shows how to launch an application into session 1 under the Administrator role with full privileges effectively bypassing the UAC prompt. Windows tasks scheduler is used for this purpose. The approach may be useful for some automated tasks which need to run under the administrator account.


The article will be expanded further to show how RPC can be implemented effectively to run administrative applications.

The concept used is very straightforward. A normal user mode application is developed which communicates with a service through custom messages. On receiving the custom message, the service will register a task in the task scheduler. Depending on the attributes assigned, the task is run on demand with the highest privileges of that account. At the end the task is deleted from the task scheduler.

First let us review the file CustomMessageSender.cpp. This is the user-mode application which communicates with the service. This application can be any normal application without any special privileges.

The code above is very simple and straightforward. SERVICE_USER_DEFINED_CONTROL and SC_MANAGER_CONNECT access permission is used because any user mode applications can connect to the service to send custom messages to it. No admin privileges are required. So this application sends the SERVICE_CONTROL_CUSTOM_MESSAGE to the service. Once the message is sent to the service it will register a task under the current user account which can be run at normal or highest privileges under that account.

Most of the code for registering the task in the task scheduler is taking from the Windows Whitepaper on UAC. I have added a section on the IPrincipal interface to set the highest privileges attribute.

The code snippet shows that first COM and its security attributes are initialized. Then we create an instance of the Task Service.

These are the general steps to be followed. Once this is done we need to get a interface pointer to the IPrincipal interface and define the runLevel which is TASK_RUNLEVEL_HIGHEST. The Code snippet below shows the same:

Once this done we save the task in the root folder to run under the current user account.

I will be further extending this article to demonstrate an example of the service broker model where the a normal user application communicates with a service through RPC, which is one of the methods recommended by Microsoft to run administrative applications.