I'm building a windows application from Visual Studio - VB.NET. This application administrative privileges from the operating system. This is completely fine with the PCs which got the administrative privileges. But for the PCs which doesn't have administrative privileges the UAC prompts.
I tried so many things to embed administrative access to the application but non of them success.
Please guide me to make this success
Thanks
Related
I'm logged into a Windows 8.1 machine using domain admin credentials and want to run regsvr32. I receive an access denied error unless I choose Run As Administrator from the context menu. Domain Admins are in the Administrators Group as seen in the Local Users and Groups window. Can someone explain why? Thanks.
It is part of User Account Control, which was introduced in Vista.
Admin users do not have full admin rights by default, even they have to be granted permissions when appropriate. It is Microsoft locking down its security model for a "Least Privileged Environment", where a user does not have more permissions than they actually need at any given time.
Have a look at this article:
The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)
Can we access administrator settings of windows in a Metro-style Windows 8 and Windows RT application?
I'm currently using c#. but answers for other compilers (for example, Qt) are welcome.
administrator settings = (Registry, IO, etc...) -> everything that needs administrator access...
No, because a Metro App is sandboxed and only has access to the WinRT .NET Library and, if in desktop, 3rd party libraries.
This is because of security issues and such.
here is the scenario:
We will be moving the development environment from servers to our local machines. Our local machines will have SQL server, SP 2010 server, SP 2010 designer, and Visual Studio 2010 on them. I need some technical specs stating administrator permissions is required to perform development and debug tasks, do any exists? i have been trying to find something on but have come up short.
Granted this is assuming admin permissions is required to perform these tasks, but i don't see how it wouldn't.
Yes, you need administrative permissions on the local machine. For instance you need to run Visual Studio 2010 using elevated privilegies to be able to debug your solution and you need admin privs to be able to deploy farm solutions.
For sandboxed solutions, there is no need for admin privs though.
I'm trying to integrate WiX into my automated build solution using TFS 2010 running on Windows Server 2008 R2. Everything seemed very easy, and then I get this:
light.exe: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
That's odd. But hey! They provided a link. That should help, right?
Error LGHT0217
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Not at all. These posts just describe a situation involving scripting engine registration, and the conditions they describe were not present. However, I came upon Re: (WiX-users) Why do I get ICE failures building from a serviceaccount? (2010-01-14) that seemed to indicate that if I used a domain account to run the Windows Installer service, it would work. It sounded like it was worth a shot.
"For whatever reason on Windows 2008 (I didn't test Vista, XP, 2003, 7, or
2008 R2) the MSI Service is only available from logins that either have
administrative access or are logins that are "interactive". Logins that are
from service accounts that to not have administrative privileges cannot
access the msi service and thus cannot run ICE tests."
However, when trying to start the Windows Installer service with my build service account:
Windows could not start the Windows Installer service on SKILLET-1. Error 1297: A privilege that the service requires to function properly does not exist in the service account configuration. You may use the Services Microsoft Management Console (MMC) snap-in (services.msc) and the Local Security Settings MMC snap-in (secpol.msc) to view the service configuration and the account configuration.
OK, Windows, so you're telling me that my build service account is missing some ambiguous permission that it needs to start up the service. Making it administrator should fix that right? Nope, that doesn't work either.
So I revert back to local system for the Windows Installer service account. This time I made the build service a local administrator, and lo, success! That's hardly a solution, though.
My next idea was to attempt to isolate the permission set that the build service would actually require to get this done. That would be a nice solution instead of having to add more accounts to the administrator set. Step 1: go into local security policy and add the build service account to all permissions currently given to Administrators. In theory, that should allow the build to succeed, and from there I could selectively remove permissions until I've isolated all the permissions that must be held in order for it to succeed.
Unfortunately, even with all the same permissions, the build will still fail unless the build service account is a member of local administrators. Why is this? What other things besides LSP have dependencies on the administrator group that I could have changed to bring my build service account to equivalence with administrators?
Current conclusion: the build service must be an administrator in order to avoid ICE validation errors.
Open questions:
Why didn't my permissions isolation idea work?
What is this mysterious Error 1297 being thrown when running Windows Installer Service as a domain user? There's almost no documentation I can find on this.
I too faced the same problem. After some struggling and googling I came to the solution that suppressing ICE validation in the WiX project would make the project compile.
I develop an extension for Visual Studio 2005, 2008, and 2010. The Visual Studio 2005 SDK requires write access to the following registry key during builds. The normal way to handle this run Visual Studio with elevated privileges. The entire issue can be avoided if there's some way I can set permissions to allow access to this particular registry key without elevation:
HKLM\SOFTWARE\Microsoft\VisualStudio\8.0Exp
Side note: This key is only used for testing Visual Studio 2005 extensions. The issue does not occur on client machines so this is just a workaround for my own development machine.
It should work to just add permissions to yourself on that registry key. UAC works by disabling the administrators group SID in your session token, so when running non-elevated you will get all permissions that you have - except those that are granted to you through your membership in the administrators group.