Category Archives: vSphere

Administering ESXi Hosts With ESXCLI using PowerCLI

There are times as a vSphere admin, you are going to want to run ESXCLI commands against multiple ESXi Hosts from a central location. This could be for configuration / administration, reporting, patching or a number of other things.

Recently I have been testing different values in the /DataMover/MaxHWTransferSize advanced setting. To make life easier, I wanted a way to change multiple hosts quickly and easily. To do this, I customised a script that Luc Dekens posted as a solution to a problem someone was having that can be used to send ESXCLI commands to multiple hosts using PowerCLI and plink.exe. This slightly modified version uses a CSV file as a source containing my hosts FQDN and the username and password I will be connecting with.

Plink, which is part of the PuTTy suite, can can be found here.

When using this script, you need to either run the script from a directory containing the plink executable, copy it to where you want to run the script, or adjust the script to include the path to the plink executable… whichever takes your fancy.

Disclaimer: Always complete your own testing in an appropriate environment and refer to the vendors official documentation!

$Hosts = Import-Csv C:\ESXiHosts.csv
$Commad = 'esxcfg-advcfg -s 16384 /DataMover/MaxHWTransferSize'

Foreach ($H in $Hosts) {
    #Starting the SSH Service if not already started
    $SSHService = Get-VMHostService -VMHost $H.HostName | where {$_.Key -eq 'TSM-SSH'}
    if ($SSHService.Running -eq 'True') {
        Write-Host "****************************" -ForegroundColor Blue
        Write-Host "WARNING: SSH already enabled, this will be stopped on completion of this script" -ForegroundColor Yellow
    }
        Else {

            Write-Host "Starting SSH Service on Host $($H.HostName)" -ForegroundColor Green
            Start-VMHostService -HostService $SSHService -Confirm:$false > $null
        }
    #Running the defined ESXCLI Command(s)
    Write-host "Running remote SSH commands on $($H.HostName)." -ForegroundColor Green
    Echo Y | ./plink.exe $H.HostName -pw $H.Password -l $H.UserName $Commad
    
    #Stopping the SSH Service
    $SSHService = Get-VMHostService -VMHost $H.HostName | where {$_.Key -eq 'TSM-SSH'}
    if ($SSHService.Running) {
        Write-Host "Stopping SSH Service on Host $($H.HostName)" -ForegroundColor Green
        Stop-VMHostService -HostService $SSHService -Confirm:$false > $null
        Write-Host "****************************" -ForegroundColor Blue
    }
}
Write-Host "Complete $(Get-Date)" -ForegroundColor Green

You can run as many commands as you need by declaring another ‘Command’ variable at the beginning of the script and adding another line to the ‘Running the defined ESXCLI Command(s)’ section.

When run, it will then cycle through each of the ESXi hosts from your CSV file, enable SSH (if its not already enabled), accept the host key, run the commands you have specified and finally turn the SSH service off.

Here you can see it has set the MaxHWTransferSize to 16384 on each host.

You will see the Recent Task pane show the SSH Service starts and stops.

The commands passed in can be anything you need. All you need to do is change the commands that are defined in the variables section. For example, restarting the management agents –

$commad = 'etc/init.d/hostd restart'
$commad2 = 'etc/init.d/vpxa restart'

I hope this has been of use for anyone needing a centralised, quick way to administer multiple hosts via ESXCLI.

Thanks for reading!

Deploying vCenter 7.0 via the CLI

Recently I decided it was time to add a second vCenter 7.0 Appliance to my main lab environment after the lab containing my SRM and vSphere Replication installation ceased to exist…

I thought I would take the CLI route as its been a while, and thought I’d share!

To begin, you need to decide what you are deploying. There are four deployment options available to you, which you can see listed below. To see the options, mount the vCenter ISO image, browse to vcsa-cli-installer\templates\install, and you will find 4 templates;

  • Embedded on ESXi
  • Embedded on VC
  • Embedded replication on ESXi
  • Embedded replication on VC.

Note there is not a distributed option here anymore as this is depreciated in 7.0.

For my lab I will be using the 3rd option; ‘Embedded replication on ESXi’. Firstly because I’m deploying to a standalone host and not to an existing vCenter. Secondly as I already have an existing VCSA and SSO Domain. This new VCSA will be added, or linked to the existing VCSA for my ‘Recovery’ site, in my Site Recovery Manager (SRM) setup.

If you are looking to deploy your first VCSA, onto a standalone host, you will want to use the ‘Embedded on ESXi’ template.

Once you have decided on the template that suits your scenario, you are going to add some details to this template, such as the ESXi host information you are deploying to, networking information, NTP and in my case SSO details as I will be adding it to an existing SSO Domain. One important value is the deployment size (deployment_option in the example below).

A useful command that can be run to help you decide what size appliance is suitable for your needs is:

vcsa-deploy --supported-deployment-sizes

This outputs the vCenter sizing to assist you. It shows you the resource requirements as well as the amount of hosts and VM’s each can support.

Information 
Options 
tiny 
——supported—deployment—sizes 
about deployment sizes: 
vCPUs Memory CGB) Storage CGB) HostsCup to) VMsCup to) 
tiny—Istorage 
tiny—xlstorage 
small 
small—Istorage 
small—xlstorage 
medium 
medium—Istorage 
medium—xlstorage 
large 
large—Istorage 
large—xlstorage 
xlarge 
xlarge—lstorage 
xlarge—xlstorage 
2 
2 
2 
8 
8 
8 
16 
16 
16 
24 
24 
24 
12 
12 
12 
19 
19 
19 
28 
28 
28 
37 
37 
37 
56 
56 
56 
463 
1538 
3293 
528 
1583 
3343 
748 
1748 
3568 
1113 
1813 
3573 
1853 
1953 
3713 
16 
16 
16 
lee 
lee 
uee 
uee 
leee 
leee 
leee 
2eee 
2eee 
lee 
lee 
lee 
leee 
leee 
leee 
leeee 
leeee 
leeee 
35eee 
35eee

For my lab, ‘tiny’ covers my needs.

Here is the json file I used for the deployment in my lab.  I have excluded the passwords for obvious reason, but it can be ran like this, and will prompt you for the passwords in the terminal.

{
    "__version": "2.13.0",
    "__comments": "Sample template to deploy a vCenter Server Appliance with an embedded Platform Services Controller as a replication partner to another embedded vCenter Server Appliance, on an ESXi host.",
    "new_vcsa": {
        "esxi": {
            "hostname": "smt-lab-esx-04.smt-lab.local",
            "username": "root",
            "password": "",
            "deployment_network": "vSS_PG_Management",
            "datastore": "smt-lab-vmfs-02a"
        },
        "appliance": {
            "__comments": [
                "You must provide the 'deployment_option' key with a value, which will affect the VCSA's configuration parameters, such as the VCSA's number of vCPUs, the memory size, the storage size, and the maximum numbers of ESXi hosts and VMs which can be managed. For a list of acceptable values, run the supported deployment sizes help, i.e. vcsa-deploy --supported-deployment-sizes"
            ],
            "thin_disk_mode": true,
            "deployment_option": "tiny",
            "name": "smt-lab-vcsa-02"
        },
        "network": {
            "ip_family": "ipv4",
            "mode": "static",
            "system_name": "smt-lab-vcsa-02.smt-lab.local",
            "ip": "10.200.15.249",
            "prefix": "24",
            "gateway": "10.200.15.254",
            "dns_servers": [
                "10.200.15.10"
            ]
        },
        "os": {
            "password": "",
            "ntp_servers": "0.uk.pool.ntp.org",
            "ssh_enable": true
        },
        "sso": {
            "password": "",
            "domain_name": "vsphere.local",
            "first_instance": false,
            "replication_partner_hostname": "smt-lab-vcsa-01.smt-lab.local",
            "sso_port": 443
        }
    },
    "ceip": {
        "description": {
            "__comments": [
                "++++VMware Customer Experience Improvement Program (CEIP)++++",
                "VMware's Customer Experience Improvement Program (CEIP) ",
                "provides VMware with information that enables VMware to ",
                "improve its products and services, to fix problems, ",
                "and to advise you on how best to deploy and use our ",
                "products. As part of CEIP, VMware collects technical ",
                "information about your organization's use of VMware ",
                "products and services on a regular basis in association ",
                "with your organization's VMware license key(s). This ",
                "information does not personally identify any individual. ",
                "",
                "Additional information regarding the data collected ",
                "through CEIP and the purposes for which it is used by ",
                "VMware is set forth in the Trust & Assurance Center at ",
                "http://www.vmware.com/trustvmware/ceip.html . If you ",
                "prefer not to participate in VMware's CEIP for this ",
                "product, you should disable CEIP by setting ",
                "'ceip_enabled': false. You may join or leave VMware's ",
                "CEIP for this product at any time. Please confirm your ",
                "acknowledgement by passing in the parameter ",
                "--acknowledge-ceip in the command line.",
                "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
            ]
        },
        "settings": {
            "ceip_enabled": true
        }
    }
}


Once you have prepared your file, there are a couple of commands you can run from a PowerShell prompt to validate your configuration before deploying, saving you some time should mistakes have been made. The first being:

.\vcsa-deploy.exe install --accept-eula --acknowledge-ceip --verify-template-only <Path to json File>

This completes some basic checks to ensure your json file is correct, here is a successful output:

[START] Start executing Task: To validate CLI options at 
Command line arguments verfied . 
[SUCCEEDED] Successfully executed Task 'CLIOptionsVaIidationTask: Executing CLI 
optionsvalidation task' in TaskFIow 'template_validation' at 
[START] Start executing Task: To validate the syntax of the template. at 
Template syntax validation for template 
'M: . json' succeeded . 
Syntax validation for all templates succeeded . 
[SUCCEEDED] Successfully executed Task 'SyntaxVaIidationTask: Executing 
Template Syntax Validation task' in TaskFIow 'template_validation' at 
[START] Start executing Task: To check the version of each template, and for 
each older template that supports CEIP, convert it to the latest template 
format, and save it to the Template Blackboard at 
Template version processing for template 
'M: . json' succeeded . 
Version processing for all templates succeeded . 
[SUCCEEDED] Successfully executed Task 'VersionprocessingTask: Executing 
Template Version processing task' in TaskFIow 'template_validation' at 
[START] Start executing Task: To validate the template structure against the 
rules specified by a corresponding template schema. at 
Template structure validation for template 
'M: . json' succeeded . 
Structure validation for all templates succeeded . 
[SUCCEEDED] Successfully executed Task 'StructureVaIidationTask: Executing 
Template Structure Validation task' in TaskFIow 'template_validation' at 
[START] Start executing Task: To create a dependency graph for the provided 
templates, with an edge pairing two templates that are dependent on each other. 
Such graph relationships will affect whether certain templates can be deployed 
in parallel, or must be deployed sequentially. at 
Dependency processing for all templates succeeded . 
[SUCCEEDED] Successfully executed Task 'DependencyprocessingTask: Executing 
Template Dependency processing task' in TaskFIow 'template_validation' at 
Template verification completed . 
----------------------------------= 12 : l€:eu

Secondly:

.\vcsa-deploy.exe install --accept-eula --acknowledge-ceip --precheck-only <Path to json File>

This will perform a more in depth validation, checking things like the credentials for your SSO domain, DNS or whether the IP or name you plan to use for your VCSA is in use already.

Note: Make sure you have your DNS setup correctly and is resolving the appliance FQDN!

It will also provide warnings if it thinks you might not be using an appropriate template. I originally specified a host what was already managed by vCenter, so it warned me like so:

DRS Warning: The target ESXi host ' smt—lab .10caI' is managed by 
of these hosts are in a cluster, and DRS 
vcenter server '1€.2€€.15.25€' . 
If any 
is enabled, vMotion can take effect and 
adversely impact the installation, 
upgrade, or migration processes. 
It is 
recommended that you use the 
*_on_vc.json template file for the target ESXi host if it is managed by a 
vCenter Server, and ensure the ESXi hosts you have specified are not members of 
clusters with DRS set to Fully Automated during the installation, upgrade, or 
migration processes.

You will get a similar output to the first command, should you pass all the tests. If not you will need to look at resolving them to ensure you get a successful deployment.

The Install!

Once you are confident you have everything in place, including DNS, and your configuration files are correct, you are ready to install:

.\vcsa-deploy.exe install --accept-eula --acknowledge-ceip --no-ssl-certificate-verification <Path to json File>

Here is a cut down version of the output you will see during the deployment:

 ====== [START] Start executing Task: To validate CLI options at 12:46:25 ======
 Command line arguments verfied.
  [SUCCEEDED] Successfully executed Task 'CLIOptionsValidationTask: Executing CLI
 optionsValidation task' in TaskFlow 'template_validation' at 12:46:26
  [START] Start executing Task: To validate the syntax of the template. at
 12:46:27
 Template syntax validation for template
 'M:\Software\VMware\vCenter\embedded_vCSA_replication_on_ESXi.json' succeeded.
 Syntax validation for all templates succeeded. 

 ====== [START] Start executing Task: Perform precheck tasks. at 12:46:39 ======
  [START] Start executing Task: Verify that the provided credentials for the
 target ESXi/VC are valid at 12:46:45
 The certificate of server 'smt-lab-esx-04.smt-lab.local' will not be verified
 because you have provided either the '--no-ssl-certificate-verification' or
 '--no-esx-ssl-verify' command parameter, which disables verification for all
 certificates. Remove this parameter from the command line if you want server
 certificates to be verified. 

 ================== [START] Start executing Task:  at 12:47:47 ==================
 = [SUCCEEDED] Successfully executed Task '' in TaskFlow 'install' at 12:47:47 =
  [START] Start executing Task: Check whether the datastore's free space
 accommodate the VCSA's deployment option at 12:47:51
  [SUCCEEDED] Successfully executed Task 'Running precheck: TargetDsFreespace' in
 TaskFlow 'install' at 12:47:51 

 ==========VCSA Deployment Progress Report==========         Task: Install
 required RPMs for the appliance.(RUNNING 5/100)   - Setting up storage
 VCSA Deployment is still running 

 ==========VCSA Deployment Progress Report==========         Task: Install
 required RPMs for the appliance.(SUCCEEDED 100/100)       - Task has completed
 successfully.         Task: Run firstboot scripts.(SUCCEEDED 100/100) - Task has
 completed successfully.
 Successfully completed VCSA deployment.  VCSA Deployment Start Time:
 2020-12-28T13:19:19.291Z VCSA Deployment End Time: 2020-12-28T14:18:27.103Z
  [SUCCEEDED] Successfully executed Task 'MonitorDeploymentTask: Monitoring
 Deployment' in TaskFlow 'embedded_vCSA_replication_on_ESXi' at 14:18:45
 Monitoring VCSA Deploy task completed
 The certificate of server 'smt-lab-vcsa-02.smt-lab.local' will not be verified
 because you have provided either the '--no-ssl-certificate-verification' or
 '--no-esx-ssl-verify' command parameter, which disables verification for all
 certificates. Remove this parameter from the command line if you want server
 certificates to be verified.
 == [START] Start executing Task: Join active domain if necessary at 14:18:59 ==
 Domain join task not applicable, skipping task
  [SUCCEEDED] Successfully executed Task 'Running deployment: Domain Join' in
 TaskFlow 'embedded_vCSA_replication_on_ESXi' at 14:18:59
  [START] Start executing Task: Provide the login information about new
 appliance. at 14:19:10
     Appliance Name: smt-lab-vcsa-02
     System Name: smt-lab-vcsa-02.smt-lab.local
     System IP: 10.200.15.249
     Log in as: Administrator@vsphere.local
  [SUCCEEDED] Successfully executed Task 'ApplianceLoginSummaryTask: Provide
 appliance login information.' in TaskFlow 'embedded_vCSA_replication_on_ESXi' at
 14:19:10
 =================================== 14:19:16 =================================== 

Once complete, you will now have a second vCenter appliance deployed in Linked mode with the original.  Here it is once I had configured a datacenter and cluster with two hosts.

v @ smt-lab-vcsa-02_smt-lab.locaI 
smt-lab-dc02 
a:] smt-lab-cl-wl-02a 
(Maintenance Mode) 
smt-lab-esx-07_smt-lab_local (Maintenance Mode)

And there you have it, thanks for reading!

Using Tags To Automate The Assigning Of vCenter Object Permissions

Tags are a really useful component in VMware. They can be used for all manor of things, whether it’s for storage policies, backups, identifying a group of objects or in the case of this post, managing permissions.

Having a method of easily assigning permissions to singular or multiple objects in vCenter can be a great benefit to a vSphere Admin as it’s gives them greater control over the environment they manage.

Lets take a look at what is needed to get this setup:

  • Script
  • Tag Category & Tags for each support role.
  • AD Security Groups
  • AD Service Account
  • vCenter Roles (one for the service account, then one for each of the support roles)
  • PowerCLI VICredentials
  • Scheduled Task

In this example I will use 4 common support teams that could be used, DBA, EUC, Operations and Storage. These can be anything you have a requirement for.

Script

Here is the script that applies the permissions based on the assigned tags. It can also be found here on GitHub. Save this on your management server of choice, or wherever you intend to run the scheduled task as a .PS1 file. In this example it’s saved on a management server in C:\Scripts\VI_Permissions.ps1.

#Load PowerCLI Modules
Import-module VMware.PowerCLI

#Get the Credentials
$creds = Get-VICredentialStoreItem -file  C:\Scripts\VM_Tagging_Perms.creds
 
#Connect to vCenter
Connect-VIServer -Server $creds.host -User $creds.User -Password $creds.Password -Force

#Tags
$dbaT = "Support Team/DBA_Team"
$storT = "Support Team/Storage_Team"
$eucT = "Support Team/EUC_Team"
$operT = "Support Team/Operations_Team"

#Active Directory Groups
$dbaG = "smt-lab\dba_admins"
$storG ="smt-lab\storage_admins"
$eucG = "smt-lab\euc_admins"
$OperG = "smt-lab\operations_users"

#Roles
$dbaR = "DBA VM Administrator"
$storR = "Storage VM Administrator"
$eucR = "End User VM Administrator"
$OperR = "Operations Users"


$VMs = Get-VM

ForEach ($VM in $VMs) {

        $TAGS = Get-TagAssignment -Entity $VM | Select @{l='SupportTeam';e={('{0}/{1}' -f $_.tag.category, $_.tag.name)}}, Entity

                                If ($TAGS.SupportTeam -contains $dbaT)  {New-VIPermission -Principal $dbaG -Role $dbaR -Entity $vm.name} Else {Get-VIPermission -Entity $vm.Name -Principal $dbaG | Remove-VIPermission -Confirm:$false}
                                If ($TAGS.SupportTeam -contains $storT) {New-VIPermission -Principal $storG -Role $storR -Entity $vm.Name} Else {Get-VIPermission -Entity $vm.Name -Principal $storG | Remove-VIPermission -Confirm:$false}
                                If ($TAGS.SupportTeam -contains $eucT) {New-VIPermission -Principal $eucG -Role $eucR -Entity $vm.Name}  Else {Get-VIPermission -Entity $vm.Name -Principal $eucG | Remove-VIPermission -Confirm:$false}
                                If ($TAGS.SupportTeam -contains $operT) {New-VIPermission -Principal $OperG -Role $OperR -Entity $vm.Name}  Else {Get-VIPermission -Entity $vm.Name -Principal $OperG | Remove-VIPermission -Confirm:$false}
                        }

Tag Category & Tags

Now onto Tag Categories and Tags in vCenter. Create a Tag category called ‘Support _Teams’ (Or something of your choosing, just make sure you are consistent throughout):

Or using PowerShell – New-TagCategory -Name Support_Teams -Cardinality Multiple -EntityType All

You can select as many object types as you wish and you will also want to allow multiple tags per object.

Now create a tag for each of the support teams in the tag category you just created:

New-Tag -Name Storage_Team -Category "Support_Teams"
New-Tag -Name DBA_Team -Category "Support_Teams"
New-Tag -Name EUC_Team -Category "Support_Teams"
New-Tag -Name Operations_Team -Category "Support_Teams"
Storage_Team 
DBA—Team 
EUC_Team 
Operations _ Team 
Support Team 
Support Team 
Support Team 
Support Team

Create AD groups

Now for some corresponding AD Security Group for each role you wish to have:

Name 
dba admins 
operation 
storage_ad, 
Type 
Security Group 
Security Group... 
Security Group, 
Security Group

Service Account (AD User)

Now to create an AD user account that will be used to apply the permissions within vCenter. This will be the account that will be used to run the scheduled task, connect to vCenter and will have the appropriate permissions to assign permissions for the support roles.

Name 
Type 
tag_permissions User

Support Team Roles

Now we need to create a suitable role for each team.  In this example I have copied the Virtual Machine Power User role, but these roles can contain which ever privilege’s you require.

Under ‘Administration > Roles’ you will see the options to either create a new Role or copy an existing.  From here you will be able to assign it a name and specify the privilege’s you require.

Roles 
Roles provider: 
Admlnlstrator 
Read-only 
No access 
AppdAppllenceUser 
AutoUpdateUser 
VSPHERE.LOCAL v 
DESCRIPTION 
Datastore 
USAGE 
PRIVILEGES 
Content llbrery edmlnlstretor (sample) 
Content Llbrery Reglsry admlnlstrator (sample) 
Datastore consumer (sample) 
DBA VM Admlnlstretor 
End User VM Admlnlstretor 
Network admlnlstretor (sample) 
No cryptography admlnlstrator 
No Trusted Infrastructure admlnlstretor 
NSX Admlnlstretor 
NSX Auditor 
NSX VI Admlnlstretor 
Operatlons Users 
Resource pool admlnlstretor (sample) 
SRM Admlnlstrator 
42 items 
Browse datastore 
Global 
Cancel task 
Scheduled task 
Create tasks 
• Modify task 
• Remove task 
• Run task 
Virtual machine 
Change Configuration 
Acquire disk lease 
Add existing disk 
Add new disk 
Add or remove device 
Advanced configuration 
Change CPU count 
Change Memory 
Change Settings 
Change resource 
o Modify device settings 
Remove disk

You will be referencing these Role names in the script so make sure you continue to match the names thought the process.

Permissioning Role

As mentioned in the service account section, the account (tag_permissions) running the scheduled task will need permissions in vCenter through a role.  The privileges this role will hold, needs to include all the privilege’s that are referenced in all of your Support Team Roles in order for it to have the right to assign the permissions. For example, if all your support roles are a copy of the ‘Virtual Machine power user’ role, your tagging permissions role will need to contain the same privileges.

Depending on how broad the scope of your support team roles, you may want to use the ‘Administrator’ or the ‘No cryptography administrator’ role.  This is entirely up to you and how you manage your estate.

For this example in my lab, I will use the predefined ‘Administrator’ role to grant the ‘tag_permissions’ AD account permissions at the Global Root, ensuring you have selected the ‘Propagate to children’ option.

Change Role 
Domain 
User/Group 
Role 
Global Permission Root 
SMT-LABLOCAL 
tag_permissions 
Administrator 
Propagate to children 
CANCEL

You could create a copy of the ‘Administrator’ role and name it something like ‘VI Permissions Service’ for instance, to give you flexibility to modify it in the future as well as making it easy to identify. With any high privileged account, ensure you secure it appropriately.

Create VI Credential Item

Now to create an encrypted credentials file that the service account running the scheduled task can import and then use to connect to vCenter without any intervention.

The AD account that is used to run the scheduled task, must be the account that also creates the credentials file as this is the only user that can use it.  It will require permissions to run PowerShell and have access to a folder location to store the credentials file on your chosen management server.

To begin, start a PowerShell session in the context of the service account:

Windows Security 
Run as different user 
Please enter credentials to use for 
Domain: smt-lab 
OK 
Cancel

Note: Ensure the server that you are running this scheduled task from has PowerCLI installed.  Installing PowerCLI.

Then run the following, entering your vCenter FQDN and the user and password that you created:

New-VICredentialStoreItem -host "smt-lab-vcsa-01.smt-lab.local" -user "smt-lab\tag_permissions" -password "VMware123!" -file C:\Scripts\VM_Tagging_Perms.creds
PS C: 
_Perms . creds 
New—VIC redenti al Storeltem 
C: \ Scri pts ng 
-host 
smt—lab. local" -user 
"smt—l ssion 
s" -password 
"VMware123! " 
Hos t 
User 
smt—1ab—vcsa—01 s 
smt—l . 
C: \ Scri ng_Perms . creds

Ensure you are storing the file somewhere with appropriate access to allow this but, also to restrict any unnecessary access.  The credentials file can have the password read if the user account that created it is compromised and gains access to the file using those windows credentials.

Scheduled Task

Now for the last component, the scheduled task. On a management server or a server of your choosing, create a scheduled task:

Vl_permissions Properties (Local Computer) 
General Triggers Actions Conditions Settings 
History 
Location: 
Author: 
VI Permissions 
SMT- LA8\Administrator 
Description: 
Security options 
When running the task, use the following user account: 
SMT- LA rmissio ns 
C) Run only when user is logged on 
@ Run whether user is logged on or not 
Change User or Group... 
[3 Do not store password. The task will only have access to local computer resources. 
Run with highest privileges 
Hidden 
Configure for: 
Windows Vista" , Windows Server" 2008 
Cancel

Assign an appropriate schedule that suits the level of change and size of your environment:

Vl_permissions Properties (Local Computer) 
General Triggers Actions Conditions Settings 
History 
Location: 
Author: 
VI Permissions 
SMT- LA8\Administrator 
Description: 
Security options 
When running the task, use the following user account: 
SMT- LA rmissio ns 
C) Run only when user is logged on 
@ Run whether user is logged on or not 
Change User or Group... 
[3 Do not store password. The task will only have access to local computer resources. 
Run with highest privileges 
Hidden 
Configure for: 
Windows Vista" , Windows Server" 2008 
Cancel

Now configure the trigger to execute the script:

(9 
Create Task 
General Triggers Actions Conditions Settings 
When you create a task, you must specify the action that will occur when your task starts. 
Action 
Start a program 
New... 
Details 
powershell -File 
Edit... 
Delete

Now thats everything you need to set this up, so lets give it a run though!

Assigning Tags and Permissions

Lets take a look at my demo VM permissions before we begin assigning permissions:

Lets check the VM permissions before having any tags assigned:

Get-TagAssignment -Entity $VM
$VM | ForEach-Object {Get-VIPermission -Entity $_ | Where {$_.Principal -like "*smt-lab*"} | Select Principal, Role}

Note that the tag_permissions account has been propagated from the root permissions you set earlier.

—TagAssignment 
-Entity 
ps Get 
ForEach—Object {Get—VIPermission 
principal 
Role 
SMT-LAB\tag_ 
permissions Admin 
—Entity 
Where 
principal 
—like 
Select principal, 
Role} 
SMT-LAB\Stephan 
Admin

Now assign a tag or two from the ones you created earlier using ‘New-TagAssignment’:

New-TagAssignment -Tag DBA_Team -Entity $VM
New-TagAssignment -Tag Operations_Team -Entity $VM
DBA_Team 
Tag 
Support 
Tag 
Support 
New—TagAssignment —Tag 
Team/DBA_Team 
New—TagAssignment —Tag 
Team/Operations_Team 
-Entity $VM 
Entity 
tfdemol 
Operations_Team —Entity $VM 
Entity 
tfdemol

Now you can either manually run the scheduled task or wait until its next scheduled run time.  Once the job has run, you can now check the tags match the permissions assigned by running the following:

Get-TagAssignment -Entity $VM
$VM | ForEach-Object {Get-VIPermission -Entity $_ | Where {$_.Principal -like "smt-lab"} | Select Principal, Role}
—Entity 
Tag 
Support 
Support 
Get—TagAssignment 
Team/DBA_Team 
Team/Operations_Team 
ForEach—Object {Get—VIPermission 
Entity 
tfdemol 
tfdemol 
—Entity 
Where 
principal 
—like 
Select principal, 
Role} 
principal 
SMT 
SMT 
SMT 
SMT 
—LAB\dba_admins 
—LAB\operations_users 
—LAB\tag_permissions 
—LAB\Stephan 
Role 
DBA VM Administrator 
Operations Users 
Admin 
Admin

You will see that the two tags assigned align with the the two AD groups being granted the corresponding role.

Now let do this for multiple VM’s:

Here I have multiple VM’s in the variable ‘$VM’ and I am assigning two tags to each of them.

$VM | ForEach-Object {New-TagAssignment -Tag DBA_Team -Entity $_}
$VM | ForEach-Object {New-TagAssignment -Tag Storage_Team -Entity $_}
DBA_Team 
Tag 
Support 
Support 
Support 
Support 
Support 
Tag 
Support 
Support 
Support 
Support 
Support 
—Object 
ForEach 
Team/DBA_Team 
Team/DBA_Team 
Team/DBA_Team 
Team/DBA_Team 
Team/DBA_Team 
—Object 
ForEach 
Team/Storage_Team 
Team/Storage_Team 
Team/Storage_Team 
Team/Storage_Team 
Team/Storage_Team 
{New—TagAssignment —Tag 
Entity 
Demopho€€6 
Demophoe€5 
Demopho€€2 
Demopho€€u 
Demophoe€3 
—Entity $_} 
{New—TagAssignment —Tag 
Storage_Team 
Entity 
Demopho€€6 
Demopho€€5 
Demopho€€2 
Demopho€€u 
Demopho€€3 
—Entity $_}

You can now see the tags assigned:

$VM | ForEach-Object {Get-TagAssignment -Entity $_}
{Get—TagAssignment 
Entity 
Tag 
Support 
Support 
Support 
Support 
Support 
Support 
Support 
Support 
Support 
Support 
ForEach—Object 
Team/Storage_Team 
Team/DBA_Team 
Team/Storage_Team 
Team/DBA_Team 
Team/Storage_Team 
Team/DBA_Team 
Team/Storage_Team 
Team/DBA_Team 
Team/Storage_Team 
Team/DBA_Team 
—Entity $_} 
Demophoe€6 
Demopho€€6 
Demopho€€5 
Demophoe€5 
Demopho€€2 
Demopho€€2 
Demophoeeu 
Demopho€€u 
Demophoe€3 
Demophoe€3

Following the script / job being run:

 $VM | ForEach-Object {Get-VIPermission -Entity $_ | Where {$_.Principal -like "*smt-lab*"} | Select Principal, Role} 
ForEach 
principal 
—Object {Get—VIPermission 
Role 
DBA VM Administrator 
—Entity 
Where 
principal 
—like 
Select principal, 
Role} 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
SMT 
—LAB\dba_admins 
—LAB\storage_admins 
—LAB\tag_permissions 
—LAB\Stephan 
—LAB\dba_admins 
—LAB\storage_admins 
—LAB\tag_permissions 
—LAB\Stephan 
—LAB\dba_admins 
—LAB\storage_admins 
—LAB\tag_permissions 
—LAB\Stephan 
—LAB\dba_admins 
—LAB\storage_admins 
—LAB\tag_permissions 
—LAB\Stephan 
—LAB\dba_admins 
—LAB\storage_admins 
—LAB\tag_permissions 
—LAB\Stephan 
Storage VM Administrator 
Admin 
Admin 
DBA VM Administrator 
Storage VM Administrator 
Admin 
Admin 
DBA VM Administrator 
Storage VM Administrator 
Admin 
Admin 
DBA VM Administrator 
Storage VM Administrator 
Admin 
Admin 
DBA VM Administrator 
Storage VM Administrator 
Admin 
Admin

As in the singular example, you will see that the two tags assigned, align with the the two AD groups being granted the corresponding role.

Removing Tags and Permissions

Now lets look at removing permissions, in this case, the Operations Team permissions from a VM:

Get-TagAssignment -Entity $VM | Where {$_.Tag -like "*Operations*"} | Remove-TagAssignment -Confirm:$false

Leaving it with just the ‘DBA_Team’ Tag assigned:

Once the script has run:

$VM | ForEach-Object {Get-VIPermission -Entity $_ | Where {$_.Principal -like "*smt-lab*"} | Select Principal, Role}

Reviewing Permissions

Finally, if you want to know which objects are supported by a specific team and have access you can check this by running:

Get-TagAssignment | Where {$_.Tag -like "Support_Teams/DBA_Team"}

You now have a way of assigning and removing permissions from vCenter objects using Tags. In this example I have used virtual machine object, but depending on your requirements, and the scope you set on the tag category, you could use this for other vCenter objects.

Thanks for reading!

SRM 8.3 Certificate Management

Following on from my last post on vSphere 7.0 certificate Management, I wanted to continue with another certificate related post. This one being Site Recovery Manager (SRM) 8.3. Like vSphere 7.0, this version seems simpler than previous versions I have used.

With SRM, it’s the Appliance Certificate replacement that I am going to take you through in this blog post.

Firstly log into the SRM appliance management console via https://<srm-fqdn&gt;:5480 and select the ‘Certificates’ option on the left, followed by ‘Generate CSR’ in the top right.

Fill in the information for your certificate, then click ‘Generate and Download’. You then need to process the CSR with your certificate authority, whether thats an internal, public or lab CA.

New Private Key and CSR 
Generating a new private key invalidates any existing Certificate Signing Request (CSR) configuration. 
A private key is created when you generate the CSR, making a key pair. 
This information will be used to generate a certificate. 
Organization 
Organization unit 
Locality 
State 
Country 
FQDN 
IP addresses 
smt-lab.local 
smt-lab 
Lab City 
Labshire 
GB 
Two letters country code. 
smt-lab-srm-01.smt-lab.local 
10.200.15.25 
CANCEL 
GENERATE AND DOWNLOAD

Once you have your certificate, select the ‘Certificates’ option on the left again, this time followed by ‘Change’ in the top right.

Select the last option in the Select certificate type section; ‘CA-signed certificate generated from CSR’. Then, browse both your newly generated certificate and either you root CA certificate, or the CA chain. Click ‘Change’ once done.

This should complete the replacement of the SRM appliance certificate!

If like me you get an error complaining that the IP or Common name / SAN is missing, make sure the local host field is set to the FQDN when connecting SRM to vCenter.

Thanks for reading!

vSphere 7.0 Certificate Management

vCenter 7.0 brings many new features, one of which is a much smoother certificate management experience. There are now 4 main ‘modes’ for certificate management.

These are; Fully Managed Mode, Hybrid Mode, Subordinate CA Mode and finally Full Custom Mode. There is a great article here from Bob Plankers explaining the difference between each.

As mentioned in Bob’s blog, Hybrid Mode is the recommend option, and I will show you that process here in this blog.

Firstly, in your vSphere Client, browse to Administration > Certificates. Then click Actions and select ‘Generate Certificate Signing Request (CSR)’.

Complete the required fields with your information, making sure you have at least added the common name as a Subject Alternative Name to avoid issues with modern browsers. Click Next.

Finally, copy or download your CSR to generate the certificate on the CA of your choosing. Click Finish when ready.

Generate CSR 
1 Enter Info 
2 Generate CSR 
Generate CSR 
X 
Copy or download the CSR below and provide it to your Certificate Authority 
to be signed. 
---BEGIN CERTIFICATE REQUEST.... 
MllDrZCCAPCCAQAwfZEmMCQGAIUEAWWdC210LWXhYi12Y3NhLTAXLnNtdCISY 
Wiu 
bG9jYWwxCzAJBgNVBAYTAkdCMREwDwYDVQQlDAhMYWJzaGIyZTERMA8GA 
IUEBWWI 
TGFilENPdHkXEDAoagNVBAOMB3NtdCISYWlXEDAOBgNVBASMB3NtdCISYWlW 
ggEi 
MAOGcsqGSlb3DaEBAGUAA41BDWAwggEKAOlBAQCXZYRq1HAU7M601HmvuT 
EsFnNZlpP2sBz4C9K87Wi/4kgLMq04LCTjCK08SPa+6w7AwVjmFja1np4hrSVl+N 
mh5dUOUDFHgKqFeuIAvjfXCAEVS4ircreCN7KfW12ytfUin8ce8qEu5DouguhWhl 
oi5Fa1xOGKybZFzLpySsA7rdJ6bYcJYeyn+uf7YHbO+dWHz3XZ9FG7M8fCbtLdW 
COPY 
CANCEL 
DOWNLOAD 
BACK 
FINISH

Once you have your certificate, return to Administration > Certificates and this time select ‘Import and Replace Certificate’.

You then need to select the second option. This may seem slightly deceiving but it effectively is the option you need when you have generated the CSR from vCenter like this.

Now browse and select both your freshly produced certificate, and the root certificate or certificate chain if you have issuing CA’s.

Replace Certificate 
1 Choose appropriate option 
2 Replace with signed certificate 
Replace with external CA certificate 
vCenter server services will be automatically restarted after successful replacement Of the machine SSL certificate. 
Machine SSL Certificate 
Chain of trusted root certificates 
Certificate: 
Data: 
Version: 3 (Ox2) 
BROWSE FILE 
MllDNjCCAh6gAWlBAglUZHHFEZH7/jq1Z9NXjm+ORhgflOSWDQYJKOZlhVCNA 
GEL 
CANCEL 
BROWSE FILE 
BACK 
REPLACE

Hit replace, then wait for the Web Client to restart with the new certificate.

Now one final step is needed to complete Hybrid Mode. You need to download the VMCA Root certificate from https://<vCenterFQDN by clicking the ‘Download trusted root CA certificates’ option and distributing it to your vSphere admins.

Once distributed and installed on your vSphere admins client devices, they should not get certificate errors when either browsing to vCenter or the hosts it manages.

You could however, get this error due to the default certificate having a 5 year validity period and not being within the new ‘standard’ of 398 days.

NET::ERR_CERT_VALIDITY_TOO_LONG

If you receive this, you will want to adjust the vpxd.certmgmt.certs.daysValid value in the vCenter Advanced Settings. It defaults to 1825, making it 365 (one year) will stop this.

You can then renew the certificate on each host by clicking ‘Renew’ in the Configure > Certificates menu –

Before (5 years) –

After (1 Year)-

If you want to do this renewal via PowerCLI (because…well why wouldn’t you!?) there is a nice function here by Ankush Sethi which does a great job.

Thanks for reading.

Deploying and Connecting A Key Management Server to vCenter

Is it secure?  

This has to be one of the first things you consider with any technology solution or decision today.  So when I was lucky enough to receive a NFR license from HyTrust for their KeyControl Key Management System I was excited to get this into my lab so I can make use of VMware’s vSAN and VM Encryption.

In this post I will be going through the process of deploying a HyTrust Key Control appliance and creating a trust with vCenter.  It was surprisingly straight forward and I was up and running in no time at all!

Firstly, deploy the OVA to an ESXi Host or Cluster that isn’t going to be managed by the Key Control appliance.  You don’t want your encryption keys in the same place as the objects you are encrypting!  

Follow the OVF deployment wizard, providing the details as prompted, and once the appliance is online, complete the final configuration steps to finish the installation.

You will then be met with this screen – 

System setup has completed successful ly . 
System Conf iguration Sunmry : 
Hostnam: smt-lab-kms-al 
Phnagemnt IP Address: 1B . Zag . 15 . 15 
From your browser, please go to https ://IB .ZBB . 15 . 15

Now, browse to the web GUI and log in using the default credentials.  You will then be prompted to set your own, followed by SMTP and online monitoring configuration options.

Once this is done and you are logged in there are a few KMIP settings you need to adjust in order for it to be ready to connect to vCenter as a Key Provider – 

State = ENABLED

Protocol = Version 1.1

TRUST 
H 
SECURITY 
Actions • 
Host Name: 
port: 
State 
Basic 
Client Certificates 
Objects 
10.200.15.15 
5696 
ENABLED 
OFF 
Yes 
Version 1.1 
Detault 
OFF 
O Infinite 
CREATE-MODIFY 
DISABLED 
Connections Will use TLS 1.2 if set to Enabled 
AUDIT LOG 
v 
Auto-Reconnect 
Verity 
Protocol: 
Certificate Type: 
Nöio: 
Timeout: 
Log Level: 
Restnct TLS] 
Custom nex value

Below is a link to a HyTrust document with the details for vSphere 6.5.  I used this for deployment in my vSphere 7 environment. You can find it here.

You will also want to apply a license file.  This is done via; ‘Settings > License’, by way of uploading the license file you have been issued.

This completes a basic configuration that is now ready to connect to vCenter.  If you are deploying outside of a lab environment, you are going to want to review your installation appropriately for the environment it is intended for.

So over to the Web Client.  Select the vCenter Server object, select ‘Configure > Security > Key Providers’ and hit ‘Add Standard Key Provider’.

smt-lab-vcsa-01.smt-lab.local 
Summary Monitor 
Con figure 
Permissions 
Key Providers 
Settings 
General 
Licensing 
Message of the Day 
Advanced Settings 
Authentication Proxy 
vCenter HA 
Security 
Trust Authority 
Ke Providers 
Alarm Definitions 
Scheduled Tasks 
Storage Providers 
vSAN 
Update 
Internet Connectivity 
ACTIONS V 
Datacenters 
Hosts & Clusters 
V Ms 
Datastores 
Networks 
Linked vCenter Server Systems 
Extensions 
Updates 
ADD STANDARD KEY PROVIDER 
MAKE DEFAULT 
REMOVE

You will then want to give it a name, followed by the requested information.  Once done, click ‘Add Key Provider’

Add Standard Key Provider 
Name 
KMS 
smt-lab-kms-011 
ADD KMS 
HyTrust Key Control 
Address 
10_200.15.15 
Proxy configuration (optional) 
Password protection (optional) 
CANCEL 
5696 
ADD KEY PROVIDER

You will receive the following prompt to confirm you want to from the Key Provider you have entered. Click ‘Trust’

This will have now created a Key Provider, but will show that it is not connected and has a certificate issue.  So next we need to set up the trust.

This can be done by clicking ‘Establish Trust’ and selecting ‘Make KMS trust vCenter’

Key Providers 
ADD STANDARD KEY PROVIDER 
Key Provider 
HyTrust Key Control (default) 
Provider By Trust Key Control - 
ESTABLISH TRUST v 
KMS trust vCenter 
Make KMS trust vCenter 
Upload Signed CSR Certificate 
vcenter Trust KMS 
Make vCenter Trust KMS 
Upload KMS Certificate 
MAKE DEFAULT 
EDIT 
REMOVE 
T 
5696 
Connection Status 
1 KMS not connected 
Key Management Servers 
T 
Address 
Certificates 
1 certificate issue(s) 
vCenter Certificate 
Connection Status 
Client trusts server 
KMS Certificate 
@ Valid until: Dec 31, 2049 
items 
items

In my lab, I have gone with the option of creating a CSR and having the KMS issue a certificate – 

Make KMS trust 
vCenter 
1 Choose a method 
2 Estaalish Trust 
Choose a method 
Choose a method to make the KMS trust the vCenter based on the KMS vendor's 
requirements Once the trust is established, all replicas in the same KMS cluster will 
also trust the vCenter_ 
C) vCenter Root CA Certificate 
Download the vCenter root certificate and upload it to the KMS. All certificates 
signed by this root certificate will be trusted by the KMS 
C) vCenter Certificate 
Download the vCenter certificate and upload it to the KMS. 
C) KMS certificate and private key 
Upload the KMS certificate and private key to vCenter 
New Certificate Signing Request (CSR) 
Submit the vCenter-generated CSR to the KMS then upload the new KMS- 
signed certificate to vCenter. 
CANCEL 
NEXT
Make KMS trust 
vCenter 
1 Choose a method 
2 submit CSR to KMS 
Submit CSR to KMS 
Copy or download the CSR below, make it available to KMS, and have the KMS 
sign the certificate. 
..BEGIN CERTIFICATE REQUEST..... 
MllE5TCCAs0CAaAwczEhMB8GAIUEAmvYa21pcENsaWVudDlwMjAw0DA5MTAy0DMy 
MaswncaYDVOGGEwJVUzETMBEGAIUECAwK02FsaWZvcmspYTEPMAOGAIUECgwGV 
AOUAA41COwAwgglKAolCAODbUPS+jw9AG09pGOg2sgOdCa1n-mvJXVTA14xOSdrOV 
BFgu06A*CBRW61rsPSKaetu7x9mHlkogcscARfy9CEqkPHfntYp7RJNcJWEVBXb0 
WXKvS+Gfoex2jBNCASB/0kLuH+LWZwz6Kq0REmpeHDbHcsXNvjKN5x9DGckDUw 
ykgB9p2YuHom/lf6YiYMadA4C2kgPkeKGDSILJsvvmTG9PtxUlrhgatA400CD+cv 
FhT+tlgpUOV2MJFowadoFT6DgrWUgyg,'noWm10E9jicEm7dxxTNGVcNAmtynJRE 
xnlEYUhGGsNHyNb0GdA9RS2qjhDekNNRg7x6snZIC+pE/gaqNOJ5Zxx3X*lmalYE 
GENERATE NEW CSR 
copy 
DOWNLOAD 
@ The trust won't be established after you finish this wizard. Go to the 
KMS to upload the CSR, have the KMS sign the certificate, and upload 
it to the vCenter to establish the trust. 
CANCEL 
BACK 
DONE

Download the CSR using the option available.  This will be in the .pem format which is exactly what you need.

Now over to the HyTrust appliance, load the CSR we downloaded into the wizard, as well as a name, and hit create.  This is via the KMIP menu and selecting ‘Actions’ followed by ‘Create New Client Certificate’.

DASHBOARD 
Actions • 
TRUST 
H 
Valid From 
SECURITY 
Basic 
Client Certificates 
Objects 
AUDIT LOG 
Create a New Client Certificate 
Load File 
KMIP 
SETTINGS 
Certificate Name 
Expires In (day 
Certificate Name 
Certficate Name 
Certificate Expiration 
08/09/2021 
Certificate Signing Request (CSR) 
CSR needs to be in beseö4 encoded PKCS#IO 
Certificate Password 
Certificate Password 
Confirm Password 
Confirm Password 
Cancel

Once this is done, select the certificate and click ‘Actions’ and select the ‘Download Certificate’ option.  This again will come in the requested .pem format.

H 
TRUST 
Basic 
Client Certificates 
Object! 
Create Certificate 
Delete Certificate 
Delete All Certificates 
Download Certificate

Back to vCenter, we now need to upload the certificate using the ‘Establish Trust’ option and selecting ‘Upload Signed CSR Certificate’.

Provider By Trust Key Control - 
ESTABLISH TRUST v 
KMS trust vCenter 
Make KMS trust vCenter 
Upload Signed CSR Certificate 
vcenter Trust KMS 
Make vCenter Trust KMS 
Upload KMS Certificate 
Key Management Servers 
T 
Address 
5696 
Connection Status 
Client trusts server 
vCenter Certificate 
KMS Certificate 
@ Valid until: Dec 31, 2049

Once uploaded, you will see that the connection is now showing as connected and has a valid certificate.

Key Providers 
ADD STANDARD KEY PROVIDER 
Key Provider 
HyTrust Key Control (default) 
Provider By Trust Key Control - 
ESTABLISH TRUST s 
MAKE DEFAULT 
EDIT 
REMOVE 
T 
5696 
Connection Status 
@ Connected 
Certificates 
@ Valid 
items 
Key Management Servers 
T 
C) 
smt-lab-kms-01 
Address 
10200.15_15 
Connection Status 
@ Connected 
vCenter Certificate 
@ Valid until: Aug 9, 
2021 
KMS Certificate 
@ Valid until: Dec 31, 2049

This is now setup and ready to begin looking at VM and vSAN Encryption.  Check out the next post which will go into both these options in more detail.

Thanks for reading.

Configuring ESXi for iSCSI Storage Using PowerCLI

Configuring host VMKernel adapters for iSCSI can be a time consuming process. PowerCLI can take away a lot if not all of the effort.

Below is an example of using PowerCLI to create a Standard Virtual Switch (vSS), configure a VMKernel adapter, set the VLAN, enable the software iSCSI adapter (if that’s what you are using), bind it to the required network adapter and finally, add a dynamic Discovery target and rescanning the HBA’s.

This is based on targeting a single host at a time and re-running it with the paramaters for each host.

#Load PowerCLI Modules
Import-module VMware.PowerCLI

#Variables
#vCenter or Host to Connect to 
$vCenter = "smt-lab-vcsa-01.smt-lab.local" 
#ESX Host to target
$ESXHost = Get-VMHost "smt-lab-esx-01.smt-lab.local"
#Name of the iSCSI Switch
$iSCSISwitchName = "vSS_Storage_iSCSI"
#vmnic to be used for iSCSI Switch
$iSCSISwitchNIC = "vmnic2"
#MTU size
$MTU = "9000"
#Name of the Portgroup for the VMKernel Adapter
$iSCSIVMKPortGroupName = "vSS_VMK_iSCSI_A"
#iSCSI VMK IP
$iSCSIIP = "10.200.33.50"
#iSCSI VMK SubnetMask
$iSCSISubnetMask = "255.255.255.0"
#iSCSI VMK VLAN ID
$VLANID = "300"
#iSCSI Portal Target
$Target = "10.200.33.1:3260"

#Connect to vCenter
Connect-VIServer $vCenter -Credential (Get-Credential) -Force

#New Standard Switch for iSCSI
$NewSwitch = New-VirtualSwitch -VMHost $ESXHost -Name $iSCSISwitchName -Nic $iSCSISwitchNIC -Mtu $MTU
$NewPortGroup = New-VMHostNetworkAdapter -VMhost $ESXHost -PortGroup $iSCSIVMKPortGroupName -VirtualSwitch $NewSwitch -IP $iSCSIIP -SubnetMask $iSCSISubnetMask -Mtu $MTU
Set-VirtualPortGroup -VirtualPortGroup (Get-virtualPortGroup -VMhost $ESXHost | Where {$_.Name -eq $iSCSIVMKPortGroupName}) -VLanId $VLANID

#Enable Software iSCSI Adapter
Get-VMHostStorage -VMHost $ESXHost | Set-VMHostStorage -SoftwareIScsiEnabled $True

#Bind the iSCSI VMKernel Adapter to Software iSCSI Adapter (credit to Luc Dekens for this)
$esxcli = Get-EsxCli -V2 -VMHost $ESXHost
$bind = @{
    adapter = ($iscsiHBA = $ESXHost | Get-VMHostHba -Type iScsi | Where {$_.Model -eq "iSCSI Software Adapter"}).Device
    force = $true
    nic = $NewPortGroup.Name
}
$esxcli.iscsi.networkportal.add.Invoke($bind)

#Add Dynamic Discovery Target
$ESXHost | Get-VMHostHba $iscsiHBA | New-IScsiHbaTarget -Address $Target

#Rescan Hba
Get-VMHostStorage -VMHost $ESXHost -RescanAllHba

The results –

v Physical Adapters 
vmnic210000 Full 
VLAN ID: 300 
v VMkernel Ports (1) 
vmk3 :
Ad apter 
Model: 'SCSI Software Adepter 
e vmhbe65 
Type 
'SCSI 
Sta tus 
Onllne
Properties 
Devices 
Paths 
Dynamic Discovery 
Static Discovery 
VMkemeI Adapter 
vmk3 
Network Port Binding 
Addm X Remove Vlew Details 
Port Group 
Advanced Options 
Port Group Policy 
Compllant 
Path Status 
Actlve 
Physical Network Adapter 
vmn.c2 (10 Gblt's, Full)
Properties 
Devices 
Paths 
Dynamic Discovery 
Advanced___ 
Static Discovery 
Network Port Binding 
Advanced Options 
Addm X Remove 
iSCSI server

Something you may also want to do is set the Path Selection Policy (PSP) to the commonly used; ‘Round Robin’. The first command will provide a list of attached storage, showing you the CanonicalName (which is what you need for the second command), the current Multipathing Policy and the size of the storage device.

Identify the device you wish to set the pathing policy on and substitute the Canonical Name (naa.xxxx) into the second command.

#Get storage
$esxhost | Get-ScsiLun -LunType disk | Select CanonicalName,MultipathPolicy, CapacityGB

#Set Path Selection Policy (PSP)
$esxhost | Get-ScsiLun -LunType disk -CanonicalName naa.6589cfc0000004ac4d8f1fb0d7d02184 | Set-ScsiLun -MultipathPolicy "RoundRobin"

You could of course take this further by importing all the data required for multiple hosts using an array, whether as a a manually created array in PowerShell, or by importing a csv or txt file to enable you to configure numerous hosts at once by making use of a ForEach loop.

Now, if you are using Virtual Distributed Switches (vDS), here is an alternative (I have assumed you already have an operational vDS in place).

#Load PowerCLI Modules
Import-module VMware.PowerCLI

#Variables
#vCenter or Host to Connect to
$vCenter = "smt-lab-vcsa-01.smt-lab.local"
#ESX Host to target
$ESXHost = Get-VMHost "smt-lab-esx-02.smt-lab.local"
#Name of the vDS
$iSCSISwitchName = "smt-lab-dc01_vDS_01"
#Name of the Portgroup for the VMKernel Adapter
$iSCSIVMKPortGroupName = "smt-lab-dc01_vDS_VMK_iSCSI_B"
#MTU size
$MTU = "9000"
#iSCSI VMK IP
$iSCSIIP = "10.200.34.51"
#iSCSI VMK SubnetMask
$iSCSISubnetMask = "255.255.255.0"
#iSCSI VMK VLAN ID
$VLANID = "301"
#iSCSI Portal Target
$Target = "10.200.34.1:3260"

Connect-VIServer $vCenter -Credential (Get-Credential) -Force

#New VMKernel Adapter on vDS
$NewPortGroup = New-VMHostNetworkAdapter -VMhost $ESXHost -PortGroup $iSCSIVMKPortGroupName -VirtualSwitch $iSCSISwitchName -IP $iSCSIIP -SubnetMask $iSCSISubnetMask -Mtu $MTU
Set-VDPortGroup -VDPortgroup (Get-VDPortGroup | Where {$_.Name -eq $iSCSIVMKPortGroupName}) -VLanId $VLANID

#Bind iSCSI VMKernel Adapter to Software iSCSI Adapter (credit to Luc Dekens for this)
$esxcli = Get-EsxCli -V2 -VMHost $ESXHost
$bind = @{
    adapter = ($iscsiHBA = $ESXHost | Get-VMHostHba -Type iScsi | Where {$_.Model -eq "iSCSI Software Adapter"}).Device
    force = $true
    nic = $NewPortGroup.Name
}
$esxcli.iscsi.networkportal.add.Invoke($bind)

#Add Dynamic Discovery Target
$ESXHost | Get-VMHostHba $iscsiHBA | New-IScsiHbaTarget -Address $Target

#Rescan Hba
Get-VMHostStorage -VMHost $ESXHost -RescanAllHba

A slight change to the cmdlts used; PortGroup > VDPortGroup.

Here are the results –

v smt-lab-dc01_vDS_01_uplinks 
> Uplink 1 (1 NIC Adapters) 
VLAN ID: 301 
v VMkernel Ports (1) 
vmk4 : 10.200.34_SO 
Virtual Machines (O)
Properties 
Devices 
Paths 
Dynamic Discovery 
Static Discovery 
VMkemeI Adapter 
vmk3 
Network Port Binding 
Addm X Remove Vlew Details 
Port Group 
(smt-lab-dc01 
Advanced Options 
Port Group Policy 
Compllant 
Compllant 
Path Status 
Actlve 
Acuve 
Physical Network Adapter 
vmn.c2 (10 Gblt/s, Full) 
vmn.c3 (10 GblVs, Full)

There are now two paths to my iSCSI device, one via a Standard Switch (vSS) and one via a Distributed Switch (vDS) across two subnets.

Storage Devices 
Refresh Attach 
Detach 
Name T 
Rename___ 
Turn on LED 
Turn Off LED 
Target 
Erase Pertltlons___ 
disk 
disk 
cdrom 
disk 
disk 
disk 
Mark as HDD Disk 
Mark as Local Mark as Perennlally Reserved 
Capacity 
FreeNAS 'SCSI Disk (nee.658gcfc0000004ac4d8fifbOd7d02184) 
FreeNAS [SCSI Disk (nee.6589cfcOOOOOOcaf3bc8066g7077d193) 
Local NECVMWar CD-ROM 
Local VMware Dlsk 
Local VMware Dlsk 
Local VMware Dlsk 
25000 GB 
5000 GB 
1600 GB 
2500 GB 
17500 GB 
Data store 
smvlab-ds-vmf._ 
Not Consumed 
Not Consumed 
Not Consumed 
smt-leb-ds-vsa___ 
smt-leb-ds-vsa___ 
Operational 
Attached 
Attached 
Attached 
Attached 
Attached 
Attached 
Name 
Hardware Acceleration 
Supported 
Supported 
Not supported 
Not supported 
Not supported 
Not supported 
Properties 
Enable Dlseble 
Runtime Name 
Paths 
Partition Details 
Acuve (I/O) 
Active (1/0)

Hope this has been helpful. It has saved me plenty of time throughout the countless builds and tear downs of my VMware home lab.

Thanks

Centos Based Certificate Authority For The VMware Lab

A useful thing for a home lab or VMware lab, is a certificate authority. There are Windows based CA’s as well as Linux based and many others. I wanted to take the Linux based route for my home lab to give me some administration time in Linux, being that Windows is my safe place! After a bit of googling, I settled on Easy-RSA as it looked like it would do what I needed in the lab. There are already a few guides out there for this, but this is my take on it for use in my VMware home lab.

I settled on CentOS 8 as a base OS. Why? Why not, I don’t have any Centos VM’s and I decided it would be good to use something other than Ubuntu or Photon.

Firstly, I stood up a low resource VM (1 vCPU, 1GB RAM) giving it a static IP and creating an admin account.

I then kicked off the update of all the install packages on the OS by first elevating to the root account using ‘SU’ and then running the upgrade command for the DNF package manager.

dnf upgrade

This prompts a ~600MB download after confirming you want to continue. Once the download completes it gets on with upgrading.

Once done, its time to install some additional packages starting with epel-release, easy-rsa and openssl. Lets quickly give some background to each.

epel-release (Extra Packages for Enterprise Linux) is a repository of popular packages which aren’t available by default. easy-rsa is one of the packages in this repository.

easy-rsa This is a utility for managing Public Key Infrastructure(PKI) aka Certificate Authority. Check out some info here.

openssl A widely used tool, in this case to create Certificate Signing Requests (CSR). I’ll let you read about this here.

Lets get to the install. You can run them as separate installs like this –

sudo dnf install epel-release
sudo dnf install easy-rsa
sudo dnf install openssl

or as a one liner –

sudo dnf install epel-release easy-rsa openssl

Now for ease of administration, create a directory in the admin users home directory and create a symbolic link so it remains updated. You also want to limit access to your admin user in my case ‘ca_admin’.

mkdir ~/easy-rsa
ln -s /usr/share/easy-rsa/3/* ~/easy-rsa/
chmod 700 /home/ca_admin/easy-rsa

If you’re not familiar with chmod commands, ‘chomd 700’ = Protects a file against any access from other users, while the issuing user still has full access.

Now to initialise your new PKI. Change Directory (cd) to the easy-rsa directory you created in your admin users home directory and run the initialisation command.

cd ~/easy-rsa
./easyrsa init-pki

You will get a message showing it is complete and it will state the new pki directory that has been created inside the easy-rsa directory (/home/ca_admin/easy-rsa/pki)

You now need to create and populate a file called ‘vars’ in /home/ca_admin/easy-rsa and populate it with your organisation/lab information. You can achieve this with the vi editor.

set_var EASYRSA_REQ_COUNTRY "GB"
set_var EASYRSA_REQ_PROVINCE "Labshire"
set_var EASYRSA_REQ_CITY "Lab City"
set_var EASYRSA_REQ_ORG "Home Lab"
set_var EASYRSA_REQ_EMAIL "admin@lab.local"
set_var EASYRSA_REQ_OU "Lab"
set_var EASYRSA_ALGO "ec"(or rsa if you wish...)
set_var EASYRSA_DIGEST "sha512"

Once created, you are now ready to create the root certificate and private key by running the following command –

./easyrsa build-ca

You will be prompted to specify a passphrase which you need to keep safe as you will need it when issuing certificates. There will then be a second prompt to provide a common name; Enter you CA’s name. eg. CA01.

This process will have now created your root certificate and the private key (keep this safe). You will find them in the following locations /home/ca_admin.easy-rsa/pki/ca.crt (root certificate) and /home/ca_admin.easy-rsa/pki/private/ca.key (private key).

If you are using a Windows device to access your HomeLab, you are going to want to add the ca.crl file to the ‘Trusted Root Certification Authorities’ store on your Windows device so that any certificates issued are trusted. You can copy the ca.crt file using a tool such as WINSCP to transfer the file to a local directory to then install. You can do the equivalent on Mac and Linux OS’s too.

You will also need this handy for any certificates that require the full chain to be included.

I won’t go into every Certificate Signing Request (CSR) scenario as there are many. I will however, show you the commands needed to produce a certificate from a CSR.

To issue a certificate from a CSR, you will need to copy the .req or .csr file to a directory such as /tmp on your CA server, again using a tool like WINSCP.

You can then run the following commands to import the certificate signing request. The Common name is often the device name or FQDN.

cd ~/easy-rsa
./easyrsa import-req /tmp/<csr_file_name>.req <CommonName or FQDN> 
./easyrsa sign-req server <CommonName or FQDN>

The import command will import the .req or .csr file into /home/ca_admin.easy-rsa/pki/reqs (you can’t place the .req directly in here!) which is then processed by the sign-req command, again asking for the passphrase, leaving you with your new certificate in the /home/ca_admin.easy-rsa/pki/issued directory.

You can then use WINSCP again to transfer the file off the CA, and install it on the device or service in which you requested it from.

As always with any root CA, you don’t want it to become compromised. To help with this, keep it turned off when you’re not issuing, or administering your certificates.

I have also not included any Certificate Revocation List details as this isn’t something I need in my lab environment.

Now the VMware bit… below is the process for acquiring the CSR and installing the generated certificate on an ESXi host and a vCenter server using the methods above.

Standalone ESXi Host 6.7

First for a standalone ESXi Host, browse to – Host > Manage > Security & Users > Certificates

Select Import new certificate then select either ‘Generate FQDN signing request’ or ‘Generate IP signing request’.

You will be presented with a screen like this.

Copy this into a file with the extension .req. This can then be imported and issued using the method above.

Then, go back the the ‘Import new certificate’ wizard and import the certificate in the same format at the CSR into the box. (Open the .crt file using notepad)

Once complete close and open your browser and head back to your hosts web client and you will see you no longer have a certificate error.

vCenter Server 6.7

Log into your vCenter appliance using via SSH. Then run the following command –

/usr/lib/vmware-vmca/bin/certificate-manager

Select option 1, (you will be prompted to provide your SSO credentials), followed by option 1 again.

You will then need to provide the following information for the CSR.

As you complete the wizard you will have a .csr and a .key file in /tmp which again can be issued using the process above.

If using WinSCP you may hit the following error.

You will need to change over to the bash shell.

chsh -s /bin/bash root

You could then face another error…

root@vcsa02 [ ~ ]# chsh -s /bin/bash root
You are required to change your password immediately (password aged)
chsh: PAM: Authentication token is no longer valid; new one required

This is due to the password expiring. To change the password on the account run the passwd command

Further info on both of these errors can be found at these two VMware Articles. Here and here.

Once you have issued the certificate, you need to then copy the .crt file back to the /tmp directory along with the root certificate (or chain).

Now back to the Certificate Manager. Selecting option 1 to now import the certifictes. You will be prompted to provide the path and file name of each component. The certificate you created, the .key file that was created during the CSR generation and the root or CA chain certificate. Finally you will be asked to confirm you want to replace the Machine SSL certificate, type y.

It will take a few minutes, but eventually you will get confirmation that the task is complete and you can then reload your browser to see the Web Client is now showing a valid certificate.

Hope this has been useful. I will cover vCenter 7.0 Machine SSL certificate replacement in a future post.

Thanks for reading!

Configuring Encrypted vMotion With PowerCLI

Encrypted vMotion is a feature available in vSphere 6.5 onwards. It is something that is always used to secure vMotions of encrypted virtual machines, its a required option, but is optional for non encrypted virtual machines.

By default, non encrypted virtual machines will be set to ‘opportunistic’. If both the source and destination hosts support it (so ESXi 6.5 onwards), vMotions will be encrypted. If the source or destination does not support it, then the vMotion traffic will not be encrypted.

The ‘required’ option is exactly what it says, encrypted vMotion is required. If either the source or destination host does not support it, the vMotion will fail. As I’ve said, encrypted virtual machines have no choice, they have to use encrypted vMotion.

The final option is to set it to ‘disabled’, for when you don’t want it to even attempt encrypting vMotion traffic for a virtual machine.

To set this option on either a singular virtual machine or all virtual machines, you can use the options below. Firstly to view the current settings you can run this. If you want to target a single VM enter the VM name after Get-VM.

Get-VM | Select-Object Name, @{Name="vMotionEncrpytion";Expression={$_.extensiondata.config.MigrateEncryption}}
Name vMotionEncrpytion
---- -----------------
CentOS opportunistic
vRepDR opportunistic
vcsa01 opportunistic
pho01 opportunistic

Now to change these all to ‘required’ you can run the following:

$VMView = Get-VM | Get-View
                    $Config = New-Object VMware.Vim.VirtualMachineConfigSpec
                    $Config.MigrateEncryption = New-Object VMware.Vim.VirtualMachineConfigSpecEncryptedVMotionModes
                    $Config.MigrateEncryption = "required"
            $VMView.ReconfigVM($Config)

You can confirm this by re-running the get command:

Name vMotionEncrpytion
---- -----------------
CentOS required
vRepDR required
vcsa01 required
pho01 required

To set them back to opportunistic, use the following:

$VMView = Get-VM | Get-View
                    $Config = New-Object VMware.Vim.VirtualMachineConfigSpec
                    $Config.MigrateEncryption = New-Object VMware.Vim.VirtualMachineConfigSpecEncryptedVMotionModes
                    $Config.MigrateEncryption = "opportunistic"
            $VMView.ReconfigVM($Config)

As you can see, they are then back to the default setting.

Name vMotionEncrpytion
---- -----------------
CentOS opportunistic
vRepDR opportunistic
vcsa01 opportunistic
pho01 opportunistic

And finally, setting it to ‘disabled’:

$VMView = Get-VM | Get-View
                    $Config = New-Object VMware.Vim.VirtualMachineConfigSpec
                    $Config.MigrateEncryption = New-Object VMware.Vim.VirtualMachineConfigSpecEncryptedVMotionModes
                    $Config.MigrateEncryption = "disabled"
            $VMView.ReconfigVM($Config)
Name vMotionEncrpytion
---- -----------------
CentOS disabled
vRepDR disabled
vcsa01 disabled
pho01 disabled

Here is a link to the official documentation on Encrypted vMotion for further information – here.

Thanks for reading!

Creating Virtual Distributed Port Groups Using PowerCLI

I recently needed to create a new Distributed Port Group and set a specific load balancing policy on an existing Distributed Switch. Nothing to exciting, but a task many have to complete. As this is a common repeatable task, i put together this short .ps1 to allow a repeatable way of completing this.

You can find the file here on GitHub

Just populate the Variables section with required information like so…

Save the file, then run the the .ps1 file from PowerShell prompt. (Ensure you have the PowerCLI Module installed; see my previous post)

Note you must add .\ to the beginning of the file name if you are executing the file from the directory you’re already in

Enter credentials with sufficient privilege in vCenter.

You will then see an output similar to this:

If you now take a look in the Web Client you will see the freshly created Distributed Port Group.

Creating just a single portgroup could potentially be quicker in the Web Client. What isn’t quicker, is multiple.

If you have a requirement to create multiple Distributed Port Groups on a vDS, you can use this script to do so in one go.

Just populate the Variables section with required information like above, then run the the .ps1 file from a PowerShell prompt. (Ensure you have the PowerCLI Module installed; see this post.

This uses and Array Table to build your source data, in this example, the PortGroup Name and VLAN ID for each. You can add further rows (more Port Groups) to the array by repeating the line in the red box, or add additional attributes by repeating the text from the green box on each line.

There are many ways you could modify this script to change the source of data, including ‘Get-Content’ from a .txt file for instance.

You can get the script here.

This is just one way to create Port Groups using PowerCLI, have a play around and make it work for you!

Thanks for reading.

« Older Entries