install per-machine and Privileged and AdminUser properties

  • Thread starter Thread starter Viviana Vc
  • Start date Start date
V

Viviana Vc

Hi all,

My package has to install the product per-machine (not per-user). So I
have to set into the package the ALLUSERS property on 1.

Q1: In this conditions does make any sense to check at Launch conditions
for the Privileged property or makes more sense to right away check for
AdminUser? In other words: if the current user is a restrictive user
that has elevated privileges, meaning Privileged property is set, can he
install a package that has to be installed per-machine?

Q2: If the answer is "no, it doesn't make sense. better check directly
for AdminUser", means that my application is nodeployable to
non-Administrator users, which is ok, but then is there a way in huge
companies for a system administrator to really make an automatic
mass-deploy for all the machines in the company?

Thank you,
Viv
 
If Privileged is set, the install can proceed as if the user were an
AdminUser, so it makes sense to check Privileged, so the answer to 1 is yes.
 
Thank you Phil. I wasn't sure because:

a) on
http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q105063
is written:
"ALLUSERS=1: This installs the package for all the users on the machine
provided the user has administrative privileges. If the current user
running the setup on Windows NT or 2000 does not have administrative
privileges, then the setup errors out and aborts."
It's talking only about "administrative privileges" not "administrative
privileges and users with elevated privileges".

b) on
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/allusers.asp
in the table instead of "Administrator access privileges." should be
"Administrator access privileges and user with elevated privileges"

Thank you,
Viv
 
Dear Setup Developer,

Avatar Software GmbH is pleased to announce the release of MSIStudio 3.1, a
set of Windows Installer authoring tools which enables developers and system
administrators to easily build reliable MSI setup packages, upgrades,
patches, merge modules, and much more.
Additional tools allow packages to be debugged and analysed. MSIStudio runs
on Windows 2000/XP, and the install packages it creates run on all Microsoft
Windows 9x/ME/NT/2k/XP operating systems.

If you are developing MSI based installations on the Windows platform you
cannot afford not to evaluate MSIStudio. It provides the most feature rich
and easy to use development environment for dealing with MSI installations
currently on the market. It is the quickest way to earning coveted Windows
2000 Logo compatibility for the installation side of your software.

Read more details about MSIStudio here:
www.avatarsoftware.net

Download a 30 day evaluation copy of MSIStudio from here:
www.avatarsoftware.net/Evaluation.asp

MSIStudio is designed to take the pain out of developing MSI based setup
packages. It provides an easy to use layer over the complex MSI interface,
exposing the complete range of functionality to MSI setup authors through a
clear and easy to use interface. Wizards are also provided to kickstart
project creation and to perform complex tasks, such as creating transforms,
perfroming validation and creating shortcuts.

MSIStudio 3.1 provides major enhancements over previous versions including:

Support for .NET Framework 2.0
Installation of Windows Installer 3.1
Advanced visuals for setup.exe projects.
Ability to add version information to setup.exe bootstrapper.
Update graphics and look and feel

and much more....

NB Evaluation licenses require a valid Email address.

Avatar Software
 
Viviana,

It seems between your many posts it is your desired to get to restrict your
installation to a per-machine install, no matter what.

You should realized that Group Policy is capable of deploying Per-User
Managed packages which means it would be a per-user and Privileged would be
set to 1. This happens if software is either Published or Assigned to a
user.

Orca.msi has ALLUSERS=1 and I don't think it breaks any MSI rules. If you
set ALLUSERS=1. The Advertise sequence is run when an administrator
configures a package to be run via group policy - so I imagine there are
tricks to determine if that is being done per-user and generate an error
message saying the package does not support per-user installs.

D.
___________________________
Darwin J Sanoy
Principal Consultant and Trainer
DesktopEngineer.com
DesktopEngineerTraining.com
 
Hi Darwin,

Thx for your answer. My answers are inline ...
It seems between your many posts it is your desired to get to restrict your
installation to a per-machine install, no matter what.
Click to expand...

This is correct. My application is like a firewall application that just
can't be installed on a per-user basis. It's designed to be per-machine.
You should realized that Group Policy is capable of deploying Per-User
Managed packages which means it would be a per-user and Privileged would be
set to 1. This happens if software is either Published or Assigned to a
user.
Click to expand...

Unfortunately I'm not familiar with the ways the system administrators
are deploying packages on all machines from a big company this is why
I'm not so sure if I don't get into troubles with some issues.
Orca.msi has ALLUSERS=1 and I don't think it breaks any MSI rules. If you
set ALLUSERS=1.
Click to expand...

Yes, I just checked and indeed it's having it set to 1.
The Advertise sequence is run when an administrator
configures a package to be run via group policy - so I imagine there are
tricks to determine if that is being done per-user and generate an error
message saying the package does not support per-user installs.
Click to expand...

This is something I don't understand. If I set ALLUSERS=1 shouldn't be
the windows installer smart enough to warn or not work if somebody tries
to install the package per-user?
What happens if I set the ALLUSERS on 1 and the admin tries a per-user
deployment?

Thanks,
Viv
 
Back
Top