Powershell functions and referencing the script that calls that function...

Summary:
Lately I've been putting together functions so I can reuse code in my other scripts.  As part of error checking/reporting, I wanted to add a way for my function to reference the script that was making use of it.  I put a question out on twitter and here is what I learned.
Quick and Dirty:
function Test-Function
{
Param 
    (
    [string]$Weird
    )
Write-Host "MyInvocation" -ForegroundColor:Green
$MyInvocation
[string]$test = $MyInvocation.ScriptName.split("\") | select -Last 1
Write-Host $test -ForegroundColor:Green
}

Hit page break if you want more details and an example of how I used $MyInvocation.

How to null terminate object properties in Powershell

Summary:
I was working on a script, which I'll post on later, to insert IPMI/iLO/iDRAC configs into my ESXi hosts.  I would get an error the following error consistently no matter what I put into my IPMI object:

Exception calling "UpdateIpmi" with "1" argument(s): "A specified parameter was not correct. 
"
At line:50 char:2
+     $_this.UpdateIpmi($ipmiInfo)
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : VimException

The short answer, I had to 'null terminate' the properties in my IPMI object.  I don't know 'why' I have to do this, but the vSphere API docs state that this is a requirement.  Quite frankly, I had no idea what this meant.

Solution Example:
To null terminate an object's property, you can simply do like so:
$MyObject = "" | Select Usefulproperty
$MyObject.Usefulproperty =  ("Something" + $null)

Additional Notes:
I'll follow-up w/ a post of the script I put together to do this so that it makes more sense.

Get iDRAC/ILO (aka Baseboard Management Controller) IP via PowerCLI

Summary:
Needed a way to figure out what IP my HP iLO's / Dell iDrac's were configured with.  Ended up using an oldie, but a goodie script put together by Carter Shanklin.

PreReqs:

  1. Powershell 2+
  2. PowerCLI 4+
  3. Must have Port 443 (https) access to your ESXi hosts.
    • If firewalls are an issue you may have the option of running this from your vCenter if it's still running on Windows.  If it's the vApp, you'll need to open access to port 443.
  4. Download Carter's script
Short and Sweet:
$info = Get-VMHostWSManInstance -VMHost (Get-VMHost myESXiServer) -ignoreCertFailures -class OMC_IPMIIPProtocolEndpoint

$info
# You can remove the -ignoreCertFailures flags if your systems have trusted certs.

# This should return you the configuration of your iLO/iDrac, which includes IP address, like so:
$info.IPv4Address

Details:

Learning PowerCLI by Robert van den Nieuwendijk

Summary:
Don't ask me how to pronounce Robert's last name.

Review
The great thing about Robert's approach is that he takes the time to point out some basic powershell syntax outside of PowerCLI. You are then soon driven into some very useful cmdlets to extract information from your vSphere environment using Powershell and vSphere's PowerCLI cmdlets. There were a couple of areas of concern where a lack of explanation on certain things lead to a hmmm? moment, but overall an excellent book for a vSphere admin looking to use PowerCLI. For me as a technical person, I like the 'straight to the point' approach. This book is filled w/ little text and more usable script examples for me to get my job done as an admin/engineer.

Disclosure
For full disclosure, I was given this book to review, but was not compensated beyond this. I also have met Robert before, but that in no way has an affect on my review of this book. The above review reflects my honest opinion. You can find this book on http://www.packtpub.com/learning-powercli/book and Amazon.

The server naming convention is dead, long live the server naming convention!

Summary:

  1. Get rid of conventions that can be cross-referenced from other data sources in a programmatic fashion.  
  2. Consolidate or present those cross-referenced data points into one pane of glass.
Rant:

In times old, server's had cool names like Ferrari, Robotech, etc.  Although cool, this drove the need for a server naming convention which served useful purpose.  It could tell us a good many things about a server just by looking @ its name.  Some things could be:

  1. Location
  2. OS
  3. Application
  4. Etc.
Because of limitations in previous technologies, you had to limit your server name to a certain number of characters (coming from a Windows background).  Each of these data points needed to be shortened to acronyms or numbers.  This essentially requires a decoder ring for each section of the server name to understand it's hidden meaning.  When dealing w/ a small environment, not a big deal, but scalability becomes a problem.

Using the examples given above:
  1. Location Sources
    • IP Space
    • Active Directory Sites and Services
    • Virtualization Management systems like vCenter or SCvMM
    • Local iLOM/IDrac/OOB
  2. OS Sources
    • Active Directory
    • WSMan
    • Bash
    • Virtualization Management systems like vCenter or SCvMM
  3. Application - a bit more complex, but use sources.
    • WSMan
    • Other tools to extrapolate the installed applications and convert those to 'tags'
Bottom line:
Any modern naming convention should not contain any crypted metadata that can be programmatically cross-referenced from a trusted source.