It’s the perfect moment! With just a month until VMware Explore Las Vegas, we have an exciting new PowerCLI 13.3 version to share. This release brings numerous bug fixes, enhancements, and fantastic new capabilities, such as the Privilege Report cmdlet, among others. There will be plenty of topics to discuss at Explore . Let me guide you through the details of this new PowerCLI version.

VCF SDDC Manager enhancements

With 13.3 we are adding two new cmdlets:

• Wait-VcfTask – enables waiting for generic async operations like for examples Tasks
• Wait-VcfValidation – enables waiting for specific VCF validation operations like for example Validate Domains Operations

vSphere enhancements

We add new cmdlet for recording the privilege checks that occur for specified sessions during execution of a specified script block:

• Get-VIPrivilegeReport

VSAN enhancements

In PowerCLI 13.3 we are adding two new cmdlets to support alarm threshold customisations.

• New-AlarmTriggerArgument – creates a new action trigger for the specified alarm action
• Get-AlarmTriggerArgumentAttributeName – list attribute names of the alarm trigger argument for the “vsan.health.ssd.endurance” event type

Also we are updating few existing cmdlets.

• Get-VsanSpaceUsage enhancement – add  support new attribute space efficiency ratio in return type
• Set-VsanClusterConfiguration – new parameter “vsanmaxenabled” is added to enable vSAN Max service
• Get-VsanClusterConfiguration – new parameter “vsanmaxenabled” is added to check whether the vSAN cluster is vSAN Max enabled.

HSX enhancements

In PowerCLI 13.3 we are adding two new cmdlets for GuestOS customisations.

• New-HCXGuestOSNetworkCustomization creates an object for network customisation which is a part of Guest OS customisation
• New-HCXGuestOSCustomization creates an object for Guest OS customisation

Following two cmdlets are updated to receive above new cmdlets as parameters:

• New-HCXMigration for migration level guest os customisations;
• New-HCXMobilityGroupConfiguration for group level guest os customisations.

Image Builder Enhancements

With PowerCLI 13.3, we are adding support for Python version 3.12. Along with this, we are adding support for OpenSSL 3.0.

Notice: We are dropping support for OpenSSL 1.1 due to its End of Life announced in September 2023.

Updated SDK modules

Following modules are updated with PowerCLI 13.3:

• The vSphere modules are updated to vSphere 8.0U3.
• The NSX modules are updated to NSX 4.2.0.0.
• The SRM and vSphere Replication modules are updated to version 9.0.1
• The VCF module are updated to VMware Cloud Foundation 5.2.

For more details, please check detailed Change log and Release notes for PowerCLI 13.3 release version.

Removed SDK modules 

Changes in PowerCLI Offering: Horizon Module Removal in Version 13.3

With the recent separation of VMware’s End User Computing (EUC) division by Broadcom, a key update is being made in the PowerCLI offering. Starting from PowerCLI version 13.3, the VMware.VimAutomation.HorizonView module will no longer be included. This change reflects the broader restructuring of the product lines.For users requiring the Horizon module, PowerCLI version 13.2 will be the latest version that contains VMware.VimAutomation.HorizonView.

Conclusion

With PowerCLI 13.3, you can enjoy the benefits of the newest features of vSphere, vSAN, NSX, and more. And as always, PowerCLI 13.3 comes with the latest bug-fixes and performance enhancements to make your work easier and faster. Don’t wait any longer, update your PowerCLI version today. The New version is available in PowerShell Gallery and Broadcom Developer Portal.

The post Introducing PowerCLI 13.3 appeared first on VMware PowerCLI Blog.

Ever since we introduced Power Actions back in April, one of the most frequently asked questions we get from our customers is whether we plan to integrate with source control systems like Git. While we still don’t have that out-of-the-box in Power Actions, in this blog post, I’ll show you how to easily create a script that you can run with Power Actions to sync your script library with a Git folder.

Let’s get started.

Since Git is not available out-of-the-box in Power Actions, the first thing we need to do in our script is to install Git.

#Intall git
tdnf install -y git

#Clone the repo
git clone -n --depth=1 --filter=tree:0 https://github.com/vmware/PowerCLI-Example-Scripts.git
cd PowerCLI-Example-Scripts
git sparse-checkout set --no-cone PowerActions
git checkout
cd PowerActions

#Get all the files that we have cloned from the repo
$files = Get-ChildItem -Path . -File
foreach ($file in $files) {
    $name = $file.BaseName


    #Check if the item for this file already exists in the content library
    $item = Get-ContentLibraryItem -Name $name -ContentLibrary $contentLibrary -ErrorAction SilentlyContinue
    if ($item) {
        #If the item exists, check if it is up to date
        #Create a folder to store the current content library item
        if (-not (Test-Path -Path ./cl_versions -PathType Container))
        {
            New-Item -Path ./cl_versions -ItemType Directory
        }
        #Download the item from the content library
        $clFile = Export-ContentLibraryItem -ContentLibraryItem $item -Destination ((Get-Location).Path + "/cl_version") -Force
        #Compare if it's the same as the file we have downloaded from the repo
        $compResult = Compare-Object -ReferenceObject (Get-Content $file.FullName) -DifferenceObject (Get-Content ($clFile.FullName+"/"+$file.Name))
        if ($compResult) {
            #If the item is not up to date, update it
            Write-Host "Updating $name"
            Set-ContentLibraryItem -ContentLibraryItem $item -Files $file.FullName
        } else {
            Write-Host "$name is up to date"
        }
    } else {
        #If the item does not exist, create it
        New-ContentLibraryItem -Name $name -Files $file.FullName -ContentLibrary $contentLibrary
    }
}

The post Git integration for Power Actions appeared first on VMware PowerCLI Blog.

Momentum season is still going, VMware Explore in Barcelona is currently underway, and it’s the perfect time for a new PowerCLI release. We’re thrilled to introduce the new PowerCLI 13.2!

This release brings you official support for VMware Cloud Foundation (VCF) in PowerCLI, along with new features for vSphere, vSAN, and VMC. Let’s dive into the details.

New SDK modules for VCF

VMware Cloud Foundation (VCF) is an integrated platform incorporating a full range of software-defined services into a single platform. As more and more VMware customers adopt VCF, the demand for CLI automation is also increasing. Until now, the only option was to use the open-source PowerVCF module, but with PowerCLI 13.2 we’re now adding two official VCF modules – VMware.Sdk.Vcf.CloudBuilder and VMware.Sdk.Vcf.SddcManager. These are SDK modules and use the same technology as the PowerCLI SDK modules for the vSphere Automation, NSX, SRM, and the vSphere Replication APIs. As with all SDK modules, you can find PowerCLI examples directly in the VCF REST API documentation.

New vSphere Lifecycle Management functionality

In PowerCLI 13.2 we’re adding two new cmdlets for vLCM:

• Export-LcmVMHostDesiredState exports the desired state of a vSphere Lifecycle Manager host
• New-OfflineBundle creates a vLCM-compliant offline bundle based on input depots and a software specification.

New vSAN functionality

In PowerCLI 13.2 we have added a new cmdlet in the VMware.VimAutomation.Storage module – Get-VsanPerformanceContributor. It allows you to retrieve a list of the most impactful vSAN performance contributors. We have also extended the output of the Get-VsanSpaceUsage cmdlet to include an EsaObjectOverheadGB property, which provides information for the additional overhead for vSAN ESA objects to store meta-data and to provide high performance.

New VMC functionality

In PowerCLI 13.2 we have extended the New-VmcSddc and New-VmcSddcCluster cmdlets with support for I4I hosts.

Updated SDK modules

With PowerCLI 13.2 we have also updated all the modules that provide API bindings. The following modules have been updated:

• The vSphere modules have been updated to vSphere 8.0U2.
• The NSX modules have been updated to NSX 4.1.2.
• The SRM and vSphere Replication modules have been updated to version 8.8.
• The Horizon module has been updated to VMware Horizon 8 2306.

Conclusion

With PowerCLI 13.2, you can enjoy the benefits of the newest features of vSphere, vSAN, NSX, and more. Plus, you can access the official VCF modules that are now part of PowerCLI. And as always, PowerCLI 13.2 comes with the latest bugfixes and performance enhancements to make your work easier and faster. Don’t wait any longer, update your PowerCLI version today.

The post Introducing PowerCLI 13.2 appeared first on VMware PowerCLI Blog.

In this blog post, we’ll explore the powerful capabilities of PowerCLI in managing disks within a vSAN cluster and vSAN ESA enabled cluster. Disk management is a critical aspect of maintaining an efficient and optimized virtual storage infrastructure. With the help of specific PowerCLI cmdlets for vSAN cluster, we can manage vSAN disk groups, such as New-VsanDiskGroup, New-VsanDisk, Get-VsanDisk, Remove-VsanDisk, Get-VsanDiskGroup, and Remove-VsanDiskGroup. With Get-VsanEsaEligibleDisk, Add-VsanStoragePoolDisk, Remove-VsanStoragePoolDisk, we can streamline our vSAN ESA storage pool disk management tasks and ensure smooth operations within vSAN or vSAN ESA environment. Let’s dive in!

Managing vSAN Disks Groups and vSAN Disks

In vSAN clusters, vSAN architecture consists of two tiers: a cache tier for the purpose of read caching and write buffering, and a capacity tier for persistent storage. This two-tier design offers supreme performance to VMs while ensuring that data is written to devices in the most efficient way. vSAN uses a logical construct called disk groups to manage the relationship between capacity devices and their cache tier.

Managing vSAN Disk Groups

1. Creating a New Disk Group

To create a new disk group with specific solid-state and hard disk devices, we can use the New-VsanDiskGroup cmdlet. For example, let’s create a new disk group with an SSD and two data disks:

New-VsanDiskGroup -VMHost $vmHost -SsdCanonicalName $MySsdCanonicalName -DataDiskCanonicalName $DataDisk1,$DataDisk2

2. Fetching vSAN Disk Groups

To retrieve information about vSAN disk groups, we can use the Get-VsanDiskGroup cmdlet. For instance, to fetch the disk group “DiskGroup02” we can execute the following command. The output will the type of VsanDiskGroup.

Get-VsanDiskGroup -Name "DiskGroup02"

3. Removing vSAN Disk Groups

If we need to remove a vSAN disk group, we can use the Remove-VsanDiskGroup cmdlet. We can reuse the result from the Get-VsanDiskGroup command.

$diskGroup = Get-VsanDiskGroup -DiskCanonicalName $DiskCanonicalName -VMHost $vmHost
Remove-VsanDiskGroup -VsanDiskGroup $diskGroup -Confirm:$false

vSAN disk groups consist of vSAN disks. We can, therefore,  manage vSAN disks within vSAN disk groups.

4. Adding vSAN Disks to an existing Disk Group

To add a vSAN disk to an existing disk group, we can use the New-VsanDisk cmdlet. For example, we can use the New-VsanDisk cmdlet to add a new disk, “DiskCanonicalName” to this disk group:

New-VsanDisk -CanonicalName "mpx.vmhba0:C0:T11:L0" -VsanDiskGroup $vsanDiskGroup

5. Fetching vSAN Disks

To fetch vSAN disks based on their ID or disk group information, we can use the Get-VsanDisk cmdlet. For instance, to retrieve information about all disks in a specified vSAN disk group we can execute the following command:

Get-VsanDisk -VsanDiskGroup $vsanDiskGroup

6. Removing vSAN Disks from a Disk Group

If we need to remove a vSAN disk from a disk group, the Remove-VsanDisk cmdlet comes to our rescue. Let’s remove “mpx.vmhba0:C0:T11:L0” disk by using the following command:

$vsanDisk = Get-VsanDisk -CanonicalName "mpx.vmhba0:C0:T11:L0"
Remove-VsanDisk -VsanDisk $vsanDisk -Confirm:$false

Introducing Storage Pool Disks in vSAN ESA

In the vSAN 8.0, we introduced a new storage architecture. In vSAN ESA (Express Storage Architecture), we introduced a new storage format called storage pool disks. These disks provide a more efficient and simplified approach to adding, removing, and managing storage within the ESA environment.

We can claim disks to define a storage pool on a vSAN host. Each host that contributes storage contains a single storage pool of flash devices. Each flash device provides caching and capacity to the cluster. We can create a storage pool with any devices that are compatible for ESA. vSAN creates only one storage pool per host.

In a storage pool, each device provides both caching and capacity in a single tier. This is different from a Disk Group, which has dedicated devices in different tiers of cache and capacity.

Before we add storage pool disks, we can see which one is available to add by using the Get-VsanEsaEligibleDisk cmdlet. The output will be the ScsiLun type.

Get-VsanEsaEligibleDisk -Cluster $cluster

When we know the disk canonical name from ScsiLun, we can claim disks to define the storage pool on a specified host.

Add-VsanStoragePoolDisk -VMHost (Get-VMHost "MyVMHost") -VsanStoragePoolDiskType "singleTier" -DiskCanonicalName ("mpx.vmhba0:C0:T11:L0","mpx.vmhba0:C0:T12:L0")

Also, we can query the storage pool disk with the specified VMHost or Cluster, and remove the disk from the defined storage pool disk.

$disks =get-vsanstoragepooldisk -VMHost (Get-VMHost 10.192.201.50)

Remove-VsanStoragePoolDisk -VsanStoragePoolDisk $disks -VsanDataMigrationMode nodatamigration -Purpose "test" -Confirm:$false

By harnessing the power of PowerCLI and leveraging its rich features, you can simplify and optimize your storage infrastructure, ensuring smooth operations within your vSAN cluster.

Happy disk management with PowerCLI in your vSAN environment!

The post PowerCLI and vSAN: A Comprehensive Guide to vSAN Disk Management appeared first on VMware PowerCLI Blog.

In the ever-evolving world of PowerCLI, each release brings exciting updates and enhancements to vSAN. With new cmdlets and vSAN APIs, managing your virtual storage infrastructure becomes even more efficient and powerful. One of the recent additions to PowerCLI is the support for remote datastore related features, opening up new possibilities for vSAN clusters.

Now, vSAN clusters have the ability to share their datastores with other vSAN clusters, or even beyond a single vCenter Server. The beauty of this functionality lies in the flexibility it offers. Any compatible vSAN cluster can act as a server, allowing other vSAN clusters to mount its local datastores. This opens up a world of potential use cases and enables efficient data sharing across clusters.

But how do you go about mounting a remote datastore using PowerCLI? Fear not, as I’ll guide you through the process using PowerCLI cmdlets in various scenarios.

Managing vSAN Remote Datastores

Starting from PowerCL 12.7, we have introduced support for querying, mounting, and unmounting remote datastores for a specific cluster using the Get-VsanClusterConfiguration and Set-VsanClusterConfiguration cmdlets. Let’s delve into the details and discover how these cmdlets can empower you in managing remote datastores.

Query the mounted remote datastores

By utilizing the Get-VsanClusterConfiguration cmdlet, we gain access to view all the properties of the vSAN configuration within the specific cluster. This includes crucial information about the mounted remote datastores.

In addition to accessing the overall vSAN configuration, we can specifically retrieve the value of the RemoteDatastore property by using a simple dot notation. This allows us to obtain accurate details about the remote datastores and their current status.

Get-VsanClusterConfiguration -Cluster "MyCluster" | select *
$vsanConfiguration = Get-VsanClusterConfiguration -Cluster "MyCluster"
$vsanConfiguration.RemoteDatastore

Mount / Unmount the remote datastore

As we intend to modify the vSAN configuration setting, we will utilize the Set-VsanClusterConfiguration cmdlet. To do so, it is necessary to retrieve the original vSAN cluster configuration beforehand with the Get-VsanClusterConfiguration cmdlet.

$config = Get-VsanClusterConfiguration -Cluster "MyCluster"
Set-VsanClusterConfiguration -Configuration $config -MountRemoteDatastore (Get-Datastore -Name "MyDatastore")

#If we want to unmount the existing remote datastore, we can go fetch the current vSAN configuration again
$newVsanConfiguration = Get-VsanClusterConfiguration -Cluster "MyCluster"
Set-VsanClusterConfiguration -Configuration $newVsanConfiguration -UnMountRemoteDatastore $newVsanConfiguration.RemoteDatastore

Mount / Unmount the remote datastore from the stretched cluster

In the latest PowerCLI 13.1 release, which supports vSAN 8.0 Update 1, we’re thrilled to introduce the ability to mount remote datastores from both stretched clusters and vSAN ESA (Express Storage Architecture) enabled clusters. If you want to mount or unmount the remote datastore from a vSAN ESA enabled cluster, the operation would be the same as the first scenario, the normal vSAN cluster, and no additional settings are required. Let’s take a look at the configuration steps involved when mounting from stretched clusters

Mounting the Remote Datastore from Stretched Clusters

When dealing with stretched clusters, an additional configuration step is necessary to ensure seamless remote datastore mounting. Specifically, you’ll need to configure the RemoteVsanServerClusterConfig as outlined below.

Understanding the NetworkTopology Parameter

The NetworkTopology parameter plays a crucial role in defining the network topology between the client and server clusters in an HCI Mesh configuration. It offers two values: Asymmetric and Symmetric. In a Symmetric configuration, no ServerSiteName or ClientSiteName is required. However, in an Asymmetric configuration, the ServerSiteName becomes necessary and represents the fault domain of the stretched cluster, which is referred to as “Preferred” or “Secondary”. Additionally, if both the host cluster and server cluster are stretched clusters, the ClientSiteName is also required.

Below are some sample configurations for different RemoteVsanServerClusterConfig scenarios.

$serverconfig = New-RemoteVsanServerClusterConfig -cluster $clusterServer -networktopology "Symmetric" 
$serverconfig = New-RemoteVsanServerClusterConfig -cluster $clusterServer -networktopology "Asymmetric" -ServerSiteName "Secondary"
$serverconfig = New-RemoteVsanServerClusterConfig -cluster $clusterServer -networktopology "Asymmetric" -ServerSiteName "Secondary" -ClientSiteName "Preferred"

Set-VsanClusterConfiguration -configuration $clusterClient -MountRemoteDatastore $datastore -RemoteVsanServerClusterConfig $serverconfig

When unmounting a remote datastore from the stretched cluster, it is enough to pass the UnmountRemoteDatastore parameter. The RemoteVsanServerClusterConfig will be automatically adjusted and cleared accordingly.

Set-VsanClusterConfiguration -configuration $config -UnmountRemoteDatastore $datastore

Mount / Unmount the remote datastore from another vCenter Server system

In PowerCLI13.1, we also have the capability to mount and unmount remote datastores from another vCenter Server System, allowing for cross-vCenter remote datastore operations.

Adding Datastore Source to the current vCenter Server system

Before we can proceed with mounting the Cross-vCenter (XVC) remote datastore, we need to add the datastore source to the current vCenter Server system by using the appropriate credentials. This step ensures that the target vCenter Server can be accessed as another datastore source. To achieve this, we can utilize the New-VsanHCIMeshDatastoreSource cmdlet, where the VCHost parameter specifies the target vCenter that we want to add as a datastore source.

New-VsanHCIMeshDatastoreSource -VCHost 'MyAnotherVCIP' -User 'administrator@vsphere.local'  -Password 'MyVCPassword'

Retrieving HCI Mesh Datastore

Once we’ve successfully added the datastore source, we can retrieve the datastore and fetch the HCI mesh datastore from the specified source. This retrieval process allows us to access the necessary data and information required for further operations.

$dsSource = Get-VsanHCIMeshDatastoreSource -VCHost 'MyVCIP'
$ds = Get-VsanHCIMeshDatastore -VsanHCIMeshDatastoresource $dsSource

Mounting and Unmounting Remote Datastores

With the retrieved HCI mesh datastore at our disposal, we can now proceed to mount or unmount the remote datastore by using the MountXVCDatastore or UnmountXVCDatastore parameters. With these parameters, you can execute the desired operations efficiently.

Set-VsanClusterConfiguration -Configuration $clusterClient -MountXVCDatastore $ds

Set-VsanClusterConfiguration -Configuration $clusterClient -UnmountXVCDatastore $ds

Query the mounted datastore from another vCenter Server System

The mounted datastore from another vCenter Server system can be fetched with the VsanXVCDatastore parameter.

$vsanConfiguration = Get-VsanClusterConfiguration -Cluster "MyCluster"

$vsanConfiguration.VsanXVCDatastore

#output
DatastoreMoID            OwnerVcAddress
----------------------   --------------
Datastore-datastore-17   MyVCIP

Summary

In this blog post, we’ve touched upon the latest advancements in PowerCLI and vSAN, focusing on the ability to mount remote datastores. As we move forward, we’ll delve deeper into each scenario and provide step-by-step guides on configuring remote datastores for stretched clusters, understanding network topology, implementing the RemoteVsanServerClusterConfig cmdlet, and exploring the cross-vCenter remote datastores.

Join us on this thrilling journey as we unlock the full potential of PowerCLI and vSAN, empowering you to optimize your virtual storage infrastructure and harness the benefits of remote datastore mounting. Exciting times lie ahead for vSAN enthusiasts and PowerCLI users alike!

Make sure to stay tuned for our upcoming blog posts as we’ll unveil more insights, tips, and tricks to enhance your vSAN management experience. Until then, happy exploring!

The post PowerCLI and vSAN: Exploring Remote Datastore Mounting appeared first on VMware PowerCLI Blog.

This blog post explains how to configure Array Based Replication (ABR) with the PowerCLI VMware.Sdk.Srm module. Before diving in, consider reading the blog post, explaining the basic concepts of the VMware.Sdk.Srm module: “Managing SRM and VR with PowerCLI 13.1“. There you can find out more about the module’s connection management, which will not be covered in details here.

Connect Site Recovery Manager with Connect-SrmSdkServer

To connect Site Recover Manager server use the Connect-SrmSdkServer cmdlet:

$srmConnection = Connect-SrmSdkServer -Server "MySrmAddress.com" `
   -User "administrator@vsphere.local" `
   -Password "MyLocalVcPassword" `
   -RemoteUser "administrator@vsphere.local" `
   -RemotePassword "MyRemoteVcPassword"

Create Array Managers for the Array Pair

Before creating the array pair you must create array managers for the local and the remote sites.

Retrieve Storage Replication Adapter for the local Array Manager

For this example we will use NetApp Storage Replication Adapter for ONTAP:

$localAdapter = (Invoke-SrmGetStorageAdapters -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id `
   -FilterProperty 'Name' `
   -Filter 'NetApp').List[0]

Invoke-SrmGetStorageAdapters returns a list of adapters, matching the specified filters. In our case we filter the available storage adapters by their Name property and expect only one adapter with name matching ‘NetApp’ to be found. Accordingly we will use the first element of the List property of the StorageAdapterDetailsDrResponseList object, returned from Invoke-SrmGetStorageAdapters.

Prepare Connection Parameters for the Storage Replication Adapter

To allow the array manager to communicate with the storage adapter we must prepare connection parameters, which will be used for the connection. Retrieve ConnectionParamGroup object for the local storage adapter:

$localConnectionParamGroup = (Invoke-SrmGetStorageAdapterConnectionParams `
   -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id `
   -StorageAdapterId $localAdapter.Id).List[0]

The output of Invoke-SrmGetStorageAdapterConnectionParams is a ConnectionParamGroupDrResponseList object, which in our case contains a list of one ConnectionParamGroup element. You have to provide values to the connection parameter, available in the $localConnectionParamGroup.ConnectionParams list. The set of parameters, available in the ConnectionParams list is specific for the used storage replication adapter. Here we will provide values for connection parameters, specific for the NetApp storage replication adapter:

($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "username"}).Value = "myUser"
($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "password"}).Value = "myPass"
($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "VolumeInclusion"}).Value = "myVolume"
($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "SVM Name"}).Value = "myLocalSvmName"
($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "mgmtIP"}).Value = "192.168.10.10"

Create the local Array Manager

Now when we have all the prerequisites for the array manager, use the ConnectionParamGroup and the storage adapter Id to initialize ArrayManagerSpec object:

$localArrayManagerSpec = Initialize-SrmArrayManagerSpec -Name "primary-array-manager" `
   -StorageAdapter $localAdapters.Id `
   -ConnectionParams $localConnectionParamGroup

Then create the array manger, using the Invoke-SrmCreateArrayManage cmdlet:

$task = Invoke-SrmCreateArrayManager -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id `
   -ArrayManagerSpec $localArrayManagerSpec

Wait for the task to complete and retrieve the array manager. The Result property of the task will contain the Id of the array manager, once the task completes:

$localManagerTask = Invoke-SrmGetTaskInfo -TaskId $task.Id

$localArrayManager = Invoke-SrmGetArrayManager -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id `
   -ArrayManagerId $localManagerTask.Result

Create the remote array manager, using the same approach:

$remoteAdapter = (Invoke-SrmGetStorageAdapters -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.RemoteSrmServer.Id `
   -FilterProperty 'Name' `
   -Filter 'NetApp').List[0]

$remoteConnectionParamGroup = (Invoke-SrmGetStorageAdapterConnectionParams `
   -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.RemoteSrmServer.Id `
   -StorageAdapterId $remoteAdapters.List[0].Id).List[0]

($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "username"}).Value = "myUser"
($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "password"}).Value = "myPass"
($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "VolumeInclusion"}).Value = "myVolume"
($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "SVM Name"}).Value = "myRemoteSvmName"
($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "mgmtIP"}).Value = "192.168.10.11"

$remoteArrayManagerSpec = Initialize-SrmArrayManagerSpec -Name "secondary-array-manager" `
   -StorageAdapter $remoteAdapter.Id `
   -ConnectionParams $remoteConnectionParamGroup

$task = Invoke-SrmCreateArrayManager -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.RemoteSrmServer.Id `
   -ArrayManagerSpec $remoteArrayManagerSpec

#Wait for the create array manager task to complete
$remoteManagerTask = Invoke-SrmGetTaskInfo -TaskId $task.Id

$remoteArrayManager = Invoke-SrmGetArrayManager -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.RemoteSrmServer.Id `
   -ArrayManagerId $remoteManagerTask.Result

Create Replicated Array Pair

To create the replicated array pair, you have to initialize a ReplicatedArrayPairSpec object:

$replicatedArrayPairSpec = Initialize-SrmReplicatedArrayPairSpec -ArrayManagerId $localArrayManager.Id `
   -StorageArrayKey $localArrayManager.StorageArrays[0].StorageArrayKey `
   -PeerStorageArrayKey $remoteArrayManager.StorageArrays[0].StorageArrayKey

Besides the ArrayManagerId you have to specify the StorageArrayKey and the PeerStorageArrayKey parameter. The available storage array keys can be found in the StorageArrays property of the local and the remote array managers.

Use the Invoke-SrmCreateReplicatedArrayPair cmdlet to create the replicated array pair:

$task = Invoke-SrmCreateReplicatedArrayPair -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id `
   -ReplicatedArrayPairSpec $replicatedArrayPairSpec

Wait for the task to complete and retrieve the replicated array pair. The Result property of the task will contain the Id of the replicated array pair, once the task completes:

$replicatedArrayPairTask = Invoke-SrmGetTaskInfo -TaskId $task.Id

$replicatedArrayPair = Invoke-SrmGetReplicatedArrayPair -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id `
   -ArrayPairId $replicatedArrayPairTask.Result

Create Protected Group and Recovery Plan for the Replicated Array Pair

Use the Invoke-SrmDiscoverStorageDevices cmdlet to discover the storage devices of the replicated array pair. Wait for the task to complete before proceeding to the next step:

$task = Invoke-SrmDiscoverStorageDevices -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id `
   -ArrayPairId $replicatedArrayPair.Id

Invoke-SrmGetTaskInfo -TaskId $task.Id

Retrieve the storage devices from the replicated array pair:

$storageDevices = Invoke-SrmGetStorageDevices -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id `
   -ArrayPairId $replicatedArrayPair.Id

Initialize an AbrProtectionGroupSpec object. In our setup we created replicated array pair with single storage device, containing one datastore. We will create protection group for this datastore:

$abrProtectionGroupSpec = Initialize-SrmAbrProtectionGroupSpec `
   -ReplicatedArrayPair $replicatedArrayPair.Id `
   -Datastores $storageDevices.StorageDevicesData[0].Datastores[0].Id

Then initialize ProtectionGroupCreateSpec object. For the ReplicationType parameter specify ABR:

$protectionGroupSpec = Initialize-SrmProtectionGroupCreateSpec -Name "MyAbrProtectionGroup" `
   -ReplicationType ABR `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id `
   -AbrSpec $abrProtectionGroupSpec

Use Invoke-SrmCreateGroup to create the ABR protection group. Wait for the task to complete and retrieve the protection group:

$task = Invoke-SrmCreateGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -ProtectionGroupCreateSpec $protectionGroupSpec

$task = Invoke-SrmGetTaskInfo -TaskId $task.Id

$protectionGroup = Invoke-SrmGetGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -GroupId $task.Result

Finally, you can create recovery plan for the protection group, we have just crated. To do this, Initialize RecoveryPlanCreateSpec object:

$recPlanSpec = Initialize-SrmRecoveryPlanCreateSpec `
   -Name "AbrRecoveryPlan" `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id `
   -ProtectionGroups @($protectionGroup.Id)

Create recovery plan with the Invoke-SrmCreatePlan cmdlet and wait for the task to complete:

$task = Invoke-SrmCreatePlan -PairingId $srmConnection.ConnectedPairing.PairingId `  
   -RecoveryPlanCreateSpec $recPlanSpec

Invoke-SrmGetTaskInfo -TaskId $task.Id

Disconnect the SRM server connection

After you have finished interacting with the SRM server, close the connection, using the Disconnect-SrmSdkServer cmdlet.

Disconnect-SrmSdkServer "MySrmAddress.com"

Conclusion

VMware.Sdk.Srm PowerCLI module enables the access to the Site Recovery Manager Rest API through PowerShell cmdlets. In this article we covered the end to end scenario of configuring array based replication and creation of protection group and recovery plan, based on this replication flavor. If you’re interested in using host based replication, refer to the “Managing SRM and VR with PowerCLI 13.1” blog post.

The post Array Based Replication with PowerCLI 13.1 appeared first on VMware PowerCLI Blog.

PowerCLI 13.1 introduces two new auto generated modules that provide PowerShelI bindings for the vSphere Replication REST API and the Site Recovery Manager REST API. We will cover connection management for both modules – host based replication with vSphere Replication and creation of protection groups and recovery plans with Site Recovery Manager.

Note: VMware.Sdk.Vr and VMware.Sdk.Srm modules are compatible with vSphere Replication and Site Recovery Manager 8.7 and above.

Connecting vSphere Replication server with Connect-VrServer

To connect to a vSphere Replication management server you must use the Connect-VrServer cmdlet. Replications can be configured within a single vCenter Server, or between local and remote vCenter Server instances.

When configuring replication within the same VC you can connect only to the local vSphere Replication site. For Server parameter specify the vSphere Replication server address. For User and Password parameters specify the user name and the password for the vCenter Server instance where the vSphere Replication appliance is deployed:

$vrConnection = Connect-VrServer -Server "MyVrAddress.com" 
   -User "administrator@vsphere.local" `
   -Password "MyLocalVCenterServerPassword"

Let’s take a moment and look at the VrServerConnection object, returned from the Connect-VrServer cmdlet. It contains ConnectedPairings property:

This property is a Dictionary, where all connected Pairings are stored. The Pairing is the VR API representation of the paired local and the remote sites. As we just authenticated only against the local VR site, the Dictionary contains only one entry. This is the local vCenter self-pair.

You can index this dictionary, by the vCenter name, and obtain certain Pairing object. You will need this Pairing object to invoke various operations from the VR API:

To authenticate against a remote vCenter Server, you will use another parameter set of the Connect-VrServer cmdlet. (Note that you must have a site pairing configured between the local and the remote vSphere Replication sites.). This time, for LocalServer parameter specify the already available VrServerConnection object. For RemoteServer parameter specify the name of the remote VC. For RemoteUser and RemotePassword parameters specify the user name and the password of the remote VC. Note that with VR we can have multiple remote sites configured:

$remoteVc = "myRemoteVcName"
$vrConnection = Connect-VrServer -LocalServer $vrConnection `
    -RemoteServer $remoteVc `
    -RemoteUser "administrator@vsphere.local" `
    -RemotePassword "MyRemoteVCenterServerPassword"

Now, if you check the ConnectedPairings property of the VrServerConnection object, you will see that the dictionary contains second pairing, allowing you to invoke API operations on the remote site:

Alternatively you can authenticate against the local and the remote sites with a single Connect-VrServer call:

$remoteVc = "myRemoteVcName"
$vrConnection = Connect-VrServer -Server $localVr `
   -User "administrator@vsphere.local" `
   -Password "MyLocalVCenterServerPassword" `
   -RemoteServer $remoteVc `
   -RemoteUser "administrator@vsphere.local" `
   -RemotePassword "MyRemoteVCenterServerPassword"

Configuring host based replication

For convenience, let’s store the remote site pairing that we will use for the replication in a variable:

$remotePairing = $vrConnection.ConnectedPairings[$remoteVc].Pairing

Retrieve the replicated VM

To start, you must retrieve the VM, which you want to replicate. Use the Invoke-VrGetLocalVms cmdlet, which requires PairingId and VcenterId parameters to be specified. We have these IDs with the Pairing object we stored in the $remotePairing variable:

$replicatedVm = Invoke-VrGetLocalVms -PairingId $remotePairing.PairingId `
   -VcenterId $remotePairing.LocalVcServer.Id `
   -FilterProperty 'Name' `
   -Filter "VrSrmDemo"

You can also apply filter to this call. FilterProperty parameter specifies the VM property that will be used for the search. In this case this is the Name property. The Filter parameter specifies the property value, you are looking for. The result of this call is a VirtualMachineDrResponseList object, which contains list of VMs that match the specified filter. In our case this will be a list with one VM:

Configure VM’s HDDs for the replication

When configuring host based replication, you have to specify the VM’s hard disks that will be replicated. For each replicated disk you have to specify a datastore on the target VC. In this example we will replicate all the hard disks of our VM on one target datastore on the remote VC:
Retrieve the target datastore on the remote VC, using the Invoke-VrGetVrCapableTargetDatastores cmdlet:

$targetDatastore = Invoke-VrGetVrCapableTargetDatastores -PairingId $remotePairing.PairingId `
   -VcenterId $remotePairing.RemoteVcServer.Id `
   -FilterProperty "Name" `
   -Filter "MyRemoteDS"

Here for VcenterId, specify the remote VC Id. Specify FilterProperty and Filter parameters to choose the target datastore by name.

Hard disks are available in the Disks property of our VirtualMachine object, stored in the $replicatedVm variable. Iterate over the Disks list and initialize ConfigureReplicationVmDisk objects for each hard disk. Store these configurations in $replicationVmDisks array variable:

$replicationVmDisks = @()
$replicatedVm.List[0].Disks | ForEach-Object {
   $replicationVmDisks += Initialize-VrConfigureReplicationVmDisk -VmDisk $_ `
      -EnabledForReplication:$true `
      -DestinationDatastoreId $targetDatastore.List[0].Id `
      -DestinationDiskFormat 'SAMEASSOURCE'
}

Configure Host Based Replication

First you have to initialize ConfigureReplicationSpec object. Besides various replication settings, we have to specify the disk replication configuration, stored in the $replicationVmDisks variable to the Disk parameter. You also have to specify the target VC Id and the Id of the replicated VM.

$replicationSpec = Initialize-VrConfigureReplicationSpec `
   -Rpo 60 `
   -NetworkCompressionEnabled:$true `
   -MpitEnabled:$true `
   -AutoReplicateNewDisks:$true `
   -LwdEncryptionEnabled:$false `
   -MpitInstances 1 `
   -MpitDays 1 `
   -Disks $replicationVmDisks `
   -TargetVcId $remotePairing.RemoteVcServer.Id `
   -VmId $replicatedVm.List[0].Id

Then use the Invoke-VrConfigureReplication cmdlet to configure the replication. For parameters, specify the PairingId and the ConfigureReplicationSpec object:

$task = Invoke-VrConfigureReplication -PairingId $remotePairing.PairingId `
   -ConfigureReplicationSpec $replicationSpec

The result of the operation is a TaskDrResponseList object, which in our example contains list of one task. If you want, you can specify array of ConfigureReplicationSpec objects, and replicate multiple VMs with single call.

To wait until the replication configuration task completes, retrieve the task until its Status property equals to something different from ‘RUNNING’:

Invoke-VrGetTaskInfo -TaskId $task.List[0].Id

In the next chapter we will use cmdlets from the VMware.Sdk.Srm module to create protection group and recovery plan for the replication that we just created.

Connecting Site Recovery Manager with Connect-SrmSdkServer

To connect Site Recover Manager server use the Connect-SrmSdkServer cmdlet. Do not use the old Connect-SrmServer cmdlet, already available in the VMware.VimAutomation.Srm module, as it’s not compatible with the VMware.Sdk.Srm module cmdlets.

Site Recover Manager supports only one pairing between local and remote SRM sites. You can connect either only to the local site, or you can authenticate with the remote site vCenter server site in the same call. Since we will further create protection group and recovery plan we will choose the second option. Note that you must have a site pairing configured between the local and the remote SRM sites.

$srmConnection = Connect-SrmSdkServer -Server "MySrmAddress.com" `
   -User "administrator@vsphere.local" `
   -Password "MyLocalVcPassword" `
   -RemoteUser "administrator@vsphere.local" `
   -RemotePassword "MyRemoteVcPassword"

If we look at the SrmServerConnection object, returned from the Connect-SrmSdkServer cmdlet, we will see that it contains property named ConnectedPairing. In this case this is a single Pairing object that represents the pair between the local and the remote SRM sites. You will need this Pairing object for invoking various operations from the SRM API:

Creating protection group and recovery plan for host based replication

In this chapter we will use the host based replication that we configured earlier. First we will initialize HbrProtectionGroupSpec with the VM that we already replicated:

$hbrSpec = Initialize-SrmHbrProtectionGroupSpec -Vms $replicatedVm.List[0].Id

In this example we reuse the VM Id, we have stored in the $replicatedVm variable, as it’s consistent between the VR and SRM APIs. If you need to retrive the replicated VM with the VMware.Sdk.Srm module, use the Invoke-SrmGetReplicatedVms cmdlet:

$replicatedVm = Invoke-SrmGetReplicatedVms `
   -PairingId $srmConnection.ConnectedPairing.PairingId `
   -VcenterId $srmConnection.ConnectedPairing.LocalVcServer.Id `
   -FilterProperty "Name" `
   -Filter "VrSrmDemo"

Use the HbrProtectionGroupSpec object to initialize SrmProtectionGroupCreateSpec. For the ReplicationType parameter specify HBR:

$protectionGroupSpec = Initialize-SrmProtectionGroupCreateSpec -Name "SrmDemoGroup" `
   -ReplicationType HBR `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id `
   -HbrSpec $hbrSpec

Create protection group with the Invoke-SrmCreateGroup cmdlet:

$task = Invoke-SrmCreateGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -ProtectionGroupCreateSpec $protectionGroupSpec

Wait for the SRM task to complete:

$task = Invoke-SrmGetTaskInfo -TaskId $task.Id

When $task.Status is equal to ‘SUCCESS’, retrieve the protection group, using the $task.Result property, which contains the ID of the created group:

$protectionGroup = Invoke-SrmGetGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -GroupId $task.Result

To conclude this example we will create a recovery plan for the protection group. For that purpose first Initialize RecoveryPlanCreateSpec, required by the Invoke-SrmCreatePlan cmdlet:

$recPlanSpec = Initialize-SrmRecoveryPlanCreateSpec `
   -Name "SrmDemoRecoveryPlan" `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id `
   -ProtectionGroups $protectionGroup.Id

Then create the recovery plan with the RecoveryPlanCreateSpec object and wait for the task to complere, using the Invoke-SrmCreatePlan:

$task = Invoke-SrmCreatePlan -PairingId $srmConnection.ConnectedPairing.PairingId `
  -RecoveryPlanCreateSpec $recPlanSpec
Invoke-SrmGetTaskInfo -TaskId $task.Id

Disconnect SRM and VR server connections

After you have finished interacting with the SRM server, close the connection, using the Disconnect-SrmSdkServer cmdlet:

Disconnect-SrmSdkServer "MySrmAddress.com"

To close the VR server connection use the Disconnect-VrServer cmdlet:

Disconnect-VrServer "MyVrAddress.com"

Conclusion

You can combine the VMware.Sdk.Vr and the VMware.Sdk.Srm PowerCLI modules to automate the end to end scenario of creating host based replication, and utilizing it with protection group and recovery plan. If you want to automate array based replication, available with the VMware.Sdk.Srm module, refer to the “Array Based Replication with PowerCLI 13.1” blog post. Also, you can check out “vSphere Replication REST API with PowerShell: Configure VM replication“.

The post Managing SRM and VR with PowerCLI 13.1 appeared first on VMware PowerCLI Blog.

After the exciting first release of Power Actions last week, this week brings another new release – PowerCLI 13.1.

With this release, we’re delivering one of the most requested PowerCLI features – a PowerCLI module for vSphere Replication. It is built on the same technology that we used to deliver the auto-generated modules for the NSX and vSphere REST APIs and provides full coverage of the new vSphere Replication REST API.

Here are some of the other exciting features of this PowerCLI release:

• New auto-generated module for the new SRM REST API
• Added support for vLCM host configuration and offline depots
• New vSAN cmdlets for vSAN direct disk and remote datastore management
• New cmdlets for vSAN cluster shutdown
• Updated NSX and Horizon modules
• Extended Python version support for the ImageBuilder module

Let’s take a closer look at some of these new features.

New SDK modules for SRM and vSphere Replication

With the 8.6 release of SRM and vSphere Replication, these two products received new REST APIs. In fact, it was the first public API released for vSphere Replication. This gave us the opportunity to automatically generate PowerCLI modules for these products as we had already done for NSX and vSphere. As with vSphere you will be able to find the PowerCLI examples directly in the vSphere Replication and SRM REST API documentation. We’re also working on a dedicated blog post to demonstrate how to use those modules to perform some common use cases.

vLCM improvements

In PowerCLI 13.1 we’re adding new parameters to the Set-VMHost cmdlet to allow you to set the ESXi host LCM configuraiton in the same way that you set the cluster LCM configuration. This is a new feature, supported only in vSphere 8.0 Update 1. We’re also introducing cmdlets for the creation of new LCM offline depots with PowerCLI.

New vSAN cmdlets

PowerCLI 13.1 comes with a lot of new vSAN functionality. New cmdlets are introduced for vSAN remote datastore management, direct disk management, and vSAN cluster shutdown.

VMware Cloud Director changes

For VMware Cloud Director, we changed the authentication mechanism of Connect-CIServer and it now authenticates against the new vCD API authentication endpoint. This will allow the cmdlet to continue working without issues with the future vCD versions. We also updated the Import-CIVappTemplate cmdlet to work with the latest APIs. Because of this we made some cmdlet interface changes, which might lead to the need of reworking some of your Cloud Director scripts.

ImageBuilder module Python version support

With PowerCLI 13.0 we ported the ImageBuilder and AutoDeploy modules to work on Linux and MacOS. That required users to have Python installed as a pre-requisite for those modules. In 13.0, these modules only supported Python version 3.7.x, which was quite limiting. With PowerCLI 13.1, we have fixed that and the ImageBuilder module now works with Python 3.7.1 and all later versions.

Conclusion

PowerCLI 13.1 is another release that brings a rich set of new features to our customers. It delivers one of the most requested PowerCLI functionalities, vSphere replication module, as well as new SRM module, new vSAN cmdlets, extended support for vLCM, and much more. For a full list of all improvements and fixes, check the PowerCLI 13.1 Release Notes. For more information on specific cmdlets, see the PowerCLI Cmdlet Reference.

The post PowerCLI 13.1 is now released appeared first on VMware PowerCLI Blog.

We are extremely excited to announce that the first standalone tech preview release of the new Power Actions went live today.

Power Actions is a vSphere Client plug-in that provides an easy way to share PowerCLI scripts with users who have no PowerShell experience. Power Actions provides a script library where you can upload PowerCLI scripts that you want to make available to everyone in your organization. Users can then easily execute those scripts using a user-friendly interface to specify the script parameters. This provides an extremely powerful mechanism to extend the vSphere Client with custom PowerCLI scripts.

How about the security and permissions? All the scripts are executed by using the permissions of the user that’s logged in to the vSphere Client. So, if a user does not have permission to perform certain operations they won’t be able to perform these operations with Power Actions as well.

Let’s take a closer look at how to get started with Power Actions:

Installation

Power Actions is distributed as a virtual appliance. You can download the OVA file from the Power Actions page. Also from there, you can download the complete user’s guide that contains detailed installation instructions. After you install Power Actions you can use it through the Developer Center in the vSphere Client.

Script library

The main function of Power Actions is to run scripts from your script library. So the first thing to do is to create a script library and upload your scripts there.

Script libraries are actually content libraries, so any content library can be used as a script library. If you don’t have a content library at your disposal, you can create a new one by using either PowerCLI or the vSphere Client. The next step is to import your scripts to the script library. You can upload scripts one by one through the vSphere Client, or entire collections of scripts through PowerCLI.

Running scripts

Once you have uploaded your scripts to the script library, you can start running them. You have two options to run a script – from the script library directly or through the context menu. In both cases, when you execute a script with parameters, you’ll be prompted to enter them. However, when you run a script from the context menu, some parameters will be pre-populated.

Let’s take a closer look at how this works. In our Power Actions script library we have imported a simple PowerCLI script that creates snapshots of a collection of virtual machines. This is what the script looks like:

param (
    [Parameter(Mandatory=$true)]
    [VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine[]] $vms, 
    [Parameter(Mandatory=$true)]
    [string] $snapshotName)

foreach ($vm in $vms) {
    New-SnapShot -VM $vm -Name $snapshotName
}

When we run this script from the script library, we’ll get a dialog in which we’ll have to specify the script parameters.

However, if we want to run the script from the context menu, we can right-click on a VM and select “Power Actions” -> “Run script”.

We’ll get a dialog to first select the script that we want to run, and then we’ll have to enter the parameters. In this case, the vms parameter will be pre-populated from the VM we right-clicked on.

Monitoring script runs and checking the results

The next screen in Power Actions is ‘Script runs’. There you can monitor your script runs and check their result. From this page you can also stop a running script.

Console

Another feature Power Actions provides is a built-in PowerShell console with the latest PowerCLI version pre-installed. When you open the console, it automatically connects to the vCenter Server by using the vSphere Client user. You can use the Power Actions console to run single commands or entire scripts. Keep in mind that the console will not be retained when you log out of the vSphere Client, so any files that you save on it will be lost after you log out. Beware that if you switch to another view in the vSphere Client or to another Power Actions screeen, and then return to the console, a new PowerShell session will be created and all in-memory variables from your previous session will be lost.

Summary

Throughout the years, Power Actions underwent multiple transformations and was part of different fling releases of the vSphere Client. Now we’re starting to develop it again as an independent product and this first tech preview release of the new Power Actions is the first step of the process. We are very excited about the plethora of possibilities that Power Actions brings and we can’t wait to receive your feedback, use cases, feature requests and ideas. So don’t hesitate to submit your comments on the Power Actions site.

The post New Release – Power Actions 1.0 appeared first on VMware PowerCLI Blog.

Many customers use the PowerCLI credential store to avoid hard coding credentials in scripts or saving them unencrypted in files. The credential store uses the Windows data protection API to encrypt the credentials and then saves them in a file. However, this API is only available in Windows and that’s why the PowerCLI credential store is not available on the cross-platform PowerShell 7. So what is the alternative for Linux and MacOS users?

Some time ago, Microsoft released two very useful cross-platform modules for managing secrets – SecretManagement and SecretStore. You can read more details about them in this blog post. SecretManagement provides cmdlets that help users manage secrets across different vaults and SecretStore is one vault implementation. These two modules can be used instead of the VICredential store. To illustrate how this can be done, we’ve built a sample module with alternative versions of the VICredential store cmdlets using the two Microsoft modules. You can use this module as it is or just as a reference to build your own solution. Let’s go over the main use cases.

Secret store configuration and vault registration

The first step is to register and configure the secret vault. In our sample module, we have added an Initialize-VISecret cmdlet that does this. It registers SecretStore as a default vault and configures it to not prompt for a password when accessing the vault.

function Initialize-VISecret {
    [CmdletBinding()]
    param(
        [string]$Vault = "VMwareSecretStore"
    )

    process {
         Set-SecretStoreConfiguration -Scope CurrentUser -Authentication None -Interaction None -Confirm:$false 
         Register-SecretVault -Name $Vault -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
    }
}

Saving, reading and deleting credentials from the vault

To save credentials to the vault, you should use the Set-Secret cmdlet in the SecretManagement module. The secret in this cmdlet is identified by its name only, but in our case a credential is described by two identifiers – the user name and the server it’s intended for. Therefore, in the New-VISecret cmdlet we’re concatenating “VISecret”, the server and user name by using the pipe symbol as a delimiter, and then we’re using the resulting string as an identifier of the secret. If you want to save credentials for more than one product you could extend the function to replace “VISecret” with another product specific string to build the identifier, for example “VMCSecret” for VMC. You can pass the password as a plain text string or as a secure string.

Similarly, when we read a credential from the vault by using Get-VISecret, it concatenates “VISecret”, the server and username to form the identifier. Then it uses the Get-Secret to retrieve the password for the corresponding server and username.

You can also delete a credential from the store by using Remove-VISecret, which again builds the identifier, and calls Remove-Secret to delete the secret from the vault. If you’re using SecretStore as a vault, you can remove all the credentials it stores by calling Reset-SecretStore

function New-VISecret {
    [CmdletBinding()]
    [Alias("Set-VISecret")]
    param (
        [Parameter(Mandatory=$true)]
        [string]$Server,
        [Parameter(Mandatory=$true)]
        [string]$User,
        [string]$Password,
        [securestring]$SecureStringPassword,
        [string]$Vault
    )
    begin {
        if ([string]::IsNullOrWhiteSpace($password) -and (-not $secureStringPassword)) {
            Throw "Either Password or SecureStringPassword parameter needs to be specified"
        }
        if (-not [string]::IsNullOrWhiteSpace($password) -and $secureStringPassword) {
            Throw "Password and SecureStringPassword parameters cannot be both specified at the same time"
        }
    }
    process {
        $params = @{
            "Name" = "VISecret|"+$server+"|"+$User
        }
         if ($password) {
            $params += @{"Secret" = $password}
        } elseif ($secureStringPassword) {
            $params += @{"SecureStringSecret" = $secureStringPassword}
        } elseif ($Vault) {
            $params += @{"Vault" = $Vault}
        }
        Set-Secret @params
    }
}

function Get-VISecret {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory=$true)]
        [string]$Server,
        [Parameter(Mandatory=$true)]
        [string]$User,
        [switch]$AsPlainText,
        [string]$Vault
    )
    process {
        $params = @{
            "Name" = "VISecret|"+$server+"|"+$User
        }
        if ($AsPlainText.IsPresent) {
            $params += @{"AsPlainText" = $AsPlainText.ToBool()}
        } elseif ($Vault) {
            $params += @{"Vault" = $Vault}
        }
        Get-Secret @params
    }
}

Integrated connection experience

The last cmdlet in the sample module is Connect-VIServerWithSecret. It combines the cmdlets above to give you integrated experience, similar to the one that Connect-VIServer provides with VICredentialStore. You can call Connect-VIServerWithSecret with username and password and use the -SaveCredentials parameter to save the credentials in the vault. Then you can call it by passing just the username: Connect-VIServerWithSecret will automatically retrieve the password from the vault and connect you to the vCenter. When you’re using the VICredentialStore, if you only have a single credential saved for a specified server, you could connect with Connect-VIServer without specifying a username. In Get-Secret, however, the -Username parameter is mandatory as we cannot list all saved credentials and check if you only have a single credential saved for the specified server. To enable this experience, we have defined a global variable $global:defaultUser that lets you set a default user name for the Connect-VIServerWithSecret.

Conclusion

By using Microsoft’s SecretManagement and SecretStore modules, you can achieve similar user experience as when you’re using the VICredentialStore. SecretManagement also gives you a rich set of integration options with other third-party vaults, both locally and in the cloud. You can use the sample VISecret module to configure and use vaults in a similar way as with the VICredentialStore.

The post Managing VICredentials on PowerShell 7 using VMware.VISecret Module! appeared first on VMware PowerCLI Blog.