I needed to remove the Microsoft Document Image Writer from about 2000 machines on my network, so I wrote a quote .bat file as a logon script. Works like a charm!

rem ************************************************
rem this removes the MS Office Document Image Writer
rem ************************************************
 c:
cd \windows\system32\
cscript prnmngr.vbs -d -p “Microsoft Office Document Image Writer”

One of the more annoying bits of the XP-Vista transition has been the advent of the Microsoft XPS Writer. This damn thing keeps installing at boot and causing major issues all around. Instead of just appearing as an option, the XPS printer takes the role of Default Printer. This is a real problem when it starts renaming and moving printers in the elementary schools. To get around it, there’s a nifty script.

c:
cd \windows\system32\
cscript prnmngr.vbs -d -p “Microsoft XPS Document Writer”

Drop those in a .bat, set it as a logon script and BAM! Done.

Recently, we have begun rolling out systems in earnest using Windows Deployment Services. While we’re not yet using Vista, WDS has proved extremely useful for loading XP machines in timespans and situations where Ghost is not suitable. One of the more recent problems that cropped up has brought to light the differences between Uni-processor (UP) and Multi-Processor (MP) HAL’s. Specifically, I have a boat-load of Gateway E4500 systems that need to be imaged. Since they were all bought in one big batch I made the (completely incorrect) assumption that they were all identical machines. I had never before noticed any difference, so imagine my surprise when all of these systems would successfully boot WinPE, but 1/3 of them could not see any images.

I thought it might be a BIOS issue, a problem with the RAM or perhaps a bad HDD. After banging my head against the desk for a few hours I glanced up to notice that the Intel stickers on the 2 test machines were different. Could it really be that easy?

 Sure enough, the HAL is just different enough and UP machines won’t see MP images and vice versa. So what’s the solution? To take a MP image and create a UP image from it, edit your sysprep.inf file. In the [Unattended] section, add this line:

UpdateUPHAL = ACPIAPIC_UP,%WINDIR%InfHal.inf

Afterwards, run sysprep as normal, but DO NOT upload the image to your WDS server yet. Instead, reboot the machine and complete setup. The HAL type is updated only when the mini-setup reads your inf file. After you’ve used the image on the hdd to reinstall, sysprep the system again and upload it to your WDS server. Make sure to name the image something different than the MP image, or you’ll just have to create another MP image.

This is actually really easy, assuming you have Vista drivers for your hardware. You can use this for any driver (disk controllers, NICs, etc)

1) Download the device driver and put in somewhere convenient on a machine with WAIK installed.

2) Mount the .wim you want to add it to using Imagex.

imagex /mountrw [image location] 1 c:\winpe_x86\mount\

3) Add the .inf using peimg.

peimg /inf=[path to driver .inf file] c:\winpe_x86\mount\Windows

4) Unmount and commit the image back to the .wim.

imagex /unmount /commit c:\winpe_x86\mount

5) Add the image to the WDS console, or replace an existing image.

That’s it! You’re ready to go!

We run a very basic setup of Exchange at work, and I freely admit that I’m not qualified to do much more than maintain what’s already in place. One of the problems we’re having is with the spell checker on Outlook Web Access. When a user logs on from a machine on the LAN, the spell checker works just fine. However, when they use OWA from home, they get the following error:

The spelling in this item can’t be checked. Try again later.

Now I’ve been searching TechNet for quite a while, but none of their solutions seem to work. The most often quoted article is here, but it doesn’t seem to apply to me, because I am using neither ISA Server, nor forms-based authentication. Also, logging in with full.domain.name\username is a work-around that draws a lot of ire from the bosses. Anyone have another idea?

I was given the task this week (or at least pressure to get it done finally) of assigning home folders to the 500 users in my Active Directory. I didn’t have any sort of budget to throw at the task, so purchasing a tool to help me was right out. That left me with 3 options:

1. Do all the edits by hand.
2. Writing a script that would pull all the users from selected OU’s and change the info.
3. Find a free or at least open-source tool to help me accomplish the task.

This time last month, I had to add an extra email address to all 500 accounts. At that point I was tired from a lot of long days in a row and not feeling like learning anything new so I did it all by hand. BIG MISTAKE. 500 email addresses took me about 4 hours to do and I hated every minute of it.

The idea of scripting the process is highly intriguing to me. In fact, it seems like a really good idea. The down sides are that A) I’m still not very good at WMI scripting and this would be my first daliance with  ADSI, B) I didn’t have a lot of time to monkey with learning it, and C) if I was going to do it, I wanted it done right.

One of the major objectives in our restructuring is allowing the other members of the tech staff to begin dealing with account creating/deletion/changes/resets. I have much stronger reservations about giving the staff direct access to edit items in AD than my boss does, because I’m the one that’s going to have to rebuild it all and find all the missing data. We’re building up to having a central IT Department server that’s a software repository and general resource cache. The way I figure it, once I learn the scripting a bit better, I can create a website for this server that’ll allow the techs to do specific tasks (and not muck anything else up).

The upshot of all of this is that I spent a day looking for free interfaces to help me along. I looked at Apollo AD, but it just didn’t feel right and wasn’t designed to do what I needed. To my surprise, the guys at M$ have written a tool that helps do exactly this sort of thing. The best part? It’s free!

Welcome to ADModify.NET.  (The links have changed a few times, so I won’t include it here. Use Google or search TechNet for it.)

It takes a little practice to get real comfortable with the way this thing works.

• It doesn’t update the directory tree unless you specifically ask it to.
• You can only select users by selecting an OU if it’s set to display all those users in the directory tree.
• Once you add them to the list, you have to select them again to take action on them.
• After it performs the edits, the program quits.  You have to restart the entire program to make another set of edits.

I’m looking around this week, because I have 2 big goals at work and no real resources to address them.

1. I have to redirect the home folders for >500 Active Directory user accounts.
2. I need to add departmental locations/addresses to all of these accounts.

The thing is, I don’t know jack about scripting AD or much WMI so I would really like some sort of tool to help me accomplish this easily. Worse, I don’t have any sort of budget available to purchase software. The suggestions I have so far are:

• ADModify.NET
• Apollo AD

Anybody else want to weigh in here?

We’ve got a weird mix of HP/Compaq, Dell and Gateway desktops at work and we’re just now getting to the point where using WDS is actually worthwhile. I ran into a nifty little problem today and couldn’t find any documentation to explain it.

I booted up one of the new Dell desktops and configured it as a master for imaging. I sysprep-ed it as normal and used WDS to PXE boot and image the drive. The image installed back to the machine I ripped it from just fine. The problem (which sort of defeats the purpose of WDS) is that whenever I deployed that image to any other machine, I got the following error:

Windows could not start because the following file is missing or corrupt:
<Windows root>\system32\hal.dll.
Please re-install a copy of the above file.

It’s worth noting that I was using WDS to deploy a Windows XP image, not Vista. I’ve run into this problem before and had a feeling that the error was actually with boot.ini.

The Cause: Dell loads the machines with 2 partitions: 1 for diagnostic tools and 1 for Windows. Note that Windows can’t see the diagnostic partition due to the formatting used.

The image’s boot.ini looked like the following:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”Microsoft Windows XP Professional” /noexecute=optin /fastdetect

However, because of the Dell diagnostic partition, Windows was actually installing on partition 2.

The Cure:

1. Export the image from WDS.
2. Mount the image using Imagex.
3. Edit the boot.ini file to point to partition 2 (on both lines 3 and 5 of the above example).
4. Unmount the image, using the /commit switch.
5. Replace the WDS image with the edited copy.

The Result: Windows installs like a charm and I don’t have to teach the tech staff to use diskpart for all 2000 machines.

Sure would be nice to be able to embed video/audio/calendars and a whole bunch of other stuff into my Drupal site. Problem is, the Embed Filter module won’t install correctly. The admin page is truncated and doesn’t work correctly.

 The Cause: embedfilter.module is written poorly. In the comment below the config window,  somebody wrote it using <tag> ’s. PHP tries to render the actual tags.

 The Fix: Edit embedfilter.module. In line79, just replace the <tag>’s with &lt;tag>

There are a lot of nuances to using Sysprep and WDS, most of which I’ve found by trolling message boards and blogs. The Microsoft documentation is particularly lacking in this area, especially if you’ve never used RIS before. Below, I’ve included the steps I have used to successfully image an XP system and deploy it across my schools. This assumes that you already have a WDS server configured and authorized. For the sake of ease, I assume you have installed Windows XP to c:\windows\.

1. Install Windows and any other software to the master machine. Make sure all options are configured as you would like them.
2. Extract the entire contents of deploy.cab from an XP cd to c:\sysprep.
3. Use the Setup Manager (setupmgr.exe) to create a sysprep.inf file. (A better explanation can be found here.) Save the sysprep.inf file to c:\sysprep.
4. Run Sysprep.exe.
   1. I prefer to run sysprep from the command line, because it’s easier for me to keep track of which switches I’m using. Typically, I use “sysprep.exe -activated -mini -reseal” from the command line. An explanation of all available switches can be found here.
   2. It’s worth noting that if you use “-activated”, the product key in your sysprep.inf MUST match the product key used to install Windows on the master machine. A mismatch will prevent the “-activated” switch from working.
5. After sysprep completes, your machine will shut down. Do not reboot from the hard drive until you are finished imaging the machine. At this point I PXE boot from my WDS server and capture the disk image. You can also capture the image by booting from local WinPE media (a CD/DVD, USB key), but I’ve had mixed results.

It took me more than a few full days of pouring through TechNet, cursing loudly, and deploying bad images to finally get the entire process down. At this point it takes me about 3 minutes to set up a machine for sysprep, run it, and start imaging.