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:
Related
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.
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
Basically, I have an exe app that is installed with priviledges (as in, the user presses the "Allow" button in Vista/Win7 UAC check), then the application starts and sets itself to auto-run so that the application will automatically restart again once the computer is rebooted (all done while elevated). The autostarting is requested by user, and is not enforced upon them.
This reboot instruction is set in the registry, in the CURRENT_USER section as below:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
The problem is, when the computer reboots, Windows will not let it execute unless the user re-authorizes it as an elevated process again (namely, a taskbar icon pops up in the tasktray saying the starting of my EXE/process was prevented, and the user is given the ability to launch the blocked app using menus on the icon in the tasktray).
I would like to add that I have the manifest file integrated into the EXE, so there is no problem on that end, and it registers its intentions accurately in the XML file.
Why does Windows do this by design? If an exe was authorized once, shouldn't that imply that it be authorized permanently?
But the main question I would like to ask is, how do I get around this? Imagine my users having to do this every single time the application needs to autorun?
Also, I would like to avoid the whole "your app shouldn't be running in elevated mode in the first place" argument/discussion, or the "no app needs elevated priviledges, you need to rewrite it" discussion. I can assure you that my app needs elevated priviledges (unfortunately). More details below if interested, not necessary to interpret or understand the question in this post, but included because I know some people will ask)...
Additional Unnecessary Reading:
...In fact, it requires it in 87% of all launches (depending on what users do), and for the 13% of times were it is not needed (that's, 13% of all launch instances, not 13% of users), I am developing a second exe where only that is launched first, and once an elevated feature is needed/requested, the elevated portion loads, saving 13% of all launches from hassling people with UAC nag, I will only have this ready by 2013. I'm going to all this work to split up functions that don't logically belong in different areas of the application - even with all this work, the problem I mentioned above does not get resolved (but rather, very slightly minimized or deferred).
I'm not sure why this was tagged with any programming language, and since it is really a ServerFault question it doesn't even belong here as far as I can tell.
The normal way to handle this is via Task Scheduler though, using the Run with Highest Privileges option. There are several published descriptions of the process involved, such as the old one at Make Vista launch UAC restricted programs at startup with Task Scheduler.
Why does Windows do this by design? If an exe was authorized once,
shouldn't that imply that it be authorized permanently?
That's a matter of opinion, but here's mine. If I needed Visual Studio to run elevated yesterday because I wanted it to regsvr32 a DLL, that doesn't prove that I want it to run elevated today on some different app.
But the main question I would like to ask is, how do I get around this?
I would use a service. The programming is non-trivial but that's how I would autorun an elevated process.
Either ask the user to turn off UAC or, as you already mentioned, redesign your application so that it elevates at the point elevation is needed, or run a service under system account and let it do the stuff which requires elevation.
My program has a handful of settings that need to be established before it can operate correctly. I would like the user to be shown a setup wizard either at first run or at install that has them set everything up to their needs. Right now my program does not use an installer, it just runs from its exe file. The program does offer the option to change these settings when it is running, however I want the user to set the settings first before the program runs. My options seem to be:
Use a setup wizard (either my own or one created such as this link.)
Make the program use an MSI and install. Several have pointed out that an MSI will allow for a program set up while installing which would satisfy the need I have.
As an MSI option sounds like it is the norm for programs I should perhaps learn about those. But I am still curious for other peoples input on this particular problem. For those who are going to recommend the MSI solution, I'm new to this particular aspect of programming, any recommended links are greatly appreciated.
I think it really depends on what your application deployment does. If it simply copies some files and registry entries an MSI will handle most of your needs, including upgrades. Here is a similar discussion which may help you: What is the best SIMPLE replacement for VS Setup-project Installer for WinXP + WPF + .NET 4.0?
If your deployment process involves custom and/or complex tasks, a customized wizard is better because it gives you more control. MSI packages are very limited when it comes to customization.
We do something similar:
Whenever the application is launched, we check the settings storage (usually a database) and if anything needs to be set, we launch the setup wizard.
If the user cancels the setup for some reason, the application is terminated, meaning that the user can't proceed to the main application until the initial configuration is complete.
Having spent an inordinate amount of time configuring (or attempting to configure) installers (Installshield, Installaware, etc), I can promise you that this is the most effective, efficient way to accomplish your goal.
There are some things that you should (and in some cases, have) to do in the installers, but from your description, they don't apply to your situation.
I just try to figure out a good solution on designing the update process for a windows form application i created. I think of a button inside the app for manual checking of an update and checking when starting the app. Only I'm not familiar with technics. I though to have the update setup file in a FTP Server and checking the server for an update with a txt file in there with filename and version info. When app is finished downloading the update, closing and starting the update setup file.
Any suggestions, opinions on the subject?
Application updates these days are one of those necessary evils. Thinking of applications that update automatically, I tend to group them into two categories:
Clean updating, once a month or less often, a speedy update without a lot of nagging or clicking. And definitely no sneaky software included like toolbars and desktop search programs... Firefox tends to be "nice" about updates, though its addons can be naggy.
The other group nags constantly, requires a lot of button clicks or that you reboot, takes a long time to 'unpack' (Adobe Acrobat, looking at you), changes settings against your wishes (Java), or is just generally unpleasant.
With those points in mind, design your automatic update to be as user-friendly as possible, and plan on your users sometimes wanting to skip the update (unless it is critical to operation).
At my company we have a small application that requires updates, but also must function in a very time-sensitive environment. To facilitate updates, we have it do the following:
At startup, a text file is checked on an internal URL (this could be an HTTP or FTP call). The version number is compared to the contents of the file.
If the software is up to date, nothing more is done. If not, a dialog is presented informing the user that the application must perform an update. (In our case there is no option to cancel or wait, but I highly recommend it if you can.)
A setup file is downloaded from the same site, and launched via Process.Start command, with some switches to perform an unattended install/update.
The application is launched after installation and the interruption to user is minimal.
Some things you may want to do differently:
If not checking for updates at startup, provide an option to schedule update checking or manually perform an update check from (for example) a Help menu.
If possible allow the user to cancel or delay an update; there's nothing more frustrating than trying to get work done with a popup dialog asking you to perform an update every few minutes.
Make sure you test your install packages or patches before deployment! (Voice of experience!)
Use ClickOnce http://msdn.microsoft.com/en-us/library/t71a733d%28VS.80%29.aspx
http://www.15seconds.com/issue/041229.htm
Kind regards.