So I have a WPF application and here is what I want it to do. I can right click on the executable, select Run As Different user, and get the Windows Security box with User Name and Password, as well as the Smart Card logon. I was wondering if there was a way to launch the Sysinternals Run as Different User to come up automatically, without having to right click and select Run As Different User. Any thoughts?
I was able to go into the Assembly Manifest and force it to run as administrator, but that isn't what I need. I really need the option to run it with Smart Card credentials. Thank you in advance!
AFAIK, the only way to do it that works is by using the RunAs exe as follows. The /savecred will cache credentials, but your user will still have to enter it the very 1st time (which might be annoying for your use-case).
runas.exe /savecred /user:<localmachinename>\administrator "path to your WPF exe"
or, if you're on a domain:
runas.exe /savecred /user:<DomainName>\<AdministratorAccountName> "path to your WPF exe"
Example: To Run Visual Studio 2012 in Admin Mode, I tried the following and it worked. I was prompted to enter my password just once, for the 1st time.
runas.exe /savecred /user:<My_DomainName>\<My_AdministratorAccountName> "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe"
Further Reading: Runas Documentation.
Related
I created a service in C# which generated an executable "GodzillaService.exe". The service itself is just a basic template generated EXACTLY according to this link, other than the name: https://www.c-sharpcorner.com/article/create-windows-services-in-c-sharp/
The issue comes when I try to run InstallUtil. Per the article above, I execute
cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
on an elevated command prompt, run as administrator. I then type in
InstallUtil.exe C:\Path\To\My\EXE\Godzilla.exe
and I get hit with this error:
An exception occurred during the Install phase.
System.InvalidOperationException: Cannot open Service Control Manager
on computer '.'. This operation might require other privileges. The
inner exception System.ComponentModel.Win32Exception was thrown with
the following error message: Access is denied.
Looking at the error message, experience tells me that I need to grant access to something or someone, but what? I'm already running the program as an administrator. I've tried these things so far:
Run command prompt as administrator.
Run Developer Command Prompt for VS 2017 as administrator.
Log out of my user account, log in to my admin account, and try running it.
Move the GodzillaService.exe file into Program Files directory in case applocker is messing with it.
Run VS 2017 as admin, rebuild the exe file, then try it.
Try using the full path of both the exe file and InstallUtil.
Made sure my admin account was in the local admin group.
Tried looking at Event Viewer for more information (did not find any logs related to this issue, maybe I'm looking in the wrong place?)
Tried changing the account in the service program from LocalSystem to User, LocalService, and to NetworkService
I'm fresh out of ideas... Does anyone have any suggestions for what I can do to further troubleshoot this problem? I appreciate any advice given!
It took me a while, but I was able to finally figure this out! The problem was that even though I said I was running it as an administrator, I was running it as a user with administrator privileges. Completely different.
In my environment (which is a domain environment), for some reason we have the "Run as Administrator" option blocked for running programs. Thus, to run things as an administrator, we actually have to run it as a different user, and then select our admin account. This works for 99% of things, but not for this case.
The solution was that I had to log completely out of my regular user account and log in with my administrative account. Then, I had to right click on command prompt and Run As Administrator. Upon doing this, I no longer received the error!
I have a .bat script with I configure to run in my post-build event call $(ProjectDir)scripts\install.bat, this script to install a service in my local machine.
When I open a cmd and run as administrator, this script works, but if I run in normal cmd doesn't work. Exist some way I run call $(ProjectDir)scripts\install.bat in administrator mode in visual studio in post-build event command line or someone other way to script works in normal command line.
Note: I have administrador privileges
Assuming this is Windows 7 or later:
Even though you have administrator privileges on the machine, you still need to run Visual Studio with administrative privileges to do things that a normal user can't do, because of UAC. Right-click on your VS icon, and select "Run as Administrator".
Maybe a few years too late, but here is the solution for anyone still searching.
Just add this to the top of your batch file and it will ask UAC for admin rights before executing the rest of the script.
if not "%1"=="am_admin" (powershell start -verb runas '%0' am_admin & exit /b)
I have a project in c# which requires auto update functionality, since it has quite a lot of dependencies and runs a Windows service, ClickOnce installer is not suitable for this work. So I created a setup project for this application. Now I want to include an auto update feature.
My auto-update strategy is:
From the main application, check for updates every morning.
If an update is found, get the msi link
Application passes control to the msiexec and quits
Ex.
msiexec /i http://www.example.com/share/package.msi /L*V "C:\log\example.log"
Since my application is running on administrator account UAC prompt will not occur.
Are there any pitfalls that I haven't seen? Or there any superior way to do auto update gracefully?
Note: The setup project of the application is marked with the property RemoveAllPreviousVersion = True so it will take care of the uninstallation of previous versions.
A couple of comments/answers:
"Note: The setup project of the application is marked with the property RemoveAllPreviousVersion = True so it will take care of the uninstallation of previous versions."
But only if you increment the Version property of the setup project, accept the change in ProductCode, keep the UpgradeCode the same, ensure that the value of EveryOne or Just me is the same in the older product and the upgrade, and increase the file versions of files you need to update.
It's also not obvious to me that you won't get a UAC prompt because "running on an administrator account" does not mean the same as "running with administrator privilege". If the running process is not running elevated a prompt will occur, because UAC means that even administrators are running limited unless explicitly elevated. Even if you are elevated, calling msiexec as an external shell call will not result in msiexec being elevated. A shell execute does not transfer privilege to the offspring process. The other thing to consider is whether it's the current interactive user that is effectively doing this update, because there may be an issue trying to show UI if another user owns the desktop.
Anyway in general it's ok to do that, it's quite common, and signing the MSI would be more secure. Also, Windows Installer will sometimes prompt a repair, so that install URL needs to remain valid. A better approach would be for you to download the MSI to a location on the client system that you own and prompt the user to run it, or you run it - it's more friendly to offer that than pull the rug out and just do it.
What is the best way to install a .msi in a c# application in silent mode. I want to install a .msi file using msiexec, but I don't know how to do this. The problem is for using msiexec with /qn, you have to run it in a cmd.exe process start "as a administrator" and I don't know how to accomplish something similar with a c# application (for more details, a wpf project in VS 2010). The best I come to is :
Process p = new Process();
p.StartInfo.FileName = "runas.exe";
p.StartInfo.Arguments = "/user:Administrator cmd";
p.Start();
A windows will pop and ask for a password, but I found this behavior pretty ugly. I mean, I don't want to ask the user for his password. Is there anyway way to start my project, set it as a kind of "run as administrator" (the UAC will pop-up, but that's ok) and just run the msiexec command ? Or is there any other way to make a silent install of a .msi file ?
Thank you
Despite somebody voted down without comment, this is a very thorough answer IMO:
Maybe somebody misunderstood, because the answer is quite long.
Recommendation for short reading: Take option 2) .
First, generally, try to avoid RunAs as often you can. With RunAs you are creating a mixed user situation which is not supported by all scenarios and applicatons/processes. With operating systems newer than XP it is not really necessary. Requiring admin rights with UAC (e.g. the correct manifest in the .exe) is at least MS recommendation !
(Just a security remark: Most secure way is still having the admin account completely separated so that neither RunAs nor UAC are normally needed.)
1) The most easy (but not my recommended) method to assure admin rights for a MSI install is doing nothing and let UAC work.
If the MSI needs admin rights, UAC will normally come up itself after some time (not every part of the install process needs admin rights, so it will take some time.
To ensure, that UAC requests come up in child processes, kinda UAC-inheritance, you have to use ShellExecute in the baseline. This is a Windows thing, has nothing to do with MSI or C#.
In C# you can do this like this:
ProcessStartInfo startInfo = new ProcessStartInfo(exeFile, arguments);
StartInfo.UseShellExecute = true;
This is of not much use, if you want a silent installation with no installation dialog (e.g. "/qn") at all.
Moreover the UAC so late has small disadvantages, so the following is recommended and very much safer:
2) Admin rights from the beginning, e.g. in the bootstrapper .exe:
If it is sure, that a setup should be started, or in general, your app needs admin rights for it's own or child processes, the best idea ist to assure, that your app itself has already admin rights from the beginning.
In other words, UAC comes up when starting the app. Then your child processes have admin rights too, and it works also for CreateProcess-type child processes and not only for ShellExecute-type.
To achieve this, just add a manifest to your app containing the following line.
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
How to do it?
Given the fact that the whole Windows 7 evangelism was based on manifests ("What is the sense of life? Giving applications a manifest."), Visual Studio in it's different versions of the last years has not really done an excellent job of supporting this. Every version is different, and it is different for C#, C++, VB apps.
For VS 2010 and C# the way to go is:
(For VB.Net, it's in 'View Windows Settings' in the solution's Application tab, I've read here.)
In Solution Explorer, right click on the project and select "Add New Item", "New element" and choose "Application Manifest File".
Open this in VS by clicking and you will find the existing node of together with comment lines describing the alternatives. If you don't know about them, it is a good point of googling to learn one of the most important things about modern Windows.
Change the line so that level="requireAdministrator" is configured, and you are done. Your app now needs elevated rights. Try out after build.
(The "uiAccess" attribute, you can ignore, until your app shall control/automate the UI of other apps like in a remote control or UI testing app.)
Start the MSI install normally with "msiexec.exe ...". Don't forget the quotes at the right places and to catch the return code for errors and reboots.
An alternative to msiexec is using the MSI API (socalled external UI), but it is more complicated.
3) No admin rights at all. Unfortunately this is not possible or would break security policies for standard applications which should be installable machine-wide in the programs directory. There is a lot more to say to this in detail of course.
I have a C# application, and a Visual Studio (2010) Setup Project with it. In my Setup Project, I am using InstallAllUsers = True. Additionally, my application needs to launch at Startup, so a shortcut is being added to the User's Startup Folder.
So I install my application as user Bob (from a share), and then I log off and log on as user Alice. Alice gets a dialogue that says:
The feature you are trying to use is on a network resource that is unavailable.
It provides the network path from which the MSI was installed. So, basically, it's looking for the MSI on a share that Alice doesn't have access to. This is repeatedly reproducible if Alice tries to manually launch the Startup link. However, Alice can directly launch the exe from the installation location, which works fine.
I don't fully understand why it is looking for an MSI, but I guess it makes sense that an application can not be completely installed by one user for another user, so the MSI is needed to complete the installation.
But if that is the case, then I don't understand why the MSI only seems to be required when launching from the Startup link, and not from the exe directly.
My question has several parts:
Is what I am experiencing expected behaviour for the InstallAllUsers option?
If so, how can I ensure that my application is fully installed for all users?
Is it necessary to copy the msi locally, and ensure that it does not get deleted before each user has had a chance to log on?
This is happening because the shortcuts are "advertised shortcuts" hence the greyed out target box.
More info here...
http://www.advancedinstaller.com/user-guide/advertised-shortcuts.html
When an advertised shortcut is launched it validates the checks
associated with the key resources. If any is missing it will fix it by
running the installation package and installing again all information
from the .msi file.
This is why its trying to run the msi.
You can turn off advertised shortcuts by reading this article...
DISABLEADVTSHORTCUTS=1 disables all shortcuts
If its an all users install, then the shortcut will probably want to reside in the all users start menu. Win 7: C:\ProgramData\Microsoft\Windows\Start Menu.
Eric, I would recommend taking a look at the shortcut file contents. You can do this by using Powershell, and there is a SO link to help you on your way:
Editing shortcut (.lnk) properties with Powershell