We are moving, we are moving

In the immortal words of Eddie Murphy in Trading Spaces, “We are moving, we are moving”.  Yes, this blog now has a new home: http://myitforum.com/cs2/blogs/jsandys/default.aspx.  I’ve ported all of the content so pleasae update your bookmarks.

Also, in the immortal words of Bartles & James, “Thanks for your support!”

Configuration Manager on Server 2008

I just finished my first production deployment of Configuration Manager SP1 on a Windows Server 2008 system. It is fully supported and I didn’t run into any issues. The Techcenter for ConfigMgr has a page with all the “special” configuration details: http://technet.microsoft.com/en-us/library/cc431377(TechNet.10).aspx.

There were only two things that didn’t work immediately: reporting and remote console access. Reporting not working was my fault: I forgot to enable ASP via the IIS role. Remote console access was a firewall issue; I simply went into the Windows Firewall with Advanced Security management snap-in and enabled the three Windows Management Instrumentation rules.

Installation was a bit more involved, but everything was well documented in the page linked above. Good on ya ConfigMgr Team!

ConfigMgr OSD Quirk

I just hit an interesting snag when deploying XP using source files and a capture and create task sequence. In the process of customizing the task sequence, I forgot to change the User Name and Organization name for the Apply Windows Settings task. Not a big deal except that the username defaults to the currently logged on user; in this case, I was logged on as Administrator. When XP setup reached the username and organization input screen, it stopped and threw up an error saying that you cannot use Administrator for the username. As many times as I’ve installed XP, I guess I never tried to use Administrator as the username. It let me manually change it and hit OK, so, no harm, no foul I guess.

Strictly speaking this should actually be defined as an XP unattended setup quirk, but I hit it during OSD.

Server Manager vs. Computer Manager

Server Manager is the much talked about new, all-in-one, handy-dandy MMC snap-in to manage Windows Server 2008 systems.  It provides most of the same functionality of the Computer Manager snap-in that we are all used to in previous versions of Windows.  There are some notable changes and difference however:

• Server Manager does not allow connections to remote systems. Some functionality of Server Manager, specifically Roles and Features, can only work on the local system so allowing it to connect to a remote system doesn’t make sense.
• Server Manager can be launched by right-clicking on My Computer and selecting Manage.  This isn’t a difference between these two snap-ins, but is changed functionality in Server 08: previous versions of Windows launched Computer Manager using this shortcut.  A shortcut to the Computer Manager snap-in is still available via the Administrative Tools Start Menu folder(which is also reachable via the Administrative Tools item in Control Panel).
•  
• Server Manager is automatically launched upon administrative user login by a scheduled task.  A new choice for scheduled tasks in Vista and Server 08 is to run them at login and this is how the server manager launch is handled.

The main impact for me so far is a combination of numbers one and two above.  I commonly right-click on My Computer, select Manage, and then connect to another system to view logs, services, etc. instead of remoting into that system.  Now I just have to remember to go to the Admin tools to do this same task. 

This really comes into play for Hyper-V systems installed on Windows Core.  Because Windows Core has no GUI admin interface of its own, it is very difficult, if not impossible, to perform some tasks on the Core console; e.g., disk management, event log review, and device manager.  Thus, the best way to accomplish these taks on a Hyper-V core system is to connect using the Computer Management snap-in.

Nothing earth-shattering here, just a few observations and differences that are not immediately obvious and caused me a small amount of web searching.

Master Deployment Images (Part 2)

Thick vs. Thin Images.  The distinction between these two is somewhat subjective so I will start off with my simplistic and generic definitions.  Both are generic descriptions of what should be included in an image.

Thick Image:  An image that includes the OS, OS updates and patches, miscellaneous components, drivers and applications.

Thin Image: An image that contains only the OS and a very minimal set of updates and patches.

So why, in theory, is a thin image better?  Because it is easier to maintain; it contains a minimal set of components and thus a smaller set of components that must be updated.

I don’t agree with this thin vs. thick theory in whole however.  Like many theories, they sound great, but reality gets in their way.  Maintenance of images should be automated and should be a minor concern: see part 1 of this series for a further explanation.

There are a few goals for the master deployment image(s) and ease of maintenance is not one of them:

1. Hardware agnostic.  Few organizations are actually able to standardize on a single hardware system for al of their desktops, so this goal should be obvious.  What might not be readily obvious is that it is achievable.  The main obstacles to this goal are drivers and the Hardware Abstraction Layer (HAL) in XP.  Part 3 will cover this one.
2. Universal.   Images should be a baseline for all deployments in an organization, they should contain the least common denominator of all the desktop needs in an organization.  If not everyone in the organization needs an application or component, it shouldn’t go into the image and instead should be layered on after the image is deployed.  Part 4 will cover this one.
3. Deployment Speed.  This is not as important as one and two, but is still worth including and does become very important if network is not as fast as it should be or a WAN is involved.  Applications and components included in an image only slightly increase the time it takes to deploy a system because they are already installed and do not have to be pulled across the network separately.  Applications and components layered on after the deployment increase the time significantly because they must be installed and pulled over the network.  Typically installations include some files that aren’t even installed on the system, so this can have a greater impact than is first realized.

Ultimately, I honestly feel the thin vs. thick is a moot argument.  Every deployment image will probably be somewhere in the middle and what is right for one organization may not be right for another.  However, I do feel strongly that having a thin image, just for the sake of having a thin image, should not be a primary goal.  Maintenance of images, if automated and done correctly, is a minor concern.

Master Deployment Images (Part 1)

Often also called “Gold Images”, these are the images of reference systems that are created for deployment to production systems.  In this series of posts, I will go through my best practices, tips, and advice.

The first issue I would like to address is the process of updating images and how painful this is especially when there is a need to maintain multiple images.

So why would anyone want to update their master image(s)?  There are a lot of potential reasons; here’s a few I came up with off the top of my head:

1. Adding or removing a standard line of business application
2. Adding or updating a common denominator component like the .Net Framework or Internet Explorer
3. Refreshing the patch level or updating the OS service pack
4. Add new or updated drivers

Definately not a exhaustive list — I’ll go into thick vs. thin images in the next part.

If you are using a “legacy” tool from a non-Microsoft vendor, this process could definitely be painful.  First you have to update your documentation (15 minutes), find the appropriate hardware (??), deploy the image (20-25 minutes), then you have to verify the state of the image (5 minutes), update the image (5-30+ minutes), then you have to re-capture the image (20-25 minutes), re-deploy to test (20-25 minutes), test (5-10 minutes) plus any coffee breaks, user interruptions, OpsMgr alerts, etc.  All told at least 90 minutes and more like 2 hours.  Some folks even do this using ConfigMgr OSD and MDT.

My first reaction is to put up a bulls-eye on the wall that reads “Bang Head Here”.  One of the beauties of System Center Configuration Manager (ConfigMgr) Operating System Deployment (OSD) and the Microsoft Deployment Toolkit (MDT) is that they are more than imaging tools.  They are complete processes for defining an image, creating and capturing an image, deploying an image, and configuring a system after it is imaged.  You should never manually load a system to create an image; you should never manually do anything that will be done more than one or two times.  IT is about automation, so why would an IT administrator, the master of automation, not automate?

Both MDT and ConfigMgr provide facilities to automatically deploy Windows from source files (XP and 2003) or the source image (Vista and 2008), add baseline applications, add standard configurations, update the OS, and automatically capture the final state to an image.  In my experience, this usually takes about 45 minutes with very limited (if any) manual intervention.  Updating an image is simply adding the application, component, update etc. to the MDT workbench or ConfigMgr console and kicking off the automated image build.  This of course has exponential benefits if you are for some reason maintaining multiple images (and there are valid reasons for doing so).

Maintaining images, if done correctly with the LAB build in MDT or Image Creation & Capture task sequence in ConfigMgr is painless and requires very little hands-on time.  These build processes are also extensible, easily customized and scale easily to support multiple images without any duplication of effort.  Both tools are also hardware agnostic, but I’ll talk about that in a future post.

VBScript and OpsMgr

I just ran into another bizzaro problem.  Here’s the low-down:

• Clean OpsMgr 07 SP1 environment
• Installed agents on two DCs, no problems encountered
• Installed Windows base MP, no problems encountered
• Installed AD MP, problems encountered.  The DCs never showed up in the DC State view and the following warning was recorded in OpsMgr and in the OpsMgr Event Log on both DCs.
  

  Event Type:    Warning
  Event Source:    Health Service Modules
  Event Category:    None
  Event ID:    21405
  Date:        6/10/2008
  Time:        3:18:55 PM
  User:        N/A
  Computer:    XXXX-DC-02
  Description:
  The process started at 3:18:55 PM failed to create System.Discovery.Data, no errors detected in the output.  The process exited with 1
  Command executed:    “C:\WINDOWS\System32\cscript.exe” “C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 1\2170\ADLocalDiscoveryDC.vbs” 0 {42180558-CF7E-7292-C345-CF1B3F5362DD} {24A4E1CD-9AB6-51C7-BB4C-B6A8E3BE69B9} xxxx-dc-02.YYY.ZZZ.COM XXXX-DC-02
  Working Directory:    C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 1\2170\

  One or more workflows were affected by this. 

  Workflow name: Microsoft.Windows.Server.2003.AD.DomainControllerRole.DCDiscovery
  Instance name: xxxx-dc-02.YYY.ZZZ.COM
  Instance ID: {24A4E1CD-9AB6-51C7-BB4C-B6A8E3BE69B9}
  Management group: XXXX-MG-01

My first step was of course searching the web: surprisingly almost nothing to be found.  Some references to oomads, the Operations Manager Helper Objects for AD.  So I checked out one of the DCs and they’re not there.  These are usually installed automatically when the MP rules are pushed to a system, but I gave it a shot.  After a manual install and re-installation of the MP, same issue.

Next, I logged into the DC to try to run the script manually: Can’t find script engine “VBScript” for script…  Now that’s something I’ve never seen before.  Back to my favorite search engine and lots of hits.  The solution appears simple: regsvr32 %systemroot%\system32\vbscript.dll.  This time, after re-installing the AD MP, everything works as expected.

So what’s unique about these DCs?  The only thing is that they are 64-bit Windows 2003.  I’ve installed lots of agents on 64-bit Windows 2003 before without issues, but this is the first time on 64-bit 2003 DCs.  Without further testing, I can’t verify if this is indeed the case, but it’s something to note. 

This was definitely not an OpsMgr problem, but I could see OpsMgr getting blamed for it — a classic example of shooting the messenger.  I’m sure that all OpsMgr administrators are used to this though.

Oh yeah, this was another “I am better than you [you stupid system]” moment.

I Am Better Than You…

That’s what I like to tell a system when I solve a particularly troublesome problem; sometimes I even pound on my chest.  I know: what a geek.

The problem this time had to do with sending e-mail through Outlook 2007 via a third-party application; in this case, the application was FeedDemon.  The problem was that when I clicked on the in-application link to forward a post via e-mail, the e-mail was created in plain text — this of course caused a loss of the post’s formatting and pictures which resulted in an ugly e-mail to say the least.  What was really annoying was that this worked fine last week and I didn’t change anything (that I know of).

Another reason that this caused me so much anguish is that I’ve experienced this issue before with another RSS feed reader: OnFolio.  I never got that fully resolved either.  There are two primary commonalities: Outlook 2007 and Internet Explorer 7.  The problem never manifests itself with Internet Explorer 6 and goes away if I load Outlook 2003.

After a lot of searching I finally came upon a promising potential fix: the file association for URL:MailTo.  Upon investigation, it was missing.  Resetting Outlook as the default program did not restore this file association.

I downloaded a reg file to add it back, updated the file to match my configuration, and imported it (contents copied below).  Like magic, the send to from FeedDemon produced a pretty HTML message again.

How did the file association get deleted?  I have no idea.

Why doesn’t resetting the default program recreate this key?  Not a question I can answer.

Would this have fixed my issue with OnFolio? I don’t know because that was at a previous employer. 

I am now happy again and can resume spamming my colleagues and friends with “useful” blog posts.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\mailto]
“EditFlags”=hex:02,00,00,00
“URL Protocol”=”"
@=”URL:MailTo Protocol”

[HKEY_CLASSES_ROOT\mailto\DefaultIcon]
@=”\”C:\\Program Files (x86)\\Microsoft Office\\Office12\\OUTLOOK.EXE\”,7″

[HKEY_CLASSES_ROOT\mailto\shell]

[HKEY_CLASSES_ROOT\mailto\shell\open]

[HKEY_CLASSES_ROOT\mailto\shell\open\command]
@=”\”C:\\Program Files (x86)\\Microsoft Office\\Office12\\OUTLOOK.EXE\” -c IPM.Note /m \”%1\”"

Microsoft Deployment and Hyper-V

Now that I’m up and running with Hyper-V on my laptop, I decided to put together a LiteTouch demo using the latest Microsoft Deployment Toolkit (MDT).  In the process, I discovered two annoying things concerning the so-called Uberbug.

1. The Hyper-V RC1 emulated BIOS for Windows XP is susceptible to the Uberbug. 
2. Windows XP SP3 does not include the published fix from Microsoft for the Uberbug in Windows XP SP2: KB931760.  The article specifically identifies only SP2 so I doubt that the patch would work on SP3 without breaking other things.

While neither problem is a show-stopper and both are easy to fix via the Set Diskpart BIOS Compatibility Mode task sequence task, it is still annoying that they were not accounted for or addressed.

Other than that, no issues.  Hyper-V rocks BTW.

Hyper-V RC0

As most folks know, the RTM version of Windows Server 2008 includes a beta version of Hyper-V. In March, Microsoft released Hyper-V Release Candidate Zero (RC0). The update from the beta to RC0 is described in KB 949219. Now the thing I discovered about 949219 is that it doesn’t only apply to the Hyper-V hypervisor itself, it must also be applied to any 2008 Server systems where the Hyper-V tools were installed in order to connect to an RC0 Hyper-V server – this unfortunately takes a reboot. Additionally, 949219 must also be applied to virtual guests running Windows Server 2008. By default, 2008 Server has the integration components installed; the problem is that it has the beta integration components and these must be updated to the RC0 integration components. Without the RC0 update, the mouse will not work via a terminal session and the NIC drivers will not be present (among other things).

So how do you get 949219 to the guest if it doesn’t have a network connection? The easiest way (for me) is to create an ISO using a tool like ImgBurn and then mount it in the guest. You can even get fancy and add an autorun.inf to the ISO so it launches the update automatically. I actually had to do this because I’m RDPed into a 2008 server where the Hyper-V tools are installed to connect to a server 2008 core Hyper-V system and without the mouse integration working, I can only use the keyboard to control the guest.

I also discovered a great way to enter product keys: Entering Product Keys into Virtual Machines.