Run shortcut as administrator - installshield

In InstallShield 2015 Premier , how to set a shortcut created for an EXE to have ability of Run As Administrator. I have searched every corner in InstallShield, but not find option I need
Thanks

There is no front-end option. However, you can create a registry entry in your project to set up the following:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\yourapp.EXE"="~ RUNASADMIN"
It may or may not accept [INSTALLDIR] variable, if it does not, you can create registry entry using InstallScript.
Alternatively, you can embed application manifest into your application itself, in which case you won't need to worry about setting admin rights in IS.

Related

How do I get my application to run with administrator rights automatically?

I've made a console application that is supposed to update some registry entries so that I can access 32 bit COM components from a 64 bit application. If I have admin rights, it works great, but I can't seem to get the application run with admin rights out of the box.
This is what I've done.
Create a Windows Console Application.
Add my code.
Right click on my project and select Properties.
Navigate to Configuration Properties > Linker > Manifest File > UAC Execution Level and set to requireAdministrator (/level='requireAdministrator').
It took a lot to figure out this because all of the info on the web is for Visual Studio 2010 or earlier which required manually creating an XML manifest file and conflicts with the auto generated one that this creates.
However, this doesn't seem to be enough to get it to run as an admin. It is a real PITA that this information isn't made easily findable. Is there some other step that I am missing? Something like a signing process?
Turns out it is how this mini application is run.
From my main programme, using ShellExecute() or ShellExecuteEx() with the "runas" verb will allow running of this executable with administrator privileges without popping up a UAC dialog.
Running this from the command line however, will result in this mini app being executed in the user's security context, which is what I was doing.

team foundation server multiple check outs disabled but still possible

I use Team Foundation Server for Source Control and in my Visual Studio I unckeckd the Option: "Multiple Check Out".
But when I check out a file and modify it another user can still check out the same file and also modify it.
What went wrong??
If you have to look at this issue then you are probably not checking in enough. Its a workflow and not tool change that is required.
TFS only supports the single checkout model if all users are using Server Workspaces. The default changed in 2012 to Local Workspaces which does not support this.
https://msdn.microsoft.com/en-us/library/ms181383.aspx
Check out the MSDN documentation for how to change workspace modes.

Is there a way to reset IIS 7.5 to factory settings?

I modified a lot of options in IIS, and would like to reset its settings to default.
I already tried installing/reinstalling it. After the reinstall, it still had the site I created. It was still breaking on the setting I made to the DefaultWebSite.
People suggested uninstalling Windows Process Activation Service first, but it seems like it wasn't installed anyway, so I can't really uninstall it.
How can I reset this installation of IIS back to an out-of-the-box state?
You need to uninstall IIS (Internet Information Services) but the key thing here is to make sure you uninstall the Windows Process Activation Service or otherwise your ApplicationHost.config will be still around. When you uninstall WAS then your configuration will be cleaned up and you will truly start with a fresh new IIS (and all data/configuration will be lost).
There are automatic backup under %systemdrive%\inetpub\history but it may not help much if you already made lots of changes.
http://blogs.iis.net/bills/archive/2008/03/24/how-to-backup-restore-iis7-configuration.aspx
You will have to regularly back up manually using appcmd.
If you try to reinstall IIS, please first uninstall IIS and WAS via Add/Remove Programs, and then delete all existing files under C:\inetpub and C:\Windows\system32\inetsrv directories. Then you can install again cleanly.
WARN: beginners on IIS are not recommended to execute the steps above without a full backup of the system. The steps should be executed with caution and good understanding of IIS. If you are not capable of or you have doubt, make sure you open a support case with Microsoft via http://support.microsoft.com and consult.
What worked for me was going to the article someone else had already mentioned, but keying on this piece:
application.config.backup is not created by automatic backup. The backup files are in %systemdrive%\inetpub\history directory. Automatic backup is also a Vista SP1 and above feature. More information can be found in this blog post, http://blogs.iis.net/bills/archive/2008/03/24/how-to-backup-restore-iis7-configuration.aspx
I was able to find backups of my settings from when I had first installed IIS, and just copy and replace the files in the inetsrv\config directory.
Source: http://forums.iis.net/t/1085990.aspx
There is one way that I have used my self. Go to Control Panel\Programs\Turn Windows features on or off then uninstall IIS and all of its components completely. I restart windows but I'm not sure if it's required or not. Then install it again from the same path.
This link has some useful suggestions:
http://forums.iis.net/t/1085990.aspx
It depends on where you have the config settings stored. By default
IIS7 will have all of it's configuration settings stored in a file
called "ApplicationHost.Config". If you have delegation configured
then you will see site/app related config settings getting written to
web.config file for the site/app. With IIS7 on vista there is an
automatica backup file for master configuration is created. This file
is called "application.config.backup" and it resides inside
"C:\Windows\System32\inetsrv\config" You could rename this file to
applicationHost.config and replace it with the applicationHost.config
inside the config folder. IIS7 on server release will have better
configuration back up story, but for now I recommend using APPCMD to
backup/restore your configuration on regualr basis. Example: APPCMD
ADD BACK "MYBACKUP" Another option (really the last option) is to
uninstall/reinstall IIS along with WPAS (Windows Process activation
service).
Resetting IIS
On the computer that is running Microsoft Dynamics NAV Web Server components, open a command prompt as an administrator as follows:
a. From the Start menu, choose All Programs, and then choose Accessories.
b. Right-click Command Prompt, and then choose Run as administrator.
At the command prompt, type the following command to change to the Microsoft.NET\Framework64\v4.0.30319 folder, and then press Enter.
cd\Windows\Microsoft.NET\Framework64\v4.0.30319
At the command prompt, type the following command, and then press Enter.
aspnet_regiis.exe -iru
At the command prompt, type the following command, and then press Enter.
iisreset

Setup project creates extra keys

I have a setup project, its been working nicely for atleast a couple of years. I have recently added a new project to the mix, a winform. I took me a great deal of googling and research to make it work - many thanks to the loads of articles I found during my "adventure".
This new project enables me to right click a file in Explorer and add it to my system. I can install the project fine, files are being added/copied to their rightfull place. Code is fine, does precisely what I told it to.
For some reason the Registry editor and Windows Registration DB does not agree on keys.
Registry editor states I should have HKCR\*\shell\Add to system\command and a string key saying
Name: (Default)
Value: "[TARGETDIR]mySystemAddFileForm "%1"
Sofar so good, yes Windows reg db also believes the path to be right. Yes there is a "but".
For some reason Windows reg db believes there should be a 2nd string key saying
Name: (Default)
Value: null
The Windows takes precedence and messes up my logic (design, code, idea).
If I manually clean this up, I can right click the files just fine and add them to the system. Just to be clear. Yes, Explorer does have a right click option that says "Add to system" and yes after I edit regedit manually it does work when I click it.
Before I changed it to the Registry editor, I had the key generation in the CustomSetupActions but I couldn't make that handle if the user decided to edit the installation folder. From default [programfiles] (c:\Program Files\ .. ) to whatever the user decided at install point.
By Registry editor I mean the one in the Setup project, View/Registry.
How can I tell Windows to stay the f* of my finely tuned code and let me decide what reg keys are created when and where.
Edited: (Standard) to (Default). Windows may translate the (Default) to the local language. Leave it at Default.
Windows Installer can install default values and usually they are not overridden automatically by Windows.
To install a default value with a Visual Studio setup project, make sure that the Name field is empty: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371168(v=vs.85).aspx
This is usually enough. If the value is not as expected after install, try creating a verbose installation log to see what happens during install. Most likely the registry entry is skipped or written somewhere else.

Windows installer security/credential question

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?

Resources