First of all, yes, I was searching about this topic around the internet, but my case is a little more specific, so this is the reason of my question.
My app is an executable winform app developed in Visual Studio .NET 2005 with Framework 2.0, C#
The app needs run some commands on a command line. This command must run as administrator.
The code that actually works is:
string output = "";
Process Consola = new Process();
ProcessStartInfo ConsolaStartInfo = new ProcessStartInfo();
ConsolaStartInfo.FileName = "cmd.exe";
ConsolaStartInfo.WorkingDirectory = System.Environment.SystemDirectory;
ConsolaStartInfo.UseShellExecute = !NeedOutput;
ConsolaStartInfo.RedirectStandardOutput = NeedOutput;
Consola.StartInfo = ConsolaStartInfo;
ConsolaStartInfo.WindowStyle = ProcessWindowStyle.Hidden;
ConsolaStartInfo.CreateNoWindow = true;
ConsolaStartInfo.Arguments = "/C " + CommandToPerform;
ConsolaStartInfo.Verb = "runas";
Consola.Start();
Consola.WaitForExit();
where:
CommandToPerform is a string var with a command
NeedOutput is true or false depending if i need a return output or not.
(This works)
The first tip is: this application works perfectly as is expected if I'm running the Visual Studio as administrator on Windows 7.
The second tip is: this application works perfectly as is expected if I'm running the Visual Studio NOT as administrator, but everytime the command line is executed, the process ask me for security validation on the screen (UAC)
Yes, I tried to work with the manifest but I've a lot of problems to compile it. It returns 9009 error sometimes, a lot of kind of errors.
So my questions are:
1) There's possible to do that without ask to the user for permissions? The application must be silent. This is the real question. If so...
2) How can I define the manifest for my application runs this command as administrator? I miss anything about? It's the same sign the application?
3) Can My app runs these commands as administrator without running as administrator? This is the perfect scenario, the users that will use this app can't be / can't will be administrators.
4) This will work on XP? XP ask for UAC? (I can't test it on XP until I develop a minimal requirement version)
Any kind of idea / solution / tip will be appreciated, and if on the final is not a solution, the better workaround will be mark as answer (I've a 100% rate)
Notes:
I can't migrate the framework from 2.0 to an above edition by client requirement.
I can't migrate the Visual Studio .NET 2005 to an above edition by client requirement.
The applications needs run for all editions from XP (without any SP) to Windows 7
Yes, I can use a workaround IF is under "Microsoft Policy" and app requirements (Framework 2.0, API or something like, mods/controls/library that are NOT from microsoft can NOT be used)
EDITED:
The solution of adding a key to: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers WORKED.
But when you run the application, it's prompt (with the common UAC prompt) for permissions
Well the answers to questions 1) and 3) are simple: this is impossible. Because if it were possible, the whole UAC would have no use at all.
I don't know about XP compatibility (but I do think XP will ignore the manifest) and unfortunately I have no experience with the UAC prompt and VS2005 either. I only did this in VS2008 and above, so I can't help there either. I did find a guide for VS2005, but it's likely you have seen the same one as well:
Enabling your application for uac on vista.
It can be done doing a little service that runs the command, and the service process installer must be with the property Account on: LocalSystem.
So your application doesn't need any requirement or manifest.
It's working on Win7 and on XP
MSDN Creating a Windows Service
And the note:
The LocalSystem account has broad permissions, including the ability
to write to the event log. Use this account with caution, because it
might increase your risk of attacks from malicious software. For other
tasks, consider using the LocalService account, which acts as a
non-privileged user on the local computer and presents anonymous
credentials to any remote server.
Related
I am building an auto-updating mechanism. A windows service that runs on a local service account responsible with the auto-updating of a msi.
The service downloads the msi file then it tries to install it using this code:
Process process = new Process();
process.StartInfo.FileName = "msiexec.exe";
process.StartInfo.Arguments = string.Format(" /i \"{0}\" /qn /norestart ALLUSERS=1", sMSIPath);
process.Start();
process.WaitForExit();
Where sMSIPath is a string representing the path to the file, for example "C:\test.msi".
This code, from a regular console application seems to be running fine. I managed to silently install adobe reader, for example.
But from my windows service, it does nothing. According to the logs, i get a warning with this message:
Failed to connect to server. Error: 0x80070005
Where the user is "LOCAL SERVICE" (as i mentioned, my windows service runs as a local service).
Also, the projects have target x86, but i am running a 64-bit OS. (i need them at x86, i want this software to be able to run on multiple operating systems).
Any help is very well received.
Thanks alot!
I don't think you have much chance of making this work. If the MSI tries to access folders like Desktop, User's Program Menu, the CommonFilesFolder (not a complete list) or looks at the LogonUser property and any number of other things it will fail because in a normal install from the interactive user these are all valid properties associated with that installing user. When the installing user is localservice you're likely to be in a mess.
If you need to do this, configure the service to run as a valid administrator account - that might give you a chance of it working better. It's possible that the failure to connect to server error is because MSI files are expected to be run from some kind of user account.
Open service management console Start->Run->Services.msc
Right click on your service and go to properties
On property page select second tab i.e. "Log On"
Check checkbox called "Allow Service to interact with desktop".
Harry Johnston is right, local service doesn't have the privileges to do that. Local system works great though, so i'll use a local system account.
Thank you for your answers, they were all helpful!
I am working on a WiX installer that uses Burn and therefore has a .Net requirement. Bundling the prerequisite version of .Net does not work on server OS's as they require the role manager to be used. The fact that it's part of a WiX install is not really of overwhelming importance it's there in case there are other methods to help me accomplish my task. I am running/testing the code below as a standalone .Net Console application. After failing using this method in order to work around this I wrote the following use powershell and "Enable-WindowsOptionalFeature".
static void Main(string[] args)
{
PowerShell ps = PowerShell.Create();
Runspace runspace = RunspaceFactory.CreateRunspace();
runspace.Open();
Pipeline pipeline = runspace.CreatePipeline();
Command addDotNet = new Command("Enable-WindowsOptionalFeature");
addDotNet.Parameters.Add("-FeatureName netfx3 -Online -All");
pipeline.Commands.Add(addDotNet);
Collection<PSObject> log = pipeline.Invoke();
}
When I run it this window pops up.
Windows Server roles and features cannot be automatically installed or uninstalled via the Windows Features Control Panel.
Seeing as how I figured I was already using the equivalent of "Server Manager cmdlets" I'm not sure what it's actually asking for. So the two part question is 1) What is the proper way to work around this issue. 2)How do I keep it quiet during install.
PS: If this question really belongs to Server Fault let me know.
Enable-WindowsOptionalFeature is part of the DISM, it would be used to create a windows image to deploy to a new system
Add-WindowsFeature is the one you are looking for, it adds a feature to the current instance of Windows Server. It is in the ServerManager powershell module, which is only available on Windows Server (not on Windows 7)
All I'm going to say is based on common sense, rather than on prior experience, so sorry if this is not relevant.
You seem to be able to be on Windows Server 2012 as only this version has Windows ADK that you are using. Windows 8 (client os )nd Windows Server 2012 (server os) have differen ways of enabling feature. Those surfaced as Optional Features in Windows 8 but as Server Roles/Features in the server.
Note, that contrary to what you say, the bundle does not work not because it's a server OS it does not work because it's included with the OS and need to be enabled. This applies both to server OS (Win 2012) and client OS (Windows 8).
It's just that you need to use different methods for Windows 8 and Win 2012.
For Windows 8 your method could work. For Windows 2012 the help you are seeing suggest that you use Add-WindowsFeature cmdlet.
Basically, the command fails, because the component you need to install is not present in the component store. The administrator needs to insert the install media. Perhaps you could include the respective file(s) with your installer to avoid that manual step, but I've never tried that and it might also pose a licensing problem.
For Server 2012 Microsoft decided to remove the .NET framework 3.5 from the component store by default. It's still present on the install media, just not spooled onto the disk during installation. I wrote a rant about this in my blog a while ago.
I added some additional logging/writeline statements while trying to figure out where things were broken in the server 2012 instance. I realized that those debug lines were not output to the console at all.
It turns out that I was not READING the pop-up closely enough. The complaint was not about using the PS commandlets, but a complaint about trying to install .Net 3.5 to run my app. My app was targeting .Net 3.5 so the message was about the attempt to automatically install .Net 3.5
May this question be more than a testament to my momentary blindness and stupidity, but also serve as commentary on the importance of paying attention to detail and reading the error understanding why it's occurring. :)
When I install my C# app in windows 7, UAC always shows. I'm not logged in as Administrator but I want my application to be installed without the UAC.
Can you give me ways on how to do it?
The UAC prompt shows for any number of reasons, none of which is "the code inside the exe calls function X or tries to write to place Y." These include:
the name contains setup, patch, update etc (eg setup21.exe) and there is no manifest
you embedded a manifest that asks for requireAdministrator. You would have done this on purpose in Visual Studio.
there is an external manifest (for NewApp.exe it would be NewApp.exe.manifest) in the same folder that asks for requireAdministrator. You would have done this on purpose too.
you have right-clicked the exe, and on the Properties Compatibility you have chosen to elevate it, or to run as XPSP2 which for 7 also elevates
someone in your company has applied a Group Policy that this installation app should run elevated (unlikely)
you once ran it, got a dialog from Windows saying "that may not have worked right" and agreed to try again with "recommended settings"
Do any of these seem likely? If so, correct them and see if the UAC prompt goes away.
Single Package Authoring link text
You'll want to use Windows Installer / Windows Installer XML to make this install behave the way you request.
If you want to install an app without UAC then you can only touch folders that the currently logged in user can write to. Google Chrome does this--it installs the entire application to the user's local application data folder.
It's very non-standard and I would argue MS should prohibit running code from this location, but it's a working solution to requiring administrator/UAC access to install applications.
Incidentally, Google Chrome more recently made a traditional installer available so one user can install it to be used by all users on the computer.
If you want your application to be installed without triggering the UAC, install to %APPDATA% (instead of installing to %ProgramFiles%) and write to the HKCU hive only in the registry (i.e. don't try to write to HKLM, HKCR, etc.)
I have an application that is supposed to read from the Registry and when executing a console application my registry access works perfectly.
However when I move it over to a test this returns null:
var masterKey = Registry.LocalMachine.OpenSubKey("path_to_my_key");
So my question is:
Does Visual Studio run Tests with a less privileged process?
I tested to see what user this gave me: var x = WindowsIdentity.GetCurrent().Name; and it gives me the same as in the console application. So I am a bit confused here.
I am using MS Test Framework and the machine is Windows 2003 64 Bit.
It is not a security issue. It's the fact that you are running on a 64-bit operating system. 64-bit apps have a different view of HKLM\Software than 32-bit apps. 64-bit apps get the "normal" view, 32-bit apps are redirected to HKLM\Software\Wow6432Node. The EXE determines the bit-ness of the process, it will be different when mstest runs the code. 32-bit, probably.
You'll need to create the key you are trying to read in the Wow6432Node tree. Or make the regular app have the same bit-ness, Project + Properties, Build tab, Platform Target = x86. Also changeable on-the-fly with Corflags.exe.
I would say yes. Why do you expect anything different?
It would have to be this way to be Windows Logo compliant.
It's also good from a security viewpoint.
Visual Studio .NET is Windows Logo compliant, so you would expect that it runs as a restricted user
http://blogs.msdn.com/vcblog/archive/2006/09/06/742187.aspx
I have a relatively simple ASP.NET application that I am trying to create an installer for. I am currently using Visual Studio 2008's "Web Setup Project" which, though I'm told is not ideal, has proved no problems when installing on Windows Server 2003 & IIS6.
IIS7 on Server 2008 and Vista has proved substantially more difficult. The installer starts off fine before halting with an unhelpful "The installer was interrupted before could be installed. You need to restart the installer to try again." UAC is switched off, and I've already ensured I'm executing the installer with administritive privledges.
The problem sounds identical to the issue outlined in this blog post, however I have the IIS6 Metabase Compatibility role service installed already. I've also tried playing around with AppPools, the Integrated/Classic pipelines and so on, all to no avail.
I've since turned on MSI logging and, whilst I found nothing concrete, I believe the rollback begins somewhere around this error message.
The error indicates that IIS is in 64 bit mode, while this application is a 32 bit application and thus not compatible.
This doesn't make any sense to me whatsoever, as both Vista and Server 2008 are 32-bit installations. I suspect it's a red herring, but I can't be sure.
Has anyone encountered a similar problem, and if so, is there a solution that doesn't involve me moving to a different installation framework?
Try putting a friendly lil checkmark beside each node in
[Programs and Features // Turn Windows features on or off // Internet Information Services // Web Management Tools // IIS 6 Management Compatibility]
Note that I had the same symptoms posted in the blog though, and this fixed it for me. Yours may be different.
Just tackled this last night, therefore my sincerest good luck to you.
In order to fix that error message for those using Windows 2003 x64, use the following commands from a cmd prompt:
cscript.exe %SystemDrive%\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 "true"
cd WINDOWS\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis.exe -i
Source:
How to Run a Microsoft .NET 2.0 or higher Web Application in 32-bit Mode in IIS 6.0 on a 64-bit Server
Note:
By doing the first step, you will now notice that the ASP.net tab is no longer visible.
This is a known bug and the work around is too use scripts to change the .Net version for any running sites.