Setting Up Server 2008 Core

Configuring IPv4 on the Local network interface:

  • To set your IP address:
    netsh interface ip set address name=”Local Area Connection” static <ip address> <netmask> <default gateway>
    (Note:  If you are using netsh on a platform earlier than Server 2008 (i.e. Server 2003) you may nned to provide more explicit parameters such as:
    netsh interface ip set address name”Local Area Connection” source=”static” addr=”<addr>” mask=”<mask>” gateway=”<gateway>” gwmetric=”1″)
  • To set your first DNS server:
    netsh interface ip set dns “Local Area Connection” static <DNSServerIP>
    (NOTE:  You may want to set DNS info first if you need your interface to be functional as soon as the IP address comes online.)
  • To set your first WINS server:
    netsh interface ip set wins “Local Area Connection” static <WINSServerIP>
  • Setting up additional WINS and DNS servers:
    • run “netsh”
    • go to the context “interface ip”
    • run:
      add dns "Local Area Connection" <DNSServerIP> index=2
      add wins "Local Area Connection" <WINSServerIP> index=2
    • Verify settings with:
      "ipconfig /all" or "netsh interface ip show config"

Installing VMWare Tools:

  • In the ESX console, initiate “Install VMWare Tools”
  • At the server console, switch to D:, run setup.exe with typical options, wait wait wait wait, affirm that you want to install the updated help files, reboot.

Changing the console resolution:

  • use regedit.exe
  • navigate to:
    (or whichever GUID key have the subkey of “0000” named “VolatileSettings”)
  • Change “DefaultSettings.XResolution” and “DefaultSettings.YResolution” to your desired values in decimal format.

Enabling remote desktop:slmgr

  • cscript C:WindowsSystem32Scregedit.wsf /ar 0
  • netsh advfirewall firewall set rule group=”Remote Desktop” new enable=yes

Activating a KMS:

  • After networking is configured, use SLMGR.vbs to activate your KMS
  • For you sanity, you may wish to perform “cscript //H:cscript” to set the command line script interpreter as the default script handler.
  • run “slmgr.vbs -ipk <KMS product key>”
  • run “slmgr.vbs -ato” to activate the KMS
  • run “Netsh advfirewall firewall set rule group=“Key Management Server” new enable=yes” to allow KMS client traffic through the firewall (more on this below)
  • run “slmgr.vbs -dlv” to monitor KMS activity.

Allowing Remote Administration:

  • Netsh advfirewall firewall set rule group=“<rule group>” new enable=yes
  • <rule group> can include:
  • Remote Event Log Management
  • Remote Service Management
  • File and Printer Sharing
  • Remote Scheduled Tasks Management
  • Performance Logs and Alerts
  • Remote Volume Management
  • Windows Firewall Remote Management
  • Now that I have remote access via MMC, I see that the group “Key Management Service” is also available.  Also see the “Remote Desktop” group, above.
  • Making “PostReflect.exe” functional

    Vista Service Pack 1 is here, and with it a few new tricks that need to be learned.  The first shocker for me is that you cannot apply Vista SP1 to an offline image… bummer!  I had understood from earlier MS brags about Vista that the "componentized" (sic) OS could always be maintained offline.  Adding insult to injury, you cannot slipstream SP1 into RTM source media, as was possible with XP and Server 2003.  Oh well…

    The new Windows AIK v1.1 which supports Vista SP1 states that you must run the "postreflect.exe" tool on any offline Vista SP1 image before you attempt to apply that image to new hardware.  Why?  I don’t know… they have some mumbo jumbo about critical driver availability which is hard to grok.  The problem for me was that PostReflect failed to work! 

    Here is what I did:

    1. Applied Vista SP1 to a fresh Vista Enterprise install
    2. Ran sysprep on the system, then used imagex from a WinPE instance to capture the image
    3. transferred the image to our distribution server (which has Microsoft Deployment 4 and the new AIK installed).
    4. Used imagex to mount the image in read/write mode
    5. Ran "vsp1cln.exe" from the AIK to remove the SP1 uninstall information.
    6. Ran "postreflect e:mountwindows c:" to "reflect" the critical device drivers in the offline image mounted at "e:mount", which uses the system drive letter "c:" when running.  This returned a "FAILED" error, with return code "0x0000007E".

    What the heck?

    Since SP1 and postreflect are brand new, Google and the Microsoft news groups were of no help in debugging the problem.  The godlike Mark Russinovich was.  I started "procmon.exe" with a filter for "postreflect.exe", then ran the prostreflect operation again.  As usual, I captured a ton of activity, but it not take too much examination to see that postreflect was looking for the AIK 1.0 DLL "drvstore.dll", but was unable to find it.  As a quick fix, I did a "cd" to "C:Program FilesWindows AIKToolsx86Servicing6.0.6000.16386_x86" (where one copy of drvstore.dll is located).  I then re-ran postreflect, and the operation now completes successfully!

    As a long-term fix, I copied the contents of "C:Program FilesWindows AIKToolsx86Servicing6.0.6000.16386_x86" to a directory "C:Program FilesWindows Imaging", then laid the contents of "C:Program FilesWindows AIKToolsx86Servicing" and "C:Program FilesWindows AIKToolsx86" on top of that.  My "Windows Imaging" folder was already in my system "PATH" environment variable as a fix for a similar problem we had with "wdsutil" in the past.  "postrefect" now should be able to locate all of the files that it needs for future operations.  However, I will need to keep an eye out of future AIK tool updates… those files will need to be copied to my "Windows Imaging" folder.

    stsadm -o export fails with “Guid should contain 32 digits…” error

    While trying to use stsadm to export/import a site (part of my usual site repair process), I encountered an error in exporting “field” objects. The error stated “FatalError: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).”.

    Some digging revealed this forum post:

    It is suggeted here that the file “Fields.xml” in the directory “C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATEFEATURESTSATypes” contains illegal curly-brace characters (i.e. {}).

    To fix the problem, we mack a backup of fields.xml, then search and replace ID=”{ with ID=”, and }” with “. After performing these actions, stsadm is able to create an export archive of the site.

    Another forum hints that one of the site templates in the “fab 40” application templates is at fault, but I cannot determine which one this would be from the content of the files.

    Windows DS woes… and the cure

    The people in the computer depot clinic reported a vexing problem with Windows DS deployment today… one of the techs reported a 0x80070020 error in a WDS deployment session.  The text was “Windows cannot install required files”.  There is no mention of which files, which is quite irritating.  The error comes up after 20-25 minutes of deployment activity (when the process is 97% done).  Annoying… and no telling how long it has been going on, either.

    I had a look that the Vista setup log files on a system that was experiencing the reported error:
    To look at the log, press shift-F10 to bring up a command prompt, then “cd” to “C:$WINDOWS.~BTSourcesPanther”, and “notepad setuperr.log”.  In this case we see that the file “WinPEpge.sys” failed to copy owing to a “sharing violation”.

    Some quick Googling reveals:
    Some of these images have a file called “WinPEpge.sys” in their root directories.  This file is not supposed to be in the image at all.  I have purged the Student X20 and X30 images of this foulness.  I am not sure how that file got in there, as it should be excluded by default.  However, to be safe I have updated the WDS Deployment and Capture images with config files that explicitly exempt the winpepge.sys file from capture and deployment.

    Having to spend four hours on this today was not all bad, though.  This gave me the chance to add GImageX.exe to the deployment/capture images:
    this is a new graphical front-end to imagex that allows easier image capture, mounting, and maintenance.  It will be available on the CD drive letter of a WDS Capture/Discover ISO, or the flash drive letter of a USB bootable version.

    I really should try to dredge though the current image library for these “winpepge.sys” files in some sort of programmatic fashion.  Doing so is made somewhat more complicated by the fact that you cannot directly edit WDS images that have been single-instanced into “.RWM” files by the WDSUTIL or its sister MMC console… ImageX just can’t handle this.  You have to export the image from WDS, then edit it, then re-import.  WDSUTIL is highly script-able, so this should be possible… it is just not “simple”.  Maybe next week…

    Recursively adding drivers in a distribution share to a WinPE image with “FOR” and “peimg”

    Microsoft has provided a handy tool for adding additional drivers into Windows Vista and WinPE 2.0 WIM files.  This tool is called “PEIMG”, and it is included in the Windows AIK, available from  Unfortunately, PEIMG does not have a recursive function, so if you want to add all of the drivers in a complex driver store (e.g. all of the drivers in a BDD Distribution Share), you need to do some scripting.

    Fortunately, not much scripting is required… FOR comes to the rescue again!

    for /R . %i in (*.inf) do peimg /inf=”%i” e:winpe_x86mountWindows

    In this case, we are using “/R” to tell “FOR” that we want it to recurse though the given directory path (in this example, “.”) setting the variable “%i” to be equal to each “inf” file that it finds.  On each pass we run “peimg /inf=”, injecting our variable as the inf file to inject.

    All of this assumes that you have already mounted the target WIM file into the directory e:winpe_x86mountWindows.

    We could fairly easily automate the whole winpe build process by stringing together these commands:

    1. imagex /mountrw <WIM file> <WIM Index> <mount directory>
    2. for /R .net %i in (*.inf) do peimg /inf=”%i” <mountDirectory>windows
    3. for /R .hdc %i in (*.inf) do peimg /inf=”%i” <mountDirectory>windows
    4. for /R .system %i in (*.inf) do peimg /inf=”%i” <mountDirectory>windows
    5. for /R .SCSIAdapter %i in (*.inf) do peimg /inf=”%i” <mountDirectory>windows
    6. imagex /unmount /commit <mountDirectory>

    We could then use WDSUtil to import the image into a Windows DS server, convert it to a “discover” image.  OSCDIMG from the Windows AIK to create automatically a WDS Discover ISO file.