Debugging an MDT build that fails to start

If you’ve been using the Microsoft Deployment Toolkit (MDT), aka Deployment4, then you will have probably had the scenario at some point where you PXE boot your client into PE and then the whole process just stops.
Microsoft Deployment Toolkit (MDT) Non-Starter

The giveaway sign here is that you have the command prompt returned to you.

This can be a bit perplexing, as to what your next move should be in working out what went wrong. During the Beta I was given a helpful hint from the MS guys:

cscript.exe x:\deploy\scripts\litetouch.wsf /debug:true

This provides a bit more output and has been successful in pointing me in the direction of whatever was causing the grief.
Microsoft Deployment Toolkit (MDT) Starting with Debugging
The last line is the important one in this example. The path with “broken” in it is showing that I had entered the wrong BuildID in the computers details configuration. That would explain why it couldn’t find the TaskSequence in question! ;)

Running Windows Server 2008 for 240 Days without Activation

Following on, in my recent trend of joining other people’s conversation rather than starting my own, I thought I’d highlight this tip, which I can see will be handy for testing.

Announced recently on bink.nu was Microsoft KB article 948472.

Basically:

Any edition of Windows Server 2008 may be installed without activation, and it may be evaluated for 60 days. Additionally, the 60-day evaluation period may be reset (re-armed) three times. This action extends the original 60-day evaluation period by up to 180 days for a total possible evaluation time of 240 days.

This is achieved, by using the slmgr.vbs script shipped in the image, in the System32 folder. The process can be automated through Task Scheduler, using an XML file, the contents of which are in the KB article.

I haven’t tried this approach yet, but I believe the key here is to not let the 60 days elapse! The article makes serveral references to performing the rearm’s “just before the end of …” each 60-day period.

I’ll have a closer look over the weekend and do a follow up post with the results.

Ubuntu Feisty and a Creative Xmod sound card

I ordered a Creative Xmod USB sound card yesterday. The ear phone jack on my laptop gave out on me a few weeks ago, and I finally let the music withdrawal symptoms get the better of me.

At work today one of the guys told me that he’d had an Xmod and replaced it due to a few hassles. Namely on his 64-bit Windows machine it had caused numerous BSOD’s. That would have been sufficient for him to pass it on, but his other two criticisms were that it required external power to run, and drivers installed to get it operational under Windows.

Suffice to say I got home tonight, less than expectant about my new toy. I figured I’d give it a try on my Ubuntu machine, and if it didn’t live up to my expectation – namely no driver hassles, and power drawn off the USB alone, I’d send it back and pick up a Terratec Aureon instead.

Well, my first impression was good. I liked the packaging and the iPod-esque colouring. I’m not an Apple Fanboy by any stretch, but you have to give them points for style!

First up I connected it to my Windows XP laptop, and sure enough I got the New Hardware dialogue. Not a good sign!

I hooked the unit up to the Ubuntu laptop, and opened up a terminal session to see if the OS recognized the device.
cat /proc/asound/cards

Now I’m not brilliant with configuring sound on Linux – despite my work mates labeling me as the token tree-hugging-sandal-wearing Nix-Fanboy ;) I do however know how to configure Amarok to use a different card, so this is where I started. Under Settings | Configure Amarok select the Engine settings from the left side of the dialogue, as below.

Amarok ALSA Device Configuration

The output from the cat command previously gave us the name of the audio device – Xmod. So this is the name we use.

A quick restart of Amarok, had “Blink182 – Feeling This” pumping down my earphones :)

So far so good, but I still had no system sounds, or any of other other media apps (Totem, or VLC etc). What I needed to do was set the Xmod as the default audio card in the system.

A quick look around the OS, and I found – asoundconf. Typing the command gave us a list of expected switches, of which two looked useful: list and set-default-card

asoundconf - configuring the systems default audio card

As you can see, stepping through the switches appears to have set the Xmod as the default card. A quick reboot, and, I suddenly have system sound, and all the media apps are playing nicely!

Despite my earlier worries, the device works well with by Ubuntu machine. No extra drivers required, no extra power needed, and it even works with the hardware sound control!

Tomorrow, there shall be music :)