Monday, October 3, 2011

What Can Fail: Software Deployments

If you're using Microsoft System Center Configuration Manager, you're well aware that there's a lot of moving parts.  It often seems like staring into the back of an opened pocket watch, being awed by the mass of tiny gears working in such precision.  If you've been working with it for a long time, you're also likely aware that hiccups occur and that they tend to happen in certain places more than others.  Most CM administrators I know become familiar with particular groups of issues and have developed their own personal "solution" practices to troubleshoot and resolve them.

Package Configuration - check the data source settings, and the permissions on the folders and shares also.  Some packages don't need to be broadcast over the DP shares since they can't install from them at zero hour.  For example: AutoCAD network deployments, which contain a hard-coded UNC reference to the original administrative share location.  Yet it's very easy to let it be replicated, slowly (lots of content), and eat up a lot of disk space, when the installations will simply run back to the original location to pull installation content.  Tip: Use a script to call the installation, where only the script is replicated to the DP shares, but make sure the original share has permissions configured properly to allow the CM client/agent to install it via the advertisement.

Program Configuration - verify the command you entered as well as any additional parameters (aka "arguments").  Also, verify the disk space requirements and runtime limit value.  If you specify too large of values, some clients may fail the requirements assessment and the program won't run.  This will show up in the advertisement status details web reports for each client.  Watch out for quoted string values and special characters also.

Client Cache - the client cache can be a common source of headaches when deploying packages, especially when the same package has been updated several times, refreshed on the DPs, and re-run multiple times (usually to fix late-discovered issues).  It's not uncommon to have to manually clear out the previous package cache remains on a problem client.  It's not uncommon to have to clear out other/older deployments as well, just to free up total cache space.  Double check the client cache size setting also, but be careful about bumping the size up without carefully considering the ramifications as well.

WMI issues - as with many client health improvements in Configuration Manager 2012, I'm looking forward to seeing this issue go away.  You may be aware of the situations where you end up having to run a repair operation on the WMI stack in order to get a particular client to communicate with the site again.  Ugh.

Maintenance Windows - if you use maintenance windows for your CM site, be sure to evaluate how your software updates are being deployed and how it impacts other packages as well. Sometimes a small adjustment is all it takes to make it work, or not work at all.

Network Issues - with all the incredible power and complexity of Configuration Manager, it can't do anything if the network isn't reliable.

Anti-Virus Hurdles - yep. sometimes anti-virus products can get in the way with deployments.  Quite often by ripping out just one or two key components during the installation process (or right after) and crippling the application.  If an application works fine in your test environment, but not on the production environment, check the antivirus scan logs and quarantine reports.

Prerequisites - many software products expect things to be at least up to a certain baseline before they can install.  Sometimes they will also take care of filling in any missing requirements.  Sometimes they can't, and when they can't, they fail to install.  This should be addressed during testing, but sometimes things get missed.  Other times it stems from human communication issues.  You might have asked the desktop support team if .NET 4.0 was on every client and they might have said it was, when in fact it was only on some computers, and you didn't bother to verify this yourself.  There you go.

Custom Packaging - if you (or someone you work with) created the installation source internally, verify any pre-requisites: operating system, version, service pack level, .NET or IE requirements, 32-bit or 64-bit, and so on.  This should all be hammered out during testing, but sometimes things get missed.

Square 1 - Level 0 - if the application you're looking to deploy needs to be part of every desktop and laptop in your organization, don't forget to consider making it part of your standard image deployment as well.  If you use MDT or Configuration Manager OSD to handle your client provisioning, add your application there as well.  That way it's one less thing to push over the network later on.  It's also quite a bit less complext to implement and troubleshoot during the base imaging process than when deploying over your network environment later.

Summary

I must say that you shouldn't construe this to be a ridicule of Configuration Manager 2007 at all.  Configuration Manager is a fantastic product.  But like all products that serve a similar role, there's a lot of intricate things going on in the background, and a lot of things depend on how you configure and maintain them as well.  Many CM implementations experience only minor hiccups, while others have more frequent issues.  A lot of that is dependent upon how well the environment was designed, implemented and maintained.  It also depends on how well the clients are maintained, but software installers themselves are often the wild variable in the equation.

I'm sure there's more to add to this list, but this is enough to jot down for now.  For more insight into Configuration Manager and package deployments, check out some of the links below:

I know I haven't even come close to covering everyone that I should, but if you check out these folks, and see who they link to, you should end up with a pretty good list of amazing and interesting people to learn from.

Posted by
Labels: , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)