Any Easier Solution to Application Deployment??? 1

[kanin247]

To Whom It May Concern:

I am working on a research study and was wondering if anyone could provide any feedback from experience...

I am looking for an alternative to maintaining multiple workstation software releases (i.e., another way to release the software without having to distribute multiple CDs or having to go to each workstation). I was just curious how industry does this to "make life easier."

For example, maintaining all the software applications on a server and users can connect to it and use those software apps. But this also brings up the issue of allowing only certain apps to certain users. For example, when a user logs in, it recognizes the user and only makes available the applications pertinent to that user.

Anyhow, these were just some ideas I had and wanted to hear of any other methods or solutions other industries have used that have been successful.

If you could provide any assistance, I would appreciate it. Thanks!

kanin

 

[ReddLefty]

Here are a few suggestions you can check out:

-Microsoft SMS Server (Systems Management Server)
-McAfee ZEN or ZAC (Zero Administration Client)
-1-Vision (

http://www.1-Vision.com)

-Windows 2000 Server with Active Directory (Yup, it distributes software)


SMS and ZEN Works are full blown corporate software distribution packages with all the bells and whistles.. and then some.

1-Vision is a smaller but I found very interesting solution

Windows 2000 itself can do distribution software, but it does not do any inventory and such so it's good for smaller sized companies... like under 100 PCs.




"In space, nobody can hear you click..."

 

[kanin247]

ReddLefty,

Thanks for your feedback. Your suggestions were right along the lines of what I was looking for. Thanks again!

kanin

 

[kiptek]

Technically W2K through AD and group policy can also handle enterprise level deployment with inventory features (not just a small group) Cheers!

===>
kip

 

[rhitch]

If you don't want to waste money on SMS etc look into Windows 2k AD/GPO's and or look into using kix scripts to deploy .MSI packages. Use qumeras to deploy exe compiled packages.

 

[djwaddell]

This involves a number of areas and which makes it a good one for your research.

Initial problem is of knowing the devices being deployed to - a number of companies attempt to get round this by creating a "Standard Build". Problem here is that the company then has to try to buy as few different models of hardware as possible, as each new one increases the number of builds that need to be created - and each combination of applications destined for these builds will need to be tested with each one separately.

Next problem is Packaging Mechanism - e.g creating an InstallShield package or using MSI etc. Some packages do "differencing" - used to do this with NT. Create a SYSDIFF which is an image of the PC as it is just now - install the package and do a SYSDIFF DIFF which created package containing only the differences made by installing the package. This has a number of implications that need to be understookd by the packagers - e.g. ensure the package doesn't contain information such as the system name or user details - or deploying the package will result in every box having the same system name or user details.

Next problem is the one you really referred to initially which is the Deployment mechanism. Some software, e.g. Tivoli, enables setting rules against a distribution to prevent a package being deployed to a device with the wrong operating system, patch level, too little free space, or even devices where the package already exists. Tivoli will also handle deployment and installation of the package, e.g. install the MSI package. You need to be clear on the difference between the "Deployment" and the "Software Package". The complication with many Deployment applications is that they cannot put the Start Menu icons in place. The Microsoft Operating Systems are set up so that the user who is going to use the package logs in and carries out the installation - this obviously doesn't work with large scale deployments, so you end up with the package available to anyone who logs onto the device - unless Novell is used - but that's a whole other subject.

Next area - Licensing. Do you really want to license every device in your corporation for MS Project just in case someone needs to use the application? Conversely, can you afford for the person with a business need to use MS Project being unable to find a machine with it installed?

The only real solution to this is the use of a product like ZENWorks. When a user logs on, ZEN works out what software a user requires and deploys it to the user's desktop for the duration of the user's session. This is "PULL" as opposed to traditional "PUSH" deployment and the implications here are on Network Bandwidth.

I've only outlined some of the main areas that need to be taken into account when planning software deployment in a large organisation. Let me know if you want more detail on any specific area.

 

[mmv]

To djwaddell

I've got nothing persoanl agaainst ZenWorks, but all the problems you've outlined in your input, can be dealt with through Active Directory deployment.

First of all, and this is not directly related to AD, the image of the standardised workstation can be made to handle a lot of different hardware. In the majority of the deployments I have worked on, I use one image to somewhere between 95 and 100 pct of the workstations - laptops and desktops. There are exceptions, but most can be covered with one image and proper use of sysprep.

As for deployment of applications: If you have a mixed environment of w2k and xp's you will have to create you applications to reflect this.
I normally do not work with Windows 98 or other Nintendo systems, and Windows NT will also need to be addressed seperately by products like Zenworks, SMS, LANDesk or Mobile Automation, so I will not cover that here.

However if you work in a w2k/XP environment with an AD, the AD itself provides an excellent tool for application deployment with the Intellimirror technology, i.e. GPOs.
You can scale it from 2-3 users (Me, at home) to large worldwide installations with thousands of workstations (Me, at work). You can target on OUs, Group membership or even down to the individual. You can set rules for roaming users and you can install to the computer or the user.
With the Server 2003 AD you can do distributions based on WMI queries.

One thing you do however need to take care of is packaging, preparing the applications. With the knowledge and the correct tools you can prepare the packages to act differently on w2k's and xp's, you can install them to one user and noone else using that machine and you can create user interfaces and dialogs and statistics in you packages.

More and more applications comes as msi-packages these days, and understanding what the vendor-supplied package contains and how it installs, is the key to good solid deployments.

Oh boy, I could talk for days about this... and often do !

 

[DanMc]

In terms of a research paper, there is one theme that keeps coming up here, but nobody has nailed down. The design philosophy of the Windows Desktop is the source of Application Deployment complexities. It is HARD to distribute apps. Look at what the absolute best experts are saying, "Well it's simple, but you have to watch out for this pitfall, and you have to make sure everything is standard, and you can't let this happen...Then it works." That's not simple.

Microsoft designed Windows3.1 and Windows95 to take over the desktop market. They did this by giving the end-user ultimate control and flexibility. This was a big change from traditional mainframe and networked systems of the day. End users were stuck with what the programmers inside the company gave them. There were a lot of reasons that PCs took over and began appearing on the desks of offices, but a few major events were Lotus123 and WordPerfect appearing. There was no equivilant on the mainframe or the unix server, and even someone in a small business with no LAN could buy 1 PC and run them.

Management is finally realizing how the costs in running computers are broken down. So a manager can look at his helpdesk staff, and see that they are primarily spending their time fixing nusance problems on the desktop. How many times have you tried to deploy an application across 100 users in a Win9x environment? You spend 5 minutes installing the app, and 1-6 hours fixing the other problems on the PC, often rebuilding it. Virus here, clock wrong there, broken app because another app was installed over it, etc... Add up the helpdesk salaries, factor in the lost productivity of the end-users, and geez... We gotta do something.

Now that Microsoft has achived nearly 100% saturation, they are finally beginning to solve the problems of management and maintenance. And it's ironic, because they are doing it by becoming unix-like, and pulling away desktop flexibility, and boxing in users. It's just common sense. You can not let the PC configuration remain unknown, then try to manage the PC with a set of procedures. You can't even let the PC configuration deviate much at all. In a business, there is never really a reason to let it deviate. It will bite you when you ty to automate the next patch.

 

[DanMc]

I forgot to mention the obvious... Terminal Services. The idea here is, don't use the PC like a PC, unless you absolutely have to. We've already got them, and they kinda work, but it's not efficient. How can we move to a "better way" but not throw out this huge investment in the PC?

Microsoft was completely shocked at Citrix's success with WinFrame. Fortunately for them, they recognized it pretty quickly. They bought Citrix and designed new versions of windows with their own Terminal Services built in. And they probably vowed never to license the Windows source code to anyone ever again. Now MS Terminal Services is a core product that rakes money in.

 

[ReddLefty]

Microsoft bought Citrix? Although I can't deny what your saying, I've never seen anything to confirm it either! I still have not seen anything about MS buying out Citrix. They are still channel partners according to the Citrix web site and nothting on there suggests that they have been bought. This might be intentional, but it's not the Microsoft Way..... MS usually publishes takeovers as soon as it can for corportate and especially, investor relations.



"In space, nobody can hear you click..."