Software Deployment

It won't install if there is a user logged on to the system that lacks Admin privs. Runs fine with no user logged on or if the logged on user has Admin privs. Guess Macromedia will be joining Apple in that special place in hell reserved for companies that convince developers to buy tools to put content on their webpages, but that in turn refuse to release functioning installers for corporate types to distribute. This is getting old REALLY fast!

--Toby Ovod-Everett

Thanks for that. I got all excited thinking that I could just set SMS to only install when not logged in, but that doesn't appear to have worked either. So is there really no way to run this through SMS then? I'm a tech and my knowledge of packaging is limited to what I've discovered over the last 2 weeks playing with Installshield, so if anyone could provide a semi-dumbed down set of instructions that would be fantastic. If not, I'll even have a go at getting some complicated instructions to work.

Thanks once again.
Brett

For Flash, I'm using:

* First, uninstall the old version with job set to reboot:
MsiExec /X "{6815FCDD-401D-481E-BA88-31B4754C2B46}" REBOOT="R" /QN

* The reboot above isn't technically necessary, but it helps ensure the user isn't logged on soon after the job finishes!

* Then, running as LocalSystem, but with "Set Program can run" set to "Only when no user is logged on" :
%SystemRoot%\system32\msg.exe * /TIME:0 "Flash 8.0.24.0 is being installed. DO NOT LOGON TO THIS COMPUTER!!!! When the install finishes, the computer will automatically reboot, at which point it will be safe to log in."
%SystemRoot%\system32\msg.exe * /TIME:0 "Flash 8.0.24.0 is being installed. DO NOT LOGON TO THIS COMPUTER!!!! When the install finishes, the computer will automatically reboot, at which point it will be safe to log in."
msiexec /i "<path_to_MSI>\install_flash_player_active_x.msi" ALLUSERS=1 REBOOT="R" /QN

* Note that there is a small window between the job starting and those msg.exe commands while the user might log on. That's life. Re-runs seem to work. I do the trailing reboot because it's the easiest way to terminate those msg windows so that the user knows when it's safe to log on.

For Shockwave, I'm using:
<path_to_EXE>\sw_lic_full_installer.exe /s
KillIE.pl

Note that KillIE.pl is just a Perl script that does something like:
use strict;

use Win32::OLE;
use Win32::OLE::Enum;
use Win32::OLE::Variant;

my $loc = Win32::OLE->new('WbemScripting.SWbemLocator') or die "Unable to create WbemScripting.SWbemLocator object.\n";
my $cimv2 = $loc->ConnectServer(undef, 'root\\cimv2') or die "Unable to connect to root\\cimv2 namespace.\n";
my(@ie) = grep {lc($_->{Name}) eq 'iexplore.exe' && $_->{CommandLine} =~ /macromedia/} &my_enum($cimv2->ExecQuery("SELECT * FROM Win32_Process", 'WQL', 0x20), 1);
foreach my $process (@ie) {
print "Killing $process->{Handle}\n";
$process->Terminate();
}

sub my_enum {
my($obj, $suppress_errors) = @_;

return(Win32::OLE::Enum->All($obj)) if defined $obj;
return() if $suppress_errors;
die Win32::OLE->LastError();
}

You could rewrite that in VBScript fairly easily - basically I use WMI/WBEM to hunt for any processes that have the Name "iexplore.exe" and that have "macromedia" somewhere in their CommandLine and then I kill 'em. No need for a reboot in the Shockwave code. It does get unhappy if the user happens to be using IE with Shockwave running, but c'est la vie!

--Toby Ovod-Everett

Once again, thanks for your help Toby,

I've now got it working, based on yours and others posts. Incase anyone is interested, this is what I did. I modified the shockwave msi using ORCA to change Custom Action 35 in the CustomAction Table from "[%APPDATA]\Macromedia\Shockwave Player" to "[%TEMP]\Macromedia\Shockwave Player" and added a key in the Property Table of ALLUSERS=1. This modified msi is able to be run from SMS 2003 using the command line msiexec.exe /i "edited filename.msi" /qn and with a setting of "whether or not user is logged in".

Trying to use ORCA to add the ALLUSERS=1 key failed on the flash msi for some reason, so I'm installing it using msiexec.exe /i "flash installer.msi" ALLUSERS=1 /qn. Again, this installs whether or not someone is logged in.

I haven't looked at the whole Internet Explorer running problem, but will consider that when/if I need to. One thing I found that was very useful, was the ability to run tests using the SYSTEM account so that I didn't have to wait for the SMS advertisement to be picked up each time I changed something. You can run "at 19:30 /interactive cmd.exe" from the command prompt with the time set to about one minute into the future (in 24 hour time). When the time is reached, a new command prompt will open running as the SYSTEM account. Then, just run the command you would have run from SMS and you can see how it would have behaved ... in about 5 minutes when the advertisement would have been recieved.

Hope that saves someone some frustration.

Brett

Just out of curiosity, do your users have local Admin or not? I couldn't get Flash to install successfully when there was a user logged in if (and only if) the user didn't have local Admin privs. If there was no one logged in or if the logged on user had local Admin privs, then it would run successfully.

--Toby Ovod-Everett

Glad you asked, because I'd forgotten to test that minor point :/ . We run without admin rights for general users, and it does appear to have worked.

Brett

Weird. When I run the MSI as localsystem while logged in as a user I get a 1603 error. The zone in the logs that seems to point to where things start to go wrong is:

Action start 15:46:45: ISStartup.
1: The InstallScript engine version currently installed on this machine is adequate.
MSI (s) (FC!A0) [15:46:45:451]: PROPERTY CHANGE: Adding ISStartupEvent property. Its value is 'E4645435'.
1: Event 'E4645435' is created
1: GetInstallDriver, Can not find InstallDriver in ROT table, Return Code = 0x800401e3
1: {5E8A1B08-0FBD-4543-9646-F2C2D0D05750}
1: Extract supporting files
1: Failed to extract _IsUser.dll, Ignore it.
1: ISMsiServerStartup Failure, Failed to Initialize script support, Error = 0x80070006
1: MsiServerStartup failed. Abort installation.
Action ended 15:46:48: ISMsiServerStartup. Return value 1603.
MSI (s) (FC:F0) [15:46:48:371]: Doing action: ISCleanUpFatalExit
Action ended 15:46:48: ISStartup. Return value 3.
MSI (s) (FC:4C) [15:46:48:559]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI1C.tmp, Entrypoint: CleanUp
Action start 15:46:48: ISCleanUpFatalExit.

--Toby Ovod-Everett

Not sure what the difference is then sorry and that error report means nothing to me, so can't help you there either. You're welcome to the MSIs I'm using if you want to give them a try, but they're just the lastest downloaded from Adobe/Macromedia.

I'm guessing we're using the same MSI (install_flash_player_active_x.msi, 4625408 bytes, md5sum of ada1556768e9adea323991505da9165f), so I doubt that's the difference. Mostly I'm just curious as to why we're getting the different behavior because it might prove a problem for others and if we can figure out what the difference is, then others have a better chance of knowing whether they're likely to stumble into it or not.

The only thing I can think of is that it looks like it's blowing up in one of the InstallShield driver modules, so perhaps you have a newer version of that driver module already installed (probably by another installer that relies upon it as well) on the machines you support and that newer version doesn't trigger the problems.

Here are the results of running filever against "C:\Program Files\Common Files\InstallShield\Driver\10\Intel 32":
--a-- W32i APP ENU 10.0.0.159 shp 761,856 03-20-2006 idriver.exe
--a-- W32i APP ENU 10.0.0.159 shp 761,856 04-18-2004 idriver2.exe
--a-- W32i APP ENU 10.0.0.159 shp 180,224 03-20-2006 igdicnv.dll
--a-- W32i APP ENU 10.0.0.159 shp 262,144 03-20-2006 iscrcnv.dll
--a-- W32i APP ENU 10.0.0.159 shp 409,600 03-20-2006 isrt.dll
--a-- W32i APP ENU 10.0.0.159 shp 172,032 03-20-2006 iusercnv.dll
--a-- W32i APP ENU 10.0.0.159 shp 32,768 03-20-2006 objpscnv.dll
--a-- W32i APP ENU 10.0.0.159 dbg 540,772 03-20-2006 _isres1033.dll


--Toby Ovod-Everett

I've just run the test successfully on a Windows 2000 PC as well. So, it's working for me on both Windows 2000 and Windows XP. Both are updated with the latest updates from Microsoft, and have Trend Micro AV and SMS advanced client installed. My 2000 PC also has InstallShield 7 demo installed, but the XP is basically a clean build.

I don't seem to have that directory though on my PCs. The 2000 PC had C:\Program Files\Common Files\InstallShield\ but no driver folder, and the XP PC had no InstallShield folder at all. Is there anything else I can check for you?

Brett

Weird, weird, weird. Does it leave that folder in place after it installs flash?

--Toby Ovod-Everett

Sorry, which folder were you meaning? Was it the "C:\Program Files\Common Files\InstallShield\" folder? If so, I've just reinstalled onto the XP pc and it appears that the folder does not exist before or after the install of Flash. I suspect it only exists on the 2000 PC because it's got the InstallShield AdminStudio product installed.

Yeah - that "C:\Program Files\Common Files\InstallShield\ . . ." folder. What is the file size on the .msi file you're using to install Flash?

--Toby Ovod-Everett

After much discussion and some experimentation on both of our sides, I have found an explanation.

The default file permissions under Windows XP on C:\WINDOWS\TEMP are:
Path Trustee Mask Inheritance Desc
C:\WINDOWS\TEMP INHERITANCE_BLOCKED DB
C:\WINDOWS\TEMP BUILTIN\Users FILE_APPEND_DATA|FILE_EXECUTE|FILE_WRITE_DATA|SYNCHRONIZE CONTAINER_INHERIT_ACE DX
C:\WINDOWS\TEMP "BUILTIN\Power Users" MODIFY THIS_FOLDER_ONLY DX
C:\WINDOWS\TEMP "BUILTIN\Power Users" DELETE|GENERIC_EXECUTE|GENERIC_READ|GENERIC_WRITE SUBFOLDERS_AND_FILES_ONLY DX
C:\WINDOWS\TEMP BUILTIN\Administrators FULL THIS_FOLDER_ONLY DX
C:\WINDOWS\TEMP BUILTIN\Administrators GENERIC_ALL SUBFOLDERS_AND_FILES_ONLY DX
C:\WINDOWS\TEMP "NT AUTHORITY\SYSTEM" FULL THIS_FOLDER_ONLY DX
C:\WINDOWS\TEMP "NT AUTHORITY\SYSTEM" GENERIC_ALL SUBFOLDERS_AND_FILES_ONLY DX
C:\WINDOWS\TEMP BUILTIN\Administrators FULL THIS_FOLDER_ONLY DX
C:\WINDOWS\TEMP "CREATOR OWNER" GENERIC_ALL SUBFOLDERS_AND_FILES_ONLY DX
C:\WINDOWS\TEMP "NT AUTHORITY\NETWORK SERVICE" DELETE|FILE_READ_DATA|SYNCHRONIZE FULL_INHERIT DX

When the 8.0.24.0 Flash MSI runs as LocalSystem, it extracts some files into a directory under C:\WINDOWS\TEMP (named with a GUID). It then switches to the currently logged-on user account and attempts to do some things (not sure what) as that account in which it attempts to access those files it extracted into that subdirectory of C:\WINDOWS\TEMP. This, of course, it cannot do, because Microsoft wisely and craftily set the permissions on C:\WINDOWS\TEMP so that anyone can create files and folders therein, but so that access to those files and folders are restricted to the account that created them.

The workaround is either to avoid running the MSI while there is a user logged on that lacks admin privs or to adjust the permissions on C:\WINDOWS\TEMP before and after running the MSI like so:

PermChg.pl -q -a="BUILTIN\Users:M" "%SystemRoot%\TEMP"
-msiexec line-
PermChg.pl -q -a="BUILTIN\Users:FILE_APPEND_DATA|FILE_EXECUTE|FILE_WRITE_DATA|SYNCHRONIZE(CONTAINER_INHERIT_ACE)" "%SystemRoot%\TEMP"

That's assuming that you have ActivePerl and Win32::Security installed. If you don't, you can substitute whatever permissions modification scheme you prefer. Modify may be overkill - it may be adequate to grant Read+Execute permissions, but at this point I don't feel like testing any more!

--Toby Ovod-Everett