There was an video posted recently showing the difference between setting up Hyper-V with Windows Server Core, and setting up ESX3i.  Mike DiPetrillo posted an interesting comment to the effect that the commands that were entered were net new for Windows Server 2008 Core.

I watched the first video and counted one net new command line for Windows Server 2008 (let alone core).  The command sequence is something like:
netdom (around since Windows NT 4.0)
shutdown (around since Windows NT 4.0)
netsh (around since Windows 2003)
netdom (see above)
netsh (see above)
ocsetup (Only net new command)

The second video shows setting up the ISCSI storage and I counted no net new command line tools there:
iscsicli (has been available as part of the ISCSI initiator for a while now - it's available for 2K, XP, 2003 - this is first time the iscsi initiator is in the OS) - it is probably fair to say that it's not the most intuitive command line in the world, but it is well documented.
diskpart (been around since Windows XP)

So far from being all net new command lines, we have one net new command line tools, and a bunch that have been around for a while (over ten years in some cases).  Guess you'll need to update that MCSE to the new Windows 2008 certification Mike? :)

The great thing about having all this command line stuff available is that it works on both Windows Server Core & Windows Server Full installs, and you can use all this stuff to automate your server builds (or even better, use System Center Configuration Manager to deploy your Windows Server with image based deployment and task sequences).

My question to Mike is this:  once I have my host up and running, what extra steps do I have to do to do things like copy my ISO files on there, or copy my gold images on there? 

With Windows I browse to my file share and copy them on.  It's the Windows you know and love.

What do I have to do to do this on ESX3i?  Usually it's getting a SCP tool and copying files on there, then when I want to provision it means logging on to the console (command line) and copying my images around.  It's the *nix you might not know or love.

Either that or I deploy System Center Virtual Machine Manager and use that to manage my Hyper-V & VMware environments, and use that to do all my provisioning. 

I recently had a look at an issue with the Configuration Manager PXE Service Point running on a test environment of mine.  I couldn't get any of my operating system images to deploy - in fact I couldn't get the PXE boot to complete successfully.  In the smspxe.log file I was getting the following messages:

No Boot Action for Device (38) found

ProcessDatabaseReply: No Advertisement found in Db for device

I found this a little odd, as the machine definitely had a task sequence advertised against it, and my custom WinPE image had been made available for PXE. 

Digging in the event log, I was getting error messages when WDS started up, saying:

Source: WDSIMGSRV

Category: WdsImgSrv

Event ID: 258

Description: An error occurred while trying to initialize the Windows Deployment Services image server.  Error information 0xC1030104

A little cryptic, and not exactly obvious what it meant.  Having a dig around, it appears that 0xC1030104 actually means that the WDSServer is not configured.  Strange, I thought the Configuration Manager PXE Service Point setup did that?  I checked all the appropriate logs (pxesetup.log, pxemsi.log) and everything seemed in order.  I decided to try and initialise the server at the command line to see if that made a different.  I ran:

wdsutil /initialize-server /REMINST:"D:\remoteinstall"

where D:\remoteinstall was the directory that Configuration Manager had configured WDS to use.  Sure enough, as soon as I did that, PXE started working perfectly.

I'd just finished upgrading my Config Mgr lab to SP1, and found that as soon as I'd restarted my machine, SMS_EXECUTIVE started to fail about 30 seconds or so after starting.  I didn't get a lot of information to know this was happening, apart from the usual "SMSexec has crashed, do you want to send an error report". 

Putting on my troubleshooting hat, I had a look at the CrashDumps directory under the default logs directory.  This is where a dump of various logs and bits of the Config Mgr state get dropped should a component fail.  The interesting log in this case was crash.log which is a summary of the failure, and the various thread states of each of the components.  I had an error which looked like:

EXCEPTION INFORMATION

Time = 06/05/2008 15:21:29.358
Service name = SMS_EXECUTIVE
Thread name = SMS_HIERARCHY_MANAGER
Executable = D:\Program Files\Microsoft Configuration Manager\bin\i386\smsexec.exe
Process ID = 3548 (0xddc)
Thread ID = 4256 (0x10a0)
Instruction address = 78141e3a
Exception = c0000005 (EXCEPTION_ACCESS_VIOLATION)
Description = "The thread tried to read from the virtual address 00000080 for which it does not have the appropriate access."
Raised inside CService mutex = No
CService mutex description = ""

The key message in this case is the description, which points to a virtual memory address (00000080).  To find this, I searched the crash.log for that error, and found this:

STACK TRACE FOR SMS_HIERARCHY_MANAGER THREAD 4256 (0x10a0) AT 06/05/2008 15:21:29.358

EAX: 00000080  CS: 001b  EIP: 00000000  EFLAGS: 00010202
EBX: 2ec8a0fe  SS: 0023  ESP: 013df35c
ECX: 7ffffffe  DS: 0023  EBP: ffffffff
EDX: 00000073  ES: 0023
ESI: 00000000  FS: 003b
EDI: 00000080  GS: 0000

This seemed to indicate that the issue was happening in Hierarchy Manager.  Opening hman.log  the last lines were:

Update the Sites table: Site=XXX Parent=~  $$<SMS_HIERARCHY_MANAGER><Thu Jun 05 15:21:29.137 2008 New Zealand Standard Time><thread=4256 (0x10A0)>
Nothing has changed for the boundary  $$<SMS_HIERARCHY_MANAGER><Thu Jun 05 15:21:29.268 2008 New Zealand Standard Time><thread=4256 (0x10A0)>
 No profile in DB, will try to create first version of AMT profile  $$<SMS_HIERARCHY_MANAGER><Thu Jun 05 15:21:29.298 2008 New Zealand Standard Time><thread=4256 (0x10A0)>
Trying Update Amt profile, new version will be created  $$<SMS_HIERARCHY_MANAGER><Thu Jun 05 15:21:29.338 2008 New Zealand Standard Time><thread=4256 (0x10A0)>

This seemed a little strange, as there should have been more information in there after that.  It didn't indicate why the Hierarchy Manager would have failed, just that it had suddenly stopped.  On a hunch I went looking in the hman.box directory (<Config Mgr install path>\Inboxes\hman.box) and found a bunch of CT2 files in there.  In a steady state you wouldn't expect to see any files in there - they should get processed and moved on.  I decided the best thing I could do would be to move the files out (but keeping them in case they were important) and try restarting the SMS_EXECUTIVE service.  As soon as I did this, all sorts of activity started to take place.  All the components that should have been reinstalled as part of the SP1 upgrade were reinstalled, and the system eventually started functioning as normal.

 Lessons learned:

• All the information you need to troubleshoot is there in the logs
• It's not necessarily that obvious what log you need to look at
• Follow your hunches

I upgraded my home laptop to the beta of Windows 7 this weekend, and when I ran Windows Update I kept getting error 80072ee2 in the windowsupdate.log.  It's a good idea to run windows update when you've done a fresh install of Windows 7 as it picks up a fair few of the missing device drivers (including in my case video).  Error 80072ee2 is one of those errors that seems to be relatively generic, and related to network connectivity of some kind.  My fix was relatively simple - I manually downloaded the latest Intel network drivers for my machine and installed  them - problem solved.  Windows Update works again.  If you're getting this error, it's a relatively easy first step to try.

I’ve just been playing with the new Service Level Dashboard for System Center Operations Manager 2007 R2.  It’s a great improvement on the first version, and it’s pretty straightforward to set up.  I thought I’d document the steps I took to configure it, although if you just follow through the documentation you’ll get there pretty easily.

First the prerequisites:

1. Install Operations Manager 2007 R2

2. Install Windows SharePoint Services 3.0 (You need to install against SQL, not against the internal Windows database)

3. You’ll need to import the Service Level Dashboard management pack into Ops Mgr

4. Install the Service Level Dashboard following the wizard – it’s pretty straightforward.

5. Make the following change to the web.config file for the Service Level Dashboard application that gets created (by default it’s stored in C:\inetpub\wwwroot\wss\VirtualDirectories\51918) and change the line that reads:
<identity impersonate=”false”> to:
<identity impersonate=”true”>

You’ll need to run iisreset after you’ve done this.  If you don’t do this, you’ll get a “Cannot complete this action” when you navigate to the home page.

6. Make sure to create a firewall exception for the port that you’ve configured for the Service Level Dashboard.

Now you should be good to go.  First thing you need to do is define your service level in the Operations Manager console.  Open the console and go to the Authoring pane.  Choose the “Service Level Tracking” option. 

In the right hand pane, click Create. This brings up the Service Level Tracking wizard.  Give it a name.

Now we need to define what we’re interested in tracking for service levels.

The first thing we need to do is select the class that we’re monitoring.  Click the top Select button and choose the class that matches what you’re interested in.  By default it’s scoped to Distributed Application, but you can change this to Group or All.  In this case I’m interested in tracking one of my pre-created distributed applications, so I choose “Distributed Application” from the list.

Now we’ve selected our class, we need to target to a specific object – in this case I’m looking for my distributed application called “OpsMgr Website”.  This is a distributed application I created based on the “Line of business web application template” – it monitors the OpsMgr web console & backend database of the OpsMgr server itself.

Also make sure you choose a management pack to store this new service level in.

Now we need to define what our service level objective actually is

Click the Add button and we can define what we want our service level objective to be.  I want my app to available at least 95% of the time and I can specify which states count as downtime.

Once I’ve done this, I can now create the service level tracking.

Now that I’ve defined what I need to track, I can then go to the Service Level Dashboard and setup the web page that lets me view this.  Navigate to the website you set up when installing the service level dashboard (by default it’s http://localhost:51918).  It’s also blank by default.  Make sure you log on as an Administrator of the site so that you can make changes.

Go to the Site Actions button, and choose Edit Page.  This will bring up the screen below and, all things going well, you should have your service level that you’ve defined available to select.  Choose the one you want to monitor, and choose the refresh rate and over what period you want to report.  Once you’re done, exit edit mode.

You should now have a nice view of how you’re tracking against your service levels – you can see that I’m not meeting my 95% objective (that’s what happens when you stop the web console web site for a few hours…)

As you can see, the new version of the Service Level Dashboard is easy to set up and provides a great view of how you’re tracking.