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 :-)

What do all of you feel is the best practice and why?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

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.
Answered 07/21/2010 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 07/21/2010 by: mhsl808
Fifth Degree Brown Belt

Please log in to comment
0
- Checking AD for user/group membership
Here's where your debate takes place

- 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? :-)

Packager's Baseball Bat time again, I think...
Answered 07/21/2010 by: VBScab
Red Belt

Please log in to comment
0
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 [:@]
Answered 07/21/2010 by: mhsl808
Fifth Degree Brown Belt

Please log in to comment
0
Hmmmm...so if he wants to

- modify the registry
- move files/shortcuts
- change application prefs

via the deployment tool, WTH does he need MSIs for?
Answered 07/21/2010 by: VBScab
Red Belt

Please log in to comment
0
THAT is exactly my point [:D] It is really, really hard talking to people who refuse to admit they are wrong and then they dig their heels in to defend their position. Wanna switch jobs?
Answered 07/21/2010 by: mhsl808
Fifth Degree Brown Belt

Please log in to comment
0
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?
Answered 07/21/2010 by: icbrkr
Senior Yellow Belt

Please log in to comment
0
When you're talking about......

- modify the registry
- move files/shortcuts
- change application prefs

.....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.
Answered 07/21/2010 by: michaelnowell
Second Degree Blue Belt

Please log in to comment
0
Yep I'm firmly with Camp A on this one - try hitting him up with these benefits for starters:

1) OS integrated / elevated install rights
2) Standard logging capabilities
3) Failed installation rollback
4) Advertising / Install on demand
5) Conflict management
6) Standard installation footprint
7) Custom actions
8) Reliable uninstall

Perhaps your manager should stick to the network side of things and leave you to the packaging [;)]

Cheers,
Rob.
Answered 07/22/2010 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
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.
Answered 07/22/2010 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 07/24/2010 by: AngelD
Red Belt

Please log in to comment
0
>(though I'm searching for a basic overview class to send us all to).

I found this one very helpful:
http://desktopengineer.com/overview

Sande
Answered 07/25/2010 by: snissen
Fourth Degree Green Belt

Please log in to comment
Answer this question or Comment on this question for clarity