HONORABLE MENTIONS Medium-Sized Business
Paul Ingram,
former IT director for CI Travel
pingram@cox.net
In his previous job as IT director for a $150 million travel company, Paul Ingram had to address the company mandate to reduce its gargantuan phone bill. CI Travel has about 300 employees at 49 locations across the United States and relies heavily on telephone communications to conduct business. "High phone bills were eating up company profits," Paul says. "Because reducing call volume really wasn't an option, I decided to take advantage of [Voice over IP] VoIP technology to reduce per-call expenses."
Paul oversaw the company's purchase and implementation of its VoIP service (currently 175 VoIP phones) on the corporate network, which consists of a highcapacity Gigabit Ethernet copper backbone located at corporate headquarters and a Multiprotocol Label Switching (MPLS) WAN that connects the 49 sites. The new VoIP phones dramatically reduced per-call costs but "came with a new set of problems," Paul says. The biggest problem was sound quality, which was far less consistent than regular phone lines. "Since much of the company's business is conducted over phone lines, I had to be certain that VoIP users were getting the best quality of service attainable," says Paul.
Paul soon discovered that what the company saved on its phone bill it might end up spending again on IT resources to monitor and troubleshoot the VoIP exchange. He sought a way to reduce the amount of monitoring and make the VoIP service more reliable. Paul chose a network-monitoring product, Network Instruments' Observer, which included a probe (a software agent) that let Paul monitor VoIP packets traveling over the WAN backbone.
Paul used Observer to troubleshoot problems such as erratic jitter occurring between network nodes. He captured packets traveling between the two sites, then replayed them so that he could pinpoint the problem. "A packet capture identified a misconfigured application that was hogging bandwidth and causing a general network slowdown. I reconfigured the misbehaving application and also defined a [Quality of Service] QoS policy on the switch to give VoIP traffic the highest priority, thereby preventing other applications from compromising VoIP reliability," he says.
Paul says his solution benefited the company by ironing out the kinks in its VoIP implementation and making its quality and reliability comparable to the standard phone system. "I was able to successfully manage VoIP traffic, providing the best QoS to our customers—and saving the company 25 to 30 percent on phone bills."
Bernie Pannone,
Systems Engineer, Delta Health Group
bernie@thepannones.com
Deploying an application on multiple PCs isn't an unusual job for an IT pro. Typically, you'd use Windows Installer to create a package, then maybe write a script that copies the files and performs the deployment. But what happens when the application files you have to deploy don't work with Installer? While on assignment as a systems engineer for a previous employer, Bernie Pannone faced this exact situation and found a clever way to solve the problem.
Bernie's client wanted him to deploy an inhouse-written application on about 200 XP PCs at six sites at various locations. "I can't mention the name of the software because it was so poorly written!" he says, laughing. In fact, the application filenames weren't Universal Naming Convention (UNC)-compatible, so he couldn't simply deploy the software by using standard Windows commands. Bernie further discovered that he couldn't package the software as an .msi file.
An old hand at scripting, Bernie naturally thought of writing a script to solve the problem. "I wrote a script (local.bat) that mapped the unused I: drive of each PC to a share where the .exe [the application] existed. As no user has the rights to install software, I created an Installer account and added it to the Domain Admins group. The customer ensures that the account is either deleted or disabled after each use because the password is in clear text and changes at every use," he says.
He wrote a second script, main.bat, which copied the local.bat file to each PC's Admin$ share and invoked the local.bat script by using a freeware tool, Sysinternals' PsExec, which lets you execute processes on remote systems from a central location.
Bernie used two other tools in his solution: the Windows Csvde utility and Excel. Before writing the scripts, Bernie used Csvde to import the client's Active Directory (AD) database into an Excel spreadsheetin comma-separated value (CSV) format. He then sorted the data he needed (i.e., names of the computers on which the application would be deployed) into one column, deleted the columns he didn't need, and saved the spreadsheet as a text file. The local.bat file contained this text file, the name of the executable, and the switches to use in deploying the application. (The application actually was compiled via InstallShield, so Bernie specified InstallShield switches in the script.) Once he'd determined the solution, working it out was fairly straightforward, Bernie says. "I had the Csvde conversion and both scripts written in under 30 minutes."
Bernie—who proudly says he's been a Windows IT Pro subscriber since the third issue of Windows NT in 1995—preaches the gospel of using scripting to solve administrative problems. "My soapbox is zero administration and scripting," he says. "I pound it into junior techs' heads at work." His ingenuity in using scripts to deploy a recalcitrant software package proves that Bernie practices what he preaches.
)
)
Register
Chet December 08, 2005 (Article Rating: