I’ve got the week off because The Automotive Company™ I’m contracted to is having its annual two week shutdown the first two weeks of July. This is an unpaid vacation because the contract house I’m working for doesn’t accommodate the shutdowns the way other contract houses I’ve worked for in the past did. Fortunately they’re only making us sit out one week and not the full two as that would mean the complete loss of one paycheck.
I’ve been with this contract house and this new job for a month now and I have to say that I’m going to try and keep my time with them as brief as possible. This position is about as entry-level as you can get and still call it an IT job. At the moment I’m functioning more as the arms and legs of a software team that does all its work out of an office in Canada. My job is basically to make sure the equipment gets to the desk and then I set it up and turn in on and then they take it from there. At least, that’s the idea. The reality is that they don’t have all the info they need to do the job remotely when I first set things up because the process they have in place is, to put it simply, idiotic. As a result if the user who’s getting a new PC is lucky they’ll only be down for most of one day, but usually they’re not that lucky and getting things completed can take upwards of three days or more.
Here’s why: I show up at a desk and the new equipment is there so I call my “RC”, I can’t recall what RC stands for, and tell them that it’s ready to go. They call the software team who schedules a disk wipe of the old equipment that will take place as soon as the user next logs off. They tell the RC and the RC calls me and I ask the user if they’d please log off their PC. If they do the system immediately reboots and proceeds to wipe their HD (all data is stored on remote servers so there’s no need to back anything up at first). Sometimes the disk wipe doesn’t work on the first try and I have to contact the RC who contacts the remote team and we play phone tag until someone figures out they mistyped part of a MAC address or IP address and finally it works. That’s usually a sign things aren’t going to go well. At this point the user is committed to the process. We can’t put his old PC back into place if there’s problems with the new one.
Next is the easy part, except for having to crawl under desks. We break down the old equipment and bundle it up to be shipped to storage and then put the new PC in place and boot it up. We then write down the MAC address and the subnet the new PC is on and call the RC so they can put in a ticket requesting the remote software team submit a build for the new PC. Why no one bothers to get this info ahead of time someplace else so the build can be ready to go prior to us arriving at the user’s desk is beyond me, but there ya go. Again, if the user is lucky the submitted ticket will be picked up within a few minutes, the info will be transcribed properly enough for them to enter it correctly, and I’ll get a call back in ten minutes or so to reboot the machine at which point it works on the first try. That happens maybe 50% of the time I’d guess.
When things go badly then it can mean the ticket isn’t picked up for awhile, sometimes for more than an hour, and we have to leave the current location and go to someone else’s desk and get them ready for the exciting adventure of getting a new PC. Finally the call comes in and we go back to the first PC we were working on, reboot, and wait with nearly literal baited breath to see whether or not it kicks off like it should. Too often it fails to launch so we try it again just to be sure it wasn’t a network hiccup and then we call the RC who puts in another ticket and, if we’re lucky — which we’re often not, you’re probably noticing a pattern here — the remote team will call us directly to work out the issue. When that happens it might take maybe an hour or so to get the build started. When it doesn’t happen that way, when the remote team insists on playing phone tag with the RCs, then we may revisit that PC another half dozen times over the course of the next several days before they finally get their shit together and get it working. Usually that’s due to a misunderstood bit of data. A wrong subnet or MAC address or something else as stunningly stupid. One PC we worked on last week we ended up visiting two or three times a day for four days straight before they figured out what they were doing wrong. Because it’s all remotely run there’s not much we can do other than re-read the same info back to the RCs and hope they transcribe it properly.
Once the build is actually launched the deployment of the image, the base OS, assorted drivers, and universal software, takes maybe 20 minutes. Then the managed software install starts and that appears to be throttled to keep it from overwhelming the network so, depending on how much software the user is getting, that can take anywhere from two to four additional hours. Once that is done the user can login and about 90% of the time they’ll have all their software and can go right back to work. When the process works it takes too much time and when the process doesn’t work it takes an inordinate amount of time. They could eliminate some of this idiocy by giving us field techs laptops and allowing us to submit the build requests and communicate directly with the remote software folks, but that would eliminate some of the functions the RCs perform and would require them to spend money on providing us with laptops thusly reducing some manager’s bonus for cost containment. It doesn’t help that the locations of the PCs we’re working on are often far apart from each other with one or two on one floor of a building and one or two on some other floor of a building so there’s a lot of time eaten up just walking to the next PC to be done and then back to the one that’s not working. This process is affectionately referred to as “running tickets” and is met with the same enthusiasm as having a root canal done without anesthetic.
When I first started at this job we were doing more traditional style system refreshes where we’d set the machine up and build it first and then work with the user to transfer their data. As near as I can tell, running tickets is limited specifically to a certain class of workstation used in CAD/CAE work which we’d normally not be involved with. Since that first batch of refreshes we did when I first hired in, though, they’ve not been able to get the machines available for the next go round so they stuck us all on running tickets so we’re not just sitting around the whole day twiddling our thumbs, which is what we did do a couple of days before they stuck us on tickets. Personally I can’t wait to get back to the refresh team as it at least uses some of my technical skills and know-how compared to being a robot for the remote software team doing CAD/CAE boxes. The process for refreshes isn’t perfect, but you have an ability to influence the process and make it at least slightly less imperfect and it at least works 95% of the time.
So despite the fact that I’m not getting paid this week I have to admit that I’m enjoying the time off. Running tickets will wear your motivation and love of life down pretty quickly until you learn to repeat the mantra they’re not paying me enough to give a shit and then, perspective in its proper place, you can relax a bit.