Saturday, January 19, 2008

Database Druid versus Desktop-Support Sage

This past week I took a call from an IT guy from one of our sister agencies who was in Dallas.

He had a collection of laptops he was needing to install for their users, but there was one little problem; the image on the drives was wrong.

Lost

Seems the procurer ordered them from Dell using a direct order, and not with one of our specialized state contract channels.  That resulted in the drives getting bare XP images, and not our highly customized agency images.

He called us since we have a few of their users in our area and he was going to need to come down here to Houston also to install the laptops for those users.  Perchance did we have a good laptop image?  Seems no one on his agency's side did.

Turns out we didn't either, but we had one close enough we thought we could get it working for him.

He drove in and by the time he got here we were able to work with his IT team to try to get one of the stored images off a networked image-repository location.  (That ended up being a two-day fiasco that never bore the expected fruit.)

So we called it a day and ended up deciding to try one of our other "close-enough" images for their agency I had.

The plan was that if we could get it up just enough, we could then re-prep it, and image all the others he had, saving him days of work since he was already seriously behind.

Turns out the poor guy wasn't a "real" IT desktop-support guy.  We had assumed he was since he was delivering and installing laptops.  He was actually an IT database manager who somehow got pulled for the job.

I quickly lost him when I began outlining a plan of attack for the image work.  He knew of Ghost but that was it. I mentioned using a faster solution called imagex and needing to be sure to do a Sysprep and making sure we got new SID's on the machines (see also the NewSID tool). He was clueless.

Found

Fortunately, I already had an Imagex wim file of a desktop system from their agency that was pretty recent. So we decided to try that one.  Using a desktop image on a laptop is always a dicey affair. Hardware is pretty specialized on laptops and drivers are a booger to work out if they aren't on the image.

The image went on smoothly and the laptop was "functional" except for only having about ten drivers missing.

I tried to download and apply the laptop-model's driver package Dell that I have access to, but for some reason, none of the drivers were accepted by the XP system's driver installation wizard.

So I ended up having to download the individual laptop component drivers based on what I pretty-well thought they were and installing them by trial-and-error.

In the end, I was successful.  I ended up with only two cryptic missing drivers. One was a "PCI device" and other was a network controller.  Turns out the network controller was for the Bluetooth adapter.  That took me a few minutes to figure out since I had managed to get all the network adapters working (Ethernet and wireless) until I remembered this model did come with Bluetooth. The "PCI device" was harder.  After about ten minutes of pondering, I remembered the laptops have internal modems.  I looked for it in the device-list but it wasn't there. One more driver download from Dell and all the hardware/drivers were fully functional and loaded.

I turned the laptop back over to our visitor who then got with his IT team and they remotely finished the desktop setup and configurations with him as well as bringing the OS up to date with patches.

When they were all done, I used one of my own generic agency sysprep packages on it and got it bundled up.

I then used a WinPE 2.0 and ImageX boot disk I made and captured the system image to a portable USB drive.

I showed him how to apply the image to the remaining systems and left him to it.  In about four-hours he had the remaining laptops all imaged and ready for deployment

One last thing I did was to "bake" a WinPE 2.0 boot disk with Imagex and the custom image.wim file (how-to here) onto a DVD.  This way he could now have a working image disk in case of any issues.

Next day he was out the door and on his merry way.

Lucky for him he fell into our IT group's lair.  We just happened to have both the knowledge, resources, and time available to spare him a lot of work and trouble.

Shop Talk

While we were chatting during the process we did some "shop-talk."  He was looking into getting a new system and we talked about the "home-brew" building techniques versus OEM pros and cons.

He asked how he could preserve all his programs and settings when he reloaded his XP system. So I gave him some (limited) options.

I asked him why he was going to reload his system.  Turns out it was running slower-and-slower over the past two years and he heard that you need to reload your XP system every year or so.

I encouraged him to try some relatively easy fixes first, before doing a system-reload.

He seemed very pleased with the information and tips.

The One Thing that illustrated the Big Difference (to me at least)

Even though he was from a database administration background and my specialty is desktop support, we pretty much talked on the same IT level.

It wasn't until I was driving home late that night that it struck me where the difference was that I had observed and had been nagging at me.

When I was showing him how to to use the WinPE 2.0 boot CD and the USB drive, I reminded him that the laptops came from the factory with the BIOS set to boot from the floppy, the internal drive, then the CD-ROM.  I helpfully told him that he would need to break into the BIOS to change the boot device order.

He smiled and said he didn't need to do that.  He would just do a one-time-boot option to use the CD-ROM. He did that to save time and not need to deal with the BIOS settings.

This was the philosophical and practical difference I realized that pointed out (to me anyway) the difference between IT support folks who support applications versus those (like me) who support entire desktop systems (hardware, software, networking).

His perspective was that even though he was going to be setting up the pcs, he needed to only use the boot-cd media once to accomplish his task at hand.  Made perfect sense to him from his perspective.

Mine was to go in and permanently change the boot-device order in the BIOS.  From my perspective, I (or my team-members) will eventually be back in front of this machine in the future. We will need to re-use a boot-cd disk to do future work on the system, or for imaging, or for the final secure-data wipe when we retire it.  So it makes sense to me to make a permanent change now to avoid having to do it later.

Both solutions work well, they were just based on the different ways we relate to the system.

I thought it was interesting, anyway.

--Claus

No comments: