Hi have created an installer which installs the application at user level.
When i extract setup.exe from the cab file and run locally it does not prompt me for UAC and installs normally and installs in user context.
The application and cab are digitally signed.
But when i install the same using one click installer it prompts me for UAC and installs it in admin context.
Can any throw some light why same setup.exe behaving differently?
What can i do to avoid this?
I want my application to be installed at user level without admin access?
My guess is that setup.exe is triggering the UAC setup compatibility heuristic. From MSDN:
User Account Control: Detect application installations and prompt for elevation
When an application installation package is detected that requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
Windows tries to detect certain applications that are installers (e.g. those containing setup, install, update in their filenames) and will try to elevate them automatically. Microsoft does this as a compatibility hack:
most users won't realize they are supposed to Right-click a setup application and select Run as Administrator
even fewer developers correctly mark their installer as requireAdministrator
even fewer developers use MSI, which knows how/when/if to elevate to an administrator
You can inform Windows that your application should not be run as an administrator. You do this by adding the asInvoker option to your executable's assembly manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="client"
type="win32"
/>
<description>CodeJunkie Widget Installer</description>
<!-- Disable Setup elevation compatibility heuristics since we're named setup.exe -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Related
On Windows XP, I'm redirecting user32.dll for a specified application, but with the same setup on Windows 7, user32.dll is not redirected.
The setup is this - a directory containing:
app.exe
app.exe.manifest
user32.dll
app.exe.manifest contains:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="0.0.0.0"
name="Redirection"
type="win32"
/>
<file
name="user32.dll"
/>
</assembly>
On Windows XP, app.exe loads the user32.dll from the application folder. On Windows 7, app.exe loads user32.dll from the system32 folder.
How can I get app.exe to load user32.dll from the application folder on Windows 7? The MSDN docs don't mention any differences between platforms for the way assemblies work, but there must be some difference that's stopping the redirection from working...
Any ideas?
So it turns out that Windows platforms from Vista onwards do some activation context caching, i.e. a manifest is looked for the first time the application runs. If a manifest is added or changed after the first run, Windows doesn't bother to look for it to save time loading.
So my scenario does work, but you need to force Windows to re-cache the activation context by modifying the applications binary (e.g. the time-stamp).
I tried that and my user32.dll is loaded in Windows 7 from the application directory.
Refs:
http://blogs.msdn.com/b/vistacompatteam/archive/2006/11/13/manifest-and-the-fusion-cache.aspx
VB6 Manifest not working on Windows 7
I am building a tool which allows to install an application into our simulator and it is called 'cl-install.exe'. It really doesn't need any administrator privileges to run. But Windows 7 always pops up a dialog asking the user to provide administrator privileges when this command is invoked from the command prompt.
If I rename the same executable to some other name, without the words 'install' or 'setup' in it, Windows doesn't ask for admin privileges.
Is there any way I can prevent Windows from doing this, without renaming my executable?
This is part of the heuristics present in Windows Vista and later. From here if the file contains the words "install", "setup", "update" or "patch" - installer is assumed.
You can prevent this by adding the following to your manifest
<requestedExecutionLevel level="asInvoker" />
I've found a working solution here: https://github.com/bmatzelle/gow/issues/156
Quote:
The solution is to write a manifest file listed below for the executables, in order to persuade UAC that it does not require administrative privilege.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<!-- Make sure that UAC believes
that it does not require administrative privilege -->
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
The filenames of the manifest files should be install.exe.manifest and patch.exe.manifest, and then put them in the same folder as install.exe and patch.exe.
If the UAC prompt still pops up, change the timestamp of install.exe and patch.exe to persuade Windows to pick up the new manifest file.
If I remember correctly you can disable this behaviour the following way (quoted from Technet):
Click Start, click All Programs, click Accessories, click Run, type secpol.msc in the Open text box, and then click OK.
From the Local Security Settings console tree, click Local Policies, and then click Security Options.
Scroll down and double-click User Account Control: Detect application installations and prompt for elevation.
Select the Disabled option, and then click OK.
Close the Local Security Settings window.
You may need to re-logon for the setting to take effect.
Help!!!
I am trying to create a windows ami that when launched (need multiple [20] live servers to be launched for short durations at short notice) auto logon and run an .exe application (unfortunately I can not get the app to run as a service). Also machine names must be unique.
Problem works fine pre sysprep, but when I launch instance from the ami it fails to logon as the machine name has obviously changed from the original machine image.
The only way I have managed it is to not sysprep, take an ami, then log onto the new machine when launched and manually change the machine name, and set the autologon sysinternal tool. THis is not ideal as the end user is not technical and time constraints do not allow for this action to be performed efficiently.
I am at my wits end! Your help is very much appreciated.
I am aware this is a very old question. Google, nonetheless, led me to this question when I faced a similar issue. I did the following to solve my issue.
Customize an instance to your liking. The AMI will be created using this instance.
Create a new user account with admin privileges. This is needed as Sysprep\Ec2ConfigService will reset the Administrator password. Add this user to the group Remote Desktop Users, so you can RDP using this user account.
Edit EC2's Sysprep answer file to enable auto-logon.
Append the following to component node named Microsoft-Windows-Shell-Setup in the file C:\Program Files\Amazon\Ec2ConfigService\sysprep2008.xml
.
<AutoLogon>
<Password>
<Value>NewUser'sPassword</Value>
<PlainText>true</PlainText>
</Password>
<Username>NewUser'sName</Username>
<Enabled>true</Enabled>
<LogonCount>999</LogonCount>
</AutoLogon>
The resulting file should look like the snippet below. I have removed the parts not necessary for this answer.
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<!-- snip -->
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- snip -->
<AutoLogon>
<Password>
<Value>NewUser'sPassword</Value>
<PlainText>true</PlainText>
</Password>
<Username>NewUser'sName</Username>
<Enabled>true</Enabled>
<LogonCount>999</LogonCount>
</AutoLogon>
</component>
</settings>
<!-- snip -->
</unattend>
Next we edit the EC2ConfigService settings.
In the file "C:\Program Files\Amazon\Ec2ConfigService\Settings\BundleConfig.xml", ensure the value for SetPasswordAfterSysprep is Yes.
In the file, "C:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml", ensure the state node has the value Enabled for the plugin Ec2SetPassword.
In the file, "C:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml", ensure the value for RemoveCredentialsfromSysprepOnStartup is false.
You are already launching an exe on logon. Using the same mechanism, also launch a script that will delete the AutoLogonCount setting from the registry. This step is important, else after 999 (as per the example mentioned above) logins, the autologon will stop.
.
powershell.exe -command { Remove-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\winlogon" -Name AutoLogonCount -Force -ErrorAction 0 }
Now we can start Sysprep. Either use the UI or the following command.
.
%ProgramFiles%\Amazon\Ec2ConfigService\ec2config.exe -sysprep
Any instance launched using an AMI created from the above instance, retains the auto-logon behaviour indefinitely.
Don't know if this software can help, look at LogonExpert and its satilite articles:
1) Deployment
2) Commmand line/vbscript control
3) Scheduling
Im trying to get the Appfabric Cache running with IIS7 using an MVC asp.net project.
Using the XML-configuration provider in a shared directory.
I can access the AppFabric Cache when using the cassini webserver (My local administrator account).
When using IIS ("ApplicationPoolIdentity") I can not get it to work, and I get the standard message that it can not connect to the host.
I have tried to grant access to different users (APPPOOL\name, NETWORKservice, Everyone and so on) to the cache but I get this null exception everytime.
PS C:> Grant-CacheAllowedClientAccount "Everyone"
Grant-CacheAllowedClientAccount : Object reference not set to an instance of an
object.
At line:1 char:32
+ Grant-CacheAllowedClientAccount <<<< Everyone
+ CategoryInfo : NotSpecified: (:) [Grant-CacheAllowedClientAccou
nt], NullReferenceException + FullyQualifiedErrorId :
System.NullReferenceException,Microsoft.Applicat
ionServer.Caching.Commands.GrantCacheAllowedClientAccountCommand
I have two almost identical developer machines using win7 x64 (domain connected) where the error is the same on both computers.
But at my home computer (which is not domain connected) it works as expected with the same installation settings, same shared directory.
What I have done so far:
Reinstalled appfabric cache twice
Reconfigured the Cache to use another directory
Set configuration directory share, full access to Everyone
Security permissions for the directory, full access to Everyone.
Is there a way to go deeper and debug this error message or a solution to fix it?
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="dataCache"
type="Microsoft.ApplicationServer.Caching.DataCacheSection,
Microsoft.ApplicationServer.Caching.Core" />
</configSections>
<dataCache size="Small">
<caches>
<cache consistency="StrongConsistency" name="default" minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
</caches>
<hosts>
<host replicationPort="22236" arbitrationPort="22235" clusterPort="22234"
hostId="1556989554" size="3003" leadHost="true" account="DOM\vitcpu7$"
cacheHostName="AppFabricCachingService" name="vitcpu7.office.domain.se"
cachePort="22233" />
</hosts>
<deploymentSettings>
<deploymentMode value="RoutingClient" />
</deploymentSettings>
</dataCache>
</configuration>
It´s because it is setup in a domain environment and the "Remote Registry"-service was not started. Since my home computer in a workgroup, did not need "Remote Registry" started its the combined which AppFabric cache needs this to make most changes in powershell.
More information at msdn social
Agree with Kiteloop, need to start "Remote Registry" and run the "Caching Admin Powershell Windows" as Run as Administrator.
For build in accounts simply use the command in this format
Grant-CacheAllowedClientAccount -Account "DOMAIN1\Server1$"
More at this MSDN link http://msdn.microsoft.com/en-us/library/ff921012.aspx
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to prevent Vista from requiring elevation on patch.exe?
One of my programs is called "PatchCompiler.exe". It runs in the console. Or rather, it doesn't run, because Windows 7 treats an EXE file differently if it has "Patch" anywhere in its name, requiring elevated permission ("Do you want to allow the following program from an unknown publisher to make changes to this computer?"). Even if I grant this permission, it runs in an ephemeral console that disappears before I can see its output.
Yes, I know I could fix this problem by renaming my program. But it compiles patches...
Does anybody know how to change this annoying behaviour?
Edited to add: Just to make myself clear: I don't want my program to run with elevated status! Who knows what bugs I left in it?
Attach an application manifest that includes
<requestedExecutionLevel level="asInvoker" uiAccess="true"/>
OK, I got it working, thanks to phihag's answer. It didn't work straight from the box, so here's what I did:
Create a file Manifest.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Create a resource file, Manifest.rc:
#include "winuser.h"
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST Manifest.xml
Compile the resource file to create Manifest.res:
windres --input Manifest.rc --output Manifest.res --output-format=coff
Add Manifest.res to the link:
g++ -Wall -oPatchCompiler PatchCompiler.cpp Manifest.res
And that's it!
As far as I know, that's a feature, not a bug. The idea is to make sure that you really really want to run a patch on your computer.
Also, as far as I know, there isn't a nice way to solve the problem. You could disable the UAC or rename the program.
As far as the console is concerned, that's a programming question and there's not enough information to help you. You should simply add a check which will wait until you do something before closing the program. A typical example of that is reading a character from terminal at the end.
You could start an elevated command prompt which shouldn't bring the UAC warning when starting the program and should stay on after the program is completed.