User Error

Today I had a problem where MDT2010 didn’t apply the correct “FLAGS” value to the OS within the captured WIM when capturing an image via MDT. This shouldn’t happen in theory, but there’s nothing like a gnarly problem when you’re under the pump.

The value was appearing like this:

      <VERSION>
        <MAJOR>6</MAJOR>
        <MINOR>0</MINOR>
        <BUILD>6002</BUILD>
        <SPBUILD>18005</SPBUILD>
        <SPLEVEL>2</SPLEVEL>
      </VERSION>
      <SYSTEMROOT>WINDOWS</SYSTEMROOT>
    </WINDOWS>
    <NAME>CAP-1CDrive</NAME>
    <FLAGS>%OSSKU%</FLAGS>
  </IMAGE>
</WIM>

I found a similar issue and solution in the MDT2010 documentation:

To resolve this issue, add an Edition ID to the image by running the following command (where edition_id is the appropriate SKU ID as defined in the original factory image or in the Windows AIK, wim_file is the name of the WIM file, new_image_name is the new image name, and new_image_description is the new description for the image):

imagex /flags <edition_id> /info <wim_file> 1 <new_image_name> <new_image_description>

In my case, I did the following:

imagex /flags "Business" /info "capture.wim" 1 "Windows Vista Business" "Windows Vista Business x86"

Just something I came across last week on a SBS 2011 setup; the current version of HP’s CDP software refuses to recognise a newly-inserted RDX cartridge if you’re connected to the server via RDP. This had me puzzled for a while until I connected a monitor, keyboard, and mouse to the server and logged on there. The new cartridge was recognised instantly.

Hopefully they fix this soon, as it’s an issue in headless server setups. I’ve gotten around it for now by using LogMeIn on that server.

Just had an issue with three newly-configured Hyper-V Servers (Server 2008 R2 Enterprise) where the Server, or lanmanserver, service was failing to start. Incidentally, all of these (blade) servers are hooked up to a HP LeftHand P4xxx SAN, but are booting from local disk.

Included in the LeftHand setup instructions is a recommendation to make the lanmanserver service dependent on the MSiSCSI service. This is to ensure that any iSCSI volumes are initialised before the Server service starts. To quote the HP documentation:

LeftHand recommends setting sc.exe to create dependencies rather than editing the registry. sc.exe is included with Server 2008 and can be run from an alternate network computer.
From a DOS prompt, type sc config <your_service_name> depend= MSiSCSI.

For example: sc config lanmanserver depend= MSiSCSI.

We had dutifully followed these instructions, but then later noticed that admin shares were inaccessible and that we couldn’t add the three hosts to VMM 2008 R2. During the troubleshooting process, I noticed that the Server service was failing to start with the error “Windows could not start the Server service on Local Computer. Error 2: The system cannot find the file specified.”

Cue a wild goose chase for a while due to the uselessness of the error message and absence of any useful information in the error logs. I Then stumbled upon this post on the the TechNet forums in which user “soundstripe” describes the exact same problem (albeit with a different iSCSI SAN). User “m_a_tt” on these forums describes the problem also. I didn’t read that his solution was the same as mine until I had figured it out myself. I also noticed a post on the HP forums where someone was having the same issue, but hadn’t received an answer (in 4 months).

The HP documentation is in effect directing users to remove the original service dependencies for the lanmanserver service, instead of appending the MSiSCSI dependency to the existing list. I’m not sure if that’s because of a difference in the behaviour of the “sc” command in Server 2008 as compared to Server 2003, but I don’t know why I didn’t think of it earlier!

I logged onto another Server 2008 box that had no iSCSI configuration and noticed that the Server service had two dependencies; SamSS, and Srv. My three Hyper-V boxes only had a single dependency for MSiSCSI.

While the HP documentation advises to run the following:

sc config lanmanserver depend= MSiSCSI

The correct command on a stock Windows Server 2008 box should be (Dependencies separated by / (forward slash)):

sc config lanmanserver depend= SamSS/Srv/MSiSCSI

Do the above, and then reboot. This will solve the problem, the Server service will start, and it will still be dependent on the MSiSCSI service.

I hope this saves someone some time!

Edit: I just thought I’d add this footnote after completing HP’s LeftHand SAN training last week; Don’t forget that you may want to set other services as dependencies if their data resides on the iSCSI volumes. For example, I’ll set the Hyper-V service to be dependent on MSiSCSI if the server is a Hyper-V host.