In this fourth article on leveraging collections for Software Delivery 6.x lets see how collections can be modified to simplify the staging of software rollouts. These modifications provide a very effective platform for transitioning your software delivery though the various deployment phases; beginning in the lab and ending in a full site-wide deployment.
Introduction
In many organisations, software deployment best practice requires that rollouts are undertaken in a number of stages, exposing your systems to updates in a controlled manner. This graduated approach gives the rollout team the ability to continually assess the impact of their rollouts, providing a valuable opportunity to back-out in the event of problems being reported. Such best practice balances your business needs to upgrade systems against the ever-present risk of unintended effects creeping into your deployments.
This article builds upon the foundations laid on in the three articles below,
Deployments Can Go Wrong!
Managing software rollouts is a tricky business, and the larger your environment the tricker and more nerve jingling it gets. Let's say you've been asked to deploy a remote control package to a PC estate of 1000 machines. You deploy the package successfully to your test machines and, as these reflect reasonably well your desktop hardware diversity, the risk of something going awry in the full rollout is considered minimal. You hit the 'Big Red Button' and the package is deployed site-wide. Back at the helpdesk, calls start coming in. Machines across site are blue-screening, and you've got that sinking feeling.
So, what went wrong? In short, the risk of something going wrong in the rollout was considered, but the potential impact on the business operation of the desktops was not. The testing lab is at most a crude representation of your live environment. Consequently, be wary of that rush of satisfaction which follows successful lab deployments. Obviously, it's a prerequisite that the deployments work on clean machines, but any sense of security gained here can be misleading and lend itself to over-confidence when assessing the risk and impact of a full rollout.
The above "blue-screening" scenario isn't fictitious -this happened to me on one of my first ever deployments. The system crashes were the result of an incompatibility with the remote control software and particular driver releases for an Intel graphics chip. The impact of this deployment could have been huge -each machine required a visit by a technician to update the driver in safe-mode before the workstation was once again useable. I considered myself lucky at the time -perhaps 30 machines were affected.
What I am trying to get across here is that changes you apply to your computers have the potential to end badly, compromising the very systems you are trying to manage. This article will help you avoid catastrophes like this by utilising collection code which actually simplifies the process of dividing your rollouts into stages.
The Benefit of Phasing Deployments Into Stages
In the last article, I revealed a tip which allows you to stagger software deployments using T-SQL's TOP command. The TOP command limits the number of rows returned by your SQL queries, and thus can be used to cap the computer count in your software rollout collections. As long as your collections specifically target machines which have not yet received your software package, you can limit the number of machines which are simultaneously targeted with this technique. This reduces not only your server load during deployments, but also your network bandwidth. Both of these savings can be advantageous in environments where these are at a premium.
Using TOP to limit your deployments also has another advantage -your users are exposed gradually to your deployment updates. This then has the added benefit of giving you more time to disable the task should problems emerge.
Today's article focuses on a more predictable way to gradually expose your PC population to software rollouts. The cornerstone of this method revolves around the idea of dividing your rollout into stages. My personal preference is to divide rollouts into at least three stages;
- Stage 1: Test machines
This stage tests that the package deploys as expected in your test environment. If you do not have a test network in your workplace -get one! A minimal cost test network can be constructed using spare desktops (such as those you keep handy to replace staff machines in the event of failed hardware). The test network provides you with complete access to machines subjected to your deployments, allowing you to thoroughly check at your leisure that the deployment does exactly as intended across the configurations you support.
Some things to consider here are,
1. How the deployment interacts with the user
2. Does the deployment require a reboot. If so, how is this handled
3. How robust is the deployment
4. How the deployment progress is logged
5. How is the deployment confirmed as being successful
6. How can the deployment be reversed in the event of problems
The test stage is therefore much more than pushing out a package and ticking a box if this appeared to work. Once you're happy that all is well here, you can proceed to Stage 2.
- Stage 2: Pilot machines
This stage ideally tests your package on a statistical sample of your computer environment. For job security do not to select VIP machines, but rather select machines whose users who have both the aptitude and inclination to provide useful feedback, and are unlikely to complain at the occasional glitch. Forming a good rapport with users in the pilot group is essential.
In large environments, consider having multiple pilot groups which divide this stage into sub-stages.
- Stage 3: Full deployment
As it says on the tin, this is the full deployment across your organisation. At this point, you should be pretty confident that all the deployment bugs revealed in the previous stages have been ironed out. With luck, you've also briefed the helpdesk and the various managers so that all this is not going to come as a surprise...
Things to consider at this stage are, 1. Should the deployment be scheduled to a specific day and time 2. If users are expected to notice a change on their systems, have they been notified of the change 3. Is it necessary to consult with section or department managerial staff to notify them of this change 4. Has the helpdesk been prepared for the call scenarios which might emerge from the rollout 5. Have the IT staff on the ground been a technical brief, allowing them to resolve any anticipated deployment problems
So, at this point the deployment changes from being technical in nature to logistical. Therefore good process is required to deliver a successful deployment. In large environments consider dividing the full rollout into sub-stages as this can simplify the communication element.
Unsubtle Approach To Building Stage Collections and Tasks
One common approach to tackling staged deployments in the console is to create separate collections and tasks for each stage.
This deployment strategy is depicted in the graphic above which shows a sample layout of an "Adobe Reader 8.1.3" deployment folder. This folder has been created with the mindset that all the deployment objects should be immediately visible as shown in the last article -it contains three tasks, three collections and the deployment package. So far, so good. To cover the first phase of deployment, I've created the task "Test Group: Upgrade Adobe Reader 8.1.3". This explicitly deploys the software update to the computers in the collection called "Computers in Test Group requiring Adobe Reader 8.1.3 Upgrade". I have created similar tasks and collections for the second and third stages too.
This approach of using a one-to-one correspondence between tasks and collections is fine, but it has a couple of drawbacks.
- Inflation of Tasks and Collections
Each software package will have at least 3 tasks and 3 collections associated with it. As the number of packages you support & maintain increases, this can start to get quite cumbersome. This method therefore does not scale well, and can seriously bloat in large environments with an expanded number of deployment stages. The console objects using this method are not only painful to manage over time, but they also add an overhead to the server.
- Forwarding Task Revisions
As this approach has a unique task allocated to each stage, you must remember to confirm that any task amendments are forwarded to the following stages. Double and triple checking your tasks at each stage is critical to verify that mid-deployment amendments (like only running when users are logged off, or execute with window hidden) are passed on.
Despite these problems, this method is adequate for small environments -I used to use it myself. However, when I began support more software packages across a larger environment, I started to feel annoyed at all the console objects I was creating. I couldn't help but think there must be a better way.
Scalable Approach To Building Stage Collections and Tasks
To get around the above issues, I opted for a scheme similar to that already employed by Altiris Patch Management. In this solution's implementation of software deployment, two collections are created for each software update. These are the master and intersect collections.
- The Master Collection
The master collection holds all computers which are potentially in focus for any particular software update. For those familiar with Patch Management, its likely you've set the master collection to all your machines with the Software Update agent installed. This actions puts your computers in scope for Patch Management to apply any particular software update. All it needs to do next is see if the computer actually requires the proposed update (determined by the intersect collection discussed next). In this article we will treat the master collection as a container into which we'll sequentially add the computers representing each deployment phase. The number of computers in the master collection will therefore grow as you progress your deployment through each stage.
- The Intersect Collection
In Patch Management Solution, one of the main tasks for the patch engine is to determine which machines in the master collection require any particular software update. Each software update will generally not be required by all the computers, so software updates are targeted at intersect collections. These collections contain all those machines from the master collection which are missing any particular software update. The intersect collection in Patch Management is created behind the scenes by the patch engine and has no visibility in the console for simplicity. In this article, we'll have to manually create our intersect collections using a SQL queries to filter the master collection for computers which are reported as not having applied our updates.
Using this Patch Management strategy whilst a little tricky initially has a tremendous advantage -by targeting your deployments at intersect collections you can now realise an entire deployment through a single software task. Pushing your deployment through each phase is now as simple as adding further computer collections to the master collection.
In the opposite above, I have illustrated a sample software deployment layout using this method. Here I show the three deployment stage collections ("Test Group", "Pilot Group" & "Domain Group") in the root of the software rollouts folder. I call these recyclable collections as these collections can be used now in all your software rollouts -hence their placement in the root folder. In the "Adobe Reader 8.1.3" folder i've put all the software deployment objects unique to this rollout. Here we have a master collection, the intersect collection, the software task and the package.
So how does all this work? Well, its rather simple.
- Initiating 'Stage 1' of your rollout: Test Group
Add to your initially empty master collection your 'Test Group' collection. At the next collection update, the intersect collection will populate with machines from the test group which require your software update (which initially might be all the test PCs). Depending on your task schedule, the next configuration update could well see your package downloading and executing on your test computers. At the end of your deployment, the intersect collection should be empty and all your computers should have the update.
- Initiating 'Stage 2' of your rollout: Pilot Group
Levitating your deployment to the second stage is simple: you now add the 'Pilot Group' collection to the master collection. The intersect collection at the next update will then populate with the pilot computers which require the update and soon they too will start to download the package.
- Initiating 'Stage 3' of your rollout: Domain Group
Finally, to activate the final stage which delivers the task site-wide, you just add the 'Domain Group' collection (which holds all your site computers) to the master collection. Transitioning your rollout through the stages has just become very simple.
Let's now look at all this in practice.
Building your Stage Collections
In order to deploy packages in stages, we'll need to create the corresponding collection objects in the console. Open up the Resources tab in the Altiris Console, and Right-Click the Resource Management -> Collections folder to bring up the context menu. Select New -> Collection to create a new collection.
The Test Group Stage Collection
To add your test computers, expand the Explicit Inclusions and Exclusions option and click the hyperlink select a resource from the Inclusions section.
In the resource locator popup,
- Enter in the name of your first test computer and click Find
- Select the computer from the list presented and click OK
- The 'Selector Dialog' page will now appear presenting the current computers to be included in your collection. To add more computers click the blue plus sign (repeating the above steps), or click OK to finish.
If you're lucky enough to have a good naming convention for your test machines, such as they are all prefixed with 'test-' then you can accelerate the process by entering 'test-' in the Name Like text box, which will allow you to highlight all the test machines from the list at once.
Once you've finished adding all your test computers into this collection, you should have an inclusions list similar to that opposite.
Click Apply to save the collection.
The Pilot Group Stage Collection
To create your Pilot collection, repeat the above procedure naming the collection "Pilot Group". This time you'll have to select manually all your pilot computers. This can be laborious, and there are some cleverer ways to do this, but let's just keep this simple for now. Note that this collection should be bigger than your test group!
The Domain Group Stage Collection
Finally, let's create the create the collection to determine the machines encompassed by the full site deployment. To do this, create a collection as in the previous steps but instead of using specific inclusions use the following SQL query to determine the collection membership.
select Guid from vComputer vc
where (vc.domain like 'MyDomain' and vc.[OS name] like 'Microsoft Windows XP')
Naturally you'll need to replace MyDomain with your domain (or common workgroup for Novell networks). If you support multiple domains, you can either add all of them into the where clause, or create additional Domain collections.
The console window at this stage should look similar the screenshot above. Notice here how i've also restricted this group so that it only contains Microsoft Windows XP computers. Firstly, this explicitly prevents your packages installing onto servers, and secondly it restricts deployment to your supported Operating Systems (you might want to edit this if you also support Windows 2000, and/or Vista). Click Apply to save these changes.
Moving the stage Collections
As I mentioned in the previous article, I like to keep all my console objects for software deployment in the same folder structure. In fact, I'm a bit fanatical about it. The console allows you to move collections natively within the interface, so its a doddle. In the Resources tab, select each of your collections and in turm move them into the root of the Software Rollouts folder (in the Tasks tab) as illustrated below
The result, as shown in the picture below, is that your deployment collections are nestled nicely in the root of your Software Rollouts folder. Feel free of course to rename these to a convention which you feel best suits your site.
Employing Stage Collections in Rollouts
As mentioned earlier in the article, the key to these deployments lies in the creation of master and intersect collections. Let's now create a deployment folder using this new strategy. There will be some SQL involved, but don't worry -I'll explain this later.
Using the rollout folder created in the previous articles, do the following,
- Remove all collections and reports from the Adobe Reader 8.1.3 folder, leaving behind just the task and package
- Create a collection in the resources tab, calling it "Adobe Reader 8.1.3 Deployment Group", and move it into you Adobe Reader 8.1.3 folder. This will be the master collection
- Create the collection "Computers in the Adobe Reader 8.1.3 Deployment Group requiring upgrade", and move this also into your Adobe Reader 8.1.3 folder. This will be the intersect collection. Edit the collection SQL, pasting in the following code:
select Guid from (SELECT vc.Guid as 'Guid', max(dbo.Custom_ConvertVersionToBigint(T2.Version)) as MaxVersion
FROM vComputer vc
JOIN Inv_Aex_OS_Add_Remove_Programs T2 on vc.Guid = T2._ResourceGuid
WHERE (T2.[Name] like 'Adobe Reader%'
AND T2.[name] NOT LIKE '% CE'
AND T2.[name] NOT LIKE '%Font%'
AND T2.[name] NOT LIKE '%Language%'
AND T2.[name] NOT LIKE '%Security Update%')
group by vc.Guid) xxx
where MaxVersion < dbo.Custom_ConvertVersionToBigint('8.1.3')
AND Guid in
(SELECT vc.[Guid]
FROM collectionmembership cm
JOIN item c
ON cm.collectionguid = c.guid
JOIN item r
ON cm.resourceguid = r.guid
JOIN vComputer vc
ON vc.guid = r.guid
WHERE c.name = 'Adobe Reader 8.1.3 Deployment Group')
- Repoint the task entitled Task: Upgrade Adobe Reader to 8.1.3 to only act on computers in the intesect collection created in step 3 above
- Add the Test Group collection to the previously empty Adobe 8.1.3 Deployment Group collection
- Enable the Task
And that's it -you've just started the first phase of your deployment. To move to the next phase with the pilot group, all you have to do is add the Pilot Group to the Adobe 8.1.3 Deployment Group collection. And similarly for advancing the rollout to the final stage by adding the Domain Group collection.
Summary
What I have shown you today is a way of designing your scoped software upgrades in a framework which allows you to progress your deployments as if they were unscoped. By creating utilsing master and intersect collections, you let Notification Server take on the hard work leaving you with a much simplified deployment.
Utilising such collection code templates (such as I've shown in today's article) allows you to both simplify and standardise your Altiris setup with regard to software rollouts. This in turn allows you the breathing room to allow such rollouts become a standard process in your environment. This in the end will make your rollouts safer, and take you that one inch closer to IT Utopia.
Kind Regards,
Ian./