Can you believe it? PowerCLI is closing in on a year of being in the PowerShell Gallery! We’re up to 20 different modules and, wait for it, over 2,000,000 downloads of those modules!

1. Ova Vmware Workstation

As exciting as that is, there’s still quite a few questions on how to install PowerCLI to systems that do not have internet access. We’re going to take a much closer look at that with this post. Preparing the Offline System First things first, we need to uninstall any prior instance of PowerCLI that was installed by way of the MSI. This can be done by:. Open the Control Panel. Look beneath the ‘Programs’ section, select ‘Uninstall a Program’.

To start the Horizon Workspace installation, you must deploy the OVA file using vSphere Client.

Select ‘VMware PowerCLI’, click ‘Uninstall’ One last thing to check, ensure there is no folder containing PowerCLI as part of the title in the following directory: C: Program Files (x86) VMware Infrastructure We can verify whether such a folder exists or not with a oneliner. Test-Path -LiteralPath 'C: Program Files (x86) VMware Infrastructure PowerCLI ' Accessing the PowerCLI Modules We’re now ready to download the PowerCLI modules. This task will require a system with internet access. This section has a couple of variables which depend on the version of PowerShell available on your online system and whether or not you’ve ever accessed the PowerShell Gallery previously by way of the PowerShellGet module. The easiest way to figure out which version of PowerShell you have is by using the PSVersionTable variable. Based on the output of that, follow the set of instructions below that matches the output. Online System with PowerShell 5.x:.

Open PowerShell. Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Save-Module -Name VMware. PowerCLI -Path C: Path To Destination Folder. If requested, update the NuGet provider.

If requested, trust the ‘Untrusted repository’ that is named PSGallery Note: This is a local system trust, not something that has something to do with an SSL certificate. Copy those downloaded module folders to a location that can be made accessible to the offline system. Example: USB Flash Drive, Internal File Share, etc. Online systems with the older PowerShell versions of 4.0 or 3.0, may need to have an additional module installed to access the PowerShell Gallery. The module is called ‘PowerShellGet’. We can verify whether the online system has the ‘PowerShellGet’ module available with the following command. Save-Module -Name VMware.

PowerCLI -Path C: Path To Destination Folder. If requested, update the NuGet provider. If requested, trust the ‘Untrusted repository’ that is named PSGallery Note: This is a local system trust, not something that has something to do with an SSL certificate. Copy those downloaded module folders to a location that can be made accessible to the offline system. Example: USB Flash Drive, Internal File Share, etc.

Online System with PowerShell 4.0 or 3.0 without the PowerShellGet module:. Download and install the ‘PowerShellGet’ module by way of the. Open PowerShell. Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Save-Module -Name VMware. PowerCLI -Path C: Path To Destination Folder. If requested, update the NuGet provider.

If requested, trust the ‘Untrusted repository’ that is named PSGallery Note: This is a local system trust, not something that has something to do with an SSL certificate. Copy those downloaded module folders to a location that can be made accessible to the offline system. Example: USB Flash Drive, Internal File Share, etc. Adding PowerCLI to the Offline System It’s now time to put the PowerCLI modules on to the offline system.

To take advantage of the magic that is module auto-loading, we’ll want to copy and paste those downloaded folders in one of the locations listed in the PSModulePath variable. By default, the PSModulePath variable contains the following directories:. $home Documents WindowsPowerShell Modules. $pshome Modules When everything is all said and done, you should have one of the directories listed above looking a bit like this: That’s it!

Open a PowerShell session and start using your PowerCLI commands as you did before! Wait It’s Not Working For Me! What happens when you go through the above instructions and it’s not working? The most common scenario we’ve come across is where the ‘Save-Module’ cmdlet was used with an online system that has PowerShell version 5.x.

When this happens, there are an additional level of folders created between the top-level module folder and the module files themselves. This is extremely beneficial because we can then have multiple versions of the same module available on the local system. The issue though, older versions of PowerShell do not recognize those folders and therefore cannot load the modules. When I say issue, I truly mean it. Jake Robinson, the PowerCLI Product Manager, actually created a GitHub issue for PowerShellGet calling out this problem: Good news though, there are a couple workarounds available!

First option: Upgrade your version of PowerShell on the offline system to 5.x with. Second option: Find an online system that has PowerShell versions 4.0 or 3.0 installed and use ‘Save-Module’ on that system. Those two options are simple enough, but generally in an ‘easier said than done’ manner. With that said, I’m very excited to show off a third option. This option doesn’t require installing any software or powering on that older VM you hadn’t decommissioned quite yet. This option is a simple script that is run on the offline system.

The script simply looks for the folders that already exist in any of the PSModulePath listed directories, searching specifically for PowerCLI module folders, and then removes that additional nested level of version-based folders. The script is openly available on the PowerCLI Community Repository and is named: Here’s an example of the script in action: Here’s an example of the results: (Left is the before, right is the after) Wrap-Up PowerCLI has seen a lot of success on the PowerShell Gallery. A set of modules with over 2,000,000 combined downloads is pretty impressive! However, there’s still a lot of questions over the installation process for systems that are offline.

This blog post walked us through the offline installation process, covers the most common issue users hit, and provides a new solution to help overcome that issue. Don’t delay, upgrade your version of PowerCLI on all your systems to ensure you’re getting access to the most up-to-date features, performance improvements, and bug fixes today!

This entry was posted in and tagged, on. It’s an exciting time for infrastructure automation! Enables us to use the same amazing automation framework on Mac and Linux, opening the door for many more automation opportunities in your infrastructure.

I want to personally congratulate everyone at Microsoft and the PowerShell community that made this dream a reality. The amount of effort that went into this was truly amazing and we’re excited to be a part of it! For over ten years, the PowerCLI team has been iterating on our modules as new PowerShell functionality was created, and I am excited to say we’re about to take another big leap. A little over a year ago, we released a, which was a great proof of concept that we could get PowerCLI to run on Mac and Linux. Since that time, we’ve been in very close communication with the PowerShell team about porting PowerCLI.

The PowerShell team has been a great partner in listening and responding to feedback from the PowerCLI team on the porting experience, and I am happy to say were are very, very close. Coming Soon Our next release is currently in closed alpha, and I am excited to announce we will have an open beta beginning on Feb 1 Feb 2, 2018. My goal with the open beta is to give you the opportunity to get started with PowerCLI on the OS of your choice, while also allowing us to hear your feedback and put the final polish on the release. More information about the open beta will be available very soon. The early feedback on the next release of PowerCLI is already coming in, and the critics say: IT’S AWESOME! Important Notes about the Upcoming Release The next release of PowerCLI supports PowerShell 3,4, 5.x, and Core 6.0 on Windows, and PowerShell Core 6.0 on Ubuntu 16.04, CentOS 7, and MacOS 10.12. We’ll continue to add more as we have the opportunity to add testing for these operating systems.

Finally, there are a number of deprecated cmdlets and parameters that we’ll be removing in this release, so make sure you have your in your current version so you know what will be removed. This entry was posted in on. VMware Tools is a collection of in-guest drivers and agents that optimize performance and increase the manageability for VMs within vSphere environments. Guess what, PowerCLI provides a way to automate the management of the VMware Tools lifecycle! Even better, a new module was recently entered into the to help make those management tasks even easier than before! The module includes a collection of over 10 different advanced functions!

These include the following: Get-VMByToolsInfo Retrieves the virtual machines with specified VMTools info. Get-VMToolsGuestInfo Retrieves the guest info of specified virtual machines.

Get-VMToolsInfo Retrieves the VMTools version and build number info of specified virtual machines. Get-VMToolsInstallLastError Retrieves the error code of last VMTools installation on specified virtual machines. Get-VMToolsUpgradePolicy Gets the VMTool’s upgrade policy of specified virtual machines. Invoke-VMToolsListProcessInVM Lists the running processes in the virtual machine. Invoke-VMToolsUpgradeInVMs Upgrades VMTools to the version bundled by ESXi host. Invoke-VMToolsVIBInstall Installs VMTool VIB in specified ESXi hosts. Set-VMToolsUpgradePolicy Sets the VMTool’s upgrade policy to either “manual” or “upgradeAtPowerCycle” of specified virtual machines.

Update-VMToolsConfInVM Updates the tools.conf content in guest OS. Update-VMToolsImageLocation Updates the /productLocker link in an ESXi host directly Let’s take a look at how to get started using this great module. Accessing the Module There are a couple ways to get access to this great module, all of which go through the. One of the easiest ways is to load up the repository’s page, click on the green ‘Clone or download’ button, then clicking on ‘Download ZIP’. This downloads the entire contents of the repository to your local system.

Once the download is complete, unzip the files and browse to the ‘Modules’ directory. We are now going to copy the VMToolsManagement folder and paste it in one of the directories that are listed in the PSModulePath variable. Doing this allows the module to be available for automatic importing by your PowerShell session!

By default, the PSModulePath variable contains the following directories:. $home Documents WindowsPowerShell Modules. $pshome Modules In my environment, I have placed the module in the first of the above options. This is also where my PowerCLI modules are available. One item to keep in mind, the ‘Update-VMToolsImageLocation’ does require the usage of an ESXi host’s SSH service. Therefore, the SSH service on the ESXi host must be running as well as having an SSH library on your local system. Module Usage There are a couple functions that make it really easy and straight forward to retrieve VMware Tools information from VMs in the environment.

These functions accept VM input from either direct VM parameter usage or pipeline. Here’s example output from the following advanced functions:. Get-VMToolsInfo. Get-VMToolsGuestInfo. Get-VMToolsInstallLastError There’s a very versatile function which allows us to query our environment for specific information about the state of VMware Tools on our VMs. This advanced function is ‘Get-VMByToolsInfo’ and has a couple nice parameters to help us out. The first parameter is ‘Tools Version’ which displays only VMs which contain the specified version.

The next parameter is ‘ToolsRunningStatus’ which displays only VMs which are of the specified running state. The last parameter is ‘ToolsVersionStatus’ which displays only VMs that are of a certain status. The last two parameters feature tab complete functionality for each of their inputs. Here are examples of a couple commands I ran within my environment: Let’s move on past simply retrieving information now. There are two functions which allow us to both retrieve and manage the upgrade policy for VMs. This can be done with the following advanced functions:.

Get-VMToolsUpgradePolicy. Set-VMToolsUpgradePolicy The Set-VMToolsUpgradePolicy allows us to modify the upgrade policy for a VM with the ‘UpgradePolicy’ parameter. This parameter also allows for tab completion between the two accepted policies. Here’s an example of those two functions in action: We also have the ability to change the VMware Tools logging level. This is something that is normally done internally on the guest system but, through the magic of PowerCLI, we can now do this remotely with the ‘Set-VMToolsConfInVM’ advanced function! This function features a ‘LogLevel’ parameter which handles the changing of log level.

Tab completion is available for this parameter as well. Additional information about configuring these settings can be found in. One note about this function, be aware of what the permissions are on the local system. Certain OSes can be touchy about modifying files within the folders where these configuration files are held. This module wouldn’t be complete without the ability to also upgrade a system’s VMware Tools too! This is accomplished with the ‘Invoke-VMToolsUpgradeInVMs’ advanced function. Here’s an example of it in action: Lastly, there are two functions that help to manage VMware Tools’ accessibility directly from ESXi hosts!

The ‘Update-VMToolsImageLocation’ advanced function allows us to change the location of where VMware Tools are stored for ESXi hosts. For example, we could store the VMware Tools and floppy files on a datastore instead of the local system! One other nice feature of this function, there is no reboot required for the configuration update to go into effect. Then, there is the ‘Invoke-VMToolsVIBInstall’ advanced function. This function allows us to install and make available updated versions of VMware Tools out of the normal ESXi update lifecycle. Here’s an example of updating an ESXi host with a newer version of VMware tools by way of a VIB: Summary The VMToolsManagement module is a terrific resource for any administrator needing to get quick and easy access to manage the lifecycle of VMware Tools in their environment. This module comes packed with over 10 different advanced function to handle a majority of the tasks admins face.

Head out to the, download it, and let us know in the comments how you’re putting it to use in your environment! This entry was posted in and tagged, on. PowerCLI 6.5.3 was released a few short weeks ago and one of the biggest additions was the module to manage VMware NSX-T! This version of NSX provides network virtualization to not only VMware environments, but also multi-cloud and multi-hypervisor environments too. Before diving into the module itself, there are a couple things we should cover first. This module was released as a low-level, API access only, module.

That means the module comes with the following cmdlets: Connect-NsxtServer, Disconnect-NsxtServer, and Get-NsxtService. The first two cmdlets should be fairly straight forward, but the third is where it gets interesting. The Get-NsxtService cmdlet allows us to have full access to NSX-T’s public API!

This module also gives users the capability to use a ‘create’ method to create PowerShell objects. These objects can then be modified and used as input back to the endpoint. This really helps simplify and streamline the interaction between PowerCLI and the NSX-T API endpoint!

For more information about the NSX-T 2.0 release, see the Network Virtualization blog: For more information about the NSX-T 2.0 API, see the Getting Started First things first, open up a PowerShell session and authenticate to your NSX-T Manager with the ‘Connect-NsxtServer’ cmdlet. Output Example: We are now ready to start exploring the NSX-T API with the ‘Get-NsxtService’ cmdlet. Running that cmdlet as is will return every named call for the NSX-T API, so this may be a little overwhelming at first. To make this easier, remember to reference the API Explorer as well as PowerShell’s ‘where-object’ cmdlet to help filter the names for what you need. Example: Getting NSX-T Manager Information For the first example, we are looking for information about the NSX-T Manager node.

Searching through the for ‘nsx manager appliance’, we see a ‘GET’ method against ‘/node’ that is probably the most relevant call. To consume this in the PowerCLI module, we will use the ‘Get-NsxtService’ cmdlet to search for a name that ends in ‘node’ with the following code. Get ( ) Output Example: Example: Retrieve Transport Zone Information In our second example, we will retrieve information about the configured Transport Zones. We can do this as easily as we did the NSX Manager node. Referring back to the, we can search through the available namespaces for ‘transport zones’. We’ll find one in particular that has a description of ‘List Transport Zones’. Based on that information we can infer that the service name is going to end in ‘zones’.

We’ll run the following command to find the service. $logSwitchSpec = $logSwitchSvc. Create ( ) Checking the output of the variable ‘logSwitchSpec’ we can now see a PowerShell object that can be modified to be included as part of our ‘create’ action. The required parameters are the Logical Switch name, Transport Zone ID, and admin state.

However, since this is an overlay logical switch, we can also specify the replication mode as noted in the ‘Help’ output. We can make those modifications with the following commands. Delete ( $ipPoolRemove. Id ) Output Example: Summary: PowerCLI 6.5.3 introduced a great new module to manage VMware NSX-T environments. In the NSX-T module’s current release, it has three cmdlets to connect and disconnect from the NSX Manager while the third is used to interact directly with the NSX-T API.

This blog post went through several examples including retrieving information about the NSX Manager node, Transport Zones, Logical Switches, and IP pools. We then took a look at using the API access to create a logical switch and remove an IP Pool. Let us know in the comments how you’re using the NSX-T module to manage your environment! This entry was posted in, and tagged, on. It feels just like yesterday that we released PowerCLI 6.5.3. Shockingly, it was less than a month ago when we released the brand-new module to help manage and automate your NSX-T environments.

Yet, we’re back with another brand-new module to manage VMware Cloud on AWS environments as well as a bunch of new and updated storage cmdlets too! PowerCLI 6.5.4 features the following:. New module for VMware Cloud on AWS functionality. 14 new cmdlets added to the Storage module. Several cmdlets have also been improved in the Storage module Let’s take a closer look at each of these. New VMware Cloud on AWS Module VMware Cloud on AWS (VMC) was announced earlier this year at VMworld US.

PowerCLI with the vSphere infrastructure out of the box. Mcafee activation code. How about managing the VMC service itself? Doing tasks such as creating SDDCs, adding or removing ESXi hosts, and so forth.

PowerCLI 6.5.4 makes all of that possible! This module is being released as a low-level, API access only, module and will feature the following cmdlets:. Connect-VMC.

Disconnect-VMC. Get-VmcService Note: The VMC API is currently available as a “Technical Preview” and therefore the namespace and functionality provided by the module may change in the future. When we get started with the VMC module, we’ll notice immediately that it has a little different authentication process than the other connection cmdlets. This module requires you first acquire the OAuth Refresh Token from the: Copy the refresh token, open a new PowerShell session (after having updated to PowerCLI 6.5.4), and connect to the VMC service with the following command. List ( $orgId ) Example Output: New Storage Module Cmdlets The Storage module has added a ton of functionality around vSAN encryption. PowerCLI can now manage Key Management Servers (KMS), configure KMS clusters, manage certificates, and even start the vSAN encryption process on a cluster! There are also a couple of other cmdlets available to repair vSAN objects, obtain evacuation plan information, and manage vSAN rebalance cluster actions.

Here’s a list of all the new cmdlets available:. Add-KeyManagementServer. Get-KeyManagementServer. Set-KeyManagementServer. Remove-KeyManagementServer. Get-KmsCluster.

Set-KmsCluster. New-KmipClientCertificate. Get-KmipClientCertificate.

Start-VsanEncryptionConfiguration. Get-VsanEvacuationPlan. Repair-VsanObject. Start-VsanClusterRebalance.

Stop-VsanClusterRebalance. Get-VsanRuntimeInfo Taking a look at some of these new cmdlets in action. PS C: Users kruddy Get-Cluster Demo Get-VsanRuntimeInfo Cluster VMHost ResyncTrafficMbps - - - Demo esx01.corp.local 0 Demo esx02.corp.local 0 Demo esx04.corp.local 0 Demo esx03.corp.local 0 PS C: Users kruddy Get-Cluster Demo Get-VMHost esx01.corp.local Get-VsanEvacuationPlan ft -AutoSize Entity EvacuationMode DataToSyncGB ExtraSpaceNeededGB EvacuationSucess - - - - - esx01.corp.local Full 41.375 True esx01.corp.local EnsureAccessibility 0 True esx01.corp.local NoDataMigration 0 True. Local NoDataMigration 0 True Improved Storage Module Cmdlets Last, but not least, there are some cmdlets that have received updates for additional functionality. I’m excited to announce that it’s release day yet again!

We have a great new update for you with PowerCLI 6.5.3! Just a few short months ago, two to be exact, the last version of PowerCLI was released. That release introduced a new parameter, some new content library functionality for ISOs, and even new support for certain features. PowerCLI 6.5.3 comes packed with the following:.

New module for NSX-T functionality. Addition of a ‘Create’ method for use with the ‘Get-.Service’ cmdlets. Several issues have been resolved Let’s take a closer look at each of these. New NSX-T Module PowerCLI 6.5.3 introduces a brand-new module in order to manage VMware NSX-T environments. NSX-T was announced this year at VMworld US. In a nutshell, NSX-T is the newest iteration of VMware’s multi-hypervisor NSX platform. It is also the key to multi-cloud, and container infrastructures!

This module is being released as a low-level, API access only, module and will feature the following cmdlets:. Connect-NsxtServer. Disconnect-NsxtServer.

Get-NsxtService An example of connecting to an NSX-T server and listing the nodes included in the cluster: For more information on the NSX-T RESTful API, the API documentation can be viewed on the. New Create Method Available The other major update is around the addition of a ‘Create’ method to the Get-CisService and, newly released, Get-NsxtService cmdlets when used in conjunction with an object’s ‘Help’ property. This streamlines the creation of certain objects for a template-like experience. Those who have worked with specifications when using the ‘Get-View’ cmdlet will be quite familiar with how this ‘Create’ method will work and be interacted with.

This method works against the following objects:. Parameter. Elements of a parameter (Limited to types: List, Set, Optional).

Key and value of parameters (Limited to types: Map). Fields of a parameter (Limited to types: Structure) Here’s an example on how the new ‘Create’ method can be used to create and apply settings to a specification in order to make a new VM while using the vSphere Automation SDK API. Create ( $ createSpec ) Resolved Issues This release of PowerCLI also contains some usage improvements to a handful of cmdlets. New-TagAssignment: When connected to multiple vCenters and using string based inputs for the ‘Tag’ and ‘Entity’ parameters, the cmdlet has been updated to no longer throw an error of “The specified parameter ‘Tag’ expects a single value, but your name criteria ‘’ corresponds to multiple values.”.

Set-VMHostNetworkAdapter: When configuring an ESXi host’s virtual NIC to use an IPv6 address which is managed through a vCenter Server of version 6.5, the AutomaticIPv6 property has been corrected to no longer flip the switch to ‘True’. Summary We are continuing our commitment to getting the latest and greatest functionalities, performance improvements, and issue resolutions with this latest release of PowerCLI 6.5.3. After only 2 months, we have released a new module to manage NSX-T environments, added a new ‘Create’ method for use with the Get-CisService and Get-NsxtService cmdlets, and fixed a handful of issues with existing cmdlets. Remember, updating your PowerCLI modules is now as easy as: Update-Module VMware.PowerCLI For more information on changes made in VMware PowerCLI 6.5.3, including improvements, security enhancements, and deprecated features, see the. For more information on specific product features, see the.

For more information on specific cmdlets, see the. This entry was posted in and tagged on. Is PowerCLI supported by VMware? Can support requests be opened about PowerCLI through MyVMware? Questions like these keep coming up at VMUG meetings and customer meetings. This shouldn’t be a secret! The 18 modules that are available for with the current release of PowerCLI 6.5.2 are covered under VMware’s Basic Support and Production Support scope.

With that said, there are some areas in need of clarification. The coverage areas are around the installation process and cmdlet failures. If you’re running into errors while installing or initializing PowerCLI, a support request can be opened.

If you’re using a cmdlet and you’re hitting some form of error, where the command used to work or should work according to the documentation, a support request can be opened. VMware’s Global Support Services (GSS) will work to identify the issue with you. There are some areas of PowerCLI where GSS does not have the ability to support. These areas are around any guidance for custom scripts and/or advanced functions.

VMware does have the ability to offer vSphere SDK Developer Support Service. If you are in need of this service, I would recommend speaking to your VMware account team. Now that we have the groundwork laid, let’s discuss a little further how to make a support request regarding a PowerCLI issue. Ask the Community We’re talking support requests in this blog post, but Have you asked the community?

PowerCLI has a very active community which can be accessed in many ways. First, there’s fantastic that’s open and available to search through and ask questions.

It even just recently hit 12,000 discussions! Then, there’s the channel on PowerCLI is constantly one of the busiest channels in the Slack team and has over 500 members! There’s also Twitter and using the PowerCLI hashtag. Support Request Creation In order to help streamline the process of creating a support request to VMware, I’ve compiled some helpful suggestions from both customers whom have submitted support requests and the GSS representatives whom may respond to these support requests. First and foremost, when creating a support request, you’ll notice there isn’t a “PowerCLI” support section. The best thing to do here is create a support request for product that’s having issues.

Example: If it’s a VMHost cmdlet failure, create an ESXi support request. Isolate the Issue When creating the support request, only include the specific cmdlet which is not operational. Make sure to also include the output from running the cmdlet, such as the exact error message wording. Also, where possible, attempt to use the ‘Verbose’ parameter to help generate additional informational output. User Resolve-Error If you are receiving an error, try to make use of the following function after receiving the error. The Resolve-Error function’s output helps to provide as much context about the error as possible. For more information about it’s origin and usage, please refer to the following: Include All Version Information Including all of the necessary version information is a very important step.

Part of this would include PowerShell version, PowerCLI module versions, vSphere version, and so forth. PowerShell information can be found using the built-in variable: $PSVersionTable PowerCLI module version information can be found with the following command: Get-Module –Name VMware. If your PowerCLI session is connected to your vSphere environment, obtaining the vCenter version can be done with the following command: $global:DefaultVIServer select Name,Version,Build If you happen to be running into a vSAN PowerCLI issue, obtaining the vSAN version can be obtained through the new Get-VsanView cmdlet. An example command: (Get-VsanView -Id 'VsanVcClusterHealthSystem-vsan-cluster-health-system').VsanVcClusterQueryVerifyHealthSystemVersions((Get-Cluster).Id) select VcVersion If you happen to be running into a vRealize Operations Manager (vROps) PowerCLI issue, obtaining the vROps version can be a bit tricky. This is because it involves accessing the underlying API. This can be done in two command lines though: $OmServer = $global:DefaultOMServers0.ExtensionData $OmServer.GetCurrentVersionOfServer select ReleaseName Last one, if you happen to be running into a Horizon View PowerCLI issue, obtaining the Horizon View version can also be a little tricky. However, it can be obtained in two command lines: $hvserver = $global:DefaultHVServers0.extensiondata $hvserver.ConnectionServer.ConnectionServerlist.General select Name,Version Additional Information Feel free to include any additional information which may help bring the support request to resolution.

One example, screenshots are always helpful. If the error involves any variables or pipeline input, include the output for those items as well. Summary VMware PowerCLI is supported by VMware and support requests can be opened!

VMware supports both the installation process and cmdlet usage. However, to make the support process easier:. Open a support request for the product area where the failure is occuring. Isolate the problem to the usage of a particular cmdlet. When dealing with an error, include the output from the Resolve-Error function.

Include the versions of all related products (PowerShell, PowerCLI, vSphere, etc). Include any variable and/or pipeline input being referenced Also, don’t hesitate to ask the community!

There’s a terrific wealth of knowledge who are eager to help! This entry was posted in and tagged on. When PowerCLI was converted to modules, it introduced the ability to pick and choose which modules are loaded. Taking it a step further, it also allowed users to specify which versions of those modules are loaded. Historically, PowerCLI was released as one large ‘bundle’ of modules, and was not a great release practice.

This meant that even though most modules were not touched, we were still required to go through our release processes to get them out the door. This is not scalable when trying to get features to you more frequently. With modules in the Powershell Gallery, we can now release individual modules asynchronously from other modules.

The first release to really take advantage of that is PowerCLI 6.5.2. For those whom have already updated their VMware.PowerCLI module from the Microsoft PowerShell Gallery, you noticed there were only 3 modules which were updated and needed to be downloaded. The Better Way In prior releases, we could use the ‘Get-PowerCLIVersion’ cmdlet and receive a high-level look at the overall PowerCLI version which was installed.

Previously, our versioning scheme was not supported in PowerShell, so it took a cmdlet to print the version out (Example: VMware PowerCLI 6.5 R1). That is gone now. We’ve made the change to semantic versioning in 6.5.1. This means there will be no more R1, R2, or R3 releases! Starting with PowerCLI 6.5.2, the process to get module versions has changed. Running the ‘Get-PowerCLIVersion’ cmdlet now results in a warning message indicating that it is deprecated and to use the ‘Get-Module’ cmdlet instead. Using Get-Module There are a couple ways to use the ‘Get-Module’ cmdlet to help us determine our versioning.

The reason for that is because the ‘Get-Module’ cmdlet only shows the modules which have been imported. The first way is to get the overall PowerCLI version, which is dependent on the ‘VMware.PowerCLI’ module. We can determine the version by first importing the module (if it’s not already imported) and then running the following command: Get-Module -Name VMware.PowerCLI Select-Object -Property Name,Version From the above example, we can see that we’re using PowerCLI version 6.5.2. Another way is to just reference the modules which have been loaded automatically. I have an example where we connect to our vCenter Server and then run the following command to find the versions of all the PowerCLI modules which are in-use: Get-Module -Name VMware. Select-Object -Property Name,Version From the above example, we see that we’re only using a single PowerCLI module and it happens to be versioned at 6.5.2. Running a couple additional, random, commands, we re-run the above command and see there’s now a bit more of a mix amongst our loaded modules.

Summary The new method to obtain what version of PowerCLI you’re using is through the ‘Get-Module’ cmdlet. This update was made for many reasons. This new method takes advantage of how our the PowerCLI modules can be loaded independently of each other on an as needed basis. It also takes advantage of how the PowerCLI module releases can now be done asynchronously from each other. Lastly, since we’ve changed the PowerCLI versioning over to align with the standard PowerShell versioning, there’s no need for a custom cmdlet anymore! If you’re using ‘Get-PowerCLIVersion’ in your scripts or modules, make sure you’re aware of this and update your resources to reflect this change! This entry was posted in and tagged, on.

Post navigation.

Can you believe it? PowerCLI is closing in on a year of being in the PowerShell Gallery! We’re up to 20 different modules and, wait for it, over 2,000,000 downloads of those modules! As exciting as that is, there’s still quite a few questions on how to install PowerCLI to systems that do not have internet access. We’re going to take a much closer look at that with this post. Preparing the Offline System First things first, we need to uninstall any prior instance of PowerCLI that was installed by way of the MSI.

This can be done by:. Open the Control Panel. Look beneath the ‘Programs’ section, select ‘Uninstall a Program’. Select ‘VMware PowerCLI’, click ‘Uninstall’ One last thing to check, ensure there is no folder containing PowerCLI as part of the title in the following directory: C: Program Files (x86) VMware Infrastructure We can verify whether such a folder exists or not with a oneliner. Test-Path -LiteralPath 'C: Program Files (x86) VMware Infrastructure PowerCLI ' Accessing the PowerCLI Modules We’re now ready to download the PowerCLI modules. This task will require a system with internet access.

This section has a couple of variables which depend on the version of PowerShell available on your online system and whether or not you’ve ever accessed the PowerShell Gallery previously by way of the PowerShellGet module. The easiest way to figure out which version of PowerShell you have is by using the PSVersionTable variable. Based on the output of that, follow the set of instructions below that matches the output. Online System with PowerShell 5.x:.

Open PowerShell. Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Save-Module -Name VMware.

PowerCLI -Path C: Path To Destination Folder. If requested, update the NuGet provider. If requested, trust the ‘Untrusted repository’ that is named PSGallery Note: This is a local system trust, not something that has something to do with an SSL certificate.

Copy those downloaded module folders to a location that can be made accessible to the offline system. Example: USB Flash Drive, Internal File Share, etc. Online systems with the older PowerShell versions of 4.0 or 3.0, may need to have an additional module installed to access the PowerShell Gallery.

The module is called ‘PowerShellGet’. We can verify whether the online system has the ‘PowerShellGet’ module available with the following command. Save-Module -Name VMware. PowerCLI -Path C: Path To Destination Folder. If requested, update the NuGet provider. If requested, trust the ‘Untrusted repository’ that is named PSGallery Note: This is a local system trust, not something that has something to do with an SSL certificate.

Copy those downloaded module folders to a location that can be made accessible to the offline system. Example: USB Flash Drive, Internal File Share, etc. Online System with PowerShell 4.0 or 3.0 without the PowerShellGet module:. Download and install the ‘PowerShellGet’ module by way of the.

Open PowerShell. Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Save-Module -Name VMware. PowerCLI -Path C: Path To Destination Folder. If requested, update the NuGet provider.

If requested, trust the ‘Untrusted repository’ that is named PSGallery Note: This is a local system trust, not something that has something to do with an SSL certificate. Copy those downloaded module folders to a location that can be made accessible to the offline system. Example: USB Flash Drive, Internal File Share, etc. Adding PowerCLI to the Offline System It’s now time to put the PowerCLI modules on to the offline system. To take advantage of the magic that is module auto-loading, we’ll want to copy and paste those downloaded folders in one of the locations listed in the PSModulePath variable. By default, the PSModulePath variable contains the following directories:.

$home Documents WindowsPowerShell Modules. $pshome Modules When everything is all said and done, you should have one of the directories listed above looking a bit like this: That’s it! Open a PowerShell session and start using your PowerCLI commands as you did before! Wait It’s Not Working For Me!

What happens when you go through the above instructions and it’s not working? The most common scenario we’ve come across is where the ‘Save-Module’ cmdlet was used with an online system that has PowerShell version 5.x. When this happens, there are an additional level of folders created between the top-level module folder and the module files themselves. This is extremely beneficial because we can then have multiple versions of the same module available on the local system. The issue though, older versions of PowerShell do not recognize those folders and therefore cannot load the modules.

When I say issue, I truly mean it. Jake Robinson, the PowerCLI Product Manager, actually created a GitHub issue for PowerShellGet calling out this problem: Good news though, there are a couple workarounds available! First option: Upgrade your version of PowerShell on the offline system to 5.x with. Second option: Find an online system that has PowerShell versions 4.0 or 3.0 installed and use ‘Save-Module’ on that system. Those two options are simple enough, but generally in an ‘easier said than done’ manner. With that said, I’m very excited to show off a third option.

This option doesn’t require installing any software or powering on that older VM you hadn’t decommissioned quite yet. This option is a simple script that is run on the offline system. The script simply looks for the folders that already exist in any of the PSModulePath listed directories, searching specifically for PowerCLI module folders, and then removes that additional nested level of version-based folders.

The script is openly available on the PowerCLI Community Repository and is named: Here’s an example of the script in action: Here’s an example of the results: (Left is the before, right is the after) Wrap-Up PowerCLI has seen a lot of success on the PowerShell Gallery. A set of modules with over 2,000,000 combined downloads is pretty impressive! However, there’s still a lot of questions over the installation process for systems that are offline. This blog post walked us through the offline installation process, covers the most common issue users hit, and provides a new solution to help overcome that issue. Don’t delay, upgrade your version of PowerCLI on all your systems to ensure you’re getting access to the most up-to-date features, performance improvements, and bug fixes today!

This entry was posted in and tagged, on. It’s an exciting time for infrastructure automation! Enables us to use the same amazing automation framework on Mac and Linux, opening the door for many more automation opportunities in your infrastructure.

I want to personally congratulate everyone at Microsoft and the PowerShell community that made this dream a reality. The amount of effort that went into this was truly amazing and we’re excited to be a part of it! For over ten years, the PowerCLI team has been iterating on our modules as new PowerShell functionality was created, and I am excited to say we’re about to take another big leap.

A little over a year ago, we released a, which was a great proof of concept that we could get PowerCLI to run on Mac and Linux. Since that time, we’ve been in very close communication with the PowerShell team about porting PowerCLI. The PowerShell team has been a great partner in listening and responding to feedback from the PowerCLI team on the porting experience, and I am happy to say were are very, very close. Coming Soon Our next release is currently in closed alpha, and I am excited to announce we will have an open beta beginning on Feb 1 Feb 2, 2018.

My goal with the open beta is to give you the opportunity to get started with PowerCLI on the OS of your choice, while also allowing us to hear your feedback and put the final polish on the release. More information about the open beta will be available very soon.

The early feedback on the next release of PowerCLI is already coming in, and the critics say: IT’S AWESOME! Important Notes about the Upcoming Release The next release of PowerCLI supports PowerShell 3,4, 5.x, and Core 6.0 on Windows, and PowerShell Core 6.0 on Ubuntu 16.04, CentOS 7, and MacOS 10.12. We’ll continue to add more as we have the opportunity to add testing for these operating systems. Finally, there are a number of deprecated cmdlets and parameters that we’ll be removing in this release, so make sure you have your in your current version so you know what will be removed.

This entry was posted in on. VMware Tools is a collection of in-guest drivers and agents that optimize performance and increase the manageability for VMs within vSphere environments.

Guess what, PowerCLI provides a way to automate the management of the VMware Tools lifecycle! Even better, a new module was recently entered into the to help make those management tasks even easier than before! The module includes a collection of over 10 different advanced functions! These include the following: Get-VMByToolsInfo Retrieves the virtual machines with specified VMTools info. Get-VMToolsGuestInfo Retrieves the guest info of specified virtual machines. Get-VMToolsInfo Retrieves the VMTools version and build number info of specified virtual machines.

Get-VMToolsInstallLastError Retrieves the error code of last VMTools installation on specified virtual machines. Get-VMToolsUpgradePolicy Gets the VMTool’s upgrade policy of specified virtual machines. Invoke-VMToolsListProcessInVM Lists the running processes in the virtual machine. Invoke-VMToolsUpgradeInVMs Upgrades VMTools to the version bundled by ESXi host.

Invoke-VMToolsVIBInstall Installs VMTool VIB in specified ESXi hosts. Set-VMToolsUpgradePolicy Sets the VMTool’s upgrade policy to either “manual” or “upgradeAtPowerCycle” of specified virtual machines.

Update-VMToolsConfInVM Updates the tools.conf content in guest OS. Update-VMToolsImageLocation Updates the /productLocker link in an ESXi host directly Let’s take a look at how to get started using this great module. Accessing the Module There are a couple ways to get access to this great module, all of which go through the.

One of the easiest ways is to load up the repository’s page, click on the green ‘Clone or download’ button, then clicking on ‘Download ZIP’. This downloads the entire contents of the repository to your local system. Once the download is complete, unzip the files and browse to the ‘Modules’ directory. We are now going to copy the VMToolsManagement folder and paste it in one of the directories that are listed in the PSModulePath variable. Doing this allows the module to be available for automatic importing by your PowerShell session! By default, the PSModulePath variable contains the following directories:.

$home Documents WindowsPowerShell Modules. $pshome Modules In my environment, I have placed the module in the first of the above options. This is also where my PowerCLI modules are available. One item to keep in mind, the ‘Update-VMToolsImageLocation’ does require the usage of an ESXi host’s SSH service. Therefore, the SSH service on the ESXi host must be running as well as having an SSH library on your local system.

Module Usage There are a couple functions that make it really easy and straight forward to retrieve VMware Tools information from VMs in the environment. These functions accept VM input from either direct VM parameter usage or pipeline. Here’s example output from the following advanced functions:.

Get-VMToolsInfo. Get-VMToolsGuestInfo. Get-VMToolsInstallLastError There’s a very versatile function which allows us to query our environment for specific information about the state of VMware Tools on our VMs. This advanced function is ‘Get-VMByToolsInfo’ and has a couple nice parameters to help us out.

The first parameter is ‘Tools Version’ which displays only VMs which contain the specified version. The next parameter is ‘ToolsRunningStatus’ which displays only VMs which are of the specified running state. The last parameter is ‘ToolsVersionStatus’ which displays only VMs that are of a certain status. The last two parameters feature tab complete functionality for each of their inputs.

Here are examples of a couple commands I ran within my environment: Let’s move on past simply retrieving information now. There are two functions which allow us to both retrieve and manage the upgrade policy for VMs. This can be done with the following advanced functions:. Get-VMToolsUpgradePolicy. Set-VMToolsUpgradePolicy The Set-VMToolsUpgradePolicy allows us to modify the upgrade policy for a VM with the ‘UpgradePolicy’ parameter. This parameter also allows for tab completion between the two accepted policies. Here’s an example of those two functions in action: We also have the ability to change the VMware Tools logging level.

This is something that is normally done internally on the guest system but, through the magic of PowerCLI, we can now do this remotely with the ‘Set-VMToolsConfInVM’ advanced function! This function features a ‘LogLevel’ parameter which handles the changing of log level. Tab completion is available for this parameter as well.

Additional information about configuring these settings can be found in. One note about this function, be aware of what the permissions are on the local system. Certain OSes can be touchy about modifying files within the folders where these configuration files are held. This module wouldn’t be complete without the ability to also upgrade a system’s VMware Tools too! This is accomplished with the ‘Invoke-VMToolsUpgradeInVMs’ advanced function. Here’s an example of it in action: Lastly, there are two functions that help to manage VMware Tools’ accessibility directly from ESXi hosts!

The ‘Update-VMToolsImageLocation’ advanced function allows us to change the location of where VMware Tools are stored for ESXi hosts. For example, we could store the VMware Tools and floppy files on a datastore instead of the local system! One other nice feature of this function, there is no reboot required for the configuration update to go into effect. Then, there is the ‘Invoke-VMToolsVIBInstall’ advanced function. This function allows us to install and make available updated versions of VMware Tools out of the normal ESXi update lifecycle. Here’s an example of updating an ESXi host with a newer version of VMware tools by way of a VIB: Summary The VMToolsManagement module is a terrific resource for any administrator needing to get quick and easy access to manage the lifecycle of VMware Tools in their environment. This module comes packed with over 10 different advanced function to handle a majority of the tasks admins face.

Head out to the, download it, and let us know in the comments how you’re putting it to use in your environment! This entry was posted in and tagged, on. PowerCLI 6.5.3 was released a few short weeks ago and one of the biggest additions was the module to manage VMware NSX-T! This version of NSX provides network virtualization to not only VMware environments, but also multi-cloud and multi-hypervisor environments too. Before diving into the module itself, there are a couple things we should cover first.

This module was released as a low-level, API access only, module. That means the module comes with the following cmdlets: Connect-NsxtServer, Disconnect-NsxtServer, and Get-NsxtService. The first two cmdlets should be fairly straight forward, but the third is where it gets interesting. The Get-NsxtService cmdlet allows us to have full access to NSX-T’s public API! This module also gives users the capability to use a ‘create’ method to create PowerShell objects. These objects can then be modified and used as input back to the endpoint. This really helps simplify and streamline the interaction between PowerCLI and the NSX-T API endpoint!

For more information about the NSX-T 2.0 release, see the Network Virtualization blog: For more information about the NSX-T 2.0 API, see the Getting Started First things first, open up a PowerShell session and authenticate to your NSX-T Manager with the ‘Connect-NsxtServer’ cmdlet. Output Example: We are now ready to start exploring the NSX-T API with the ‘Get-NsxtService’ cmdlet. Running that cmdlet as is will return every named call for the NSX-T API, so this may be a little overwhelming at first. To make this easier, remember to reference the API Explorer as well as PowerShell’s ‘where-object’ cmdlet to help filter the names for what you need.

Example: Getting NSX-T Manager Information For the first example, we are looking for information about the NSX-T Manager node. Searching through the for ‘nsx manager appliance’, we see a ‘GET’ method against ‘/node’ that is probably the most relevant call.

To consume this in the PowerCLI module, we will use the ‘Get-NsxtService’ cmdlet to search for a name that ends in ‘node’ with the following code. Get ( ) Output Example: Example: Retrieve Transport Zone Information In our second example, we will retrieve information about the configured Transport Zones. We can do this as easily as we did the NSX Manager node.

Referring back to the, we can search through the available namespaces for ‘transport zones’. We’ll find one in particular that has a description of ‘List Transport Zones’.

Based on that information we can infer that the service name is going to end in ‘zones’. We’ll run the following command to find the service. $logSwitchSpec = $logSwitchSvc. Create ( ) Checking the output of the variable ‘logSwitchSpec’ we can now see a PowerShell object that can be modified to be included as part of our ‘create’ action.

The required parameters are the Logical Switch name, Transport Zone ID, and admin state. However, since this is an overlay logical switch, we can also specify the replication mode as noted in the ‘Help’ output. We can make those modifications with the following commands. Delete ( $ipPoolRemove.

Id ) Output Example: Summary: PowerCLI 6.5.3 introduced a great new module to manage VMware NSX-T environments. In the NSX-T module’s current release, it has three cmdlets to connect and disconnect from the NSX Manager while the third is used to interact directly with the NSX-T API. This blog post went through several examples including retrieving information about the NSX Manager node, Transport Zones, Logical Switches, and IP pools. We then took a look at using the API access to create a logical switch and remove an IP Pool.

Let us know in the comments how you’re using the NSX-T module to manage your environment! This entry was posted in, and tagged, on.

It feels just like yesterday that we released PowerCLI 6.5.3. Shockingly, it was less than a month ago when we released the brand-new module to help manage and automate your NSX-T environments. Yet, we’re back with another brand-new module to manage VMware Cloud on AWS environments as well as a bunch of new and updated storage cmdlets too! PowerCLI 6.5.4 features the following:. New module for VMware Cloud on AWS functionality. 14 new cmdlets added to the Storage module.

Several cmdlets have also been improved in the Storage module Let’s take a closer look at each of these. New VMware Cloud on AWS Module VMware Cloud on AWS (VMC) was announced earlier this year at VMworld US. PowerCLI with the vSphere infrastructure out of the box. How about managing the VMC service itself? Doing tasks such as creating SDDCs, adding or removing ESXi hosts, and so forth. PowerCLI 6.5.4 makes all of that possible! This module is being released as a low-level, API access only, module and will feature the following cmdlets:.

Connect-VMC. Disconnect-VMC. Get-VmcService Note: The VMC API is currently available as a “Technical Preview” and therefore the namespace and functionality provided by the module may change in the future.

When we get started with the VMC module, we’ll notice immediately that it has a little different authentication process than the other connection cmdlets. This module requires you first acquire the OAuth Refresh Token from the: Copy the refresh token, open a new PowerShell session (after having updated to PowerCLI 6.5.4), and connect to the VMC service with the following command. List ( $orgId ) Example Output: New Storage Module Cmdlets The Storage module has added a ton of functionality around vSAN encryption. PowerCLI can now manage Key Management Servers (KMS), configure KMS clusters, manage certificates, and even start the vSAN encryption process on a cluster!

There are also a couple of other cmdlets available to repair vSAN objects, obtain evacuation plan information, and manage vSAN rebalance cluster actions. Here’s a list of all the new cmdlets available:. Add-KeyManagementServer. Get-KeyManagementServer. Set-KeyManagementServer.

Remove-KeyManagementServer. Get-KmsCluster. Set-KmsCluster. New-KmipClientCertificate. Get-KmipClientCertificate. Start-VsanEncryptionConfiguration. Get-VsanEvacuationPlan.

Repair-VsanObject. Start-VsanClusterRebalance. Stop-VsanClusterRebalance. Get-VsanRuntimeInfo Taking a look at some of these new cmdlets in action. PS C: Users kruddy Get-Cluster Demo Get-VsanRuntimeInfo Cluster VMHost ResyncTrafficMbps - - - Demo esx01.corp.local 0 Demo esx02.corp.local 0 Demo esx04.corp.local 0 Demo esx03.corp.local 0 PS C: Users kruddy Get-Cluster Demo Get-VMHost esx01.corp.local Get-VsanEvacuationPlan ft -AutoSize Entity EvacuationMode DataToSyncGB ExtraSpaceNeededGB EvacuationSucess - - - - - esx01.corp.local Full 41.375 True esx01.corp.local EnsureAccessibility 0 True esx01.corp.local NoDataMigration 0 True. Local NoDataMigration 0 True Improved Storage Module Cmdlets Last, but not least, there are some cmdlets that have received updates for additional functionality.

Ova Vmware Workstation

I’m excited to announce that it’s release day yet again! We have a great new update for you with PowerCLI 6.5.3! Just a few short months ago, two to be exact, the last version of PowerCLI was released. That release introduced a new parameter, some new content library functionality for ISOs, and even new support for certain features. PowerCLI 6.5.3 comes packed with the following:.

New module for NSX-T functionality. Addition of a ‘Create’ method for use with the ‘Get-.Service’ cmdlets. Several issues have been resolved Let’s take a closer look at each of these. New NSX-T Module PowerCLI 6.5.3 introduces a brand-new module in order to manage VMware NSX-T environments. NSX-T was announced this year at VMworld US. In a nutshell, NSX-T is the newest iteration of VMware’s multi-hypervisor NSX platform. It is also the key to multi-cloud, and container infrastructures!

This module is being released as a low-level, API access only, module and will feature the following cmdlets:. Connect-NsxtServer.

Disconnect-NsxtServer. Get-NsxtService An example of connecting to an NSX-T server and listing the nodes included in the cluster: For more information on the NSX-T RESTful API, the API documentation can be viewed on the. New Create Method Available The other major update is around the addition of a ‘Create’ method to the Get-CisService and, newly released, Get-NsxtService cmdlets when used in conjunction with an object’s ‘Help’ property.

This streamlines the creation of certain objects for a template-like experience. Those who have worked with specifications when using the ‘Get-View’ cmdlet will be quite familiar with how this ‘Create’ method will work and be interacted with.

This method works against the following objects:. Parameter. Elements of a parameter (Limited to types: List, Set, Optional).

Key and value of parameters (Limited to types: Map). Fields of a parameter (Limited to types: Structure) Here’s an example on how the new ‘Create’ method can be used to create and apply settings to a specification in order to make a new VM while using the vSphere Automation SDK API. Create ( $ createSpec ) Resolved Issues This release of PowerCLI also contains some usage improvements to a handful of cmdlets. New-TagAssignment: When connected to multiple vCenters and using string based inputs for the ‘Tag’ and ‘Entity’ parameters, the cmdlet has been updated to no longer throw an error of “The specified parameter ‘Tag’ expects a single value, but your name criteria ‘’ corresponds to multiple values.”.

Set-VMHostNetworkAdapter: When configuring an ESXi host’s virtual NIC to use an IPv6 address which is managed through a vCenter Server of version 6.5, the AutomaticIPv6 property has been corrected to no longer flip the switch to ‘True’. Summary We are continuing our commitment to getting the latest and greatest functionalities, performance improvements, and issue resolutions with this latest release of PowerCLI 6.5.3. After only 2 months, we have released a new module to manage NSX-T environments, added a new ‘Create’ method for use with the Get-CisService and Get-NsxtService cmdlets, and fixed a handful of issues with existing cmdlets. Remember, updating your PowerCLI modules is now as easy as: Update-Module VMware.PowerCLI For more information on changes made in VMware PowerCLI 6.5.3, including improvements, security enhancements, and deprecated features, see the. For more information on specific product features, see the. For more information on specific cmdlets, see the. This entry was posted in and tagged on.

Is PowerCLI supported by VMware? Can support requests be opened about PowerCLI through MyVMware? Questions like these keep coming up at VMUG meetings and customer meetings. This shouldn’t be a secret!

The 18 modules that are available for with the current release of PowerCLI 6.5.2 are covered under VMware’s Basic Support and Production Support scope. With that said, there are some areas in need of clarification. The coverage areas are around the installation process and cmdlet failures. If you’re running into errors while installing or initializing PowerCLI, a support request can be opened. If you’re using a cmdlet and you’re hitting some form of error, where the command used to work or should work according to the documentation, a support request can be opened.

VMware’s Global Support Services (GSS) will work to identify the issue with you. There are some areas of PowerCLI where GSS does not have the ability to support. These areas are around any guidance for custom scripts and/or advanced functions. VMware does have the ability to offer vSphere SDK Developer Support Service. If you are in need of this service, I would recommend speaking to your VMware account team.

Now that we have the groundwork laid, let’s discuss a little further how to make a support request regarding a PowerCLI issue. Ask the Community We’re talking support requests in this blog post, but Have you asked the community? PowerCLI has a very active community which can be accessed in many ways. First, there’s fantastic that’s open and available to search through and ask questions. It even just recently hit 12,000 discussions! Then, there’s the channel on PowerCLI is constantly one of the busiest channels in the Slack team and has over 500 members! There’s also Twitter and using the PowerCLI hashtag.

Support Request Creation In order to help streamline the process of creating a support request to VMware, I’ve compiled some helpful suggestions from both customers whom have submitted support requests and the GSS representatives whom may respond to these support requests. First and foremost, when creating a support request, you’ll notice there isn’t a “PowerCLI” support section. The best thing to do here is create a support request for product that’s having issues.

Example: If it’s a VMHost cmdlet failure, create an ESXi support request. Isolate the Issue When creating the support request, only include the specific cmdlet which is not operational. Make sure to also include the output from running the cmdlet, such as the exact error message wording. Also, where possible, attempt to use the ‘Verbose’ parameter to help generate additional informational output. User Resolve-Error If you are receiving an error, try to make use of the following function after receiving the error. The Resolve-Error function’s output helps to provide as much context about the error as possible. For more information about it’s origin and usage, please refer to the following: Include All Version Information Including all of the necessary version information is a very important step.

Part of this would include PowerShell version, PowerCLI module versions, vSphere version, and so forth. PowerShell information can be found using the built-in variable: $PSVersionTable PowerCLI module version information can be found with the following command: Get-Module –Name VMware.

If your PowerCLI session is connected to your vSphere environment, obtaining the vCenter version can be done with the following command: $global:DefaultVIServer select Name,Version,Build If you happen to be running into a vSAN PowerCLI issue, obtaining the vSAN version can be obtained through the new Get-VsanView cmdlet. An example command: (Get-VsanView -Id 'VsanVcClusterHealthSystem-vsan-cluster-health-system').VsanVcClusterQueryVerifyHealthSystemVersions((Get-Cluster).Id) select VcVersion If you happen to be running into a vRealize Operations Manager (vROps) PowerCLI issue, obtaining the vROps version can be a bit tricky. This is because it involves accessing the underlying API. This can be done in two command lines though: $OmServer = $global:DefaultOMServers0.ExtensionData $OmServer.GetCurrentVersionOfServer select ReleaseName Last one, if you happen to be running into a Horizon View PowerCLI issue, obtaining the Horizon View version can also be a little tricky. However, it can be obtained in two command lines: $hvserver = $global:DefaultHVServers0.extensiondata $hvserver.ConnectionServer.ConnectionServerlist.General select Name,Version Additional Information Feel free to include any additional information which may help bring the support request to resolution. One example, screenshots are always helpful.

If the error involves any variables or pipeline input, include the output for those items as well. Summary VMware PowerCLI is supported by VMware and support requests can be opened! VMware supports both the installation process and cmdlet usage. However, to make the support process easier:. Open a support request for the product area where the failure is occuring. Isolate the problem to the usage of a particular cmdlet. When dealing with an error, include the output from the Resolve-Error function.

Include the versions of all related products (PowerShell, PowerCLI, vSphere, etc). Include any variable and/or pipeline input being referenced Also, don’t hesitate to ask the community! There’s a terrific wealth of knowledge who are eager to help! This entry was posted in and tagged on. When PowerCLI was converted to modules, it introduced the ability to pick and choose which modules are loaded.

Taking it a step further, it also allowed users to specify which versions of those modules are loaded. Historically, PowerCLI was released as one large ‘bundle’ of modules, and was not a great release practice. This meant that even though most modules were not touched, we were still required to go through our release processes to get them out the door. This is not scalable when trying to get features to you more frequently. With modules in the Powershell Gallery, we can now release individual modules asynchronously from other modules.

The first release to really take advantage of that is PowerCLI 6.5.2. For those whom have already updated their VMware.PowerCLI module from the Microsoft PowerShell Gallery, you noticed there were only 3 modules which were updated and needed to be downloaded. The Better Way In prior releases, we could use the ‘Get-PowerCLIVersion’ cmdlet and receive a high-level look at the overall PowerCLI version which was installed. Previously, our versioning scheme was not supported in PowerShell, so it took a cmdlet to print the version out (Example: VMware PowerCLI 6.5 R1). That is gone now. We’ve made the change to semantic versioning in 6.5.1.

This means there will be no more R1, R2, or R3 releases! Starting with PowerCLI 6.5.2, the process to get module versions has changed. Running the ‘Get-PowerCLIVersion’ cmdlet now results in a warning message indicating that it is deprecated and to use the ‘Get-Module’ cmdlet instead.

Using Get-Module There are a couple ways to use the ‘Get-Module’ cmdlet to help us determine our versioning. The reason for that is because the ‘Get-Module’ cmdlet only shows the modules which have been imported. The first way is to get the overall PowerCLI version, which is dependent on the ‘VMware.PowerCLI’ module.

We can determine the version by first importing the module (if it’s not already imported) and then running the following command: Get-Module -Name VMware.PowerCLI Select-Object -Property Name,Version From the above example, we can see that we’re using PowerCLI version 6.5.2. Another way is to just reference the modules which have been loaded automatically. I have an example where we connect to our vCenter Server and then run the following command to find the versions of all the PowerCLI modules which are in-use: Get-Module -Name VMware. Select-Object -Property Name,Version From the above example, we see that we’re only using a single PowerCLI module and it happens to be versioned at 6.5.2. Running a couple additional, random, commands, we re-run the above command and see there’s now a bit more of a mix amongst our loaded modules. Summary The new method to obtain what version of PowerCLI you’re using is through the ‘Get-Module’ cmdlet. This update was made for many reasons.

This new method takes advantage of how our the PowerCLI modules can be loaded independently of each other on an as needed basis. It also takes advantage of how the PowerCLI module releases can now be done asynchronously from each other.

Lastly, since we’ve changed the PowerCLI versioning over to align with the standard PowerShell versioning, there’s no need for a custom cmdlet anymore! If you’re using ‘Get-PowerCLIVersion’ in your scripts or modules, make sure you’re aware of this and update your resources to reflect this change! This entry was posted in and tagged, on. Post navigation.