5 Rules for Managing User Desktops
Here are some tips for dealing with users in a relatively pain-free fashion.
After hopping up on my soapbox last
and wagging my finger at administrators who demand the benefits of proactive desktop administration without the learning curve, I've had more conversations with administrators who seem to understand the problem. They're still searching for answers, though.
In many ways, the problem is organizational in nature rather than technical. In last month's column, I discussed how making the jump from reactive to proactive behavior involves an initial spurt of extra effort before you can reap the benefits. With the right systems-management toolsets in place, though, you can manage virtually every component of the desktop lifecycle.
Management Best Practices
From operating system and application installation through configuration, troubleshooting and patching, finishing with hardware refresh and user state migration, there are technology-based solutions today that can automate all of these manual steps. Developing the experience to use them in the best way possible is what many administrators need.
These discussions got me thinking about the best practices for managing user desktops. Gleaning from my own experiences doing this for large enterprises, I've come up with five simple practices I consider when doing any of the tasks listed above. None are highly technical. All are designed to guide your actions when interacting with your user's desktops.
These were originally put together for a recent Redmond magazine webcast with Kaseya, and I thank them for letting me share them with you.
Rule No. 1: If you leave any component of desktop management to the user, you're no longer managing that machine.
Many desktop management toolsets available today let you relegate certain management components to the user. You can give your users the ability to install their own pre-packaged applications. They can reset or reconfigure predetermined desktop configurations. They can adjust their own firewall settings and install patches when it suits their schedule.
The problem with this abdication of duties relates to the user's responsibilities within the business. A user in the accounting department is responsible for the financial documentation of the business. A person in sales is responsible for selling. Neither is responsible for or has the proper knowledge regarding the health of the IT infrastructure, an infrastructure that includes their assigned desktop or laptop.
By assigning responsibilities for desktop management back to these users, you effectively rescind proactive control over the environment you are chartered to control and manage. Interestingly enough, the converse is also true. In neither of these jobs would the other person delegate their accounting or sales responsibility to you, "the IT person." You don't have the proper experience or operational knowledge in place to do their jobs either.
Rule No. 2: Never interrupt the user's workflow.
Using automated deployment systems to distribute patches and applications significantly speeds up the installation process by eliminating manual steps. As with skinning cats, though, there are many ways to get the bits and bytes onto users' desktops.
One of the least successful ways to do so involves interrupting the user's workflow. When you have applications and patches installed in ways that cause your users to see pop-up windows or splash screens, you often get user irritation and a spike in help desk calls in return.
One solution for this is to ensure that you only distribute software and patches when users are logged out of their workstations. This accomplishes the double duty of preventing user interruptions, while also ensuring critical files on the desktop aren't being used.
Should users forget -- or refuse -- to log out at the end of their workday, simply instruct your desktops to reboot before distribution. If you do this, informing users of such a policy is probably a good idea. An auto-rebooted machine containing an unfinished Word document is equally a source of user interruption.
Rule No. 3: With desktop management, never ask for the user's opinion.
Some automated-management toolkits let you give your users options. Don't want patches installed right now? Just delay them until later. Not ready for a software update? Reject the installation. As with Rule No. 1, providing options to users increases the management effort required by IT while also forking the desktop baseline.
Providing options in core desktop configurations is a lot like giving your users just enough rope to hang themselves. They'll enjoy the freedom, at least until they start experiencing problems and application conflicts. In the end, the desktop instability that comes as a consequence of user choice becomes IT's problem to fix.
Rule No. 4: Computing equipment belongs to the business, not to IT and not to the user. Manage it as such.
Many of these rules sound draconian on paper, but ultimately computing equipment is provided in order to drive the business needs. Users who gain a sense of ownership over their desktop systems often end up forgetting that point. Desktop personality elements are necessary for bringing a sense of familiarity to a machine used every day by its user, but the customization stops there.
With the right systems-management toolsets in place, you can easily transfer that personality from one desktop to another. This gives IT the right to rip-and-replace desktops as necessary for troubleshooting, upgrades and hardware refresh purposes. When IT works to bind users to their "personality elements" instead of their individual machines, this enhances IT's ability to better do its job and ultimately serve its customers.
Rule No. 5: Moving desktop management from reactive to proactive will initially involve more work than less, as we discussed last month.
Making that necessary jump from a reactive mode of constant firefighting to a proactive mode of measured and calculated change requires two components.
The first is a proper systems-management toolset that helps you with automating common and otherwise manual tasks. The second is the knowledge and experience necessary to broadly implement change with minimal impact to users. Learning the key skills discussed in last month's column and following these few rules goes a long way toward getting you to that desired conclusion.
Greg Shields is a senior partner and principal technologist with Concentrated Technology. He also serves as a contributing editor and columnist for TechNet Magazine and Redmond magazine, and is a highly sought-after and top-ranked speaker for live and recorded events. Greg can be found at numerous IT conferences such as TechEd, MMS and VMworld, among others, and has served as conference chair for 1105 Media’s TechMentor Conference since 2005. Greg has been a multiple recipient of both the Microsoft Most Valuable Professional and VMware vExpert award.