That… Could Be A Problem…

15Sep/151

PowerCLI 6.0 R2 – Announcing vROps Integration!

For those that have been requesting some vCOps and/or vROps integration into PowerCLI, as I have been, we finally have our solution! PowerCLI 6.0 R2 brings that to the table in the form of a new module: VMware.VimAutomation.vROps

The following functions are featured in the module:
Connect-OMServer
Disconnect-OMServer
Get-OMAlert
Get-OMAlertDefinition
Get-OMAlertSubType
Get-OMAlertType
Get-OMRecommendation
Get-OMResource
Get-OMStat
Get-OMStatKey
Set-OMAlert

Here's a couple tips to get started using it:
To begin pulling stats you will need to authenticate to the vROps instance via Connect-OMServer:
Connect-OMServer

After getting connected, and being connected to an associated vCenter, check out the resources via Get-OMResource by piping it a VMHost, VM, or so forth:
get-omresource

As you can see, I pulled the resources for a VMHost. Some of the basic, higher level, information is in there such as Health status and value, whether or not vROps is receiving any data about it, and how far back data has been collecting for the resource.

The following is pulling the same information for the vROps VM in my lab environment:
get-omresource

If you want to go straight to the stats, I don't blame you one bit. However just running the Get-OMStat command is going to fill your PoSh window with every single stat available for that resource at all the time points available. Overwhelming would be putting it lightly, so you'll want to also familiarize yourself with Get-OMStatKey. This function allows you to see what all stats you can actually pull:
get-omstatkey

Couple things I feel the need to point out:

  • Include both the AdapterKind and ResourceKind objects when calling this function, it returns every possible stat key possible without it... All 17,646 of them.
  • Even when including the AdapterKind and ResourceKind, I would highly recommend filtering out what what you're looking for. The HostSystem ResourceKind has 2225 stat keys alone.

Finally, lets select a stat key and pull some detailed stats by way of the Get-OMStat function. In this scenario, I'm pulling CPU Ready Summation values:
Get-OMStat

Some of the other functions included surround alerting.

The Get-OMAlert function pulls all of the vROps alerts:
get-omalert

Since there happens to be some alerts, let's check out two abilities of the Set-OMAlert function. The first option being cancelling of an alert:
set-omalert -Cancel

If you notice in the example, the alert still exists but it's status is changed to "Inactive".

Next up, let's check out the suspend function of the Set-OMAlert function:
Set-OMAlert -SuspendMinutes

Overall, the new module definitely gets my stamp of approval! Thanks to the Automation and PowerCLI team for listening to the users and getting this integrated!

Additional information is available at the following link: https://blogs.vmware.com/PowerCLI/2015/09/powercli-6-0-release-2-is-now-generally-available.html

24Aug/151

PoSh – Gathering VMware NSX Info via API

I've been lucky enough to get a chance to do some work involving VMware's NSX product lately. Having watched a bunch of VMworld sessions, live demos and messed around with it in the VMware Hands on Labs I was fairly comfortable in an existing environment. However I've gotten fairly used to using Powershell to do most of my work and there doesn't appear to be much out there in the way of cmdlets or functions.

Chris Wahl has some really good resources regarding using Powershell to do API calls with NSX to both gather controller information (Creating NSX API Calls with PowerShell - Wahl Network) and create/remove virtual network tiers (Leveraging PowerShell to Deploy Virtual Network Tiers with VMware NSX - Wahl Network).

Thanks to Chris' first post, I've taken what he created and built out a couple additional functions and even dumped them all into module form.

An overview of what's currently included in the module:

Function Name Description
Get-NSXController Will inventory all of your controllers from NSX Manager
Get-NSXController
Get-NSXEdges Will inventory all of your Edge Nodes from NSX Manager
Get-NSXEdges
Get-NSXEdgeFeatures Will inventory all of your Edge Nodes' Features from NSX Manager
Get-NSXEdgeFeatures
Get-NSXEdgeInterfaces Will inventory the selected Edge Node's Interfaces from NSX Manager
Get-NSXEdgeInterfaces
Get-NSXEdgeNats Will inventory all of your Edge Node's NATs from NSX Manager
Get-NSXEdgeNATs
Get-NSXEdgeRoutingOverview Will inventory all of your Edge Nodes' Routing Overview details from NSX Manager
Get-NSXEdgeRoutingOverview
Get-NSXUplinks Will inventory all of your Edge Nodes' Uplinks from NSX Manager
Get-NSXEdgeUplinks

A general walk-through of what's occurring within each function is Powershell using the Invoke-WebRequest cmdlet against the NSX Manager's REST API and formatting what's returned into an easy to consume format that is a similar match to what's returned back by way of the "Networking and Security" plugin.

Requirements:
Powershell 3.0 or better: Invoke-WebRequest first appeared in Powershell version 3.0, so anything less won't work.
NSX Manager Admin credentials: All of the information is being pulled directly from the NSX Manager
Import the module by way of the .psd1 file: while not really a requirement, it certainly helps with the formatting of the output

Example of how the formatting is handled, first with the .psd1 file then with the .psm1 file:
Loading NSX PSD1 vs PSM1

Link to the GitHub repo location: https://github.com/kmruddy/Powershell/tree/master/Modules/NSXModule

An automated way of downloading the files into a dedicated directory and importing the module into the current session:

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

4Mar/151

vSphere SSO – Removal of Additional Application Users

Have you ever logged into the vSphere Web Client and received a warning like this:
Could not connect to one or more vCenter Server systems

This "Could not connect to one or more vCenter Server systems" error means the web client cannot talk to vCenter server. In this case, the server having the error was decommissioned and no longer exists.

To resolve this issue, head into the "Administration" area of the web client. Follow that by going to the "Single Sign-On" area and select "Users and Groups". From there, hit the "Application Users" tab and take a look at the users. In this case there were a total of three vCenters and their associated Inventory Services:
Application Users

While in the above screen, take note of the last 6 characters of each user.

Prior to removing any of those user account it's time to verify those user accounts against the services still in existence. This information is hidden a bit, so some digging is required.

For the vCenterServer Service account, look for the "solutionUser" section of the following file: C:\ProgramData\VMware\VMware VirtualCenter\vpxd.cfg
DecomvCenter03

For the InventoryService account, again, look for the "solutionUser" section of the following file: C:\Program Files\VMware\Infrastructure\Inventory Service\lib\server\config\dataservice.properties
Inventory Service User Account

Once the user account information has been gathered, head back to the "Application Users" section and remove the accounts that were not able to be verified:
Remove vCenterServer Account
Remove InventoryService Account

Once removed, log out of the vSphere web client and log back in and the error message will no longer be displayed across the top of the screen.

Filed under: VMware 1 Comment
17Feb/150

PoSh – HP iLO – Configuring the iLO Hostname

If you've had any chance to use the HP Scripting Tools for Powershell at all you might have noticed some inconsistencies specific to the handling of server names. These issues are only made worse when combined with blade enclosures.

The biggest example to illustrate this is by using the get-hpiloservername cmdlet:
Get-HPiLOServerName Output

Now by going to the login screen of the iLO Management page we see:
HP iLO Management Page

Since this is a blade, let's also see what the Onboard Administrator (OA) Device Bay Summary page says:
HP OA Output

According to the get-hpiloservername output the standard name should be updated to match that everywhere else. The setting in the GUI that we're looking for is the "iLO Subsystem Name (Host Name)" which is located by way of the Network --> iLO Dedicated Network Port --> General tab area:
iLO Subsystem Name

Instead of reverse engineering the HP module, there's a workaround available by way of the set-hpilonetworksetting, specifically the DNSName parameter. An example:
Set-HPiLONetworkSetting -Server '10.10.10.10' -DNSName 'newserver10' -Credentials (Get-Credential)

One big thing to note, this command does perform a reset against the iLO so if you're connected to the iLO you will be kicked out and greeted by the following message:
iLO Reset

After the iLO finishes being reset, you can refresh the page and see the newly configured name:
HP iLO Management Page

Then returning to the OA Device Summary page:
HP OA Output

The next logical question is how to automate this process... That's easy enough!

Let's check out a section of IPs that are not yet configured with the get-hpilonetworksetting cmdlet:
iLO Hostname Output

Before we run the script, there are some assumptions this script makes:

  • You have the HP Scripting Tools for Powershell modules already installed.
  • You're running Powershell version 4.0. That's a requirement for the resolve-dnsname cmdlet to work.
  • DNS entries have already been made and are resolvable.
  • The login credentials are the same for all the iLO systems.

Making sure those bases are all covered it's time to run the script:

Script output will appear similar to the following: (Note the differences in output)
Script Output

After giving it a minute or two for the iLO resets to be performed, we'll check out the names again:
iLO Hostname Output

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

Tagged as: , , No Comments
29Dec/140

PowerCLI – View – Pool Health Check Report

I've been given the chance to work with View a little more here recently and focus in on some of the gaps that are missing, specifically around reporting and alerting. vC Ops and the View adapter are in use, however the alerts leave much to be desired. I'm glad to be able to say that the gaps are filled in with the new version, and new title, of vR Ops and the View adapter but this environment is not yet to that point.

Examples of the vR Ops alerts which are included by default:

vR Ops Default View Alerts

What gaps am I referring to? I'm aiming specifically at the View Pool state, provisioning state and the amount of available desktops compared to the headroom configuration.

To do this, I enlisted the help of the View PowerCLI cmdlets and the View Connection server ADAM database to create the script below that creates an output similar to this:
(Note: the asterics around the value that caused the report to be sent)

View Pool Report Output

Before getting to the script, lets cover some of the requirements of the script:

  • This script is to be run from a Connection server.
  • This script is currently formatted to have the report be consumed by way of email.
  • The email variables need to be filled in to match the environment it's being run in.
  • The email is sent only if the following criteria are met:
    • A Pool's state is false.
    • A Pool's provisioning state is false.
    • A Pool's available desktops are less than the headroom setting by the amount set in the desktopthreshold variable.
  • The default desktop threshold is meant to be a percentage and is set to a default of 90%, or 0.9. This is easily modified on line 22.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

19Dec/140

PowerCLI – Automate the vROps OVA Deployment

For those that haven't heard, vCenter Operations (known better as vC Ops) has been not only updated but renamed. It's new name is vRealize Operations (or, probably, vR Ops) and it is officially version 6.0. Previously the system was deployed in a vApp containing a UI VM and an Analytics VM. The new systems incorporates a roles for the VMs such as Master, Master Replica, Data and Remote Collecter.

However, this blog post isn't to focus on what's been updated. It's to take a look at making the deployment a little easier since most installs will have at least two nodes. If you would like some further information on the update, please check out VMware's website: http://www.vmware.com/products/vrealize-operations

After running the script below, you'll find an output similar to the following:

vROps-Deploy

Before getting to the script, lets cover some of the assumptions and requirements made in the script:

  • The OVA has already been downloaded and is placed somewhere available to the system running the script. (Example: local disk, SMB or DFS share, etc.)
  • The VM is being placed in a resource pool.
  • The local system is able to successfully run and resolve the VM name via Resolve-DnsName cmdlet which is available in PowerShell v4.
  • The subnet being used is a /24 or 255.255.255.0. This is easily modified on line 126.
  • The VLAN ID is based on the third octet of the system's IP address. This information is set on line 128 and the portgroup is set on line 133.
  • The gateway ends with '.254'. This is easily modified on line 129.
  • DNS should be modified to match your environment which is based on line 130.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

3Nov/140

PowerCLI – Gathering VMHost NIC Driver & Firmware Info

There's nothing worse than having inconsistencies in a VMware cluster. This includes patch level, driver level and definitely firmware levels. In this particular case, the focus is on the physical network adapters. Unfortunately there's no real easy to pull this directly from the vmhost and network related PowerCLI cmdlets, however you can still use PowerCLI to pull this information by way of the get-esxcli cmdlet.

After running the script below, you'll find an output similar to the following:

Script Output

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

Filed under: Powershell, VMware No Comments
9Sep/140

PowerCLI – Process of Adding Notes to VMs

Documentation is a good thing. No matter how big or small. One of the easiest methods of documentation is to use the built in annotation section for "Notes".

Annotation Notes

What I've come up with is a fairly basic script to go through all the VM objects that do not contain notes and allow the user to insert notes on a line by line basis. Here's an example:

Running the script

Here's the script to accomplish it:

If a one-liner is more your speed, give this one a go... Note: you'll have to specify your own cluster, if that's a desired use.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

3Sep/140

View – Using Powershell to Check ADAM Replication Status

Recently ran into some issues where replication on the View ADAM database wasn't going too well. Instead of checking the replication status by RDPing into each View Connection and running the repadmin command, I created a Powershell script to do it for me. This script also helped with verification due to being able to report all the Connection servers' status within a single window.

Only item to note: you will have to prepopulate the script with the desired Connection servers

I also converted the above into a little more automated script that's usable only from one of the Connection servers, thanks to how the View API ties into PowerCLI...

Items to note:

  • This has to be run through the View PowerCLI module, which only works on Connection servers.
  • It's designed to be run as a one liner.
  • It will report back the replication status on all the Connection servers involved in that particular View environment.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

15Aug/140

PoSh – Add File Share Permissions to Existing Share

Found myself in the position of having to add some permissions to an existing file share... Unfortunately none of these systems were 2012R2, whom can take advantage of the SMBShare cmdlets, so this ended up being a bigger task than I would've thought. I found tons of help and posts on creating shares, but found a surprising lack of information on a task of this nature which I would've thought fairly basic.

Couple things to note:

  • This only changes the actual file share permissions and does not touch the NTFS permissions.
  • There are 5 variables that need to be addressed prior to running the script.
  • One of those variables will require the Active Directory module imported to search specific OUs.
    The AD module isn't a mandatory item, computer names can certainly be fed in one at a time or by way of an array.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.