Metrics, metrics, and more metrics.
I've been analysing the results from the last few months of deployments (encompasing nearly 300 machines across several departments with varying hardware) by 'binning' the deployment times got the graph below,
The blue diamonds are real results, the the two gaussian curves are trend-fits. The total deployment time is the cummulation of the time to,
- Deploy the image with rdeploy
- Run Windows mini-setup
- Install latest patches (Flash, Adobe Reader, Java etc)
- Install Departmental specific software (i.e. business critical software not present in the main image)
- Install the Altiris Agent and get it's GUID
- Domain Join
These statistics are generated from our deployment reports -a custom addition to our DS environment. We tag our job sets in ImageInvoker with a dummy job called "(START)". The last job in our deployment jobsets generates a deployment report detailing (among other things) the time and duration of each of the jobs which were executed on the machine since the start marker. These results are emailed to a log server for archive. A vbscript can then be run on demand to extract the total deployment times from the archive for histogramming in Excel.
The First Peak
The probabiliy peaks show that a machine is most likely to be deployed in 38 minutes. This highest peak corresponds to the most department builds where the software deployed post-rdeploy is restricted to web plug-in updates and small departmental packages. The standard deviation here is quite small at 7 minutes. The primary causes of this spread are,
- The time it takes the agent to get it's GUID.
- Vaguraries of network performance
- Deskop hardware variations
The Second Peak
This peak is lower and fatter with twice the standard deviation of the first. I think that if we'd been able to harvest more data, we'd see a bit more structure. This peak is mostly due to departmental deployments that contain major package deployment as a post-image job. These come down over the network, and we see a wider spread here due to the extra time required to download these packages on a intermittently busy network.
Another reason for this peak is due to our image deployment methodology -USB Flash drives. Sometimes a helpdesk tech will select with ImageInvoker and image which is not present on a USB Flash Drive. This results in our accelerated deployment option (using a local image) being unavailable and the image automatically fails back to a server download which is lengthy. These results merge into one peak as the time taken to download from the server, is about the same as the time taken for a fast flash deployment followed by large departmental package download and install.
What's Next
Ideally, we want more imaging sessions to fall within the boundary of the first peak.
Whilst we can't accelerate the deployment of the large post-install packages we can get more imaging sessions to be directed from the attached USB device. I had a chat to one of the techs and implementing an option to update an USB stick with a missing image before engaging a server based imaging session looks like a winner. That way, if they haven't updated their drive before imaging only their first imaging session will be delayed (in order to update the USB drive) -subsequent imaging sessions will however be at the top-notch deployment rate.