Installing Studio 8 Windows products over a network
This TechNote covers various ways that customers can deploy the Windows versions of certain Adobe products to workstations over a network. These instructions pertain to former Macromedia products that use the Windows Installer (also known as MSI). These include Dreamweaver 8, Flash 8, Fireworks 8 and Contribute 3/3.1, in addition to Studio 8.
The primary intended audience is System Administrators or QA for internal testing. This document approaches network installations from several perspectives:
- Administrative Installations
- Pull type network installations
- Quiet install modes
- Batch routine sample for quiet installs
- Installing patches with batch routines
- Configuring public properties during quiet installs
- Push type network installations
- Perl routine sample for pushing installations
- Implementation considerations
- Testing considerations
- Special considerations for updating Dreamweaver to version 8.0.2
Note: The information in this TechNote applies generically to MSI technology. Not all options have been tested with respect to Contribute 3.x and Studio 8 products. However, system administrators with network installation experience should be able to implement the documented approaches successfully. It is strongly recommended that network installation strategies be exercised in a testing environment prior to implementation in a live environment. Adobe support cannot provide troubleshooting assistance for customized installations. Please refer to the Additional Information section for more MSI resources.
Administrative Installations
An administrative installation is the first step in preparing an MSI installer for deployment over a network. Admin installs have these distinctive characteristics:
- The user interface is noticeably different from a standalone installation.
- CAB files are decompressed into a directory tree that reflects the structure of the msi directory table.
- Digital signatures are removed from the msi file itself.
This last point is important: If the certificate is not removed, the prompt for accepting the certificate will interrupt a quiet installation, rendering it interactive instead of non-interactive.
To invoke an administrative installation, you use the /a command line switch. For example, to invoke the Contribute 3.11 installer in interactive admin mode, you would use this syntax:
msiexec /a "Macromedia_Contribute_3.11.msi"
Note: On some machine configurations, spaces in the msi filename will interfere with invoking the installer from the command line, even with quotes around it. If you run up against this, you can safely rename the msi file to anything you like without spaces, such as "Macromedia_Contribute_3.1.1.msi" in this particular example.
Invoked as shown above, the installer will run though its AdminUISequence, involving the following dialogs. The first dialog is a simple welcome screen, and the next dialog will prompt for the Network location that you wish to install to.
Clicking Next in the Welcome dialog will invoke the Network Location dialog. Clicking Install in this dialog will deploy the admin tree to a network share:
Note: The admin install will only include those files contained within the msi file itself. Other support files required by the installation, such as bootstrap files, msi runtime installers or patches, should be copied to the shared folder by some other means of your choice (manually, with a script, batch file, etc.).
For information on distributing registration and activation files in volume license environments, see Distributing files in volume license environments (TechNote cf33c97f).
Once the admin install is deployed to the shared folder, there are a number of ways that it can be used to install the product onto a workstation: pulled interactive installs from the workstation, non-interactive (aka "quiet") installs from the workstation, or pushed installations using tools such as Active Directory and PSEXEC.
Manually launch the installer on the client
One easy way to pull the installation from an administrative image is to run it manually. This involves sitting at the client machine and launching the installation interactively from the site on which it is being shared. In the example above using Contribute 3.11, you could do this either by double-clicking the bootstrap file or by double-clicking the msi file. The bootstrap file is the recommended one to use, as it will automatically install the required version of the msi runtime first (if needed) before launching the msi file.
There is one caveat: if you've renamed the msi file to avoid command-line problems with spaces in the filename, the bootstrap file will no longer work because it is looking for a specific hard-coded filename. If that's the case, you can always opt to invoke the msi file directly instead.
The main advantage of the manual install method is that you can choose the options desired during the installation, such as the path to which you want the program installed and desired shortcuts.
Launch the installer on the client using "quiet" mode
If you don't need to customize the installation options (e.g. the install path), then you can run the install non-interactively with the quiet switch. This method requires invocation with a command line switch, as illustrated here:
msiexec /i "\\network path\Macromedia_Contribute_3.11.msi" /qb
Note that the final /qb switch must be on the same line as the rest of the command.
The /q part of the switch signifies the quiet mode, and the "b" indicates to use the basic UI level, which in this case would include a progress bar while the installer runs. When run in this mode, the default options will be used for all items that would be presented as choices in the interactive install.
A more comprehensive way to install from the command line
The simple command line syntax shown above will work in most cases, but the following section illustrates a more industrial-strength method of installing quietly.
The more expansive version of the syntax looks like this:
%Comspec% /c msiexec /i "\\network path\Macromedia_Contribute_3.11.msi" /qb
Here's an explanation of the arguments used the command-line example above:
-
%Comspec%is an environment variable provided by windows. It points to the command interpreter,cmd.exe. -
/cis a switch passed tocmd.exe telling the shell to wait until themsiexec.exe command completes before proceeding. Without this switch, the shell will execute subsequent commands before the current command finishes. -
msiexec.exeis the Windows installer runtime. When you double-click on an msi file (e.g. foo.msi) you are implicitly running "msiexec /i foo.msi". -
/iinstructs MSIEXEC to install the .MSI listed after the switch. There is an /x switch that uninstalls the .MSI specified after the /X switch.\ -
/qnspecifies a UI level for the action. "/qn" specifies no UI whatsoever, suppressing all prompts and therefore useful for silent installations. When attempting to debug, you can switch this to "/qb", which will display basic modal dialogs.
For further details about command line options available for msiexec, please refer to Command-Line Options in the MSDN Library.
How to re-install a program using a batch routine
Here is sample batch routine that will uninstall a pre-existing instance of the product, and then will install a fresh copy.
REM Begin quietInstall.bat
REM Uninstall Contribute 3.11
%Comspec% /c msiexec /x "\\network path\Macromedia_Contribute_3.11.msi"" /qb
REM Install Contribute 3.11
%Comspec% /c msiexec /i "\\network path\Macromedia_Contribute_3.11.msi" /qb
REM End quietInstall.bat
Installing patches using a batch routine
Here is sample batch routine that will patch a pre-existing instance of the product, and then will run a full upgrade installer afterwards. This particular sample might appear odd, but this is an actual functional batchfile that reflects how administrators can upgrade quietly from Contribute 3.0/3.1 to 3.11, that requires patching before the upgrade is run. The /qn switches used with the patch files allow these patches to fail quickly and silently if the older version is not found on the machine.
REM Begin quietUpgrade.bat
REM Patch Contribute 3.0
%Comspec% /c msiexec /p "\\network path\CT_3.0.1_PatchPackage.msp" /qn
REM Patch Contribute 3.1
%Comspec% /c msiexec /p "\\network path\CT_3.1.1_PatchPackage.msp" /qn
REM Install Contribute 3.11
%Comspec% /c msiexec /i "\\network path\Macromedia_Contribute_3.11.msi" /qb
REM End quietUpgrade.bat
Here are some additional examples that apply to installing the Dreamweaver 8.01 updater.
Installing the Dreamweaver 8.0.1 updater on a machine without Dreamweaver 8 installed
- Apply the patch to the original Dreamweaver 8 admin msi:
%Comspec% msiexec /a "\\network path\Macromedia_Dreamweaver_8.msi" /p "{full path}patch.msp"
- Install Dreamweaver 8.0.1 to the client machine:
%Comspec% msiexec /i "\\network path\Macromedia_Dreamweaver_8.msi" /qb
Installing Dreamweaver 8.0.1 on a machine with Dreamweaver 8 installed (reinstalling the application):
- Apply the patch to original DW8 Admin MSI file:
%Comspec% msiexec /a "\\network path\Macromedia_Dreamweaver_8.msi" /p "patch.msp"
- Reinstall Dreamweaver on the client machine:
%Comspec% msiexec /fvomus {path to updated .msi file}
or
%Comspec% msiexec /I [path to updated msi file] REINSTALL=ALL REINSTALLMODE=vomus
Updating Dreamweaver on a client machine with Dreamweaver 8 installed
- Copy the updater MSP file to the network
- Install the updater
%Comspec% msiexec /update "\\{network path}\{updater filename.}msp" /qb (or qn)
For more information on installing patches refer to the Additional Information section.
Public properties configurable from the command line
We have created some public MSI properties with which you can configure your Studio 8 and Contribute 3.x installations via the command line:
CREATEDESKTOPSHORTCUT - specifies whether a shortcut to the product will be placed on the desktop.
- CREATEDESKTOPSHORTCUT=0 means no shortcut on desktop
- CREATEDESKTOPSHORTCUT=1 means shortcut on desktop
- Default = 0
CREATEQUICKLAUNCHSHORTCUT - specifies whether a shortcut to the product will be placed in the quick launch tool bar.
- CREATEQUICKLAUNCHSHORTCUT=0 means no shortcut on quick launch
- CREATEQUICKLAUNCHSHORTCUT=1 means shortcut on quick launch
- Default =0
MACROMEDIA - specifies the installation path for the product.
- Default = [default program files folder/Macromedia
If a property is not set explicitly, the installer will use the default values. Here's an example of the command line syntax you can use to override the default values of these public properties:
%Comspec% /c msiexec /I "\\network path\Macromedia_Contribute_3.11.msi" CREATEQUICKLAUNCHSHORTCUT=1 CREATEDESKTOPSHORTCUT=1 MACROMEDIA="d:\Macromedia\" /qb
Note that in the example above, this must appear as one long line (don't let the appearance of the wrapped line deceive you).
How to install on multiple systems using Push techniques
When dealing with just a few machines, you might prefer to sit at each one, log in using an account that has local administrator rights for that machine, and run a generic batch routine posted to the network share.
However, this becomes time consuming when you have more than just a few machines. All of the methods described so far fall into the category of "pull" type installs, for which you use the client machine to pull the installer down from the server. Next we'll switch to a discussion of "push" type installs, in which you push the installation to client machines, using either a server or another workstation used for this purpose.
There are many commercial tools on the market for facilitating enterprise level software installation. One of the most commonly used tools is Microsoft's Active Directory, included with Windows Server 2003. It is beyond the scope of this paper to cover installations with Active Directory, but Windows Server 2003 Active Directory at Microsoft.com contains details about it if that is one of the scenarios you will be using.
For this discussion, we're not going to assume that you have an enterprise server available, and will instead describe some freeware tools you can use to push installs over a network using either workstations or servers. Here are the two tools we'll be describing:
- AT or SOON commands to schedule processes
- PSEXEC or similar tool to "push" batch routines.
Using AT or SOON to start a process at a workstation
AT is built into the command processor. The AT command schedules commands and programs to run on a local or remote computer at a specified time.
SOON is a version of AT with the advantage that instead of running processes at a specific time, it runs them 'soon,' given a delay (you don't need to know what time it is, useful when scripting). At the time of this writing, SOON.EXE is a free Microsoft download.
Here are examples of how you would run these commands:
AT <\\targetPC> 4:30 /INTERACTIVE<\\myPC\myShare\quietInstall.bat>
SOON <\\targetPC> 60 /INTERACTIVE<\\myPC\myShare\quietInstall.bat>
Executing processes on a remote system is an obvious security concern. There are two caveats with the above approach, both stemming from Windows security. First is establishing privileges at your desk system to start a batch routine on a remote system. Second is subsequently establishing privileges at the remote system to access network resources when running that batch routine. A quick way to test whether you have the first problem is to start a command prompt at your desk;assuming that you sit at myPC and the remote system is targetPC;and enter: AT<\\targetPC> or DIR<\\targetPC\C$>
If you see an "Access denied" message, you have to work around the first security issue.
Because most workstations will allow a network administrator access to their remote scheduling services and root drives, the simplest workaround is to log on at your desk using a domain administrator account (log on to myPC asdomain\domainadmin). If this is not an option, use an account that has local administrative privileges at each workstation.
Available options are:
- Make a dummy account that has the same privileges as every other user account in your office, except that it is added to "administrators" pool on workstations (not servers).
- Have your network administrator add your account to each workstations "administrators" group (not servers).
Both of these can be achieved via Active Directory policies.
- Design your batch routines so that your domain admin can run them from his desk, with the obvious shortcoming that you can't test them as easily while you write them.
If this discussion seems too complex for your immediate needs, skip to the next section, which introduces a shareware push application called PSEXEC.EXE
The second issue with AT or SOON is that once you get the batch routine to execute at the remote workstation, the remote station might not have access to network resources. That means the shell running your batch at targetPC might not have access to the network resource <\\myPC\myShare> .
This is perplexing, since targetPC most likely is logged in to a user account on your domain. However, when the command processor runs your batch routine through the scheduler, it executes with Local System privileges. The workaround is to add NET commands to your batch routine. When the batch routine executes with localsystem access, the batch routine itself opens a privilege pipe to the network resource you're after. That looks something like this:
net use * <\\myPC\myShare> /user:domain\username password /persistent:no
Using PSEXEC to start a process at a workstation
Another alternative to using AT and SOON is PSEXEC. In many situations, PSEXEC is easier to work with, because it collapses the two Windows security issues into just one: "Can PSEXEC.EXE execute a command at the remote system or not?"
At the time of this writing, PSEXEC.EXE is a freeware download from Sysinternals.
To run the batch routine at a workstation using PSEXEC looks like this.
psexec \\targetPC -u domain\username -p password -i -c -f \\myPC\myShare\quietInstall.bat
In the example above, domain\username has local administrative privileges to that machine.
If it is simply not an option to create an account that has local admin privileges on the workstations, then your sysadmin will have to run AT, SOON or PSEXEC for you. You can set up this line to accept arguments, so that when you supply your domain admin with a batch routine, she can run it with her domain\username and password as arguments:
psexec \\targetPC -u %1 -p %2 -i -c -f \\myPC\myShare\quietInstall.bat
Using perl to run the batch routine on many systems
Here is a sample PERL routine that uses AT to schedule a batch routine. The machinelist.txt is a simple textfile in this format:
# begin contents of \\myPC\myShare\machinelist.txt
targetPC1
targetPC2
targetPC3
# end contents of \\myPC\myShare\machinelist.txt
Here is a sample Perl routine that parses the list of workstations above to install Contribute 3.11 at each of them:
# begin contents of \\myPC\myShare\\machineLoop.pl
open (FILE, "< machineList.txt");
@lines = <FILE>;
@lines = reverse(@lines);
print "\n";
while ($line = pop @lines) {
chomp($line);
$cmdline = "AT \\\\$line 12:00 /INTERACTIVE '\\\\myPC\\myShare\\quietInstall.bat'" ;
print "Running: $cmdline\n";
system ("$cmdline");
}
close FILE;
# end contents of \\myPC\myShare\many.pl
Optional exercise: you could alter this sample script in Perl or Python to use SOON.EXE or PSEXEC instead of AT.
Special considerations for updating Dreamweaver to version 8.0.2
For technical reasons, updating existing installations of Dreamweaver 8x to 8.0.2 requires special processing in network environments.
When using normal network installation methods, you will see the message "This package could not be opened....". Follow these steps to work around this issue.
- Launch Update_Dreamweaver_8.exe or Macromedia_Dreamweaver_8_0_2.msi.
- While the install-welcome screen is showing, browse to:
C:\Documents and Settings\[USERNAME]\Local Settings\Temp\{D3A2D3EE-9CE8-473C-9AC3-EA479447F851} - Copy PatchPackage.msp to another directory.
- Quit the msi installer.
- Launch the msp file from the command line using the admin switch.
- To update an administrative install image:
msiexec /a [path to administrative image .msi file] /p "c:\PatchPackage.msp" - To patch a local installation:
msiexec /p "c:\PatchPackage.msp" REINSTALLMODE=omus /qb
- To update an administrative install image:
Additional Information
- Windows Installer Resources for System Administrators at InstallSite.org
- Applying Small Updates by Patching an Administrative Image in the MSDN library
- Applying Small Updates by Reinstalling the Product in the MSDN library
- For information on distributing registration and activation files in volume license environments, see Distributing files in volume license environments (TechNote cf33c97f).
- For more information about the volume license program and Adobe's acquisition of Macromedia, see the Macromedia Volume License Program (MVLP) section of the Macromedia Online Store.
This content requires Flash
To view this content, JavaScript must be enabled, and you need the latest version of the Adobe Flash Player.
Download the free Flash Player now!
