Archive for July, 2009

Powershell: WMI Error. RPC Server Unavailable in Xen AppServer Farm

July 29, 2009

I was getting a very puzzling RPC Server Unavailable error executing a WMI call in Powershell. The call itself was as something as simple as this:

$fruitbat = get-wmiobject -class Win32_OperatingSystem -computer BRUCE

I checked various things:
BRUCE was indeed up (online) had the RPC and WMI Services running, Windows Firewall was off, had a functioning Network Adapter and IP Address. Everything looked good.

Since BRUCE lives in a XenApp Farm I decided to make sure that the Farm was configured correctly and guess what there were some Discovery Errors when I looked inside the Citrix Access Management Console.

I ran ‘Configure Discovery’ from the Access Management Console and it completed but I was still getting RPC errors.

So, out of sheer desperation I recreated my Xen AppServer Farm.
I ran chfarm on BRUCE and recreated MyTestFarm.
Then I did a chfarm on all the other servers and re-joined them to BRUCE and MyTestFarm.

And all was well. Once again the Emergency Sacrificial Ferret was returned to his cage and started munching on those Chinese Peanuts roasted in Coconut Milk he likes so much.

So, if you’re getting RPC Server Unavailable in a Citrix Xen AppServer Farm, you’ve checked everything else and you’re feeling desperate – recreate your Farm. Your Ferret will love you for it.

BUT WAIT
As you can see the success of the WMI call depends on the health of your XenApp Farm. So before recreating the Farm, try some less aggressive fixes than I did. Recreating the entire Farm is like using a Chainsaw to get a crumpet out of your toaster. Try something a little gentler first.

1) Run “Configure Discovery” on ALL your Xen AppServer Farm servers and do that last on your Data Collector so that you know the DC is aware of all the Farm Servers.
2) Check that the Citrix IMA Service is running on all your Farm servers.

You might think of some others.
All the best!

Update: 28-Aug-2009
Here’s a little ripsnorter

Advertisements

Powershell: Cannot run EXE. The term is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.

July 29, 2009

What you may not have realised is that you need to dotsource exes as well as .ps1 script files.

In the same way that you must prepend a powershell script with .\ in order to execute it e.g. .\ripper.ps1, you must also prepend exes with .\ if the directory containing the exe is not in your PATH statement.

I was trying to run Microsoft’s devcon utility (devcon.exe) within Powershell from a backwater directory not in my PATH like so:

PS c:\backwater> devcon

Nope. It has to be dotsourced.

This works:

PS c:\backwater> .\devcon

Dotsource your exes or stick the directory in your PATH.

Powershell WMI Access Denied When Retrieving MetaFrame_Server_LoadLevel Object

July 14, 2009

This post is obscure enough for me to think it may never be read.
It was posted July 14, 2009.
Let’s see when the first read happens.

Storming the Bastille of this July 14 problem then, I am using the following escargut-wrenching Powershell WMI command to determine the load on a particular server in my XenApp farm.

$loadlevel = Get-WmiObject -Namespace root\citrix -Class metaframe_server_loadlevel -ComputerName $serverName)

Powershell was denied access. Specifically, I received the following error from the agents of the Sun King Laissez-les manger le g√Ęteau, or in Powershell-ese Access Denied

I will not pretend that I personally debugged this issue, but how you fix it is add the user group ‘Local Administrators’ to the Administrators group of your XenApp Farm in Citrix Access Management Console.

I think what it is, is that the adding of the Access overcomes the Access Denied issue. Or something.

Powershell: Shutdown/Reboot Server using WMI. Privilege Not Held

July 13, 2009

This one only took me a couple of minutes to debug, but it gave me a laugh.

Watcha Doin’ BRUCE ?
I was using the following command from within Powershell to reboot my favourite server, BRUCE

$server = get-wmiobject -computer BRUCE -class Win32_OperatingSystem
$server.reboot()

Powershell told me rack off. Specifically it was chucking an exception with Error: Privilege Not Held. Rude old Powershell.

This error had me briefly puzzled because I KNEW that the Powershell account making the WMI call had admin privileges on BRUCE.

Then I realised that the script itself was running on BRUCE. i.e. I was running a script that was trying to shut down the server on which it was running. This may not be advisable.

So I ran the script on a different server, NARELLE, and tried to reboot BRUCE from there. Surprise, surprise it worked.

In summary, you will get Privilege Not Held from Powershell WMI if you try to reboot a server on which your script/WMI call is executing. Run your script on a different machine and try again.

Other Things To Avoid
– Sawing off a branch while sitting on it.
Smashing yourself over the head with a Fire Extinguisher.

Powershell: Variable Loses Value Outside Of Loop

July 9, 2009

This never happens either.

Here is my code block modified for simplicity. NB In the actual code, “Ampersand” is a real ampersand, not the word “Ampersand”

function LoseIt($fruitBasket, $name)
{
“Ampersand”{
$numKumquats = 0
$fruitList = $fruitBasket.split(“,”)
foreach ($fruit in $fruitList)
{
$fruitname = $fruit + $name
$serv = get-wmiobject Win32_Service | where {$.name -eq $fruitName}
if ($serv.State -eq “Running”)
{
numKumquats += 1
}
write-host “Inside Loop numKumquats is ” $numKumquats
}
}
trap
{
#Exception getting Win32_Service
#scream and cry
}
write-host “Outside Loop numKumquats is ” $numKumquats
if ($numKumquats > 0)
{
MakeKumquatJam $numKumquats
}
}

The thing was, inside the loop $numKumquats was being incremented and printing out the correct values in write-host, but outside the loop, $numKumquats was always null, with the result that the function MakeKumquatJam was never called. Sob.

I “fixed” it by removing the declaration of $numKumquts outside the for loop and moving the call to MakeKumquatJam above the trap. Like so:

function KeepIt($fruitBasket, $name)
{
$numKumquats = 0
“Ampersand”{
$fruitList = $fruitBasket.split(“,”)
foreach ($fruit in $fruitList)
{
$fruitname = $fruit + $name
$serv = get-wmiobject Win32_Service | where {$.name -eq $fruitName}
if ($serv.State -eq “Running”)
{
numKumquats += 1
}
write-host “Inside Loop numKumquats is ” $numKumquats
}
}

write-host “Outside Loop numKumquats is ” $numKumquats
if ($numKumquats > 0)
{
MakeKumquatJam $numKumquats
}

trap
{
#Exception getting Win32_Service
#scream and cry
}
write-host “Outside Loop numKumquats is ” $numKumquats
if ($numKumquats > 0)
{
MakeKumquatJam $numKumquats
}

}

With the above changes the function MakeKumquatJam was called… but it had nothing to do with the for loop.

The real problem was that originally I had actually declared two variables called $numKumquats, each with different scope. The scope of the first $numKumquats was global to the entire function, the scope of the second $numKumquats variable was local to the try/trap block commencing with
“Ampersand”

Originally I thought I had declared ONE instance of the variable $numKumquats which was mysteriously losing its value after the for loop completed. No No No. I had actually declared TWO variables with different scope. What a Powershell noob boner! It would never happen to you, right?

Kumquats. Beware. They make you do stuff.