The code is really quite simple:
var key = Registry.LocalMachine.OpenSubKey("Software").CreateSubKey("somekey", RegistryKeyPermissionCheck.ReadWriteSubTree);
...but I keep getting the exception "Cannot write to the registry key", even when I run VS2010 (or the compiled code) as Administrator.
What am I doing wrong?
Running .Net Framework 4 Client Profile.
You are trying to write to HKEY_LOCAL_MACHINE. Access to HKEY_LOCAL_MACHINE is restricted by UAC. Your user may well be an administrator, but unless the process is started with elevated rights, UAC will prevent write access.
In order to write to HKEY_LOCAL_MACHINE you will need to ensure that the Registry access is performed in code that is running with elevated rights. To do that, you will need to either:
Add a UAC manifest to your application to force it to execute with elevated rights. However, this means that the user will have to deal with the UAC elevation prompt every time the application is run.
If you do not want to elevate your application, you will need to separate the parts of code that need elevation into a separate process, or into a COM object instantiated via the COM Elevation Moniker, whenever your application needs to perform an elevated operation.
Related
After installation of the program, can not make uac dialog box disappear when the program is run?
Can I grant administrator privileges to install and have it run automatically at install time?
You cannot bypass UAC, the user is supposed to be in control of their computer, that is the whole point of UAC! If you want to do machine wide changes that require administrator privileges there is no way around it, the user has to elevate with UAC at least once.
If you want the installed application to run elevated automatically then you must write a custom service that can be started on demand. When a administrator starts your application un-elevated the application must start your service and ask it to launch a elevated instance. The service must then call CreateProcessAsUser with the linked elevated token. This is too difficult for most developers and most applications just have to accept the fact that they must display a UAC prompt when they are started.
I've just developed a .NET program which has the ability to patch itself.
I've noticed that the patching process only runs if I choose "run as administrator".
It seems I need to "create and embedd an Application Manifest", according this this:
https://msdn.microsoft.com/en-us/library/bb756929.aspx
So my question:
Is it normal for applications like mine (which can patch themselves) to require Admin rights, and is this the route I should be going?
Thanks
If your application does not normally require elevation then I don't recommend that you request it in your manifest because it will be very annoying for your users. Firefox uses a NT service to get around the UAC dialog but I can't really recommend that either unless your updates are very frequent.
I would suggest that you write a little updater application that does the patching. It can request elevation in its manifest and this way the user only has to elevate when there is something to patch. If you don't want another .exe in your bundle, you can execute yourself again with the runas verb when you need to patch.
Edited the NSIS script to include this line:
AccessControl::GrantOnFile \"$INSTDIR" "(S-1-5-32-545)" "FullAccess"
This gave the User account full access to the application folder within Program Files, meaning my patcher could write to it without any problems.
I am using the Limited edition and in my installer I have a custom action where I open a cmd.exe and passing a batch file for executing.
The cmd is executing but its not in the elevated permission. I need to execute this in elevated permission since my batch file has operations which needs admin privilege.
I tried many options and the screen shots attached describes what I have done.
Let me know if this is possible with Limited Edition. I am installing in windows 10 machine.
the whole "Elevetad privilege" thing changed a lot during the lasts years.
if I were you, I'd put the schema to version 500 (the last one)
you'll might wan't to double check that your batch file is correctly found, as properties in system context can be unavailable. (use /k so the cmd prompt will not close and you'll be able to see the result of your batch file.)
also if the UAC is disabled on the client machine the user won't have the right to elevate your installer so setting the Require Administrative privilege won't change anything.
in order to be sure, you'll might wan't to use a install condition validating the Privileged property.
When working on a project that uses IIS (not IIS Express) for local development, what permissions are actually required under window 8? I don't want to run as admin all the time...the first error message I get when running using the Local User Account (LUA) was about Metabase (probably a misnomer, as changing the permissions on that gave the same error message until the config files in inetsrv/config were also available). Now it builds, but then gives an error message "Unable to start debugging on web server. IIS does not list a web site that matches the launched URL".
The blog https://blogs.msdn.microsoft.com/jaredpar/2005/02/04/myth-creating-web-applications-with-visual-studio-requires-admin-privileges/ while old, at least hints that it should be possible to manually give myself (or a group that I create) the right permissions. Just need to figure out what those permissions are...
To run VS against IIS you need to run VS elevated (the process needs admin permissions).
From a non-admin account you could run VS "As Administrator", you will also need to do this with the tools necessary to configure IIS.
However I've never tried that, rather I run with a non-elevated admin account so any file changes from within an elevated VS are fully accessible to non-elevated processes.
Additional: note, VS really only needs the Debug Any Process privilege, but giving that one privilege gives the ability to gain all others (with some effort) going through the work to limit the VS process to just that one difference seems pointless.
Folks,
I've got a strange issue at the moment with a visual studio 2010 built MSI...
When I run the msi, it performs a few tasks, then executes a tool we built - this tool then carries out some more advanced work we couldn't do within a custom task.
The issue here, is then when the msi starts my custom built tool, it doesn't execute it with the same credentials as I start the MSI with (i.e. my administrative login).
Is there a parameter I can pass to an MSI to enforece this? Or perhaps I can pass the credentials to the process when I start it?
My process is started using Process process = Process.Start(procInfo) nothing fancy. I've also noted the ability to pass in a parameterised username/password/domain, but this will vary depending on the user who is installing - can this be extracted from the installer somehow?
Any help (or questions) welcomed.
Dave
EDIT: for clarity... I'm running the MSI under my domain account, and I want my custom process to run under that 'context'. At present, it starts (regardless of whether I start as administrator or not) under the SYSTEM account (rather than mydomain\me). I'm using Windows Server DataCenter edition if that helps...
I should also add, I think this is a policy issue, but I've no idea what to check/where to check...
By default Windows Installer runs custom actions as the current user. If the MSI is elevated, custom actions will run as the elevated user.
Please note that if you are running the MSI as an Administrator, it doesn't mean your custom actions will have full Administrator privileges. On Vista or higher any user can gain Administrator privileges through elevation.
So if your custom actions need Administrator privileges, make sure they use the msidbCustomActionTypeNoImpersonate flag so they run under the local system account.
If this is not the problem and you just need access to the current user data, can you please give me more details?