In 2009, I worked briefly as an IT volunteer for a community college in my area. One of the things I noticed was the lack of scripting employed by the IT department - a common mistake I've seen made by a lot of Windows shops.

Most of their maintenance was accomplished machine-by-machine. Installing software, cleaning machines, rebuilding, and almost anything else you can think of was done either through Active Directory and Group Policy, or physically walking up to the machines and interacting with them.

As someone with a strong Unix background, this methodology for maintenance is quite contrary to my instincts. Textual interfaces are universal interfaces, as our Unix forefathers taught us.

Their regularly scheduled maintenance included deleting student profiles between semesters, and logging into the machine after local maintenance to preserve the correct domain for students to log into (students, apparently, could not recognize that domains were also required for them to log into the machines).

The reason why this particular chore was not scheduled as a task to be repeated regularly was because of its relative rarity - it only occurred once a semester. The truth was that in the time the IT department manually cleared all the machines, they could have written a decent script so that they would never have to trouble themselves again with this task.

The other problem was the tool they were using. You couldn't just build a wrapper around the tool and call it done. The user profile cleaning utility (delprof.exe) could be run remotely, but it was indiscriminate with which profiles it cleansed from the computer. Delprof had two modes: it could cause a massacre of profiles based on timestamps: the newer ones would be saved by virtue of their naissance, or it could destroy nearly every profile on the computer. You could set it to prompt you on what to delete and what not to delete, but given that most of these machines were used by hundreds of students over the course of the semester, this was a unattractive alternative. If only you could select by a regular expression...

Apparently, before a cut, they had been using a management system to help them manage profiles across computers. Unfortunately, this system, was rather expensive - especially for something that should be somewhere built into the OS's management features, right? For a small IT department like that one, the loss of the ability to manage profiles was a major blow to productivity.

Now, it might just be that I'm a Unix/Linux guy, but this looks like something that scripting should be able to solve fairly well, right? I imagined that such a simple script (something that deleted a set of folders based on a regular expression) would take very little time.

When I brought this up, my recommendation was pretty much shot down. Their reasons?

I can understand the first point. IT Departments are really pressed for time, but scripting seems like an investment of this time that will eventually pay off.

The second point is likewise understandable. Unfortunately, of course, we simply didn't have the capital to purchase a pre-built solution.

The last two points, however, are extremely aggravating for me. The CLI is what computers should be built around. As this article points out, repetition and automation is the playground of the command line.

Now I love challenges. Computer games are nothing compared to the pure, wonderful challenge of scripting or programming - that's where the real gaming is: the beautiful challenge that has very few parameters on how it should or can be accomplished. The idea that this was somehow too difficult to accomplish made me a little peeved and excited all at once. I argued that since I was part-time anyway (and wasn't receiving payment, as it was a volunteered position), I would provide a script that would accomplish this task.

So What Happened?

I don't have 30 years of experience in Windows, so it took quite a bit of research to sort this out.

About a week's worth of researched yielded some promising and interesting results: Windows not already had scripting technology built into every machine (via Visual Basic Script, and JScript) via the WSH (windows script host), but also has significant management underpinnings so most of the computer's features could be accessed via WMI.

The bad news? Deleting a profile involved so much much more than just deleting a set of folders. More than that, I had to learn another language (!) and a new technology in said language. Nonetheless, A quick bit of "before" and "after" comparison work with the registry yielded the modifications necessary to expunging a user's profile. I loath the registry (it's so clunky to use) and long for those days when we configured everything with .ini files.

The language issue wasn't too hard. Visual Basic Script has a clunky, archane, albeit natural syntax. It feels familiar, especially as someone with previous BASIC experience.

WMI, however, is a little weirder. Forming "requests" for objects like that feels unnatural, especially coming from a Linux background. I would be much easier to write the delprof.exe utility in such a way that you could use stdin to define a list of profiles to delete - so it could be used with a "filter" programming style. I do like the way that WMI made me think outside of my comfortable routine problem solving.

It should be noted that VBS and WMI are difficult technologies to master, but I picked them up in a few months at most. There's really no excuse for you to not pick them up if you're a sysadmin - think of it as an investment in the future. It's not as if Microsoft and several others don't provide any resources. Besides Microsoft has a browser for WMI objects, and the ability to create fancy GUIs with HTML for VBS, called HTA's.

So, after about a month or so, I had assembled a script that accomplished what I set out to do

I honestly don't know if the department ever used it or not, but the experience was definitely worth while.

Lessons Learned?

Okay, the script(s)?

While writing the deleteProfile script, I actually wrote a few other test scripts to do small, but very useful things. They're all available for download under a BSD license at the bottom (or under programs from the main page). Below is a description of how and why I wrote each of these. You can run these at the command line (type cmd at the run under start) and then type cscript (or wscript) and then the name of the script. Be sure the script is either in your %PATH% variable or in the current directory, or type the full pathname.

deleteProfile.vbs - This is the script to delete profiles on the local or remote machine. It has a full configuration section in the front of the script that describes how and what to delete. Currently it does not support anything besides matching profiles by regular expression. If you want to delete by timestamp, you can use delprof.exe or hack your own out of my script. It shouldn't be too hard to modify the script, anyway. I tried to design it so that it's not completely obfusctated. :P

It supports both invocation via wscript and cscript, so you can use it from the cmd prompt or just click on it. In fact, I should say that most of the scripts here are set up in a similar manner and have both CLI and GUI support.

addpath.vbs - it's a utility I used to set pathways in Windows. I usually included it with any of the scripts I was armed with on my USB drive, so that I could simply click on it and then add the script path. It's like an install program in a way.

inpath.vbs - the companion script to the one above. If I needed to look for a path inside the %PATH% this was very handy. I used this outside my IT position as well. The GIS lab at the college usually had a bunch of GIS tools, but it was hard to know if any of them were accessible from the current location. I never had a DELPATH utility because I normally did that sort of stuff manually.

loginErase.vbs - Normally, after local maintenance on a computer, the domain would be change to local. We got a lot of calls from students who complained that they couldn't log into the computers. They never checked that the domain that they were trying to log into was correct.

We found it easier to reset the computers to the correct student domain when we were done. To do this manually, however, was rather frightful. You can't just retype the domain at the login screen. No, you'd have to log into the machine as a user in the correct domain when you were done, in order to reset the domain to another domain. Keep in mind that this would mean that you had to sit there while your profile was re-created and established on that computer, then you had to log out immediately. Given that it took quite a few minutes to do each, it was pure tedium to perform this task. I estimated that with only about 18 computers, I was wasting nearly 45 minutes alone in resetting the domain. Solution? A few hours with VBS, NotePad++ and a little searching of the registry and the web.

regexTest.vbs - Another simple utility that I've also used outside the volunteer position. It was just a VERY simple "does it match" regex tester. There are no features whatsoever beyond that - you do not see what specific text actually matched. Nonetheless, it's useful when you want to know if it matches. There are probably better tools online.

Download the README

Name Purpose md5Sum Size
addpath.vbs Adds a path to your PATH environmental variable 3be56931caf00821a9862b9be69a75b3 4.3K
deleteProfile.vbs Like delprof.exe (it deletes profiles on a computer), but is far more versatile - offering regex support, and a few other features 3795f41c5e681dffe28e1836a1adfe35 15K
inpath.vbs Tests to see if a path is located in the PATH variable. cea5fb8c0711ac91caac0e50b4e176c1 2.9K
loginErase.vbs Erases or replaces the last login details (name and domain) on the machine. Although it seems like a fairly worthless utility, it's useful when you want to make sure whoever logs into the computer does so with the correct domain. 6885f7e9e65cdf94828f3d2822d2941f 4.4K
regexTester.vbs Useful script for testing if a regex matches a certain string. 00099fb4cb90d4c9eb688a4da7431bf5 3.4K
WindowsHelpScripts.zip Collection of above files in a handy-dandy zip file b841ab76a7f8c29edd0f887789d713bf 13K