BookmarkSubscribeRSS Feed
georged
Calcite | Level 5

We're going to deploy desktop SAS 9.3 and EG 4.3 to about a hundred users' machine over the next few weeks.  We usually deploy software by capturing changes before/after installation on a test machine, and then packaging those registry/file system changes as an MSI (using AdminStudio).  However, we've previously had trouble creating a reliable MSI for SAS 9.2 (other software seems to install well using this technique). Does anyone have any recommendations or suggestions on the best way to do a mass installation of SAS clients to Windows desktops?

6 REPLIES 6
jasonlosh
SAS Employee

Hi,

Repackaging in MSI can be problematic because in order to be successful all systems in the deployment must be identical.  A SAS deployment introduces a few Microsoft redistributables into the hosting environment based on the product mix being deployed and the state of the hosting environment.  If repackaging in MSI is done on a hosting environment that is different than a hosting environment on which the MSI will subsequently be deployed, certain system updates may be missing which will cause runtime errors. 

Some organizations have a strict requirement for MSI based deployment.  If that is the case in your organization the key to success is to ensure that the system on which the package is created is identical the systems on which the MSI will be deployed.  If MSI is not a strict requirement then I recommend using the SAS Deployment Wizard's record and playback capabilities documented in Chapter 3 of the SDW user's guide.

http://support.sas.com/documentation/installcenter/en/ikdeploywizug/64204/PDF/default/user.pdf

This will yeild predictable results more so than repackaging because the SAS Deployment Wizard has all the knowledge about what updates to apply and when based on the product mix chosen and the hosting environment.

Cheers, -Jason

RobbieFreddie
Calcite | Level 5

We have similar issues with creating "builds" for the SAS software in my organization.  9.2 builds seemed to be a lot better than 9.1.3, but there still have been issues with the software builds we have created and distributing them. (The builds are how a part of our IT department manages software installs, so they want SAS to fit into there method of installs)  We created response files following the directions from the link below:

http://support.sas.com/documentation/cdl/en/biig/62611/HTML/default/viewer.htm#n05023intelplatform00...

Even with this method, which I'm connecting the dots with jasonlosh's response, is that the install has many redistributable's that can affect what is installed.  These pre-reqs vary from machine to machine greatly from my experiance. (Installed on 8 machines, and I think only 2 machines had the same pre-reqs installed, other than that they all had different lists of pre-reqs to install)

What would be nice is having a response file built for typical SAS BI installs, but having the pre-install (system checker) run dynamically.  So if you perform the response file install on the 100 machines, and they have different pre requirements (redistributable installs), it can account for them.  All of this under a "silent" isntall would be nice.

We are currently working on this matter as well, and will re-post if we find any better methods of performing these installs

jasonlosh
SAS Employee

Hi Robbie,

What you describe as wanting is actually how it works.  There is no need to record N number of response files to account for N number of permutations of system requisites that will be installed.  This is why using record/playback capabilities in the SAS Deployment Wizard is a more robust solution as opposed to creating static MSIs based upon the state of one hosting environment (unless as noted previously it is known that all hosting environments are identical).

A response file can be recorded for the same product mix and installed on different systems with different updates needed and the SAS Deployment Wizard will handle this dynamically during the silent playback.  Keeping up with N number of response files wouldn't be much better than keeping up with N number of MSI distributions custom built for each unique hosting environment.

Cheers, -Jason

boschy
Fluorite | Level 6

Heh heh. All I'll say is "good luck".

What's ESSENTIAL in this exercise is having your absolute best desktop technicians working on the job.

Thorough testing of install packages in all situations is a must too (well, duh).

TonWiegman
Calcite | Level 5

Hi Georged, How did this work out?

We are in a same position to roll out tens of client installs. My problem is that the installation process takes hours.

The softwaredepot itself is bigger 30Gb in size.

Regards,

Ton

jakarman
Barite | Level 11

Knowing the installation process fucntions and steps it well possible to deploy as MSI package.

With 9.4 AMO and Eguide are being promised having to be MSI pacakge.

With 9.1.3 was delivered with CD images. That is a relative small installation step easy to be repackaged in a MSI style. (CCM).

9.2 and 9.3 are delivered in XML approach run by a java procedure.

These XML file are easy readable / re-engineerd.  It covers:

- Some Windows updates files (VB COM etc) redistributables

- Unpacking - unzipping placing of physical files

- Adjustments in .Net  (Com settings)

  when missing this step you get all installed win registered well updated. But failing in running without any clear indicators messages.   

Would advice to  have 3 steps:

1/ windows updates. These MS redistributables have a check on their own.

2/ Desktop SAS:

   2.1 update Winregister snapshot

   2.2 placing the location of files (unpack/unzipped).

  Remember: a/ a networkdrive is in zone local intranet, not local machine. (I remember caspol)

                      b/ using a networkdrive may generate the url of it not the letter.  

3/ Update .Net and other MS settings outside of the Window-register.    

Additional ideas: 

Having a well maintained fileserver approach. You could choose to place the unpacked unzipped generic file-share.
- By this the only needed updates to a windows desktop are minimized (several MB's at max).

- Needing an update in a file will be achieved by replacing files not by repackaging

- The trade off is a slightly slower start of the tool, after that Windowsprocesses will cache a lot.    

When you are dealing with AMO don not forget addtional tools like the option to switch between AMO versions 

For all make sure the result should be as the SAS deployment proces (to be tested at the packaging approach).

Some security policies are possible troublemakers in almost every approach.

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 6 replies
  • 2633 views
  • 6 likes
  • 6 in conversation