Legacy application installations

Discussion in 'Windows Vista Security' started by Mike_g, Jun 4, 2008.

  1. Mike_g

    Mike_g Guest

    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.
     
    Mike_g, Jun 4, 2008
    #1
    1. Advertisements

  2. 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
     
    David Shen [MSFT], Jun 5, 2008
    #2
    1. Advertisements

  3. Mike_g

    Mike_g Guest

    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.
     
    Mike_g, Jun 5, 2008
    #3
  4. 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
     
    David Shen [MSFT], Jun 6, 2008
    #4
  5. Mike_g

    Mike_g Guest

    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
     
    Mike_g, Jun 6, 2008
    #5
  6. 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
     
    David Shen [MSFT], Jun 9, 2008
    #6
  7. 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
     
    David Shen [MSFT], Jun 11, 2008
    #7
  8. Mike_g

    Mike_g Guest

    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.
     
    Mike_g, Jun 26, 2008
    #8
  9. 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 Shen [MSFT], Jun 30, 2008
    #9
  10. Mike_g

    Mike_g Guest

    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
     
    Mike_g, Jun 30, 2008
    #10
  11. 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
     
    David Shen [MSFT], Jul 3, 2008
    #11
  12. Mike_g

    Mike_g Guest

    Thanks, David.
    We will be looking into the references you supplied and I will get back to
    you.
    - Mike
     
    Mike_g, Jul 3, 2008
    #12
  13. 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 Shen [MSFT], Jul 8, 2008
    #13
  14. Mike_g

    Mike_g Guest

    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
     
    Mike_g, Jul 8, 2008
    #14
  15. Mike_g

    Mike_g Guest

    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
     
    Mike_g, Jul 8, 2008
    #15
  16. 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 Adare - MVP, Jul 8, 2008
    #16
  17. Mike_g

    Mike_g Guest

    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
     
    Mike_g, Jul 8, 2008
    #17
  18. No, that's not the way runas works. Why not map the drives required in the
    batch file itself?
     
    Paul Adare - MVP, Jul 8, 2008
    #18
  19. Mike_g

    Mike_g Guest

    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
     
    Mike_g, Jul 8, 2008
    #19
  20. 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
     
    David Shen [MSFT], Jul 16, 2008
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.