How often have you been finding out the PowerShell version you were using, or to which vSphere Server you were connected, or in which git repo/branch your code was being stored, or… Despair no more, it can now be available at your fingertips.
The following is a write up of a part of session HBI1729BU ,that was presented at VMworld US 2019.
Your vSphere environment is a living environment. Inventory objects are created and removed all the time. Together with these inventory objects there are often security permissions that come along. Team X needs Power User access for all VMs in folder Project-X. But the life-cycle management of these permissions is often not as fluent as your VM life cycle management. There is no built in permission cleanup method.
As a result, old permissions might be left behind, and what is worse, redundant permissions might be present. This doesn’t make the task of investigating “Who can do what?” in your vSphere environment any easier.
With the help of the function in this post you can now get rid of all these redundant permissions!
The Invoke-VMScript cmdlet is definitely one of the PowerCLI cmdlets that is indispensable when you need to do things inside the Guest OS of your VMs.
When you are interacting with a Windows based Guest OS you can run old-fashioned BAT files or use PowerShell scripts. When the Guest OS is Linux based, you currently only can run Bash scripts.
Most Linux flavours have a feature that is called SheBang, and which allows you to specify in the first line of your bash script, which interpreter shall be used to run the following lines of the script. Unfortunately, the current Invoke-VMScript cmdlet doesn’t allow one to use that feature.
Time to tackle that issue, and expand the possibilities for all VMs that have a Linux-based Guest OS. So I decided to write my Invoke-VMScriptPlus function.
How many of you have seen Alan‘s, by now famous, book, where he writes down all the user requests and comments he receives ?
Today Alan, and the PowerCLI Dev Team, have proven once again that this book is not there for the show. As I already mentioned some time ago in PowerCLI 5.5 R2, they do listen to you !, these guys keep improving an otherwise fantastic product at regular intervals. And note that 5.5R2 was only released a mere 18 months ago !
In today’s PowerCLI 6.0 Release 2 they added a bunch of highly interesting features. Just to name a few:
Further steps to a full Module distribution. The License component is now a module as well. And they fixed the issue with the $PSModulePath I mentioned in Fixing a (minor) PowerCLI 6 R1 issue
Further VROps integration, and I’m especially excited about the Get-OMStat cmdlet.
Update Manager integration. We have all been waiting for this one! No more separate product, fully integrated in PowerCLI, and it will work with Update Manager 5.5 and later.
Finding out which performance counters are available on your vSphere server over which time interval, is not always an easy task. There is of course the Performance Manager entry in the VMware vSphere API Reference, but that is not always the easiest task. Let alone finding out what a specific counter actually represents.
For that reason I decided to create a tool, which I called the Stats Toolbox, that would query the vSphere server to get the actual list of counters it collects for each interval. In the tool I added some extra features that would make working with the performance counters easier.
During our VMworld 2014 US breakout session I demonstrated the features of the Stats Toolbox, and I received quite some positive feedback.
One of the questions, related to working with vSphere events and tasks, that often appear in the PowerCLI Community, is how do we know which events to select for a query.
To make that task a bit easier, I wrote the Event-O-Matic script. It’s a GUI that allows you to pick a number of events, and the script will generate the PowerShell code, and place it in the clipboard. The Event-O-Matic script was mentioned during our VMworld 2013 US session VSVC4944.
One of the new features that came with PowerShell v3 was the introduction of “robust” or “persistent” sessions. This is, imho, a huge improvement on the concept of remote sessions who were introduced in PowerShell v2.
In short, before robust sessions, you had to keep the the client, that created the session, open to keep the remote session alive. With robust sessions, the client side can be closed, and you can reconnect to the robust session, even from another client.
This new remote session concept is something that can be used to solve a number of known PowerCLI “issues”.
Siw stands for Server in Waiting. We selected that term since we liked the sound of it, no double entendre should be suspected 🙂
For those that are working with VMware View it is probably common knowledge that View stores information about the virtual desktop infrastructure configuration in an AD-LDS (Active Directory Lightweight Directory Service) on the Connection Servers. An AD-LDS, previously known as ADAM, is an embedded LDAP directory.
Since the current PowerShell snapin that comes with VMware View is seriously lacking functionality, and doesn’t integrate too well with the PowerCLI snapin, there are several View administrators out there, that look at this AD-LDS to help them manage their View environment.
I will list a number of existing scripts that use the AD-LDS to retrieve View related information. But most of the time these scripts go for only part of the available information.
While this blog tried to bring you useful PowerCLI scripts and functions throughout the year, I now have to revert into begging mode. The VMworld Call for Papers Voting is open !
If you enjoyed one or more of the blog posts here, or if I answered one of your questions in the PowerCLI Community, or if you enjoyed one of our sessions during a previous VMworld, please cast your vote on the sessions I submitted for VMworld 2012.
Session 1328 is offering the best of all worlds. It will answer all the questions you might have about Automation and vSphere. The panel includes superstars William Lam and Alan Renouf, and the master of ceremonies is none other than Pablo Roesch. You can’t go wrong with this session !
Session 1329, which I submitted together with my long-time co-presenter and co-author Alan Renouf, will be the sequel to our successful Best Practices session from last year. There will be a ton of new best practices ! When you use PowerCLI, or intend to use it, this is the session you shouldn’t miss.
Last year’s sessions by Alan and myself definitely was one of the highlights of my year. And judging by the comments and scores we received, it didn’t go down that badly with the attendees either. So this year we want to “raise the bar”. We have some fantastic sessions planned and hope you will come and see some of the things we have organised.
If I had to use one word to describe our sessions this year it would be “Super”. After you have seen the sessions you will understand why.
So to give you an idea of what we have planned we decided to give you a quick outline of our sessions and also a mention some of the other PowerShell and PowerCLI based sessions at VMworld….