LinLog

USB drive pain

pageer@skepticats.com (Peter Geer)

It's time for another tale of IT pain. You remember CRAPS, the pathological police system we're required to use? Well, it struck again.

Today I had to travel to a nearby police agency to assist them with their CRAPS installation. They were having problems with the data transfer between the field units and the office. This is normally accomplished via a removable USB drive. In order to ease this procedure, CRAPS includes a feature to automate the copying of data files to and from the USB drive. Basically, the user clicks a button and the data files get compressed and moved in the appropriate direction.

The problem with this feature is that it's not very friendly from a configuration point of view. You see, CRAPS doesn't actually know anything about USB drives. It just knows about paths, and they're configured statically. So you actually have to tell the software, "use drive F: for the data transfer."

What's worse, CRAPS isn't even very smart about handling paths. As you probably know, when Windows detects a USB mass storage device, it assigns it the next available drive letter, so you can't depend on the same devince getting the same letter every time. However, CRAPS requires that a CRAPS administrator configure the drive letter ahead of time and it cannot be changed by a regular user. So the user ends up with, for example, a drive with multiple partitions, he can't use it until an administrator can reconfigure his system. Which sucks.

The first problem today was that CRAPS can't even join paths properly. We were having problems with the data transfer feature mysteriously failing on a couple of workstations. The USB drive path was correctly set to E: in CRAPS. However, just on a lark, because I know how cranky CRAPS can be, I tried chaning it to E:\. And you know what? It worked. *THWACK* (That's the sound of me smacking myself in the head.)

My second problem was partly Windows, partly the fact that I didn't set up this other agency's network. You see, on one workstation, the USB drive was being mapped to F:, but the primary network share was also being mapped to F:. The result? The network share clobbers the USB device and you can't access the USB drive until the network share is disconnected.

This is a fairly well known problem. As I understand it, the cause is that drive mapping is done on a per-user basis, and while network shares are mapped by the user, USB drives are mapped by a system account. There are a number of possible fixes, of course, but they all kind of suck - especially if you don't have any significant ownership over the system you're working on.

Nothing is ever as easy as it should be. Which is why "IT land" sucks.

Company-thwarted testing

pageer@skepticats.com (Peter Geer)

This week, I'm doing product evaluations at work. Specifically, evaluations of highly enterprisey system management applications. Things like Microsoft System Management Server (though I'm hoping to find a package that's slightly less hideously complicated to administer). And you know what? It's really starting to piss me off!

It's not researching an evaluating these systems that's pissing me off. Although it probably should. After all, I'm a "systems analyst," not a network administrator. I don't touch the servers without explicit permission from the network admin, and therefore don't have a great deal of experience in this area. This is not because I don't know what I'm doing (though I don't claim to be an expert on Windows administration), but because the admin jealously guards his network, and he will strike down those who trespass upon his servers with great fury! Woe to any analyst or programmer who should mess up a server in even a minor way, for he shall never again get anything done on the network. So sayeth the Lord!

The real reason I'm pissed off is that I have no test hardware. Or, more to the point, I have test hardware, but it really, really sucks. To summarize, in order to set up a Windows Server 2003 box, I'm using an old XP desktop with a RAM module cannibalized from an identical desktop just to get it up to 1/2 a gigabyte. The client boxes I'm going to have to set up will have a whopping 128MB of memory a piece. And this is the best we've got available.

Of course, my ideal setup would be to just use a completely virtual test network running in VMware. However, I'm planning on 1 server and about 3 clients initially, and the most powerful box I have available is my desktop workstation, with a measly 1GB of RAM, which would be kind of pushing it. So I'll probably end up with 4 PCs sitting in the server room running VNC servers so that I don't have to physically walk back there and let the roar of the air conditioning system slowly destroys my hearing.

The second reason I'm pissed of is because of who this project is for. If our organization made any sense, we would be looking into system management software for the 300 or 400 (or whatever - I've never seen the exact number) desktops that we support. But it's not. This is for a collection of about 60 mobile laptop units that are scattered across the countryside and hardly ever make it in to the office. The idea is that we'd like to manage updates, installations, configuration changes, and so forth on them without having to drive them 30 or 40 miles to someone with administrator access. I have no problem with that, since only three people have admin access on those machines, and I'm one of them, so it saves me some effort. It's just that it would be nice to be doing something like this in the place where it would save the most work. But then, without the constant running around clicking "next" and such, our department wouldn't have an excuse to be grossly over-staffed.

I guess the take-away here is, "Don't work for the government. Especially local government." There may not be much stress in the Silicon Valley sense, but the frustration and futility levels are through the roof. But on the up side, you can pretty much take a vacation day whenever you want and nobody cares. It's just a matter of whether you prefer stability and flexibility or a feeling that just maybe your days aren't completely wasted.

Office meetings

pageer@skepticats.com (Peter Geer)

You know what sucks? Office meetings. And I'm not talking about "office meetings" in the sense of meetings that take place in a room full of cubicles populated by people who die a little inside every day. Although those suck too. No, I'm talking about meetings about Office. Microsoft Office. Specifically, my employer migrating from our current, hideously out-of-date Office 97 plus Outlook 2000 setup (don't ask me why the two versions) to Office 2007.

We've been having these meeting every Friday since the beginning of April. The first one was an entire hour on Microsoft Outlook. The second was 45 minutes on Word and Excel. The third was half an hour on Access. Since then, the meetings have been on the order of 10 minutes a piece and have consisted mostly of someone from the help desk saying that the new version had been installed on so-and-so's PC.

Believe it or not, there is a matematical reason why we continue to waste our time on these pointless meetings even though we've run out of things to talk about. You see, in any bureaucratic organization, the number of total meeting associated with a project is given by the equation:

Here, m is the number of meetings, d is expected project duration, i is perceived importance by management, and s is the sanity quotient of the organization. Note that there is no factor relating to the need for discussion.

In our case, the Office 2007 installations will take a while because we have to do it all by hand - having an automated deployment system would make far too much sense. And since the new version of Office affects every department and is highly visible to users, my boss thinks it's extremely important. And as for the final factor, as a government agency we necessarily have an extremely low sanity quotient. Thus we have a standing meeting, even though it's completely pointless. Ain't bureaucracy grand?

Stupid user tricks

pageer@skepticats.com (Peter Geer)

It's funny the things people fail to grasp when it comes to computers. Sure, there are always the "complicated" things that are the realm of "the IT people," but there are always some users who don't get the basic concepts. Kind of like Raymond Chen's relative who thinks everyting is Outlook. he user was complaining

My favorite example of this I wittnessed by accident. I was doing an installation of some crappy software that I own (read: was foisted upon me) and the last workstation I need to do just happened to be the same one our lead PC tech was working on. We had recently switched that location to a different Windows domain and the user was complaining that his bookmarks had disappeared. However, the tech had already checked the user's profile directory and the couple of Internet Explorer favorites he had were still there.

The problem? Terminology. When the user said his bookmarks were gone, he was really referring to the recently typed addresses in the location drop-down. It turns out he only ever visited the same handful sites, so the the "recent" locations were always the same. Since that's where all his links were, he apparently just assumed that those must be those "bookmarks" everybody's always talking about. In this day and age, you'd think that everybody would understand bookmarks by now. But you'd be wrong.

Then again, there are also those users who just don't seem to be paying attention. One day, I was walking back to my desk and saw one of the help desk techs sitting slouched over, shaking her head. When I asked what was wrong, she recounted the following call.
Tech: "Help desk. What can I do for you?"
User: "I'm having trouble printing."
Tech: "OK. What are you trying to print from?"
User: "My computer."

I think this tech is an example to us all. Or at least to me. She calmly and professionally answered the user's question. I, on the other hand, don't know if I would have been able to prevent myself from openly mocking the user. "Your computer? You're sure you don't mean your calculator or your phone?" "Oh, your computer. I'm glad you cleared that up. I mean, this is the IT help desk, so it's sometimes hard to tell if a call is going to be computer-related. Thanks for saving us that extra question." I mean, it's just too easy. You almost have to take the shot.

The security is CRAPS-tastic

pageer@skepticats.com (Peter Geer)

Yesterday, I was telling you about the ridiculous install procedure for CRAPS. Today I'd like to continue the discussion.

As you remember from last time, the recommended procedure for getting the MS Access databases CRAPS uses on your network is to just install all the software directly onto the C: drive of your file server. If you're in IT in any capacity, and are at least marginally competent, I shouldn't have to explain why this is really stupid.

The customization and configuration process is similarly disjointed. Some of this you do in a crowded graphical configuration dialog. Some of it you do by hand-editing INI files. I'd say it's about a 60/40 split. And, as an added bonus, for a few settings you actually have to hand-edit rows in one of the database tables. Unless you don't have Access 2000. Then you just live with the defaults.

From the care and attention they put into the installation and configuration process, it should go without saying that the CRAPS developers take security very seriously. Thus they decided to use "binary files (also known as flat files)" to store certain data on field units. After all, "Binary files use a format that is specific to the application that creates them," which means that other programs are "unable to interpret binary files that they did not create. This makes [CRAPS] data secure, as only [CRAPS] can interpret and use its binary files." And if you don't believe me, that comes directly from the CRAPS administration manual. Seriously. The only thing I changed was the name of the system. The manual also claims speed and smaller file size as benefits, despite the fact that field units are single-user laptops with Pentium IV processors and 80GB hard drives.

It's always a bad sign when the developers feel the need to justify their choice of data format in the user manual. So it probably comes as no surprise that when you actually look at one of these "binary files," it contains mostly serialized text data. It's definitely not encrypted and most of it isn't even really binary. With a little intelligence, it's not even too hard to figure out the format just by looking at it. It sure is a good thing that opening sequential files in Vim is such a well-guarded secret, or else the security benefits might not seem so compelling.

And even worse, some of the "binary files" referred to in the manual are just standard formats. For example, guess what the "binary" import and export files are? They're ZIP archives! With a different file extension!

The really sad part is that, for all its fauilts, CRAPS actually works fairly well. Yes, it's slow (despite the speed benefits of binary files), the configuration is tedious, the user interface is arcane, and the whole system has a feel of being held together with duct tape and bailing wire, but it does work. It truly is worse than failure.

Tales of IT: Introducing CRAPS

pageer@skepticats.com (Peter Geer)

Today I start a new series: Tales of IT. In this series, I will be discussing some of the more humorous things I come across in my work in the IT world. Some are funny ha-ha, some are funny-weird, and some are just funny-sad.

Let me start by telling you a little about what I do. I'm a "Systems Analyst" for a local governement agency. In my organization, that means that I do software development (that's my favorite part), analysis, some server administration, some help desk stuff - whatever comes up. So at this point, I can basically do some of everything.

Now let me tell you about the organization I work for. Being the government, it should go without saying that it's extremely disfunctional. One of the more annoying disfunctions of the IT department is what I call the "you touch it, you own it" theory of tech support. By that, I mean that, for any software system (especially big, complicated, or expensive ones), there is an analyst who "owns" that system. Ownership is determined on a first-come, first-served basis, so if you're the first person to touch a new system, you will own that system until you quit, retire, or die. The natural result of this is that nobody will ever volunteer for anything.

Now, you may be thinking that having a "local expert" on every system we use is a good idea. And you'd be right. It is a good idea to have somebody with a degree of in-depth knowledge around. That isn't the issue.

The problem is simply that the whole situation is completely demoralizing. When you own a system, you become the goto guy for all problems related to that system. That includes everything from the hardish analysis work of determining the proper system configuration all the way down to the grunt work of clicking next through client installations on a couple dozen workstations. If somebody calls the help desk with a problem related to your system, it gets passed straight back to you - the help desk doesn't even try to resolve it or even get more information.

This brings me to a system I own, the Crazy and Ridiculously Attrocious Police System, or CRAPS for short. CRAPS is the system used by the police force to write tickets, take accident reports, and so forth. I got stuck with it because it runs on the terminals in the police cars, and since I already owned the 911 dispatching software on those terminals, and my boss apparently didn't think I had enough pain in my life, I was the obvious choice.

I've got plenty of stories about CRAPS, but today I'll just tell you about the system itself. For starters, CRAPS has a "client-server" design. By that, they mean the system stores data in Access 2000 databases that sit on a file "server" and that the "clients" get pointed to the mapped drive or UNC path to those databases. Sort of.

You see, the CRAPS manuals and installation program seem a little confused about just what a server is. The installer has options to perform a "server install" and a "client and server install." What this choice really comes down to is "install just the .MDB files on this machine or install the .MDB files and the program files on this machine."

The important thing to note here is that both options are for this machine. That means that if you want to do what we did and put just the databases on your file server, the installed expects you to log in on the file server to run the installation. You can't just run from another machine and point the installer to the network location. I know, I tried. It fouls up things in the next stages of installation. It turns out that there's a reason the manual "strongly recommends" that you keep the default installation path of C:\CRAPS - things tend to get messed up if you don't.

Part of the reason things get messed up is that a basic CRAPS install is a 2-step process. First, you install the base system. Second, you install an add-on package with all the databases you need to actually get things done. The databases from both packages need to be on the server, but there is no "server install" option for the add-on databases. In fact, you can't even change the installation path. They get installed to the same path as your base system. Unless you changed the default path. In that case, some of the files get installed to the right place and some of them disapear into the ether, never to be heard from again. In fact, I've found that it's more reliable to just install everything on a workstation and then copy manually copy the data directory to the file server. It really shouldn't be, but it is.

At this point, CRAPS is installed on the file server, but is not yet functional. We'll explore how to make it work tomorrow.