MDT 2012 – Taking LiteTouch Offline

I decided to give some of my user base something that they have been asking for for a long time… the ability to run MDT/LiteTouch deployments entirely from removable storage media. I had avoided doing this in the past as we made significant use of the MDT database in selecting hardware-specific support applications (such as Dell QuickSet).  However, with MDT 2012 (and the general deprecation of hardware-specific support software under Windows 7), I have decided to abandon the MDT database.  This makes generation of offline MDT media much more feasible.

“I should be able to get this done in a few hours!”, I thought.  Ha!  Four days later…

Gotchas in adding LiteTouch Offline media to a previously online-only environment:

Expiring stale media:

One of the leading arguments we make to persuade users to adopt the use of LiteTouch is that “we keep it up to date for you”.  What about offline media?  How to we ensure that that stays current?  One of the Brad Tucker, Deployment Guy, has a solution for that:

http://blogs.technet.com/b/deploymentguys/archive/2012/02/15/expiring-outdated-stand-alone-media.aspx

The problem there is that his script was developed for the SCCM ZTI scenatio, not LiteTouch.  However, with a little work I was able to adapt his script for use in LiteTouch.  The script body is available below.  To run it, I needed to modify the “winpeshl.ini” file in %ProgramFiles%\Microsoft Deployment Toolkit\Templates as follows:

[LaunchApps]
%SYSTEMROOT%\System32\wscript.exe,X:\Deploy\Scripts\ZUVMExpiredMediaCheck.vbs
%SYSTEMROOT%\System32\bddrun.exe,/bootstrap

The script referenced above (ZUVMExpiredMediaCheck.vbs) needs to be defined in the “Extra Directory to Include” field in the WinPE section of the Media set in the Deployment Workbench.  You need to include the “\Deploy\Scripts” folder structure in the Extras directory, too.

WinRE installation problems:

Since deploying MDT 2012, I finally worked though the problem of including both WinRE and MS DaRT tools into the LiteTouch boot media, and in the WinRE environment installed with the operating system.  However, with offline media the inclusion we would not want to copy the LiteTouch WinPE instance to disk.  Two reasons.  Firstly, the OS Deployment option simply would not work (Offline media would not be available), and secondly, we just included a script to disable the media.  To solve this problem, I needed to set the “PrepareWinRE” Property in the CustomSettings.ini file for the media set to “NO”.

MS DaRT Integration Problem:

When testing LiteTouch from a fully offline machine, I started to get a “network connection not available” error pop up at seemingly random places after starting up the boot media.  Eventually I realized that the error was coming from the DaRT Remote Connection tool that starts up with WinPE.  While this error does not cause any problems with actual deployment, I don’t want it causing end-user panic, so I decided to see if I could disable the feature.  According to documentation, I need to generate a “DartConfig.DAT” file using the DaRT configuration tool.  DartConfig.DAT is a binary configuration file (not plain text).  It’s options are not documented anywhere, so you really do have to run the GUI tool to generate a new DAT.  You then are supposed to drop the DAT file into “%ProgramFiles%\Microsoft Deployment Toolkit\Templates”, and update your boot media.  A few problems with this:

  1. If you want different configuration files installed into your WinPE instances, you will either to switch out the DartConfig.dat in the Templates directory each time you update boot media, or run the updates from a different MDT instance, or edit the LiteTouch boot WIM files each time you update the boot media.  There is no way to specify different DartConfig.dat files per deployment share or media set.
  2. The Deployment Workbench does not consistently insert the DartConfig.dat file into the LiteTouch boot media.  If you update your DartConfig.dat in the Templates directory, then update your boot media, there is no guarantee that your DartConfig.dat will get updated.  The only sure-fire way to get a new DartConfig in your deployment share seems to be to force regeneration of the boot media (i.e. you need to throw out your existing boot WIM files, not update them).  The situation is worse with offline media sets.  Rather the workbench will copy any existing boot WIMs from the root deployment share to serve as a baseline image when generating offline boot images.  Thus, to update DartConfig.dat in a media set, you need to delete both the root share boot WIMs, and the offline boot WIMs prior to updating media.
  3. You might think that you could work around that whole one-template-per-workbench problem by including a per-media-set DartConfig.dat in the “Extras” folder that you can optionally include in each media set or deployment share.  After all, the media update procedure appears to add the extras after the templates.  But if you did think this, you would be wrong.  The update apparently will not overwrite existing files within the source WIM.
  4. You might, out of sheer desperation, decided to remove DaRT from the offline boot media  by deselecting the component from the WinPE properties of the media set.  This also will fail.  The workbench will report that “DaRT cannot be removed from the media.  Use the -Force option to regenerate the media.”  Presumably the error is suggesting that you should add “-force” to the Update-MDTMedia PowerShell Cmdlet that is used to update the media set.  Sadly, “-Force” is not a valid flag for this cmdlet.

Ultimately, I just used imagex to mount the LiteTouch Offline boot media, and switched out the DartConfig.dat file using a simple “copy” command.  Now I just need to remember to do that every time.

UserExit Script – Required Modifications:

Back in 2008 I added a UserExit script to LiteTouch to generate a semi-unique computer name by taking the last eight characters of the computer’s MAC address, then appending a hyphen and a date string.  It turns out that the routine in MDT that captures the MAC address (presumably ZTIGather.vbs) will not succeed unless the computer has a functional Ethernet connection.  Grrr… When testing LiteTouch offline, we were getting computer names like “Address%-1214″.  Percent characters are not valid in computer names  so, I needed to update our UserExit to use other semi-unique system attributes such as “Serial Number” to “Asset Tag” if the MAC is not available.  I also added a fallback string of “UVMLT” if none of those variables are found.  The new script is available below, along with a sample call to the script from CustomSettings.ini.


' // ****************************************************************************
' // File:      ZUVMExpiredMediaCheck.vbs
' // Version:   1.0
' // Purpose:   Check to see if stand-alone media is expired
' // Actions:   Shuts down WinPE if media is older than iExpAge variable months
' //            Otherwise, script exits with Return 0.
' // Usage:     cscript/wscript ZUVMExpiredMediaCheck.vbs
' //            (to be added to winpeshl.ini, before bddrun.exe)
' // ****************************************************************************
Option Explicit

' // Declare Variables:
Dim cFiles
Dim dtCreationDate, dtEndDate, dtXMonthsAgo
Dim iExpAge
Dim oDiskDrive, oDrives, oExec, oFile, oFSO, oShell, oWMIService
Dim sCommand, sComputer, sExpText, sSysRoot, sUSBPath

' // Initialize Variables:
' Media Expiration Age, in months:
iExpAge = 4

' // -----------------------------------------------------------------------------------------
' // Function: Converts the WMI date query response to a simple date format.  (e.g. 09/21/2010)
Function WMIDateStringToDate(dtmInstallDate)
	WMIDateStringToDate = CDate(Mid(dtmInstallDate, 5, 2) & "/" & Mid(dtmInstallDate, 7, 2) _
	& "/" & Left(dtmInstallDate, 4) & " " & Mid(dtmInstallDate, 9, 2) & ":" _
	& Mid(dtmInstallDate, 11, 2) & ":" & Mid(dtmInstallDate, 13, 2))
End Function
' // -----------------------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------
' // Find the environment variable %SYSTEMROOT% for location of LiteTouch Executables.
Set oShell = CreateObject("WScript.Shell")
sSysRoot = oShell.ExpandEnvironmentStrings("%SYSTEMROOT%")
' // ---------------------------------------------------------------------------------

' // --------------------------------
' // Find driver letter for USB Media
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oDrives = oFSO.Drives
For Each oDiskDrive In oDrives
	If oDiskDrive.DriveType = "1" Then
		sUSBPath = oDiskDrive.Path
	End If
Next
' // --------------------------------

' // -------------------------------------------------------------------------
' // Media Check - Check for Applications.xml presence and age.
sComputer = "."
Set oWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & sComputer & "\root\cimv2")
' Query WMI for creation date of the Applications.xml file on the USB Drive:
'    NOTE: Do not add the wbemFlagForwardOnly (Decimal 32) flag to this query.  While the query would run faster
' with the flag, we also will not be able test for empty queries.
Set cFiles = oWMIService.ExecQuery("Select * From CIM_DataFile Where Name = '" & sUSBPath & "\\Deploy\\Control\\Applications.xml'")
' // -------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------
' // If Applications.xml file is not present, this is not offline media.  Exit script.
if cFiles.Count = 0 then
	Wscript.Quit(0)
end if
' // ---------------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------------------
' // If the Applications.xml file creation date is more than "iExpAge" months ago, shutdown WinPE.
For Each oFile in cFiles
	dtCreationDate = WMIDateStringToDate(oFile.CreationDate)
	dtEndDate = DateAdd("m", iExpAge, dtCreationDate)
	' Set the date iExpAge months ago from today
	dtXMonthsAgo = DateAdd("m", -iExpAge, Now)
	If dtCreationDate < dtXMonthsAgo then
		' Expiration Text, to be displayed to the user if older than iExpAge months:
		sExpText = "This LiteTouch Offline Media expired on: " & dtEndDate & chr(13) _
			& "Refresh your media using the README file located here:" & chr(13) _
			& "\\files.uvm.edu\software\Windows_Deployment_Services"
		MsgBox sExpText,vbMsgBoxSetForeground,"Expired Media"
		'Shutdown WinPE immediately:
		sCommand = sSysRoot & "\system32\wpeutil.exe shutdown"
		set oExec = oShell.Exec(sCommand)
	Else
		' If the media is fresh, run LiteTouch Offline.
		WScript.Quit(0)
	End If
Next
' // ---------------------------------------------------------------------------------------------

' // ZUVMUserExit.vbs
' // Custom Function library for use with the Microsoft Deployment Toolkit
' // Currently includes "GenUniComp" - a function for generating unique computer names

' code adapted from source content:
'   http://blogs.technet.com/benhunter/archive/2007/03/17/understanding-bdd-rule-processing.aspx

Function UserExit(sType, sWhen, sDetail, bSkip)
	UserExit = Successfs
End Function

Function GenSimDate(sSimDate)
	'Generates a simple date string in the format of YYMMDD
	Dim dNow, sYear, sMonth, sDay
	dNow = Date()
	sYear = Right(cStr(Year(dNow)), 2)
	sMonth = cStr(Month(dNow))
	sDay = cStr(Day(dNow))
	GenSimDate = sYear + sMonth + sDay
End Function

Function CleanMac(sMac)
	'Strips colon (:) characters from the variable passed to this function.  The passed variable is presumed to be a Mac address.
	Dim oRegExp
	Set oRegExp = new RegExp
	oRegExp.IgnoreCase = true
	oRegExp.Global = true
	oRegExp.Pattern = ":"
	CleanMac = oRegExp.Replace(sMac, "")
End Function

Function GenUniComp(sMac,sSerial,sATag)
	'Generates a hopefully unique computer name by:
	'   Selecting from available MacAddress, SerialNumber, or Asset Tag then
	'   triming the right eight digits from the value and appending a hyphen with the current date.
	Dim sSimDate, sUniVal
	oLogging.CreateEntry "ZUVMUserExit: sMac value in UserExit script is: " & sMac,LogTypeInfo
	oLogging.CreateEntry "ZUVMUserExit: sSerial value in UserExit script is: " & sSerial,LogTypeInfo
	oLogging.CreateEntry "ZUVMUserExit: sATag value in UserExit script is: " & sATag,LogTypeInfo
	if InStr(sMac,"%Mac") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Mac Address to generate computer name",LogTypeInfo
		sMac = CleanMac(sMac)
		oLogging.CreateEntry "ZUVMUserExit: Cleaned sMac values now is: " & sMac,LogTypeInfo
		sUniVal = sMac
	elseif InStr(sSerial,"%Serial") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Serial Number to generate computer name.",LogTypeInfo
		sUniVal = sSerial
	elseif InStr(sATTag,"%Asset") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Asset Tag to generate computer name.",LogTypeInfo
		sUniVal = sATag
	else
		oLogging.CreateEntry "ZUVMUserExit: Using Fallback Computer Name",LogTypeInfo
		sUniVal = "UVMLT"
	end if
	oLogging.CreateEntry "ZUVMUserExit: sUniVal now set to: " & sUniVal,LogTypeInfo
	sSimDate = GenSimDate(sSimDate)
	GenUniComp = Right(sUniVal, 8) + "-" + sSimDate
	oLogging.CreateEntry "ZUVMUserExit: Unique Computer Name will be: " & GenUniComp,LogTypeInfo
End Function

Calling the GenUniComp function from CustomSettings.ini:

ComputerName=#GenUniComp("%MacAddress%","%SerialNumber%","%AssetTag%")#

Windows 8 Hardware – Waiting for Godot?

I have been running Windows 8 CP on my primary workstation for about two weeks now.  The experience is surprisingly good, although I am sure that work-a-day users of Windows are going to freak out at the site of the Metro, especially when accessed from the traditional Windows keyboard and mouse.  To that end, I though it might be useful to get my hands on some touch-enabled hardware.

This has tuned out to be less than feasible.  According to the Windows 8 build blog, Win8-certified touch devices will have to be capable of handling five-point touch input:
http://blogs.msdn.com/b/b8/archive/2012/03/28/touch-hardware-and-windows-8.aspx

This is an interesting point of data, because Windows 7 “touch ready” devices only needed to support two-point multi-touch.  Thus, the almost then entire mini-ecosystem of touch devices that were built for Windows 7 will never get a Win8 certification.  Those touch monitors from Dell and HP?  Nope.  All-in-one touchscreen PCs from a multitude of manufacturers?  Nope. 

It looks as though the Win8 touch interface has been designed with the capacitive multi-touch displays that are commonplace on tablets and smartphones in mind.  But even a number of current Tablet PC and Windows Slates with capacitive multi-touch will be out in the cold, as a lot of them only support four-point multi-touch.  As for multi-touch monitors, the only that I can find that support 5+ points of touch are the 3M displayes referenced in theWin8 Build blog (see above).  Since these displays retail for over $1000, I think most people would be better off buying a tablet like the ASUS EP121, ASUS B121, or the Samsung Slate 7.

I suppose you might be able to get some mileage out of multi-touch track pads.  Most newer laptops have pads that support multi-touch, but my venerable Dell E6500 does not.  To that end, I am going to try out a Logitech TouchPad Wireless to see if having a gesture-supporting track pad buys me anything in Win8-ville.  I’ll post back with results.

In any event, it seems that those wanting to see what the Windows 8 touch experience will really be like are going to have to wait on some hardware that does not yet exist.  Touch screen ultrabooks?  Hopefully this will be more fruitful than Waiting for Godot.

MDT 2012 – The Ultimate WinPE Boot Media

This week I went to rebuild our MS DaRT Emergency Rescue Disk media.  While looking into the available tools to automate injection of our LiteTouch / MDT Deployment Workbench driver store into the DaRT boot media, I discovered something interesting in the MDT 2012 RC1 release notes… MDT 2012 supports the addition of DaRT into the LiteTouch boot media.  Once complete, you will have boot media that will support LiteTouch deployment, Standard WinRE recovery tools, and MS DaRT tools.  Too cool!  Some hours of work and a few gotchas later, it is done.  My LiteTouch media contains LiteTouch scripts, WinRE, DaRT, and PGP command line utilities.  Best of all, rebuilding of the media is sustainable.  Here is how it is done:

  1. Making WinRE available in LiteTouch boot media:
    In the Operating Systems section of the workbench, create a DEV folder.  Add to this one operating system with source files for each architecture that you need boot media for (i.e. amd64 and x86).  The OS version must match the version of WinPE used by the AIK on your build system.  (e.g. If you are using the Windows 7 AIK, you need current Windows 7 sources in the deployment share.)  To avoid trouble, make sure that these are the only operating systems with source files for this version of the AIK (e.g. You can have Vista source files if you need them, but keep only one Win 7 source so you will know which boot.wim is being used to generate your LiteTouch media).
  2. Adding DaRT:
    Follow the directions in the MDT help to install and activate the DaRT tools into the deployment share.
    In the deployment share CustomSettings.ini, set the variable:
    PrepareWinRE=YES
    This will insure that the workbench will generate a combined WinRE/DaRT image.
  3. Adding PGP:
    To make PGP tools available, use the PGPPE tools to apply pgpwde.exe to the boot.wim in the 32-bit operating system source files that you created in step 1, as follows:
    pgppe.exe /vista [pathToOSSource] [pathToPGPFiles]
    This will install PGP tools into both the Windows Setup and WinPE images in the stock boot.wim.  When you generate LiteTouch media from the Workbench, the PGP tools already will be present.
    Documentation on the use of PGPPE can be found here:
    http://www.symantec.com/business/support/index?page=content&id=HOWTO64225&actp=search&viewlocale=en_US&searchid=1332275738030
    and here:
    http://www.symantec.com/business/support/index?page=content&id=TECH149634
    (The first article contains corrections to the second article.  Note that PGPPE now is part of a standard PGP Desktop install, and does not need to be downloaded separately).

Of course, there is a lot more going on with MDT 2012 than just boot media changes… more on that later.

SharePoint 2010 – External Trust Configuration

Today I am attempting to get SharePoint 2010 to work with accounts stored in an Active Directory forest that is external to the SharePoint server.  This would be our “guest forest”.  Lots of tips are available in the net:

It is worth noting that the need to provide a username and password for search domain outside of the SharePoint web server’s domain is based on the type of trust that is present between the SharePoint server domain and the searched domain.  If the searched domain trusts the SharePoint domain (and selective authentication is not being enforced), no account credentials needs to be provided.

I used ”forest:guest.uvm.edu” as the external forest to search.  Now the people picker returns results from the external forest.  Good!  Unfortunately, when you go to apply permissions to the external user in a SharePoint site, I get a “No exact match was found. Click the item(s) that did not resolve for more options” error.  What gives?

The following thread seems to touch on this issue, but the resolution is a bit vague:
http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/edfc0ade-e994-44a3-a2e8-335abd9694ff

However, the “Full Metal Architect” page (first link in the bulleted list above) does suggest that using a “forest” search could return more limited search results, because it only queries the global catalog for user properties.  Just for grins, I converted the search scope to “domain:guest.uvm.edu”, did another IIS reset, and now I can add users.  Strange.

Ultimately, to ensure that both local domain and guest domain accounts could be searched and added using the people picker, I had to run the following commands:

stsadm -o setproperty -url [sharepointUrl] -pn peoplepicker-searchadforests -pv "domain:campus.ad.uvm.edu;domain:guest.uvm.edu"

-and-

stsadm -o setproperty -pn peoplepicker-searchadforests -pv "domain:campus.ad.uvm.edu;domain:guest.uvm.edu"

(note the abasence of the “-url” parameter in the second command)

I expect one of these commands really was not necessary, but now that things are working the way I want them to, I am going to leave well enough alone.

 

SharePoint 2010 – Authentication and Browser Support Planning

We have gone back to the drawing board with SharePoint 2010 planning, and now are challenging some ideas about how authentication must be configured for SharePoint to work with our clients.  Previously, we felt the need to provide multiple supported authenticaiton types (Windows, Basic, and Forms) hosted on different IIS web sites, with unique URL’s (sharepoint, sharepointlite, partnerpoint).  We also felt the need to have a version of sharepoint with “Client Integration” features enabled, and one with these features disabled (sharepointlite).  With changes in SharePoint 2010, is this really necessary?

First, let’s look at the Windows vs. Basic assumption.  Are there any browsers out there that do not support Windows/NTLM authentication?  In fact, there are… the Android mobile browser and, um…, well, there do not appear to be any others.  However, it is not necessary to make a separate web site available to allow basic authentication.  If we enable basic auth on an exsiting Windows-auth web site, browsers that do not support Windows auth suddenly start working. (Update, 2013-02-36:  Chrome for Android now supports NTLM authentication, so there appears to be no need to support Basic authentication at all at this point in time.)

Now, let’s look at the client integrated vs. dumbed-down assumption.  Previously, we wanted to ensure the clients handled links to MS Office documents stored in SharePoint in a predictable fashion.  Users of Firefox and Safari frequently complained about “strange” document handling behavior in SharePoint links.  For people experiencing confusion caused by failed attempts to launch Office applications from SharePoint browser links, we exposed a version of SharePoint that had the client integration features disabled.  HOWEVER, under SharePoint 2010, the client integration features are much more reliable.  On Windows, I am able to make use of Office 2010 client integration in both IE9 and Firefox.  On the Mac, client integration works with Office 2011 Mac and Safari 5 or FireFox 8.  Additionally, SharePoint will detect if a browser cannot support client integration, and will disable Office inegration links automatically.  For example, the “Open in Word” link is greyed-out in my Chrome browser, while the “Download file” link is active.

Add to this the new mobile web version of SharePoint 2010.  If you connect from a browser listed in the “compat.browser” file on the SharePoint web server, you get directed to a light-weight mobile version of SharePoint instead.  See: http://blogs.technet.com/b/office2010/archive/2010/03/09/configure-sharepoint-server-2010-for-mobile-device-access.aspx for more details on how “compat.browser” works.  This version will use Office Web Apps to render Office documents, but editing will not be possible.  This grants mobile users a functional (if somewhat limited) access method for SharePoint content, while at the same time sidestepping the issue of client integration.  It also means that we do not have to deal with the hassle of attempting to ensure that Office Web Apps will work in a myriad of underpowered mobile browsers.

All things considered, things are looking bright for SharePoint 2010.  It seems we no longer will need a “lite” version of SharePoint, and we will not need two URLs to support the varying authentication needs of legacy browsers.

Driver installation with SCCM Software Distribution

Here we are, working with SCCM again.  Making difficult things possible, and simple things difficult.  Today we wish to distribute a SmartCard driver to all of our managed servers, so that we can require Smart Card for certain classes of logins.  the newer “CNG” Smart Card minidrivers are all simple “.inf” driver packages that you can right-click install.  This ought to be easy, thought the sys admin.  Wrong!

Installation of inf drivers is not a well documented command line procedure (unlike the rather more complicated “.msi” package, which at least is easy to script).

My thanks goes out to the following bloggers and forum users for their assistance with this case:

The script that I cobbled together to install the Athena “ASECard” minidriver is displayed below.  Note that this should work for pretty much any minidriver, as long as it has a “DefaultInstall” section in the inf file.  I just unpack the amd64 and x86 driver cab files into their respective directories, put the batch script one directory above these, and make an SCCM software package of the whole thing.  The installation command line is simply the batch file name.

@echo off
REM Installs the drivers specified in the "DefaultInstall" section
REM of the aseMD.inf that is appropriate for the current (x86 or amd64) platform.
REM Install is silent (4 flag), with no reboot (N flag).
REM The INF is specified to be in the x86 or amd64 subdirectory
REM of the script directory (%~dp0).

echo Detecting platform...
IF EXIST "%programfiles(x86)%" (GOTO :amd64) ELSE (GOTO :i386)

:i386
echo Installing 32-bit driver...
cd x86
%windir%\system32\rundll32.exe advpack.dll,LaunchINFSectionEx "%~dp0x86\aseMD.inf",DefaultInstall,,4,N
goto :EOF

:amd64
REM The command will run in 64-bit mode (%windir%\sysnative\),
REM when called from a 32-bit CMD.exe (as will be the case with SCCM).
echo Installing 64-bit driver...
cd amd64
%windir%\sysnative\rundll32.exe advpack.dll,LaunchINFSectionEx "%~dp0amd64\aseMD.inf",DefaultInstall,,4,N
goto :EOF
REM End of file

VMware Performance Charts broken again – fix your connection string.

Following upgrade of our Virtual Center server to the vSphere 5 version, we have been struggling with crashing services and memory exhaustion.  Well, the server got an upgrade from 8Gb to 16Gb of RAM this am, so it is now swimming in excess memory.  Despite this, the Perf Charts in vCenter have gone dead again.

We were seeing errors similar to those described here:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012812

We got the “”perf charts service experienced an internal error” when looking at the Performance tab for any object in the vSphere Client.  A look at the latest “vctomcat-stderr[...].log” file in “C:\Program Files\VMware\Infrastructure\tomcat\logs” reveals JDBC connection errors.  The damn service is trying to connect to the standby partner of our SQL database mirrored pair!  So where are the connection strings stored for this service.  Well, no thanks to VMware documentation, I discovered the connection string stored here:
C:\ProgramData\VMware\VMware VirtualCenter\vcdb.properties

All I had to do was append “;failoverPartner=[hostName]” to the line starting with “url=”, then restart the tomcat service (the “VMware VirtualCenter Management WebServices” service).  Viola… performance reports are back.

Now back to fixing everything else that is broken… also known as “everything”.

Windows file server aliases, NetBIOS over TCP, and Incomplete Documentation

It was inevitable… some people have started to notice that their bloody Multi-Function Devices (the overpriced beasts formerly known as “printer/scanner/copiers”) no longer can scan to our file server.  Why?  Because we got all smarty pants and tried to disabled “NetBT” (NetBIOS over TCP) for access to our new file server.  We figured “Hey, CIFS over TCP has been available since, what, 1999?  We won’t have any problems with back level clients!”.  Rubes.  Turns out a lot of MFDs still require NetBT.  Rather than be a pain, I have decided to enable NetBT on the new server.  After all, it is mainly the laggards that suffer the consequences of back-level clients (and besides, if I don’t do this I will either have to go update their firmware myself, or locate some mythological pile of gold to pay for new MFDs).

The tricky bit for us was that our clients are using a name other than the server’s primary name to access the server.  Modern clients don’t care.  SMB2-capable systems only require that the server name being used has a valid matching DNS entry, and if you want Kerberos to work, you need to add a matching Service Principal Name (SPN).  We tested that our a long time back, and had no SMB2 client issues at go live.  SMB1 is a bit more fussy… you need to tell the server not to get bent out of shape when the requested server name is not the primary server name by adding the “DisableStrictNameChecking” DWORD in the HLKM\System\CurrentControlSet\Services\LanManServer\Parameters registry key.  We picked up on that one on migration night.

But now, after activating NetBIOS over TCP, client systems still are giving us grief.  Upon connection, we can see the NetBIOS Session Service reporting “Called Name Not Present” in a wire trace.  What gives?  DNS, SPN, and WINS entries are not enough for good-old LanMan?  Sounds like the server needs some additional convincing.

It turns out the key is in “optional names”.  When I added a Reg_multi_sz entry named “OptionalNames” to the HLKM\System\CurrentControlSet\Services\LanManServer\Parameters registry key, populated it with the alias name of our file server, activated NetBIOS over TCP, then rebooted, I found that the server started granting connection requests on TCP Port 139 (the legacy NetBT CIFS port).  Horray!  As an added bonus, our windows server is now registering both its primary name and its supported alias in WINS and DNS… no need for static entries.  Now to see if the MFDs are satisfied…

It really is a pity that there is no one article on this subject in TechNet.  It appears that the folks at Microsoft have little belief that anyone would be so asinine as to want to have a file server with an alias, and support for CIFS over NetBT, and support for CIFS over TCP, and support for modern SMB2 clients.  I’ll bet a consultants would say “Gee, I have never seen this before”.  We get that a lot.

Articles that helped during this troubleshooting process:

Operations Manager – Discovered Entity Cleanup

We have been tracking a problem with some of our Operations Manager Server 2008 R2 agents. We have a pool of single CPU VMs that have been reporting “Operations Manager Agent CPU too high” alerts every ten hours or so (give or take a few hours). Unfortunately, I am not able to catch the agents while the CPU spike is taking place. Maybe I could set up a “Data Collector Set” to gather lots of process information when a CPU spike condition occurs, but I am feeling lazy and don’t want to do it.

So instead, I am taking a different approach… disabling non-essential discoveries to see if this lightens the load on the agents enough to stop the CPU spikes.  I thought I knew how to do this already, but my fist pass failed, and I had to learn something new (gasp!).  My thanks to Jonathan Almquist for his post on this subject:
http://blogs.technet.com/b/jonathanalmquist/archive/2008/09/14/remove-disabledmonitoringobject.aspx
Without that one, I would still be foundering.

I our case, I wanted to suppress discovery of System Center Configuration Manager 2007 Clients in the SCCM 2007 Management Pack.  To accomplish this, we need to identify the pertinent discovery rules, create a group that contains the agents that we want to exclude from discovery, then override the discovery for this new group.  We then can speed cleanup of the now obsolete discovered objects using the PowerShell “remove-disabledMonitoringObject” cmdlet.

  1. Go to the OpsMgr console, change to the the Authoring->Management Pack Objects->Object Discoveries view.  Use the “change scope” option to limit the displayed discovery rules to only those in the Configuration Manager management packs.  In this instance, we see there are rules for “Microsoft ConfigMgr 2007 Clients Discovery” and “Microsoft ConfigMgr 2007 Advanced Client Discovery”.  I will disable discovery for both of these.  Before moving on, take careful note of the “target” column.  In this case the target is “MOM 2005 Backward Compatibility Computer”, not “Windows Computer”, as you might expect.
  2. Change to the Authoring->Groups view.  Create a group that includes only objects of the type you identified in the first step.  I used dynamic inclusion rules to add all entities that do not match the naming convention of our Configuration Manager servers.
  3. Now go back to the Object Discoveries view, find the rules you want to override again, and add an override for objects in your new group.
  4. You could wait a few discovery cycles for the discovered entities to go away, or just pop into the OpsMgr PowerShell console, and run “remove-DisabledMonitoringObject”.  If you did your override rules properly, your undesirable objects should disappear right away.

I now have removed discovery and monitoring of the SCCM Client on all of the Windows Servers in my monitored environment.  We now shall see if this makes the OpsMgr Agent CPU utilization alerts go away.

VMware Video Problems on Server 2008 R2

Jumpy mouse and slow console performance on your Server 2008 R2 ESX guests? It is likely that the VMware Tools installer did not activate the VMware video driver. See the following KB:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011709

The key is to upgrade your current video driver using the one located in:
C:\Program Files\Common Files\VMware\Drivers