SCOM and the Citrix MP

Let me just begin by saying : AAAaaaaaarrgh!

Now I feel better.

If you’ve made any attempt at implementing the MP for Citrix you likely share my pain. The dreaded “WBEM_E_Failed” error or the “Received error: 0x800a138f: 'ZoneName' is null or not an object” has likely become your nemesis, if you haven’t given up on the MP entirely. CitrixNotReady

I gave up on it for quite some time, until some new members came on board our Citrix team and said “You know, those counters in SCOM wouldn’t be so bad to have.” I expressed my earlier pain with the MP, and how we finally decided that it didn’t add much value over what was available natively in the Citrix tools. The response was, essentially, “No, really. We think we’d like this if it worked, and didn’t alert every thirty seconds for something trivial. You’re the SCOM guy, this is a SCOM thing. Make it work.”


So away we go. The course of action seemed clear. Export the MPs to xml, edit the scripts to fix the errors and perhaps tweak some defaults to fit our environment, re-seal them and re-import them. Cake and Pie, right?

Not. So. Much. For me, anyway.

You’re going to need to read this thread on the Citrix Forums, it’s the definitive place that I’ve found that deals with the issue. Hats off to Guillaume LANDY, whoever you are. However I did find bits of the thread confusing at least and the layout of solution hard to parse.

This assumes you already have some half-working installation of the Citrix MP. If not, so much the better for you.

First, export Citrix MP’s to XML. I used the Powershell Script :

$serverName = "<Your_SCOM_Server>";
$fileDestination = "<YourBackupDir>";
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
set-location "OperationsManagerMonitoring::";
new-managementGroupConnection -ConnectionString:$serverName;
set-location $serverName;
$mps = Get-ManagementPack
foreach($mp in $mps) {export-managementpack -ManagementPack:$mp -Path:$fileDestination}

to export all MP’s to the specified folder.

Once the MP’s were exported I used MPViewer to ensure that there were no overrides present in the Default MP. Even though it insisted there were not, I still could not delete the Citrix.PresentationServer MP as it said the the Default MP depended on it. I exported the Default MP and sure enough there was a “Reference Alias” to the Citrix.PresentationServer MP. I manually deleted that, re-imported the MP, and was able to delete all of the Citrix MP’s.

Even though I had the latest and greatest Citrix MP, there still appeared to be errors in the discovery javascript according to the forum post. The issues in Post Aug 18, 2008 seemed to be fixed already in the MP, but the errors outline in post Feb 26, 2009 9:25 AM clearly still existed. So below is the xml from my exported and fixed MP, beginning with line 1212 and ending with line  1240:

                // Is this server ZDC?
                    oWMIService.ExecQuery("SELECT * FROM Citrix_Zone");
                    var oZDCOutParams = oWMIService.Get("Citrix_Zone.ZoneName='" + strZone + "'");
                    var DCName = oWMIService.Get(oZDCOutParams.DataCollector);
                    if (DCName.ServerName.toLowerCase() == NetbiosComputerName.toLowerCase()) {
                        isZDC = true
                catch (ex)
                    // if we failed to get ZDC through WMI, try now MFCOM
                    var ZDCName = MFCOM_GetZDCName(strZone);
                    if (ZDCName.toLowerCase() == NetbiosComputerName.toLowerCase()) {
                        isZDC = true
                oInst.AddProperty("$MPElement[Name='Citrix.PresentationServer.ManagedServer']/IsFMS$", isFMS);
                oInst.AddProperty("$MPElement[Name='Citrix.PresentationServer.ManagedServer']/IsZDC$", isZDC);
                var loginsEnabled = false;
                    oWMIService.ExecQuery("SELECT * FROM Citrix_Zone");
                    var oCPSServer = oWMIService.Get("MetaFrame_Server.ServerName='" + NetbiosComputerName + "'");
                    var oCPSServer = oWMIService.Get("MetaFrame_Server.ServerName='" + NetbiosComputerName.toUpperCase() + "'");
                    loginsEnabled = oCPSServer.LoginsEnabled;

Sorry the formatting stinks. The key lines I’ve made red.

Now once our edits are complete it’s time to re-seal and import the MP. Although there are instructions in the Citrix Forum Post, I strongly urge you to head over to this great blog post and utilize his format for MP sealing. It will be invaluable in setting you up for future MP seals.

The key to successfully importing the Citrix MP’s is that they reference each other and you must change the /publickey info in the remaining MP’s after importing the previous ones. So:

Seal and Import Citrix.Library MP.

From the SCOM Management Console, go to Monitoring, select the Management Server, Right-Click and select “Open Command Shell” and run this command :

get-managementpack -name Citrix.Library

In the syntax returned look for “KeyToken: 5fc7f02f28591d82”. Copy whatever the hex number is on your system after the “Keytoken” and paste it into the Citrix.Library reference in line 47 of the Citrix.PresentationServer MP. Then paste it in the same spot in the Citrix.LicenseServer MP.

You can now seal and import the Citrix.PresentationServer MP. In the command prompt we opened earlier, run:

get-managementpack -name Citrix.PresentationServer

This time copy the “KeyToken” to the Citrix.LicenseServer.xml file in the Citrix.PresentationServer PublicKeyToken field. Then you can seal and import the Citrix.LicenseServer MP.

Now we’re all exported, deleted, edited, and re-imported, Everything should be happy, yes?

Well, perhaps. There may still be lingering WMI issues on the Citrix farm, particularly in the Zone Data Collectors. I’ve found these two cmd files fix most of the WMI problems on servers I encountered:

First, run this one to fix all general WMI errors (Note to change the “M:” to your system drive):

net stop winmgmt
cd %systemroot%\system32\wbem
rd /S /Q repository

regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll

mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s

Then when that’s complete, open a command window to:

\Program Files\Citrix\System32\Citrix\WMI

and run

for /f %%s in ('dir /b *.mof *.mfl') do mofcomp %%s

I’ve only had luck running that as a cmd file, not directly from the command prompt as I’ve seen elsewhere instructed.

Wait about ten minutes and check the App log for WMI errors. There should be none. ScriptoMatic v2 is a great quick tool for checking WMI across a number of servers.

So finally, after all of that, I removed and reinstalled the SCOM agent from my Citrix Farm Zone Collectors and License server. Not that I needed to or  that you should need to, but for reasons of my own.  After giving SCOM some time to percolate, I now have entries under License Server and Farm Metric Server State Views, but still nothing under “Citrix Farms” or “Citrix Zones”. We’ve also identified many, many servers in the farm with WMI issues that have been repaired.

Next up will be to step to dive into the script itself and figure out where the failure is. Since my strengths do NOT include Java programming, this should be fun. Stay tuned!

Published Sunday, April 12, 2009 12:52 PM by pwstrain
Filed under: , ,


No Comments