Friday, September 21, 2018

VCP 6.5 Delta Exam experience

The dreadful reminder of imminent VCP expiration came again. I had already decided to take the VCP delta exam called 2V0-622, without actually doing it. But this time I was prepared. Having happily paid exam fee (using my VMUG Advantage discount), I was waiting for the day to come. It came and passed pretty fast and I did pass the exam.

Must admit I was a bit scared, but it is a delta exam and if you are using the technology on a daily basis then you can't have a lot of surprises. It didn't seem to be a difficult exam to take. Maybe having delivered the ICM 6.5 a few times in my life, had helped. However, I would like to point out several aspects about how I prepared for the exam:

  • never forget configuration maximums - I failed one question because I did not read them properly
  • it is a delta exam - so what's new is important especially since 6.5 was more like a major release bringing in VMFS6, security features, NFS 4.1 and other goodies. If you don't use the features in your production environment, stand up a nested ESXi and play with them a bit (of course, always read the manual)
  • features you don't use in production on day to day basis (let's say VSAN), read the manual
  • use a practice mock exam to help you find your weaknesses and study more (this one from Simon Long is pretty cool)
  • lastly, if you don't know an answer, start and use your logic and what you know to eliminate the wrong answers. This method may lead to finding the good answer
For all of you thinking about  taking the exam, good luck! 

Saturday, September 15, 2018

Secure Boot and Acceptance Levels of Hosts and VIBs

Acceptance levels of VIB  provide an information on the amount of certification the software package has undergone. There are four levels of acceptance for VIBs:

  • VMwareCertified - most stringent requirements equivalent to VMware in-house Quality Assurance testing. Only I/O Vendor Program (IOVP) program drivers are published at this level.VMware takes support calls for VIBs with this acceptance level
  • VMwareAccepted - partner runs the tests and VMware verifies the result. VMware takes support calls for VIBs with this acceptance level.
  • PartnerSupported - The partner performs all testing. VMware does not verify the results. VMware directs support calls for VIBs with this acceptance level to the partner's support organization.
  • CommunitySupported - is for VIBs created by individuals or companies outside of VMware partner programs. They are not supported by VMware or partners.

Why is this interesting for us? Mostly because of the relationship between secure boot and the acceptance level. Secure boot does not allow to set the acceptance level to CommunitySuported. This makes perfect sens, why would you want to install a VIB that is created by someone outside the trusted partner program. Two answers come to mind: home labs and testing.

With secure boot enabled (which is default for VMs created with UEFI in vSphere 6.5 U1) you will notice the following behavior when trying to set the acceptance level:


In order to be able to set the desired acceptance level, you should disable secure boot. If it's a physical server, then you need to do this in UEFI. For VMs, it can be done at VM level, but still needs a power off and then select the VM and edit settings. On VM Options tab, under Boot Options you will find the setting for Secure Boot.


If you are connecting to vSphere 6.5, use web client since HTML one does not show the option.


Wednesday, September 5, 2018

Installing Veeam Backup for Microsoft Office 365 on Windows Server 2016 Core

Windows Server 2016 Core is a minimal installation that has a smaller footprint which translates to a smaller attack surface. Having security in mind, it make perfect sense to use Core for deploying server components on it.

Veeam Backup for Microsoft Office 365 (VBO365) allows to back up and recover Microsoft Office 365 and on-premises Exchange and SharePoint organizations data containing Microsoft Exchange items, Microsoft SharePoint items, and OneDrive documents.

VBO365 is made of several components:
  • VBO365 server 
  • console
  • SharePoint explorer
  • Exchange explorer
  • PowerShell extensions
Since VBO365 is modular and since it needs Internet access, it can be installed on separate machines. In our case, we'll install server and PowerShell extension on a Windows Server 2016 Core situated in DMZ and the console and explorers on the admin workstation in the management area. Repository space will be provisioned on the local disk of VBO365. 


First, we start by deploying a virtual machine with Windows Server 2016 Core installed on it. The VM is deployed from a template created previously. To create the template do the follwing:
  • configure a VM with 1 vCPU, 512 MB of RAM and 32 GB of disk
  • upload the Windows iso file on a datastore
  • attach the VM CDROM to the iso file
  • start the VM and follow the installation steps - basic Windows install, just choose the Windows install without Desktop Experience
  • enter the license key and wait for the install to finish
For a step-by-step guide, you may look at this blog post

Remember that Core installation is minimal and restrictive. Hence you would need to enable remote administration and file sharing. This can be done either by using netsh commands or PowerShell.

PowerShell
1
2
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Enable-NetFirewallRule -DisplayGroup "File and Printer Sharing"

netsh
1
2
netsh advfirewall firewall set rule group=”Remote Desktop” new enable=Yes
netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=Yes

Once the VM has been installed and configured, convert it to a template. Create a customization specification in vCenter Server and deploy a VM from the template. Before powering on the new VM, resources as demanded by VBO - in a very strict lab environment you could start with 2 vCPU and 4 GB of RAM. 

It's now time to install VBO365. The distribution package is made of 3 msi files:
  • Veeam Backup for Microsoft Office 365
  • Veeam Explorer for Microsoft Exchange
  • Veeam Explorer for Microsoft SharePoint
Since we will install separately the server and the explorers, we need to transfer only server msi file. Copy the file to a share on the virtual machine. Then logon to the server and in cmd prompt change location to where the installer has been copied. To install VBO365 server from command line, run the following command:

1
msiexec /i "Veeam.Backup365_2.0.0.567.msi" /qn ADDLOCAL=BR_OFFICE365,PS_OFFICE365 /L*V "vbo365.log"

This will install only server (BR_OFFICE365) and PowerShell extension (PS_OFFICE365). The install will not show any prompt (/qn) and it will log everything to vbo365.log file in the same folder with the install file.

During installation monitor the log file. Once the install is completed successfully, you will see the following lines at the end of the file:

1
2
MSI (c) (E8:C0) [22:10:14:349]: MainEngineThread is returning 0
=== Verbose logging stopped: 8/29/2018  22:10:14 ===

We need to do two more tasks before moving to installation on admin workstation:
  • check services are runing
  • open firewall ports
To check the services are running, type the following command in PowerShell:

1
Get-Services "Veeam*" | Format-List

You should see the following output:


If any service is not running, you may enable and start it:

1
2
Set-Service -Name "Veeam.Archiver.RestFul.Service" -StartupType Automatic 
Start-Service -Name "Veeam.Archiver.RestFul.Service"

To enable firewall ports for the 3 services, run the following:


1
2
3
New-NetFirewallRule -DisplayName "Open Port 9191" -Direction Inbound -LocalPort 9191 -Protocol TCP -Action Allow
New-NetFirewallRule -DisplayName "Open Port 9194" -Direction Inbound -LocalPort 9194 -Protocol TCP -Action Allow
New-NetFirewallRule -DisplayName "Open Port 4443" -Direction Inbound -LocalPort 4443 -Protocol TCP -Action Allow

It's time to logon to admin workstation where console and explorers will be installed. Transfer all 3 msi files to admin workstation, open a command prompt, change folder to msi path and run the following commands one by one (not all at the same time):

1
2
3
msiexec /i "Veeam.Backup365_2.0.0.567.msi" /qn ADDLOCAL=CONSOLE_OFFICE365,PS_OFFICE365 /L*V "vbo365-console.log"
msiexec /i "VeeamExplorerForExchange_9.6.3.567.msi" /qn ADDLOCAL=BR_EXCHANGEEXPLORER,PS_EXCHANGEEXPLORER /L*V "vbo365-vex.log"
msiexec /i "VeeamExplorerForSharePoint_9.6.3.568.msi" /qn ADDLOCAL=BR_SHAREPOINTEXPLORER,PS_SHAREPOINTEXPLORER /L*V "vbo365-vsp.log"

We are ready to connect to VBO365 and start configuring it. But this, in the next post. 

Saturday, August 18, 2018

Adding Realtek 8111 driver to vSphere 6.7 image

While reinstalling home lab with vSphere 6.7, I was remembered (the hard way) that my on-board NIC is based on Realtek 8111 chipset which is not included in the default vSphere installation media.

I had to go accept the challenge of finding the drivers and creating a new bootable vSphere ISO. Nothing I haven't done before, but since it is not often I've decided to make it a blog post.

First I needed to find the drivers. Using a bit of google foo I found the blog of a long time vExpert (thank you) which has also a collection of drivers. I've downloaded the net55-r8168 offline bundle . From VMware site I've downloaded offline bundle for vSphere 6.7. Placed both of them in the same folder and opened a PowerCLI prompt.

First, create a new software depot using the two bundles:

1
Add-EsxSoftwareDepot "C:\7_KIT\VMW\net55-r8168-8.045a-napi-offline_bundle.zip", "C:\7_KIT\VMW\VMware-ESXi-6.7.0-8169922-depot.zip"

Next, create a new image profile: see what profiles exist, clone one and change its acceptance level to "community" (because the driver I am about to load is community signed):

1
2
3
Get-EsxImageProfile
New-EsxImageProfile -CloneProfile ESXi-6.7.0-8169922-standard -name ESXi-6.7.0-8169922-standard-RTL8111 -Vendor Razz 
Set-EsxImageProfile -ImageProfile ESXi-6.7.0-8169922-standard-RTL8111 -AcceptanceLevel CommunitySupported

Add the driver to image profile:


1
2
Get-EsxSoftwarePackage | Where {$_.Vendor -eq "Realtek"}
Add-EsxSoftwarePackage -ImageProfile ESXi-6.7.0-8169922-standard-RTL8111 -SoftwarePackage net55-r8168

Lastly, generate the vSphere 6.7 ISO containing the driver:


1
Export-EsxImageProfile -ImageProfile ESXi-6.7.0-8169922-standard-RTL8111 -ExportToIso -filepath C:\7_KIT\VMW\VMware-ESXi-6.7.0-8169922-RTL8111.iso

In one picture, it looks like this:

One more step is needed. Since we have the ISO, we just need to write on a bootable USB. To do this, I've downloaded Rufus, portable version. Run the software, select destination a USB stick (it will be overwritten so better not having any useful data on it), selected the source my new ISO and pressed start.

If during the creation of the bootable stick you are asked to update menu.c32, press YES. After it finishes I've plugged the stick in my physical box and happily installed ESXi.

Update:
File download test reached 800 Mbps, a normal value keeping in mind the connectivity between my laptop and the ESXi host.

Friday, August 3, 2018

vExpert Program "You're in!"

I have the bad habit of waking up and immediately reading e-mails on my phone. This time I was in for a great surprise that put a smile on my face. I got accepted to vExpert program.

I consider it to be both an honor and a responsibility. I know my blogging is not as frequent as I wish to. And together with VMUG co-leaders we are striving to make VMUG meetings fun and interesting. The only thing I can do is to keep on giving back to community and make it better each time and hoping to see more and more people at VMUG Romania meetings.

So, thank you for this amazing ride (so far). And a special thanks to Constantin Ghioc (Titi) and Jorge de la Cruz for determining me to apply to the program.

My profile on vExpert Directory is here .

Saturday, June 30, 2018

VMware BIOS UUID, vCloud Director and Veeam Agent

Looking at the title it may seem a long and complicated story. Actually is a very simple one. While working in lab which is hosted by a vCloud Director (vCD) instance, I was testing a SQL Always ON Cluster and the Veeam Agent for Windows. I've created my 3 node cluster, installed the database, configured availability groups.  All went well until I tried to install the Veeam agent. This stopped with the error that  the same UUID was being utilized by all 3 nodes.

Well, all 3 VMs were deployed from the same vCD catalog VM. According to this VMware KB article, by default vCD keeps the same UUID value for cloned VM's. Since I did not have access to vCD to change the settings, the only choice was to actually modify the UUID of the VMs.

There are several ways of doing in it, from manual to programmatic (as can be seen in this KB article)

I've chosen PowerCLI variant. The steps are pretty straight forward:
  • shutdown the VM
  • get the current UUID
  • change the UUID
  • power on the VM

And the code to do it below. Do not forget to change the $newUuid (I used to modify the last digits from the current one).


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
$vmName = "myClonedVm"
$vm = Get-VM -Name $vmName

$vm.extensiondata.config.uuid
$newUuid = "00112233-4455-6677-8899-aabbccddeeff"

$vm | Shutdown-VMGuest
While ((Get-VM -Name $vmName).PowerState -ne "PoweredOff") {
  Write-Host -foreground yellow "... waiting for" $vmName "to power off"
  sleep 5
}

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.uuid = $newUuid
$vm.Extensiondata.ReconfigVM_Task($spec)

Start-VM -VM $vmName -RunAsync

Thursday, June 14, 2018

Automating NSX with PowerShell and RESTful API

Often, there are situations when one needs to do the same actions over and over again. System admins solved this repetitive tasks by scripting them. Scripting languages were however limited to the operating system or in some cases to a middleware application. New applications provide RESTful APIs that extend the power of scripting languages from the OS level to virtually every application available in the infrastructure. Using RESTful APIs one can create complex workflows that execute orchestrated actions on different applications. This brings a new word into the vocabulary: automation.

Let's take a simple example - new developer is hired and needs a dedicated dev and test environment. We are using VMware vSphere and NSX to provide that environment. Because we don't want to interfere with other environments, we want to isolate it. For isolating environments at network level we can use Edge Services Gateway (ESG) and dedicated VXLAN. At vSphere level we need to control resource consumption. If there is vRealize Automation or vCloud Director, these tasks can be easily automated from the GUI. What is there is no Cloud Management Portal, or the one the exists is not integrated with NSX and vSphere. Then we need to go back to scripting language.

In this post we'll take a look at how to call NSX RESTful API using PowerShell. There are languages that can be used: ruby, perl, python, JavaScript, depends on the preference. There is also a PowerShell extension for NSX called PowerNSX. The scope of the post is to see how we can use PowerShell to consume RESTful APIs (as the principles will apply to any API) using NSX.


Before we begin, a few words about the environment. I am using PowerShell 6.0.1, downloaded latest stable version from GitHub. The reason for doing this is that in version prior to 6.x there are issues with getting PowerShell methods to trust self signed SSL certificates. In 6.x you can add  -SkipCertificateCheck parameter to both Invoke-RestMethod and Invoke-WebRequest to accept self signed certificates.



Any RESTful API connection needs to be authenticated. Let's create the authentication header that will be sent with the request. We need to get the username and password and encode it to Base 64 string. The password can be simply put as a string in code, but I would like to complicate things and request the password from the user as a secure string (characters masked with star symbols)

1
2
$username = "nsxAdmin"
$securedValue = Read-Host "Enter password" -AsSecureString

After we get the password, we need to decrypt the secure string from unmanaged memory and write it in a string variable. We use the following methods: PtrToStringAuto and SecureStringToBSTR.

1
2
$password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($securedValue))
$userpass  = $username + ":" + $password

We encode the username and password to Base64 and create the header.

1
2
3
4
5
$bytes= [System.Text.Encoding]::UTF8.GetBytes($userpass)
$encodedlogin=[Convert]::ToBase64String($bytes)
$authheader = "Basic " + $encodedlogin
$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Authorization",$authheader)

Lastly we create the URI (will get existing edges) and run the query. The output will be sent to a XML file.


1
2
3
$uri = "https://nsx-manager/api/4.0/edges"
$outXml = $baseFilePath + 'allEsg.xml'
Invoke-RestMethod -Uri $uri -Headers $headers -Method 'GET' -OutFile $outXml -SkipCertificateCheck

We have the XML file with all existing edges. Let's get vnic configuration for each edge. First we load the XML file and look for edge child nodes - pagedEdgeList.edgePage.edgeSummary. For each edge we find, we use the objectId to query the API for its vnics and put that result into a file.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
$esgObjectArray = @()
[xml]$config = Get-Content $outXml
foreach ($esg in $config.pagedEdgeList.edgePage.edgeSummary) {
  $esgObject = New-Object PSObject -property @{Id=$esg.objectId;Name=$esg.name}

  $uri = 'https://nsx.eudemo.veeam.local/api/4.0/edges/' + $esg.objectId + '/vnics'
  $outXml = $baseFilePath + $esg.objectId + '-vnics.xml'
  try {
    Invoke-RestMethod -Uri $uri -Headers $headers -Method 'GET' -OutFile $outXml -ea stop -SkipCertificateCheck
  }
  catch {
    Write-Host $_ -foreground green
  }

  $esgObjectArray += $esgObject
}

Within the foreach loop we are creating an array ($esgObjectArray) that contains the edge id and the edge name. $esgObject object is used to get the parameters for each iteration of the loop and add them to the array. This will be used to get the IP addresses for each edge and export all in a CSV file.

The variable $baseFilePath can be any destination on your local system where you want to place output files (e.g "D:\scripts\myEsgConfig\").

Finally we'll export edge ID, edge name and its IP addresses to a csv file. We'll loop through $esgObjectArray and get the information from the saved xml configuration files for each edge (-vnics.xml files):


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
$esgVnics = @()
foreach ($esg in $esgObjectArray) {
  $outXml = $baseFilePath + $esg.Id + '-vnics.xml'
  if (Test-Path -Path $outXml) {
    $vnics = ""
    $item = ""
    [xml]$config = Get-Content $outXml
    foreach ($interface in $config.vnics.vnic) {
      $vnics += "," + $interface.addressGroups.addressGroup.primaryAddress
    }
    $item = $esg.Id + "," + $esg.Name + $vnics
    Write-Host $item
  } else { continue}
  $esgVnics += $item
}

$esgVnics | foreach { Add-Content -Path  $csvFile -Value $_ }

In the end we'll get a CSV file with the following format:

As you've seen, we used Invoke-RestMethod to query the API and saved the results in XML files for later use. You can use other REST methods like PUT, POST or DELETE to manage NSX environment. In the end it is all about manipulating creating and manipulating XML/JSON content to do the operations from command line .