09-12-2011 07:14 AM
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?
09-12-2011 11:22 AM
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.
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.
09-12-2011 03:52 PM
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:
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
09-12-2011 05:27 PM
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.
10-17-2011 11:06 PM
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).
07-22-2013 11:32 AM
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.
07-23-2013 01:41 PM
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.
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.