PowerCLI: UserVars.CIMoemProviderEnabled, changing to a value of 1 (or 0)

Summary:
This value appears after installing the Dell OMSA vib for ESXi 4.1.  Tried changing this value to 1 using PowerCLI proved a bit more difficult than I originally thought, even cheating w/ Onyx.
Example:
Using this:

$changedValue = New-Object VMware.Vim.OptionValue[] (1)

$changedValue[0] = New-Object VMware.Vim.OptionValue

$changedValue[0].key = "UserVars.CIMoemProviderEnabled"

$changedValue[0].value = 1

$_this = Get-View -Id 'OptionManager-EsxHostAdvSettings-00000'

$_this.UpdateOptions($changedValue)

I’d get this ‘useful’ error:
Exception calling "UpdateOptions" with "1" argument(s): "A specified parameter was not correct.
"
At line:1 char:21
+ $_this.UpdateOptions <<<< ($changedValue)
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

Solution:
Apparently the ‘value’ property needs to be declared as an int64 type.  By default, Powershell assumes the value to be a ‘string’ type.  Below is what will work:

$changedValue = New-Object VMware.Vim.OptionValue[] (1)

$changedValue[0] = New-Object VMware.Vim.OptionValue

$changedValue[0].key = "UserVars.CIMoemProviderEnabled"

[int64]$changedValue[0].value = 1

$_this = Get-View -Id 'OptionManager-EsxHostAdvSettings-00000'

$_this.UpdateOptions($changedValue)

To determine what type of value the 'option' is looking for, you can query it to find out, like so:
($_this.setting | where {$_.key -eq "UserVars.CIMoemProviderEnabled"}).value.gettype().name

Above will return the 'type' of 'value' this particular setting is looking for.

Side Note:
How would you determine host and that obscure ‘OptionManager-ESXHostAdvSettings-0000’ object to work with and what host that references?  Here is how you can get to that object in the simplest fashion:

$MyESXHost = Get-VMHost MyESXHost

$MyESXHost.ExtensionData.ConfigManager.AdvancedOption

# Using examples from above, it can also be wrote out like this:

$changedValue = New-Object VMware.Vim.OptionValue[] (1)

$changedValue[0] = New-Object VMWare.Vim.OptionValue

$changedValue[0].key = "UserVars.CIMoemProviderEnabled"

[int64]$changedValue[0].value = 1

$_this = Get-View -ID $MyESXHost.ExtensionData.ConfigManager.AdvancedOption

$_this.UpdateOptions($changedValue)

ESXTOP in Mac Terminal looks funky…

Summary:

Seems that terminal in Mac is configured in a fashion where esxtop does not display properly.  Thankfully, it’s pretty easy to fix.

Example:

This demonstrates what you would see when accessing esxtop in a default configured terminal session:

Solution:

Simply change your terminal emulator session from xterm-256color to ansi, by accessing terminal’s preferences, settings, Advanced, under ‘declare terminal as:’

Open up a new terminal session, run esxtop, and you should end up w/ what looks like this:

VMWare View Powershell useful cmdlet notes.

Summary:
I’m just staring to put this together mainly for my own benefit, but if someone else finds this useful, then great.  I’ll be continually adding to this post.  If you’d like to contribute or if I got something wrong please feel free to leave a comment.
Notes:


Disable Provisioning in all linked clone pools:

$pools = get-pool

$pools | Update-AutomaticLinkedClonePool -isProvisioningEnabled:$false

Gets list of all View related cmdlets:

get-command | where {$_.modulename -match 'vmware.view'}

#Below is so you can include it into the 

#add-pssnapin.ps1 under your View installation directory

function get-viewcommand {get-command | where {$_.modulename -match 'vmware.view'}}

Gets list of pools, max number of VM's, and datastores associated:

#Helps in making sure your pools are distributed across evenly among datastores.

Get-Pool | Select Pool_ID, MaximumCount, DatastorePaths

SQLPSX, redirected my documents, and 64-bit Windows

Summary:
These 3 things don’t really want to work together.  Three issues I’ve noticed w/ SQLPSX, but ways around them to get these awesome cmdlets to work.
Based on SQLPSX 2.3.2.1
Workaround:

1. Run the MSI installation.  It defaults to your my documents directory.  Instead redirect the installation directory to your powershell module installation directory.
• Usually for 64-bit: C:\Windows\System32\WindowsPowershell\v1.0\Modules\
• 32-bit: C:\Windows\SysWow64\WindowsPowershell\v1.0\Modules\
• These feel backwards to me, but seems to be true.
2. Once installed, you’ll need to copy the module folders into your my documents redirected location.  You can get them from either the 64-bit or 32-bit paths above.  The folders you need to copy are as follows:
1. SQLMaint
2. SQLServer
3. Agent
4. Repl
5. SSIS
6. Showmbrs
7. SQLParser
8. adolib
3. Once you do so, you should be able to run ‘import-module sqlpsx’ successfully.  To find out what new cmdlets are available to you, simply run the following:
• get-command | where {$_.module -match "SQLMaint|SQLServer|Agent|Repl|SSIS|ShowMbrs|SQLParser|adolib"}
• You can also make this a function and include it in your PS profile like so:
• Function Get-SQLcommands {get-command |where {$_.module -match "SQLMaint|SQLServer|Agent|Repl|SSIS|ShowMbrs|SQLParser|adolib"}}

If I’ve misrepresented anything or you have still have issues, feel free to leave me comments stating so.  I check each and every one.

VMWare View 4.x/5.x (missing) entries

Summary:
Stale entries in VMWare View show desktops in any of following status:

• Provisioning Error (Missing)
• Deleting (Missing)

Resolution:
If remove from the view admin console does not clear out the above entries within 30 min. – 1 hour, the steps in this KB from VMWare can assist in clearing out the those stale entries.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008658