Posts Tagged ‘PowerCLI’

PowerShell and Proxy Auto Detect Problem

August 24, 2010

Just a quick one about this issue that has been plaguing me for ages. Like many people in corporate world, the browser on our corporate build is configured to point to an “automatic configuration script”. But perhaps unlike many corporates, the script at the place I work is f_huge_. And for some reason, this has introduced a problem for a particular .NET assembly that is associated with the System.Web namespace… the same namespace that is used by PowerShell when making web connections, such as when you invoke Connect-VIServer in PowerCLI.

The result is that powershell.exe starts chewing up memory like there’s no tomorrow… basically until your entire machine hangs. Lucky for me I don’t need to use PowerShell in anger on a daily basis, but this problem was enough for me to resort to running a vanilla XP VM whenever I needed to do stuff with PowerShell. But thankfully, someone took the initiative and looked into the problem with Microsoft, discovered the root cause, and a workaround. And so let it be known that I don’t get any credit for this post, but the person who should cannot be named for stupid corporate communications policy reasons.

And so here’s the workaround. Basically, you need to add the following to the powershell.exe.config file in the same directory as the powershell executable (both locations if you’re on an x64 machine – just create the file if it’s not there):

<?xml version="1.0" encoding="UTF-8"?>
   <proxy autoDetect="false"/>

Et voila! Problem solved. Not sure if any other .NET apps are affected by this, but any PowerShell scripts that directly invoke System.Web.Client (for example) will be – I have a script to grab UUIDs via the iLO interface of HP boxes, and got the same problem whenever I invoked that script. But not anymore, hooray!

Help Get PowerShell Into More VMware Products

March 2, 2009

From the VI Toolkit blog, Carter is running a poll over in the VI Toolkit community (login required in order to vote) to help VMware identify which products are in most need of PowerShellification. Of course, all VMware products are in need of PowerShell, but we understand they need to assign priorities to each of their products.

Personally, my vote is going to vCenter Orchestrator. Currently customised atomic units of a workflow can only be coded in JavaScript. All VMware admins / engineers / architects out there who are proficient in JavaScript please yell “JavaScript is not Java” now. Hmmm, I didn’t hear anything. And I have ninja hearing.

The reason I believe PowerShell support is so critical for vCenter Orchestrator is that the combination of automation and orchestration is where we all want to be. At least, it’s where the laziest of the lazy want to be, and booooy am I lazy. And by mere virtue of the fact that they visit this blog, I’m betting the 5000 or so unique visitors that come through here each month are lazy bastards too. Errr, extremely intelligent, good looking, lazy bastards.

For vCenter Orchestrator to be really successful, it needs a community to contribute these discreet workflow actions, as it would not be practical (or possible, probably) for VMware to ship every permutation of the basic VI operations with the vCenter Orchestrator product. And even if they did, there are bound to be people out there who know better ways to do things. Or at least _think_ they know better ways to do things ;).

So get over to the poll and have your say as to which VMware product will benefit from PowerShell next!

PowerCLI Mastery, Volume 3

February 9, 2009

Phew, Volume 1 and Volume 2 down, lets wrap this monster up. See, I told you I wasn’t going to leave you hanging for weeks to nail through all this.

So, picking up right from where we left off. We need to perform a configuration operation on an ESX host. Of the available properties we’re looking at now, which is most likely to tell us what we can configure? That’s right, the configManager property! If you guessed “config”, you were close – the config property tells us _what_ the current configuration values are. The configManager object tells _how_ we can do the configuring (is that even a word?). Lets click on that.

Now we’re cookin! AS you can see at the top of the page, the configManager object is a Data Object of Type ‘HostConfigManager’, the properties of which contain a whole bunch of Managed Objects. (more…)

PowerCLI Mastery, Volume 2

February 9, 2009

Thought I was going to drag this out in some scandalous attempt to keep the viewers coming back week after week? Actually, wish I had thought of that before just now. Anyways, let’s continue. If you haven’t read Volume 1 in the series, go do so now. I’ll wait for you.

So continuing on, let’s use the MOB to find a portgroup, and see if that helps us to know what we need to do. The MOB displays the internal object names for things rather than the display name you see in the VI client (the display name is still in there, but it’s usually a property of an object rather than the name of the object itself). If it makes navigation easier, open up the VI Client as well so you can see what internal object names map to which display names. (more…)

PowerCLI Mastery, Volume 1

February 9, 2009

OK, this one has been a looooooooooong time coming. I’ve been meaning to take a shot at conveying the advanced features of the VI SDK as applied to PowerShell for quite some time now. When Carter corrected me some months ago with regards to what is and isn’t possible with PowerCLI (in the first statelesx video, about 1 minute in I mistakenly suggested there was something it _couldn’t_ do :-), I’ve thought I really should get this info out there. Whether I will succeed in this post and the ones that follow is of course for you to decide (this is way to long for a single post), but I’m going to take you through what I think is the fastest way to get your head around the _entire_ SDK. That’s right, the whole fucking thing. For as you will see, when you conquer a small piece of the SDK, the rest falls like dominoes. (more…)