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/Window...-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/...llation/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

"David Shen [MSFT]" wrote:

> 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/Window...-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/...llation/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
>
>

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 Shen [MSFT]" wrote:

> 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,

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" wrote:

> 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 Shen [MSFT]" wrote:
>

> > 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
> >
> >

On Tue, 8 Jul 2008 03:06:13 -0700, Mike_g wrote:

> 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?

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 - Identity Lifecycle Manager
http://www.identit.ca
Computer programmers do it byte by byte.

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

"Paul Adare - MVP" wrote:

> On Tue, 8 Jul 2008 03:06:13 -0700, Mike_g wrote:
>

> > 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?

>
> 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 - Identity Lifecycle Manager
> http://www.identit.ca
> Computer programmers do it byte by byte.
>

On Tue, 8 Jul 2008 03:30:13 -0700, Mike_g wrote:

> 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).

No, that's not the way runas works. Why not map the drives required in the
batch file itself?

--
Paul Adare
MVP - Identity Lifecycle Manager
http://www.identit.ca
One picture is worth 128K words.

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

"Paul Adare - MVP" wrote:

> On Tue, 8 Jul 2008 03:30:13 -0700, Mike_g wrote:
>

> > 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).

>
> No, that's not the way runas works. Why not map the drives required in the
> batch file itself?
>
> --
> Paul Adare
> MVP - Identity Lifecycle Manager
> http://www.identit.ca
> One picture is worth 128K words.
>

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/scr...r/default.mspx

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