Windows UAC Security With Exe - windows

Question

I have an exe created with an old Borland C++ compiler. It needs administrator privileges to function correctly. Since the app will run at startup, I do not want the user prompted if it's OK to run the program (testing on Win7). My question is is there ANY way to remove that annoying prompt every time the app is run?
I added a manifest file with admin privs and signed it, but it then still appears with the publisher name.
This will be distributed, so I don't want users to have to turn off UAC or do anything too complicated. Any suggestions are much appreciated.
I am hoping there's something for UAC like "Always Trust This Program" or something.

Answer 1

The answer would be using a scheduled task to run at logon. Scheduled tasks are launched by the task scheduler service which runs with SYSTEM privileges, and therefore it's possible to have them run with elevated privileges without prompting the user on startup. You still have to get the user's confirmation once - when you set up the scheduled task - but not every time the program runs.
Since I don't know how you are installing your program (which installer you are using, if any), I'll describe to you a way which you can probably implement in any environment: Using schtasks.exe and an XML file. (Note that this won't work with Windows XP and older, but there you don't have to worry about UAC anyway.)
You need to create an XML file like this:
<?xml version="1.0" ?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2013-11-01T00:00:00.0000000</Date>
<Author>USERDOMAIN\USERNAME</Author>
</RegistrationInfo>
<Triggers>
<LogonTrigger>
<Enabled>true</Enabled>
<UserId>USERDOMAIN\USERNAME</UserId>
</LogonTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<RunLevel>HighestAvailable</RunLevel>
<UserId>USERDOMAIN\USERNAME</UserId>
<LogonType>InteractiveToken</LogonType>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
<AllowHardTerminate>false</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>false</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>c:\path\to\your\app.exe</Command>
<Arguments>/your /parameters</Arguments>
</Exec>
</Actions>
</Task>
Replace all USERDOMAIN\USERNAME here with the actual user's domain and name. You can, for example, read those out of the corresponding environment variables USERDOMAIN and USERNAME.
Replace c:\path\to\your\app.exe with your application's path and /your /parameters with the arguments you want to pass to your app, if any.
The secret magic here lies in <RunLevel>HighestAvailable</RunLevel> which will make the task scheduler run your app elevated.
The Date doesn't really matter, but for completeness you could set it to the current date and time.
After creating the XML file and saving it somewhere (e.g. temporary folder), you have to run this command which will create the actual task: schtasks.exe /Create /TN "My App" /F /XML "c:\path\to\xmlfile.xml" (replace My App with the name which should appear in the task scheduler when viewed).
You can delete the task again using schtasks.exe /Delete /TN "My App".
(For a pure C++ solution, you could also take this example and add the missing things which would be specifying the username and setting the flag for using the highest available privileges.)

Answer 2

I am writing this because although CherryDT's answer is a good approach, longer-run depending on context it may be a little inflexible.
Another option (depending on the context) may be to refactor into two components:
A system service which runs at startup and does everything that needs admin access
A client program that communicates with the service and does not need admin access.
This avoids the annoying prompt but it is more work. Based on your description it is not clear this is the right way to go here, but it may be down the road (and for others finding this ticket) so I figure it is worth mentioning separately.