I'm working on a little time saving project for an installation of a software program and i'm having some real difficulties finding anything helpful.
What i'm trying to do is programmatically create and implement the common UAC workaround for executable's.
Where i'm at right is:
The executable automatically forces the user to run it as an administrator. Giving "complete" access (ie no "access denied" errors).
I programmatically create a "Scheduled Task" for an executable with no triggers that is set to run an executable with highest privelages.
The next step is to create a shortcut icon for this scheduled task (and ultimately populate it into the startup folder). This is where i'm having trouble.
I cannot, for the life of me, figure out how to create an icon that executes a scheduled task.
What i'm trying to do is here:
http://www.techsupportalert.com/content/how-create-program-shortcut-run-without-uac-prompt-windows-7.htm
It's the 7 steps following the first 12 steps.
The things i've thought of and could not figure out / find any information on are:
Programmatically running cmd command that will do this.
Locating executable for scheduled task and setting that as a shortcuts path (apparently there are no executable's for scheduled tasks).
I appreciate any help or thoughts on this.
I've tried and can't really find anything on this for help.
schtasks /run /tn TaskName
But you need to be an administrator.
There is no way around this. Security that can be avoided is not security.
Related
I am currently coding a WPF project. The project is a sort of Task Manager program. Inside of the project, there are methods that take real-time PC data (temp, frequency, etc). However, some of the methods in the project require administrator privileges, so that the program can have access to the different values/data from the PC.
The problem at hand is that the program asks for these permissions every time the program is run. While I know this is just a personal preference, I would like to make the program only ask for the said privileges at installation/first run, so that the user does not have to authorize their permission every time.
Just to be clear, this is not a question about how to get the administrator privileges in general. I know that there is the option to manipulate the app.manifest file. This question is only pertaining to keeping the set administrator privileges programmatically, or through other means such as visual studios.
(Also, the program uses NSIS as an installer, if this is at all helpful)
Thanks
EDIT:
Looking back at this question, it was a pretty stupid one. It was just due to my sloppy/lazy coding.
That is not possible because the purpose of UAC Prompt is to create awareness for the user so they know that they are allowing admin privileges to the software.
I Do not really advise you to skip the step of the prompts.
You can not do it directly but you can indirectly , if you can write a code to do the following steps here , you can achieve what you asked for.
Windows is a secure operating system. If the user is not an administrator: then you don't get to control that.
What would your application have done under Windows XP?
Would it have crashed?
Would you have refused to run?
Would you have told the user that they need to be an administator?
Is there no lesser mode you can use that can still give the user useful information? After all, Process Explorer is still able to run and give me all kinds of useful information about processes on the computer.
But if the user is a standard user, you have no way to change that at install time.
In my program, I create a registry key under current user. This program is run by the Task Scheduler with the highest permissions (S-1-5-32-545).
In my uninstall custom action, I have code to delete this key.
The code to delete the key works when I run as administrator.
The code does not work when run from the uninstall custom action.
I'm guessing that the reason it doesn't work in the latter case is because current user is different when the uninstaller executes than when local admin executes the code.
How can I delete this registry key when run from the uninstall custom action? How do I point the uninstall custom action to the correct current user?
I am largely unfamiliar with the use of task scheduler in Windows 10. I used it a lot back in the day in Windows 2000, and then it was very primitive - severely lacking in features I needed.
I'll just try to add some observations for you, bear with me if it isn't quite an answer. Please update your question with more details if this is the case - so we can understand exactly what you need.
Adding / Deleting Scheduled Tasks
I am wondering how you are creating the scheduled task? Are you hacking the registry directly? You should probably use schtasks.exe to create and delete it by command line with your WiX package. Here is one question / answer where they are dealing with the same issue: WIX Create Scheduled Task.
You already know this, but this is for others too:
Create your scheduled task manually using the scheduled task console.
Hold down Windows Key, tap R
Type in: taskschd.msc and press Enter
Now create your task manually in the scheduled task GUI and test it.
Create / Delete the scheduled task with schtasks.exe via a Quiet Execution Custom Action in your WiX package.
You can export an XML with the task settings and use it with schtasks.exe. I haven't tested this, but there is a sample here: Use an XML task file with Schtasks.exe in your WiX package.
You can also push command lines with MSI properties as shown here: WIX Create Scheduled Task.
Storage of Scheduled Tasks
It seems the scheduled tasks are not stored in the user section of the registry (HKCU), but on disk and in the per-machine section of the registry (HKLM): Where does Windows store the settings for Scheduled Tasks console? This should mean that they are deletable for all users on the machine by simply deleting them on uninstall. How does your HKCU registry key enter the picture? Here is the MSDN page on Schtasks.exe.
Alternatives to Scheduled Tasks
Just for the record, there are some alternatives to running your application as a scheduled task which may be better or easier than a scheduled task:
You can run your application as a Windows service.
This is a developer heavy "solution" requiring code changes, but is probably the most reliable - especially for business critical stuff.
See this summary: When should I use a scheduled task instead of a Windows Service?
Windows Services are more reliable for 24/7 tasks.
Scheduled tasks for stuff that happens "every now and then" (even once at logon).
"In summary, a scheduled task is often better for periodic, maintenance-type chores that don't demand sophisticated control".
Services should normally be run as LocalService, LocalSystem, Network Service - without a GUI - but it can also be run with user credentials.
Windows Services Frequently Asked Questions (FAQ). Just for reference and "safekeeping" of the link.
See some information on different service accounts you can use here: The difference between the 'Local System' account and the 'Network Service' account?
Does your application present an actual GUI to the user? It seems this is no longer possible (since Vista): interactive services. I have asked whether this is accurate or not or if "history has changed again". Phil Wilson (MSI expert) can probably tell us - I read an article of his on services back in the day.
You can use the startup folder for allusers as suggested here.
There are several options here. Please check link. There are further links in the linked article that should be worth a quick read.
Register in the registry to launch on boot / login.
Nice Tool: autoruns64.exe. If you really want to figure out a plethora of ways to run something on boot (by registering it in the registry), you could use the Sysinternals tool autoruns64.exe (that is a direct download link from the live sysinternals tool share, here is the Microsoft page).
This tool really shows you just how many ways things can be scheduled to run when the system starts up by being registered "somewhere in the registry". Drivers, services, scheduled tasks, IE, WinLogon, and much more. Perhaps uncheck the "Hide" entries in the Options menu to be truly perplexed by the number of relevant keys (heaps of malware vectors).
Warning: this tool is not for normal users. It has all the rope you need to shoot yourself in the foot if you don't know what you are disabling. Developer / sys-admin only please. Strangely enough it doesn't look like the startup folders in the user-profile are listed in the tool - I guess it is a tool concerned with registry-based launchers only. A screenshot I found:
I am still pretty much new to c# so you will have to bear with me.
I have developed a windows form program which updates some SQL records as an end of day process for one of our clients.
The next step is that I need to install the program on a server and simulate a button click in the program to become a scheduled task.
I know how to setup the task on the server side where you start program and enter the arguments. But I am unsure as to what code I need to include in my program to achieve this.
Consider using Windows Task Scheduler.
You could extract your business logic to a separate DLL and write a simple Console app that will just run your task after accepting the parameters through command line.
My recommendation would be to get away from running a GUI-based/windowed application from a scheduled task - this is generally madness in practice. Ideally, deploy a console-based version of your application that requires execution (perhaps with parameter arguments) and doesn't require any user (or quasi-user-) interaction.
If you simply can't create a 'system version' of your application, then I guess you have two choices, both immensely ugly: 1) create some kind of macro script which is executed instead of your program, this script could execute the program and issue 'the click', 2) perform 'the click' on startup of your application by invoking the button click handler (maybe based on a parameter to give it a duality in execution modes.)
I think you are also asking about command-line argument passing. See the answers to this question.
In particular, I highly recommend the accepted answer: NDesk.Options.
I have similar task to do making winforms as windows task. what i did is
in windows task scheduler in the task tab,under Run put your exe and then /Auto,it will run as schedule.
Example:winform.exe /Auto
If I'm understanding your question correctly, this is how you could possibly proceed:
Best way to parse command line arguments in C#? -> check the answers and choose a library to process the args or write your own code to do so.
Create a scheduled task if those arguments are present by Creating Scheduled Tasks
If it is a windows application, just go to the bin folder, get the executable file, and finally schedule a task for it by using windows schedule task and choose the exe file as you targeted application.
if it is web application, you may want to include your code in a quartz.net scheduled job, details are on quartz.net website.
Very popular solution is Quartz.NET http://quartznet.sourceforge.net/
Take a look in the Timer class
http://msdn.microsoft.com/en-us/library/system.timers.timer(v=vs.110).aspx
Why not extract your database update logic as a windows service
you can segregate the sql handling part in a separate DLL and use the common DLL for both your form application and the windows service.
A window service run in background and can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface.
Moreover you need not to install any third party software for same and window service code base can be ported to any windows machine with required version of .Net Framework installed.
Add reference: Microsoft.Win32.TaskScheduler
then write this code:
using (TaskService ts = new TaskService())
Microsoft.Win32.TaskScheduler.Task task = ts.GetTask(TaskName);
task.Run(); //start
task.Stop(); //End
What might cause an executing process from windows service to run slower than running from command line?
When I execute a process(another exe) from teh command line with admin rights, it is four times faster than when a windows service executes the same process. What could be causing this.
Permissions on directories and files are okay for the account. It runs successfully, just 4x slower. Need ideas on what to investigate to figure out the problem.
We have been using sysinternals processexplorer and not seeing anything.
Where is the advances tab with the ability to modify the "priority" to see if that is causing the problem?
In Windows background services may be given less priority, and that is configurable in the advanced tab of computer properties.
Assuming the priority of both applications is the same, you need to profile the app and see which calls are taking the most time. That should at least give you enough detailed information to come back and ask "why is this specific call running slowly" instead of "why is my app running slowly".
Download the sysinternals process monitor tool from www.sysinternals.com and then start tracing the application, that will show you what the process is doing in terms of registry / file access and will potentially show up what to look at when the delays are occuring.
If you have the debug symbols it can also give you the function call name in the dll / app that is being called, but even knowing what is occuring when a delay occurs and what dlls are in use, user mode or kernal gives you a good indication where to start.
I am looking for a way to monitor Windows dialog during a MSI deployment. Here is my situation: we have machines deploying daily MSIs and once in a while, one of them fail and shows a Windows dialog with an error message.
I am trying to find a way to write a script (maybe in Powershell) which will run every minutes and look for a Windows dialog with an OK button. Is there a simple way to do that?
Thanks!
You can depoly a MSI with options to not display a GUI at all.
Using MSIEXEC with the /quiet option.
Deploy via active directory to machines should not have this problem so I'd be interested in how you are deploying the MSI.
Rather than try to click the dialog, is there a way that you can determine the condition that will cause the error, and handle it?
Although you will find some methods for enumerating windows and posting click messages to them, there are some other things that you migth want to consider:
What if an unrelated dialog box appears that has an Ok button? It could cause problems for your users if an "Are you sure you want to delete the contents of c:\" gets auto-ok'ed.
Also, if your setup is running on Vista/Windows7/server2008 with UAC turned on, then your script will have to run with admin privileges, or any click messages will be rejected.
Can I assume that you are deploying updates to multiples machines (and effectively you wish to know if an update was successful?)
If that is the case, would it not be possible to code such that when the deployed software executes, it reports (via email?) the PC name and the Software Version Number?
You could then simply right a script to start the application periodically and then close it as well.
Darknight