markwilson.it [formerly known as Mark's (we)Blog]

I’ve written previously about running Windows Server 2008 as a workstation (I do it on the notebook PC I use for work) but now it’s even easier. Steven Bink has published details of a Windows Server 2008 Workstation conversion tool (via Garry Martin).

Last year, Scotty McLeod set up the Windows Server User Group UK with the intention of creating a lively discussion area (backed up with regular meetings) for UK-based IT Professionals who are interested in the development of the Windows Server platform. Unfortunately, Scotty was involved in a serious accident at the start of the year and, whilst he is making a fantastic recovery, it’s going to take a while longer yet.

With no administrative access to the user group website, we have no way of finding out who our members are and no way to contact each other should we do what we talked about at the community day in April (was that really 3 months back?) - namely to start to organise some events. So, I’ve created a LinkedIn group to supplement the user group website. If you’re interested in Windows Server and would like to take part in future user group events, please join the Windows Server User Group UK on LinkedIn.

Once we have a quorum, then I’ll be in touch to try and get the ball rolling for some meetings.

Even though choosing a hypervisor is only a small part of implementing a virtualisation strategy, much has been written about how Microsoft Hyper-V compares to VMware ESX - and there are some fundamental differences between those two products. Architecturally, Hyper-V has a lot more in common with the Xen hypervisor (although they are not identical) and indeed XenSource worked with Microsoft to provide Linux support for Hyper-V and I’ve recently been alerted to the presence of a short white paper which compares Hyper-V and the Xen technology implemented in Red Hat Enterprise Linux (the leading Linux distribution, which is not currently on the list of supported guest operating systems for Hyper-V). Despite being published by Microsoft, it seems to me to give a balanced view between the two products, although it should also be noted that Red Hat has announced it will be switching from Xen to KVM for future virtualisation support.

Back in the days when I used to shoot my photos on film, my preferred slide emulsion was Fujifilm Velvia (RVP). With strong colour saturation (particularly green) this film is particularly good for landscape work and, ever since I switched to digital, I’ve felt that there was some “punch” missing from my landscapes.

Then I came across TWIP episode 19, in which the subject of creating Photoshop actions is demonstrated using “Scott’s Photoshop Velvia”. I tried it out today and it really works.

1. Take an image and create a duplicate layer (in the process giving yourself the ability to return to the original at any time).
2. Next, use the Channel Mixer on each of the three colour channels (red/green/blue) as follows:
   • Red channel: R 118% G -9% B -9%
   • Green channel: R -9% G 118% B -9%
   • Blue channel: R -9% G -9% B 118%
3. Finally, adjust the contrast by tweaking the curves to produce a very slight S shape.

Here’s one of my images before and after the Photoshop Velvia treatment was applied:

Hopefully you can see that the second image appears much more vibrant than the first.

Photoshop CS3 users can download the Photoshop Velvia custom action, but please note there is no warranty implied, no support, and you use it at your own risk. Thanks are due to Scott Bourne for demonstrating this - it really is a great Photoshop tip.

So, last night I was in the pub with Richard, Stuart and Alex and the conversation turned to Facebook. I felt like some sort of social leper as, until then, I hadn’t responded to the various Facebook requests that I’ve received and the extent of my online social networking was LinkedIn - which is a professional networking site - in fact I think the word pretentious was used by someone (a little harsh I feel).

Anyway, I’ve done it. I’m now on Facebook, and I wasted a good chunk of this afternoon there. I suppose it will be Twitter next (although I still don’t see the attraction there).

So if you are reading this blog and you know me personally then I’d be happy to hook up with you as a friend on Facebook (after all, social networks get pretty lonely if there is no-one there to socialise with). But, just as for my LinkedIn profile (where I only accept invitations from people I know, have worked with, and would be happy to work with again), I won’t accept invitations on Facebook from people I don’t consider to be friends - it’s amazing how many people think I would like to link to them because we work at the same company (even though we have never had any interaction).

Bah humbug!

One of the problems associated with virtualisation is “virtual sprawl” - the proliferation of virtual machines (which can totally negate the idea of “server consolidation” if not carefully controlled. Management becomes critical - and a key part of that management is patching virtual machines to keep the operating system and applications up to date.

But what about the virtual machines that exist as offline images (templates, test and development machines, etc.)?

I’ve written previously about the beta of Microsoft’s offline servicing tool for virtual machine images and last week it was completed and released to the web.

The Offline Virtual Machine Servicing Tool works with System Center Virtual Machine Manager and, according to Microsoft, it “combines the Windows Workflow programming model with the Windows PowerShell interface to bring groups of virtual machines online just long enough for them to receive updates from either System Center Configuration Manager 2007 or Windows Server Update Services. As soon as the virtual machines are up-to-date, the tool returns them to the offline state in the Virtual Machine Manager library”.

There’s an executive overview on the Microsoft TechNet site and the tool can be downloaded from the Microsoft website.

One of the reasons to use Windows PE for operating system deployment is that it’s built on a modern version of Windows so, at least in theory, driver support is less of an issue than it would be using MS-DOS boot disks.

Even so, there are still times when a good old MS-DOS boot disk comes in handy and networking is a particular pain point - NDIS drivers are a pain to configure so packet-level drivers are often useful for operating system deployment tasks (but not optimised for anything more substantial). Available for many of the more common Ethernet cards, they are generally 16-bit utilities for MS-DOS and so will not work in 32-bit or 64-bit operating systems.

As this is not exactly cutting edge technology, many of the useful sites are starting to drop off the ‘net (but a surprising number remain) - here’s a few links I found that might come in handy:

• A complete description of MS-DOS TCP/IP connectivity.
• Crynwr has a load of good stuff, including a selection of packet level drivers. The Intel EtherExpress PRO 100 packet driver is particularly useful.
• Some more links to MS-DOS packet drivers together with nicscan.exe (a useful scanner for NIC cards, although I’m not sure if the database is still maintained and Craig Hart’s PCI/PCI32 may be more useful).
• Symantec’s article on manually creating a Ghost network book disk contains useful information including a generic disk which simply requires the appropriate packet driver to be added) - basically, all that is required is:
  1. Create an MS-DOS boot disk (bootdisk.com is a good source, or a blank formatted disk can have system files added to it using the sys command).
  2. Add an appropriate packet driver for the selected NIC (e.g. E100B.COM for an Intel EtherExpress PRO 100).
  3. Load the driver using by calling it from the autoexec.bat file (e.g. by adding the line e100b.com 0x60 to the end of the file).
  4. Create a file called wattcp.cfg with the following contents:
     IP=IPaddress (or leave blank if using DHCP)
     NETMASK=255.255.255.0 (this is a C-class Subnet, change if needed)

At long last (and not before time), my corporate mail account has just been moved across to an Exchange Server 2007 system with Outlook Anywhere enabled. Unfortunately, I sold my Apple iPhone (which now has Exchange ActiveSync support) last week but I will be getting a new one at some time soon and there are many other benefits too - like that I no longer have to run a 32-bit VM to VPN into the corporate network and access my e-mail; and that the 2007 version of of Outlook Web Access is a huge step forward (even the “light” version for non-Microsoft and legacy browsers).

So, now that I can access Exchange from my 64-bit Windows Server 2008 workstation, I needed to configure an appropriate Outlook profile. Except that I couldn’t find the mail applet in Control Panel, and Outlook 2007 only seemed to present the account settings for the currently loaded profile.

Then I noticed an innocuous icon in Control Panel, labelled View 32-bit Control Panel Items. Clicking on this exposed the Mail applet that is necessary in order to configure Outlook profiles.

A couple of years back I was writing about trying to squeeze Windows PE onto a 128MB/256MB USB thumb drive and how times change - these days I have piles of unused 128MB, 256MB and 512MB USB sticks that have become redundant because I have larger portable data storage devices available.

Then, as I was preparing to image a PC, I found myself using 1.44MB floppy disks and it all got very frustrating. Just enough to boot the system used half the disk and that was without any utilities - the version of Symantec Ghost that I used recently won’t even fit on a floppy disk. So, I decided to put one of my old USB sticks to use as an “ultimate boot disk” - much easier to update than the CD-based versions we were putting together a few years back.

Despite having a pile of smaller USB thumb drives doing nothing, I decided to use one of the 1GB sticks that EMC were giving away at the Windows Server 2008 launch (plenty of space for expansion).

The first step is to make the drive bootable - I used the HP USB disk storage format tool v2.1.8 (SP27608) to format the drive and put a basic Windows ME boot subsystem on it (using a disk created with the Windows XP disk format tool as a reference image) but there are other options.

Why Windows ME? Well, because it’s easy - Windows XP creates ME boot disks - and because it was a prerequisite for the the next stage - network booting using Brad Driver’s universal TCP/IP network boot disk. There are many sites on the ‘net that offer network boot disks (including bootdisk.com) but the one I chose manages to include a huge range of drivers and it fits on 1.44MB floppy.

Basically, the disk boots a very basic operating system before expanding itself to a RAM disk and reloading the command shell. USB device support is still experimental (at v6.2) but after much experimentation I worked out that I could use the makedisk script provided with the download but in order to avoid a loop of pressing CTRL+ALT+DEL to restart the computer I needed to edit the config.sys file so that the line shell=n:\command.com /e:4096 /p used c: instead of n: for the command interpreter (my drive was formatted as USB-HDD, this may not be necessary for other USB boot options) and I also removed the hidden attribute from command.com to avoid a file not found error (that didn’t seem to affect the operation of the disk in any other way). After this, the NIC is auto-detected and an appropriate network driver loaded, obtaining TCP/IP information from DHCP and logging on to the network.

With network booting working well (at least on the IBM ThinkPad T40 that I tested against - older machines may not have the necessary BIOS support), I added an autorun.inf file for when I use the drive within Windows. This file includes the following items and really just sets the drive icon and description:

[autorun]
label=USB Network Boot Disk (1GB)
icon=shell32.dll,12

Finally, the whole purpose of this disk is to run some utilities. At this point you can name your own poison but I created a C:\Tools folder (C:\Utilities is too long for 8.3 file naming, although C:\Utils could have worked) and started to pile in my favourite 16-bit .COM and .EXE files - I’m sure the list will grow substantially over time. There may be some issues with memory management but there is plenty of space to add a variety of tools and theoretically there could be multiple boot options too.

It’s been a long time since I played around in MS-DOS and there is very little call for it these days (I should really be doing this with Windows PE) but every so often it’s good to return to your roots.

I need to rebuild one of my PCs before lending it to someone for a few days but before I do that I want to take an image of it. If I had the Microsoft Deployment Toolkit 2008 set up at home then that would be reasonably straightforward but I don’t, and the old drive imaging technologies will be fine for this - at least that’s what I thought until I spent half the night and a good chunk of this morning fighting with Symantec Ghost… So, here’s a few of the things that I’ve (re-)discovered about Ghost in the last few hours.

• Using Ghost in peer-to-peer mode does require the slave and the master machines to be running the same version of Ghost - it will present a version mismatch if you try and run different versions.
• Ghost 6.x Enterprise has a multicast option but I couldn’t get it to work (it was always greyed out for me). Symantec’s knowledge base suggests that this may be down to TCP/IP issues and I’m pretty sure that packet-level network drivers are required with the MS-DOS client (the Windows server can use the normal Windows network settings) but, even with a suitable packet driver loaded, I gave up after a few hours without success.
• GhostCast Server uses (UDP) port 6666 for communications.
• GhostCast Server 8.x will create a Windows Firewall exception for itself but the exception still needs to be enabled manually.
• On a multi-homed server, there seems to be no way to select the NIC on which the GhostCast Server presents a session.
• Multicasting also seems to need the client and server versions to match one another. 16-bit Ghost 7.x should work with an 8.x server but it wasn’t working out for me with 7.5 and 8.2 (32-bit 8.x clients were connecting to the server fine, so I knew it was working, but I didn’t want to image those machines - and I didn’t have a copy of the 7.x server).
• Compression adds a lot of time to the imaging process.

Eventually, I got everything working with a 16-bit copy of Ghost 8.2 running on MS-DOS (to be completely accurate, it was a Windows ME startup disk created from Windows XP) communicating with a GhostCast Server 8.2 running on Windows Server 2008.

And for anyone who is wondering why I was messing about with 16-bit executables and MS-DOS (in these days of Windows PE), Toffa suggested that I should try a Windows PE disk with the 32-bit ghost client. Although that would have let me access USB-attached external storage, I didn’t have enough space on a USB drive and was storing my image on a server. Windows XP (and so PE) doesn’t natively recognise the network card on the machine I was imaging, so that would have required me to extend the Windows PE image and provide additional driver support. Somehow, using a universal network boot disk seemed like the easy option.