Deployment of packages

We are having quite a debate where I work on packaging so I wanted to see what others in the field thing and do for a packaging method.

Here is what we are talking about:

Camp A: 100% of the package logic should be incorporated within the package. This way, you can use any deployment tool you want (SCCM, LanDesk, Altiris, GPO, Login Script, .BAT file.....) and it will still install. You can also double click on it and it will install. Best example: When you install anything from the Internet 100% of the logic for that pacakge is inside the package.

Camp B: Thinks the deployment tool should have logic built into it and not the package. The package should only be a MSI/MST and very little else. Reason......leverage the tools we paid for to do the job.

Now, some more info: Camp A are all techs and Camp B is management :-)

Comments

Answers

0

That depends on what you mean by "logic". Do you mean determining whether UserA is in a particular AD group/Business Unit, or at a particular site/office/whatever...that sort of thing? If so, I'd say - helpfully! - that it probably comes down to a mix. I don't think you can categorically say one way or the other, as each client will have different requirements.

If I had to jump one side of the fence, I'd say that the majority of the "logic" should be in the MSI/MST. As you say, it should be as "stand-alone" as possible, making it - as far as possible - deployment tool-agnostic.

Yes, by Logic I mean any choice the package needs to make. Checking AD for user/group membership; modify the registry, move files/shortcuts; change application prefs....etc..... all the things we need to make packages do.

- modify the registry
- move files/shortcuts
- change application prefs
All of the rest belong in the package. What sort of insane management thinks it's a good idea to have a DEPLOYMENT tool do those jobs? :-)

Hey VBScript.... [:)][:D][:)][:D] That was funny. And yes, we can and do use SCCM to target deployments to certain users, offices, subnets.....which is what tools like SCCM are designed for. But I've had 3 heated debates with my manager now over how to package. My manager is a solid network guy but has never packaged......yet thinks he knows how and he is unmovable on his stance that the deployment tool should have logic built into it. It is really frustrating trying to explain to him why you script [:@]

Where I work, everything is to be self-contained in the package itself. For us, we place down the vendor's MSI in an executable, then call it using the Windows installer, and any sort of shortcut manipulation, etc, is done through Wise-Scripting. From what I understand, not always the most efficient way of doing things, however, our MSI-editing/MST creating skills are limited (though I'm searching for a basic overview class to send us all to). The plus side, however, is when a junky MSI comes into the picture, we can push back to the vendor to resolve (we're a large enough company to do so) instead of spending a lot of time attempting to fix their issue.

I'm with VBSCab. If you're going to do all this neatness through a deployment tool, why bother packaging it in the first place?

.....may help your case if you explain the self healing aspect of adding these changes into your MSI's. If they are done out of the MSI then they are going to be ignored. Mention lower call volume to the help desk etc, application intelligence and then baffle him with some other terminology.

I'd suggest that you deliver your next MSI completely void. When it fails to install 'Acme Zoomworks FudgeIt v11.6' you can simply say "Oh, I thought we were using [whatever] to deploy software now."

See how that goes down.

BTW, you have all this idiocy in writing, right? You'll need something to beat him with when someone higher up asks why packages are taking 3 times longer to create and x times longer to actually deploy.

I have no problems utilizing the deployment tool for in-house application management, I usually have a script-wrapper performing the magic amongs executing multiple commands when needed.
As a vendor creating packages I would never force the "end-user" to use more then the MSI, they would be able to create a transform to customize the deployment.