I recently heard from the manager of a call center within my organization about a problem he was having managing the call center's PCs. The call center employs seasonal temporary telemarketers for periods ranging from one day to several months. Many of the workers are college students who know enough to tweak a system to the point at which subsequent users have a difficult time finding standard tools, such as Microsoft Internet Explorer (IE). The computers had basic logons, but the workers could—and did—install any program they wanted to. Productivity lagged because workers spent a significant part of their time playing games they'd downloaded or surfing the Web. To add insult to injury, conflicting drivers that workers installed kept bringing down the business applications and PCs.
The call center manager's solution to this problem was to use a ghost image to refresh the systems when they became excessively tweaked. I knew there had to be a better option than that. And because all the systems run Windows XP in an Active Directory (AD) environment, the solution was probably going to be implemented through Group Policy.
Finding the Solution
I have a strong aversion to recreating the wheel, so I thought about the resources I might be able to leverage to avoid having to configure all the PCs' Group Policy settings from scratch. I vaguely remembered reading a TechNet article that discussed using Group Policy to implement varying levels of restriction for different systems in an organization. A quick search for the term "kiosk" on TechNet revealed the document and provided at least temporary reassurance that age hasn't yet addled my brain.
That article, "Implementing Common Desktop Management Scenarios with the Group Policy Management Console," contains some information that has been available for quite some time but also includes updated information about Group Policy Management Console (GPMC) functionality and new OS releases. The coolest feature of this article is that it provides a link that let me download sample Group Policy Objects (GPOs) for the scenarios discussed and documentation that includes a Microsoft Excel spreadsheet listing the settings for each sample GPO. (You can find the article at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/management/csws2003.mspx.)
The article provided the sample GPOs as GPMC backups and included a batch file that I could use to import all the sample GPOs into a test domain. However, I chose instead to import only the policies that closely resembled what we wanted to implement on call center PCs.
I printed out the settings reports, then sat down with the call center manager to discuss his objectives and translate the GPO settings into plain English for him. After about an hour, we'd determined that the lightly managed computer and lightly managed user settings were best suited to the call center's needs. We also determined that we'd need a few minor additions and deletions to the defaults to fine-tune the GPOs for our use.
Implementation
I went to work. First, I used GPMC to create two empty GPOs—one for user settings and one for machine settings—and to import the sample settings from the lightly managed user and lightly managed computer GPOs that I'd downloaded. To these Call Center User and Call Center Computer GPOs, I added some settings and removed a few that weren't necessary or that might cause usability problems for call center workers. The lockdown settings I put in place prevented workers from installing unapproved applications and from altering IE's Favorites folder and home page.
Because call center PCs are so widely abused and treated so much differently than our typical users' systems, I created an organizational unit (OU) named Call Center to contain them. I used the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to move the computer objects into the new OU. I chose to block policy inheritance at the Call Center OU because we didn't want to apply some of our standard GPO settings, such as folder redirection, to these machines. I then linked the imported and modified Call Center Computer GPO to the Call Center OU. I identified a few other GPOs that I needed to apply to these systems but that were blocked because of the inheritance setting, and I linked those GPOs to the OU as well.
To target the Call Center User GPO to the appropriate user population, I created a new OU in AD called Call Center Users beneath the standard Users container and moved the call center workers' user accounts into that OU. Finally, I linked the Call Center User GPO to the Call Center Users OU so that the new user settings would apply to all accounts housed therein.
The Results
I've since made a few minor modifications to the initial GPOs for usability purposes, but overall the restrictions that I put into place via the Call Center User and Call Center Computer GPOs solved the problems. After a few months, I followed up with the call center manager and learned that worker idle time had been cut in half and the time the manager spends troubleshooting had declined by as much as two-thirds. I consider that a satisfying ROI for the 3 or 4 hours I spent on the project.
—Ed Roth
End of Article
Register
