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 :-)
What do all of you feel is the best practice and why?
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
Answers (12)
Please log in to answer
Posted by:
anonymous_9363
13 years ago
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.
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.
Posted by:
mhsl808
13 years ago
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.
Posted by:
anonymous_9363
13 years ago
- 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 aDEPLOYMENT tool do those jobs? :-)
Packager's Baseball Bat time again, I think...
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
Packager's Baseball Bat time again, I think...
Posted by:
mhsl808
13 years ago
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 [:@]
Posted by:
anonymous_9363
13 years ago
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?
- modify the registry
- move files/shortcuts
- change application prefs
via the deployment tool, WTH does he need MSIs for?
Posted by:
mhsl808
13 years ago
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?
Posted by:
icbrkr
13 years ago
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?
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?
Posted by:
michaelnowell
13 years ago
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.
- 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.
Posted by:
MSIPackager
13 years ago
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.
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.
Posted by:
anonymous_9363
13 years ago
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.
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.
Posted by:
AngelD
13 years ago
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.
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.
Posted by:
snissen
13 years ago
>(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
I found this one very helpful:
http://desktopengineer.com/overview
Sande
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.