Software Deployment

Chasing SnowSoftware gets installed on machines in a variety of ways, and for a variety of reasons.

Controlling Software Deployments

In general, it is installed because someone wants to use it. However it can be a challenge ensuring that the value gained out of the software is more than the cost of the software. Most organisations have some sort of authorisation process in place to ensure they receive value for money out of their software. Individual software requests may only require line manager approval, but large deployments will often be treated as projects and go through standard governance processes.

Software can also be installed because it is required, for instance if the software patches a security hole or fixes a bug in an existing piece of software. It may also be installed as part of an upgrade programme.

Ad hoc software requests of the “I need to use this piece of software, please install it” kind) are usually treated as a service request which will be routed through the service desk and fulfilled by desktop support as a “standard change”. Deployments which affect a much larger group of users or machines, such as a patch, bug fix or upgrade programme will usually go through change and release programmes to ensure they are installed on all machines that need the software, that the installation doesn’t cause problems with other systems, and provide a ‘back-out’ path in case things go wrong.

Exception reporting is vital to ensure that all users or machines that were intended to receive the software actually do receive it, and that no one ends up with it who doesn’t need it.

Packaging

Common applications, including Operating Systems and the components of a standard build, may be installed on a server as a ‘package’ so that they can be installed quickly and easily on selected machines. All software that is packaged should go through the same testing process as any other piece of software and should also be subject to the same controls.

Tools

There are many tools on the market which assist with software deployment, and indeed many are part of a suite that also include a software asset management tool, for instance Altiris. There are also some specialist deployment tools which are part of a security suite and which focus on Patch Management, although the technology behind these tools are fundamentally the same as any deployment tool.

Deployment tools are only as accurate as the hardware management that supports them (making sure that all machines are on the network regularly, have the relevant agents installed and working, that machines intended for salvage are removed from the pool of machines etc) and also rely heavily on the accuracy of associated discovery tools to identify which machines have had the software installed and which need to have it resent to them.

Uncontrolled Deployments

Despite an organisation’s best efforts, it can be very difficult to ensure that all software that is installed is done so through the correct control procedures. It was a challenge in the days of ’sneaker-net’, when software had to be installed using physical media, but the ability to download software off the internet has made the problem acute.

The surest remedy is to ‘lock-down’ all desktop computers so that only an administrator can install software, but even the most controlled of companies will have computers that are not ‘locked down’ for whatever reason, and it will always have people who know the administrator password which gives them the ability to install what they wish. Again, exception reporting is the key to identifying uncontrolled software installs and initiating processes to have it removed.

So this is a quick run down of how software actually gets installed on machines – but you’ll notice I haven’t even mentioned licensing! That’s because, although all software will have some sort of license or intellectual property rights associated to it, in many, many cases the license will be such that the software is effectively uncontrolled from an organisation’s point of view – for instance patches, bug fixes, drivers etc. These are all pieces of software that have perfectly legitimate reasons to be installed, although the license does not need to be actively managed.

I’ll talk more about techniques for managing those licenses that do need to be managed in later posts.

Picture Credit: K J Fowler

2 comments to Software Deployment

  • Hi Kylie,

    I look forward to further articles on this subject. In my experience deployment and licensing are handled by two different departments and it is usually the case of one chasing the other.

    Nice picture!

  • Kylie

    Yes, deployment and licensing are generally handled separately – which is one reason why so many organisations end up non-compliant. Linking the two is the big SAM challenge, but many of the data management techniques I discussed in my earlier posts really help. I’m planning to expand a bit more in later posts.

    Glad you like the picture, it’s one of my favourites. It was taken years ago when we had Christmas up in Yorkshire. We went driving through the Pennines looking for snow and I caught the guys sky-lined at sunset – it’s one of those shots where you just have to be in exactly the right place at the right time.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>