Jump to content

Recommended Posts

Posted

How do you all (Vanilla Networks) handle package creation? I don't mean the GPO's etc, and I mean actually creating the package (MSI)?

 

From an RM background the done thing for me was to always create an MSI with Winstall LE, but most installation media nowadays has an MSI ready on the disc. Do you tend to use these MSI's, or do you create your own package using some 3rd party software?

Posted
We normally use any tools provided to create a customised install or just use the MSI on the disc, which installs using all default settings I believe.
Posted

We use EMCO - it's a great program but we want something a little more Robust and easier to use.

 

I'd quite like to get to know Symantec (Ghost) AI, never used it before but we have the full symantec ghost suite here and it's part of that.

 

Anybody able to tell me how it kinda works ?

Posted
If there's a MSI already shipped with the CD, I always run command prompt and type in: msiexec /a D:\filename.msi which enables me to create an administrative install of the MSI, so that I can input things like the serial key and username etc.
Posted
So only 1 for using the install media MSI's?

 

I use them if they are available but only if they don't require serial numbers etc if they don't then i'll test deploy them on a vm and if all working then deploy to network.

Posted
Should the majority of packages I've created (Winstall LE) for my RM network work on my Vanilla network, or is this bad practice?

 

I'm not 100% sure how RM systems work and how much adaptations it uses for the packages.

 

But there is no harm in building a test vanilla workstation in a seperate OU and apply the install GPO to only that.

Posted
Should the majority of packages I've created (Winstall LE) for my RM network work on my Vanilla network, or is this bad practice?

 

In my experience they tend to work fine as long as they aren't looking for any RM specific unc paths (rmshared, rmpublic etc) as the RM Application Wizard is just a wrapper for WinstallLE with some exclusions etc. (Well, in CC3 anyway..... CC4 who knows)

  • Thanks 1
Posted

I almost always use pre-built MSIs if they are available (often with MSTs to customise shortcuts and the like), unless I look at them in Orca and see that they've been created with a capture program.

 

I hate capture programs.

 

In my experience, they almost always pick up extraneous changes that are nothing to do with the program being installed, and most people using them don't have the knowledge required to work out what they can and can't drop (present company possibly excepted!). Some of the worst workstation problems I've ever dealt with have been down to badly captured MSIs screwing around with registry changes or system files that have nothing to do with them

Posted
I almost always use pre-built MSIs if they are available (often with MSTs to customise shortcuts and the like), unless I look at them in Orca and see that they've been created with a capture program.

 

I hate capture programs.

 

In my experience, they almost always pick up extraneous changes that are nothing to do with the program being installed, and most people using them don't have the knowledge required to work out what they can and can't drop (present company possibly excepted!). Some of the worst workstation problems I've ever dealt with have been down to badly captured MSIs screwing around with registry changes or system files that have nothing to do with them

 

Completely agree.

Posted (edited)

I use Wise Package Studio to create MSIs but only as a last resort. When faced with a new package, this is that I usually do:

 

See what the installer is. They are usually one of the following:

 

  1. Pure MSI
  2. Installshield installer
  3. Inno Setup
  4. Nullsoft installer
  5. Custom installer rolled by the manufacturer

 

If it's a pure MSI, I first run to see what happens. I see if there are any custom variables that need to be set. If there aren't, I cancel the installer and run it silently using MSIEXEC (The command line is MSIEXEC /i {installer.msi} /qb). If the software works after that, I stick it in the software repository and say job done.

 

If there are custom variables which need to be set, I then use Install Tailor which is part of the Wise Package Studio to see what they are. This captures the custom variables and stores them in an MST file for you. I then run the installer with the transform applied (MSIEXEC /i {installer.msi} TRANSFORMS={transform.mst} /qb) and see if it works. I also make a note of the variables that Install Tailor captures as you can pass them on using the command line too (MSIEXEC /i {installer.msi} {VARIABLENAME}={VALUE} /qb) which is sometimes preferable.

 

With Installshield, it's much the same. Installshield builds upon the Microsoft installer so the majority of what you can do with pure MSIs can be done to Installshield packages too. It's usually a good idea to unpack them using the /a command (or with WinRAR) as you can get to the MSI inside the package and pass it using MSIEXEC again. There are a few out there which insist on being run using the setup.exe and which won't let you pass variables on to them (Nelson Thornes comes to mind) but thankfully these are rare.

 

If I can't capture an MST or pass variables onto an installer, I use an AutoIT script to install the program which effectively mimics you pressing the buttons in an installation routine. It's crude but it usually works. I go through this amount of trouble because unless it's completely unavoidable, you should not repackage packages which are already packaged using a Microsoft installer. It just causes too much trouble.

 

Inno setup files are usually easy, you can get all of the documentation from here and you can get an unpacker for Inno setup routines from here. Unpacking the installer will let you look at the installation script and work out what the variable names are. You can them pass them on the installer via the command line.

 

Nullsoft installers tend to be very simple. The bulk of the command line options are here

 

Custom installers tend to be the most annoying. Sometimes there's documentation, sometimes there isn't. VLC is a good example of a custom installer which is quite well documented. For those, I tend to look at AppDeploy.com - The Application Deployment Information Center and see what other people are saying.

 

Once you've worked out how to install a program silently from the command line, you're pretty much sorted. MSIs and MSTs can be deployed by using the built in software deployment options in Windows Server. You can install programs which insist on using executables or AutoIT scripts using startup scripts or by using software management programs such as SCCM.

 

Again, with Inno, Nullsoft and custom installers, if I really can't get them to install silently using their own installation routines or with AutoIt, I repackage them using Wise Package Studio. At least with them they don't use Microsoft installer databases so it's not so bad. It is a last resort though and you do need to go through the created MSI with a fine tooth comb to make sure you weed out any unnecessary information.

 

There will always be bloody awkward software which won't deploy themselves over networks no matter what you try (Adobe CS, I'm looking at you!). In this case, I found the simplest thing to do is to just roll the software up in your main OS image and shove it out that way. It makes creating the image a little more labourious but saves time in the long run as it takes Creative Suite (for example) as long or longer to install using its own setup routines as it takes for me to deploy a 10GB image across our network.

 

An additional piece of advice re rolling your own MSIs (I'm sure you realise this already but anyway): Do so on a completely clean machine. Built it up to the required service pack level. Turn off automatic updates, BITS and anything else which will make background changes. Do it on a virtual machine if you can so you can install the OS and package manager then snapshot it. This will make it easier to make sure that you've got a clean MSI plus you'll be able to go back to a clean slate once you're finished.

 

I've been responsible for software packages and OS images on our network now for about two to three years and so far I think I'm doing OK. If you have any questions, please ask.

 

If there's a MSI already shipped with the CD, I always run command prompt and type in: msiexec /a D:\filename.msi which enables me to create an administrative install of the MSI, so that I can input things like the serial key and username etc.

 

Running an MSI with a /a command will usually only extract its files. Don't count on being able to enter variable names and them sticking from there on in. The only installer where I've seen that happen is the Office 2003 one.

Edited by Norphy
  • Thanks 2
Posted

I use the supplied msi's with transforms where needed, editing with orca as required.

 

Also started to use cameyo for application virtualisation.

 

Ben

Posted
Even on RMCC4, I still look for a msi on the disk or within the exe first, and use orca to edit it. I was taught that re-packaging an existing msi caused problems.
Posted
Also, while one about Cameyo - is it best practice to run the virtualised apps over the network off a network share, or put them on the HDD of each machine? If it is the latter, how do you get them to the machine? Part of the image, or with a copy script etc?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...