Powershell: Convert VMware NAA value to Frame and Device ID (for vMax and Symmetrix)

Summary:
Found a script to convert the naa value to device id, but not return the frame info.  So I augmented it to parse that info out as well.

Script Module:
Function Convert-NaaIdToVmaxFrameAndDeviceId ($naa) {
  # Original -> http://vmwise.com/2012/06/01/naa-ids-and-breaking-them-apart/
  if ($naa.length -ne 36) { "NAA value must be 36 characters"; break }
  $deviceString = $naa.ToCharArray()
  # Prepended w/ Frame info.
  $device = ("Frame $($deviceString[20])$($deviceString[21])$($deviceString[22])$($deviceString[23]) Device ") 
  $device += [char][Convert]::ToInt32("$($deviceString[26])$($deviceString[27])", 16)
  $device += [char][Convert]::ToInt32("$($deviceString[28])$($deviceString[29])", 16)
  $device += [char][Convert]::ToInt32("$($deviceString[30])$($deviceString[31])", 16)
  $device += [char][Convert]::ToInt32("$($deviceString[32])$($deviceString[33])", 16)
  $device += [char][Convert]::ToInt32("$($deviceString[34])$($deviceString[35])", 16)
  return $device
}

To use it:
  1. Save the above into a .psm1 file.
  2. Import-Module nameofpsm1file.psm1
  3. Convert-NaaIdToVMaxFrameAndDeviceID naa.#############################
    1. This will return something like this: Frame #### Device ######
To use it programmatically:
  1. Import the module
    1. $LUNs = Get-VMHost | Get-ScsiLUN | where {$_.Model -match "SYMMETRIX"};
    2. Foreach ($LUN in $LUNs){Convert-NaaIdToVMaxFrameAndDeviceID $_.CanonicalName}
  2. This will return all vMax/Symmetrix LUNs attached to all hosts in your vCenter server translating the naa value to "Frame #### Device ######" format.
Stay tuned for my next module where I translate vml RDM entries into Frame and Device ID's.

SCOM Adapter Configuration for vCOPs

Summary:
I wanted to test the SCOM adapter in vCOPs to see what data I could get and see how it could be used.  Unfortunately, the VMware video demonstrating it's installation did not work for me without some tweaks.

Config:
vCOPs 5.7.1 (vApp)
SCOM Adapter Build 1036195

Installing the Adapter:

  1. Log into your vCOPs admin page (Usually https://vcopsServer/admin)
  2. Select the Update tab and upload the 'pak' file

  3. Accept the EULA, wait.
    • Pretty much the same as updating vCOPs @ this point.
  4. Once completed, you need to log into the custom UI (https://vcopServer/custom) as an admin.
    • If you setup LDAP and made your account an admin, you're good.  Otherwise, you can login as the same admin account as the admin page.
  5. Once in the custom UI screen, hover over admin and select 'support'

  6. Select the 'Info' tab, click the gear to start the 'describe' process.

  7. Once the process is completed you should see the SCOM adapter available in the adapters info table.

  8. Congrats, the adapter is now installed.  Next we need to configure it to pull data.
    • If it's not there, you may need to restart vCOPs services.
SCOM Adapter PreReqs:
  1. SQL Account w/ dataread role access to the SCOM database.
    1. Windows account "MAY" work, but there may be a syntax problem.  I still need to test this more.

Configure Adapter Instance:
  1. At this point, watching the video would probably be easier than me typing it out w/ screenshots.
  2. If it works, GREAT!  If not, follow these next steps.
  3. SSH into the UI VM.
  4. Use VI to edit the scom.properties file.
    1. vi $ALIVE_BASE/user/plugins/inbound/msscom_adapter3/conf/scom.properties
    2. Click here if you need info on how to use VI.
  5. The line you need to change is jdbcDriver=jtds to jdbcDriver=sqljdbc
  6. Save your changes and now SSH into the Analytics VM and start @ step 4.
  7. Once done, try configuring the adapter again.  Hopefully this solves your problem.  It certainly solved mine.

An error occurred while restarting virtual machine after taking a snapshot.

Summary:
I was receiving the above error usually immediately after netbackup attempted consolidating the backup.

VMware KB:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1033571

My particular issue:
Seemed to revolve around the fact that I had "Storage I/O" control enabled on my datastores that was causing this issue.  It was odd that only 1 VM seemed to be affected, but after turning it off the symptoms stopped.  Reading the KB above seems to allude to this fact, but I'm still researching.

My resolution:
Turning off Storage I/O control.

UCS LDAP Authentication "Domain Users" will not work

[Update: Cisco has opened a bug for this.  Expected to be fixed in 2.2 release, but you can track the progress here: CSCui60138]

Summary:
In my previous post, I hypothesized that "Domain Users" simply contained too many members.  I was wrong.

Details:
After performing a couple of packet captures, I found that "Domain Users" was not an attribute returned in the "memberOf" property.  This seems to be a known response as "Domain Users" is typically classified as a "PrimaryGroup" and is therefore recorded in the "PrimaryGroupID" attribute.

Since UCS is only looking @ the "memberOf" attribute, "Domain Users" would not be returned.  I've made Cisco TAC aware of this discovery.  Whether it gets added as a bug or is simply relegated as a low hanging feature request is anybodies guess.  In the very least, I feel better to get this monkey off my back.

UCS Version:
2.1(1a)

UCS LDAP Workflow (as how it looked in my packet capture):

  1. UCS makes a LDAP bind call querying for the entered username for its "DN" and "memberOf" attributes.
  2. Once the information is returned, UCS appears to check the list of attributes in "memberOf"
  3. If UCS finds a match, it essentially grants whatever role access is granted to that LDAP group.
  4. UCS does query the LDAP group, but I'm unsure as to why it does this.  Seems redundant.
Additional Notes: