Legacy application installations

  • Thread starter Thread starter Mike_g
  • Start date Start date
M

Mike_g

We have a number of applications that we have built installation packages to
minimize the questions asked of the installer. These are typically .bat or
..cmd files that call the Windows Installer or setup.exe with a set of
paramaters.

With the Vista security model most of these fail to execute successfully.
We have tried to run these with the "run as administrator" but that does not
help.

One simple example is a bat file that just calls msiexec, which works fine
in XP, but does not in Vista:
msiexec.exe /i "{path to .msi}" /qn /l* "{path to log file}"
If we run the msi directly it works.

Any suggestion would be appreciated.
 
Dear Customer,

Thank you for posting in newsgroup.

According to the description, the issue happens on Windows Vista but not on
Windows XP. If I have any misunderstanding, please feel free to let me know.

Before we move on, I would like to confirm some information with you
firstly.

Information Needed:
======================

1. Did you fail to run the "msiexec" command with the local administrative
right or the ordinary domain user right on the problematic Windows Vista
computer?

2. What is the detailed error message when you fail to execute the
corresponding command on the problematic Windows Vista computer?

Analysis and Suggestion:
========================

As you descript, the simple example can work fine in Windows XP, but not in
Windows Vista. Based on the experience, this may be an UAC compatibility
issue. Many legacy programs will not run in Windows Vista unless we disable
UAC completely. This behavior frequently occurs when one program starts a
second program. For example, programs that have an update feature sometimes
cannot run unless UAC is disabled. We can run the program as an
administrator. However, the update feature tries to start even though it
does not have administrative permissions. When this behavior occurs, UAC
prevents the update feature from starting.

I would like to suggest that you perform the following steps to disable UAC
on the Windows Vista box, and then check if the issue will re-occur.

1. Open the Control Panel from the Start menu and select Classic View.

2. Double-Click User Account

3. Under "Make Changes to Your User Account" click the link labeled "Turn
User Account Control on or off"

4. Click Continue when prompted "Windows needs your permission to continue"

5. Un-select the check box next to "User Account Control (UAC) to help
protect your computer" and then click OK.

6. When prompted top restart your computer select Restart Now

For more information about UAC, please refer to:

Windows User Account Control Step-by-Step Guide
http://technet2.microsoft.com/WindowsVista/en/library/0d75f774-8514-4c9e-ac0
8-4c21f5c6c2d91033.mspx?mfr=true

Hope it helps.

I wait for your reply. Thanks.

David Shen
Microsoft Online Partner Support
 
1. Did you fail to run the "msiexec" command with the local administrative
right or the ordinary domain user right on the problematic Windows Vista
computer?
The batch file was executed with Admin rights. This failed. (note that the
batch file itself contained no commands to elevate rights).

The .msi file was also executed with Admin rights. This worked.


2. What is the detailed error message when you fail to execute the
corresponding command on the problematic
The error message is: No permissions to write to 'All Users'

Note that I believe that the UAC is enforced by Group Policy and therfore I
can not disable it.
 
Dear Customer,

Based on the research of the error message and my test, you use the syntax
/qn which means Quiet mode installation. In this way, the command won't be
aware of the elevation to administrative right. When an application is
installed silently, users are not prompted to elevate right.

Analysis:
===========

When we install the programs applications designed to deploy software, and
most write to system directories and registry keys. These protected system
locations are typically writeable only by administrator users; this
restriction means that standard users do not have sufficient access to
install most programs. Windows Vista detects installation programs and
requests administrator credentials or administrator approval in order to
run with access privileges. Windows Vista also detects update and
un-installation programs. A design goal of UAC is to prevent installations
from being executed without the user's knowledge and explicit consent since
installations write to protected areas of the file system and registry.

Suggestion:
============

In this way, I would like to suggest that you disable the UAC feature via
Group Policy management console on the DC.

1. If you use AD-based GPO, please open Group Policy Management Console
(Start > Run > gpmc.msc) from a Windows Server that is a member of the
domain. In the GPMC window, browse to the required GPO that is linked to
the OU or domain where the Vista computers are located, then edit it.

2. In the Group Policy Editor window, browse to Computer Configuration >
Windows Settings > Security Settings > Local Policies > Security Options.

3. Scroll down and double-click "User Account Control: Run all
administrators in Admin Approval Mode" In Properties dialog box, click
Disabled, and then click OK.

4. Scroll down and double-click "User Account Control: Behavior of the
elevation prompt for administrators in Admin Approval Mode", select
"Elevate without prompting" and then click OK.

5. Scroll down and double-click "User Account Control: Detect application
installations and prompt for elevation", click Disabled, and then click OK.

6. Scroll down and double-click "User Account Control: Only elevate
UIAccess applications that are installed in secure locations", click
Disabled, and then click OK.

7. If possible, you may right click the .bat file and click "Run as
Administrator" to manually elevate the permission.

Afterwards, you may check if the issue will re-ocurr.

Hope the issue will be resolved soon.

David Shen
Microsoft Online Partner Support
 
I will try changing the /qn option to see if that helps.
I do not have GPO rights so I can not make the suggested changes in the GPO
editor.
- Mike
 
Hello Mike,

Thanks for the reply.

For the further research, besides changing the /qn option to see if that
helps, you may also try with the following steps to check if the batch file
can work on Windows Vista box.

1. Find and locate the batch file that contain the corresponding
msiexec.exe command line on the Windows Vista box.

2. Right-click on the batch file and select "Run as administrator".

3. When the system popup with "User Account Control" dialog box, if
possible, please just input the domain admin's credential of local
administrator's credential to elevate the permission to run the batch file.

Hope it helps.

David Shen
Microsoft Online Partner Support
 
Dear Customer,

I am just writing to see how everything is going. If you have any updates
or need any further assistance on this issue, please feel free to let me
know. I am glad to be of assistance.

David Shen
Microsoft Online Partner Support
 
Sorry it took so long to get back to you.
In short, we have not found a way to use the command file to start the
install.
Running (with admin) the .msi is the only way it works correctly.
Details follow:
------------------------------
Well I confirmed the symptoms I saw before, if you use /qn the bat file
fails to inherit permissions; /qb gets the permissions but will not process
all the possible input screens, such as whether or not to post a desktop icon
in this case it defaulted to not, who know what screens would be bypassed for
other apps; /qr will install the app but for some reason will not process all
the msi settings; /q does not have permission to even start.
 
Hello Mike,

Thanks for the reply.

Since you don't have permission to modify the GPO settings, I would like to
suggest that you disable UAC on each client manually by performing the
following steps:

1. Logon the system as administrator

2. Open "Control Panel\User Accounts", and then choose "Turn user Account
Control on or off"

3. Un-select the Checkbox of "Use User Account Control (UAC) to help
protect your computer"

4. Click on Ok and then reboot the computers.

5. Then you may the command line to check if you can install the msi file
with non-administrator account.

Hope it helps.

David Shen
Microsoft Online Partner Support
 
David,
We are testing our processes to see what we need to modify to migrate to
Vista.
In a production, we are not allowed to turn off UAC.
The installer does have admin privileges on the individual pc, but the
installation only works properly if we run the MSI directly, not if we run
the command file. And the only thing the command file does is to call msiexec
with the appropriate parameters.
- Mike
 
Hello Mike,

Thanks for your reply.

According to the research, here is some information just for your reference.

Analysis and Suggestion:
======================

Installation programs are applications designed to deploy software, and
most write to system directories and registry keys. These protected system
locations are typically writeable only by administrator users; this
restriction means that standard users do not have sufficient access to
install most programs. Windows Vista heuristically detects installation
programs and requests administrator credentials or administrator approval
in order to run with access privileges.

Windows Vista heuristically detects updater and un-installation programs. A
design goal of UAC is to prevent installations from being executed without
the user's knowledge and explicit consent since installations write to
protected areas of the file system and registry.

This is reason that we suggested you disabling UAC on Vista clients. In
this way, we need to disable the UAC feature on Windows Vista box so that
the MSI file can be installed successfully.

For more information, please refer to:

Override Installer Detection using Manifests, the following articles
explain:
http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b70
e-b18ff918c2811033.mspx?mfr=true
(Please look at the section on Installer Detection Technology)

I understand that you want to keep UAC enabled on production environment.
If you don't want to disable the UAC feature on Windows Vista box, another
option is that you may customize a manifest file in the same location as
the executable, with the same name as the executable with .manifest
appended to the filename.

The following link explains:
http://msdn.technetweb3.orcsweb.com/heaths/rss.aspx?Tags=Installation/VS+200
5+SP1/UAC&AndTags=1

If you want to detailed support on customizing the manifest file, you may
initial a new post in our MSDN forum.

For your convenience, I have list the link to MSDN forum as followed.

http://forums.microsoft.com/MSDN/default.aspx?SiteID=1

Hope the issue will be resolved soon.

David Shen
Microsoft Online Partner Support
 
Thanks, David.
We will be looking into the references you supplied and I will get back to
you.
- Mike
 
Hello Mike,

I haven't received any responses from you lately, and I am wondering if I
can provide further assistance or if the issue has been resolved.

David Shen
Microsoft Online Partner Support
 
David,
Thanks for checking back. I did look into your suggestions and it does not
appear to be of any help. As I understand it my only real choice is to make a
..manifest file for the "executable". However the files are arbortext.msi and
testInstall-ArborText_5-3.cmd.
I copied the exact text and created .manifest files for each of the above.
Installation still fails.
- Mike
 
David,

I took one more shot at it.
I had previously tested by running the .cmd file (using "Run as
Administrator") which did not work.

So I started a "Run as Administrator" cmd window. I then tried to cd to the
mapped network drive where the install package is stored. No go.
So I then mapped a drive (using the same drive letter as is mapped in
Windows Explorer) to the network share. I then cd'd to the appropriate place
on the mapped drive and ran the command file.
This did install the software, but we need to do some testing if all
installed ok.

If this worked, this leads to a follow-on question. If "Run as
Administrator" removes access to mapped drives, what is the solution since
all of our installations run from a mapped drive?
- Mike
 
If this worked, this leads to a follow-on question. If "Run as
Administrator" removes access to mapped drives, what is the solution since
all of our installations run from a mapped drive?
Click to expand...

How are the original drive mappings being done? When you use "runas" you're
getting a command prompt that is running in a new security context, and
essentially a new user profile. Anything that is available in the security
context of the currently logged in user, such as mapped drives, will not be
available in the new security context.
 
Paul,
In our normal process the drives are mapped during login.

Hopefully there is a way to fix this. I had thought that "Run as
Administrator" just eleveted the current user's privileges (like the on VMS
model).
- Mike
 
In our normal process the drives are mapped during login.

Hopefully there is a way to fix this. I had thought that "Run as
Administrator" just eleveted the current user's privileges (like the on VMS
model).
Click to expand...

No, that's not the way runas works. Why not map the drives required in the
batch file itself?
 
Catch 22.
The batch file is on the mapped drive, which is not accesible until you map
it.
Recall that just trying the "Run as Administrator" on the cmd file fails.
I had to start a cmd.exe window (with "Run as Administrator") and the map
the drive within the session.
- Mike
 
Hi Mike,

I agree with Paul, we cannot "Run as Administrator" of the batch file in
the mapped driver session since it only elevate the current local user’s
privilege not the remote user's privilege. However, it is better for us to
customize a batch file to map the drives locally.

For your convenience, I have list the following link to TechNet Script
Center which provides some example of the scripts, just for your reference:

TechNet Script Center
http://www.microsoft.com/technet/scriptcenter/default.mspx

Hope the issue will be resolved soon.
David Shen
Microsoft Online Partner Support
 
Back
Top