Upgrade

Approach to updating a horizon infrastructure

fabio1975, , , Leave a comment

When approaching the upgrade of an infrastructure in the EUC world (as with most technologies in the IT world) it is necessary to define a roadmap of activities and follow it carefully. In many cases, IT technology vendors already have update procedures in place that should be followed carefully. When I started working as a consultant, the documentation was very scarce (we are talking about the end of the 20th century and the beginning of the 21st…) and the procedures were poorly documented and only those who took courses or had experience could approach with a certain “tranquility” updates of production environments.

Going back to EUC infrastructures and focusing on the VMware by Broadcom world (still for a while….given the transfer of the technology in question) we have a precise update sequence, especially if we talk about + technologies that interact with each other, and the need to verify the interoperability between the various technologies.

For example, we have this KB that gives us the upgrade sequence of a Horizon 8 infrastructure:

Update sequence for Horizon 7, Horizon 8, and compatible VMware products (78445)

A diagram of software Description automatically generated

And the ability to use the interoperability portal:

https://interopmatrix.vmware.com/Interoperability

A screenshot of a computer Description automatically generated

In my ten-year experience in updates and maintenance of vSphere and Horizon infrastructures, it has often happened that I have had to intervene and manage post-upgrade problems, where in most cases the problems were generated by the fact that I did not perform the update in the correct order or even did not complete all the upgrade steps.

For example, I have experienced situations where, following upgrades, the copy and glue to and from VDI sessions no longer worked correctly in a Horizon infrastructure.

In the end, the problem was solved by also performing the update step of the Horizon ADMX templates in Active Directory, something that the customer or whoever had done the update for him had not done.

Approach to updating a horizon infrastructure

Steps for Upgrade Horizon 23xx to the next version

fabio1975, , , , , Leave a comment

The release of new versions of VMware Horizon 8 each quarter of the year (to provide new features and resolve any security holes) entails the need to have a consolidated, conservative update procedure with the least impact on users.
Below I report the procedure that I am using successfully.

User impact:

  • Users already connected to the VDI do not encounter problems or disconnections
  • Users who need to connect during update activities may have problems (normally a maintenance window is declared)

Steps

  • Restarting the Connection Servers Operating System (One at a time is a step preparatory for committing any pending Windows updates), after each reboot check from the Horizon web console that everything is ok
  • Disable Provisioning
  • Shut down all three Connection Servers
  • Snapshot of the VMs hosting the Server connection
  • Turn on the Connection Server (One at a time), after each reboot check from the Horizon web console that everything is ok
  • Backup DB Adam (C:\Program Files\VMware\VMware View\Server\tools\bin\vdmexport.exe > vdmconfig.ldf)
  • Disable and Updating one Connection Server ( disabling the Connection Server being updated puts the connection server offline for the load balancer on the top of the connection servers and it is not used for authenticating users and assigning VDI) and after upgrade enable the Connection Server.
  • Repeat the previous step for all Connection Servers
  • If necessary, reapply the customizations
  • Check from the console that everything is ok

After the horizon upgrade, test the Desktop Pool:

  • Try a connection from internal
  • Try a connection from external
  • Delete a VDI machine
  • Publish a new Master Image

For upgrading three Connection servers all steps necessity of two hours
During the activities, the users connected to the VDI do not encounter any problems

The next step, after complete the Connection Servers upgrade, is to update the Horizon agent on the master image and delete the Connection Servers snapshot

Steps for Upgrade Horizon 23xx to the next version

Prechecks fail during upgrade to vCenter Server 7.0 with the following message “The source appliance FQDN must be the same as the source appliance primary network identifier”

fabio1975, , , Leave a comment

When upgrading vCenter 6.5x to version 7u3x we encountered the following problem

Text Description automatically generated

Following this KB

Upgrading to vCenter Server 7.0 fails when case differs between FQDN and PNID (84355) (vmware.com)

We identify the problem in the fact that we have the hostname that differs from the PNID because one is all uppercase and the other lowercase.

From the following KB we find that we can not on vCenter 6.5 updatethe hostname

Cannot change the vCenter Server or Platform Service Controller 6.x hostname on versions prior to vCenter Server 6.7 Update 3 (2130599) (vmware.com)

To solve we proceed first with the update to the version of vcenter 6.7u3 that fixes the part of FQDN

Graphical user interface, text Description automatically generated

Once updated to 6.7 relaunch the commands indicated by KB and see that the PNID and hostname coincide

Then we update to the vCenter version 7u3

Prechecks fail during upgrade to vCenter Server 7.0 with the following message “The source appliance FQDN must be the same as the source appliance primary network identifier”

Upgrade Unified Access Gateway

fabio1975, , , , Leave a comment

VMware Horizon infrastructures often have the Unified Access Gateway (UAG) component to enable a secure connection from outside your corporate network to VDI.

This positioning makes the UAG subject to frequent updates, today we will see how to update it.

Download the ISO file of the version we want to update from the VMware Customer Site:

File Information Unified Access Gateway 2203 for vSphere, Amazon AWS and Google Cloud (Non-FIPS) DOWNLOAD NOW File size: 2.63 File type: Ova Read More Unified Access Gateway (UAG) 2203 for vSphere (FIPS) DOWNLOAD NOW File size: 2.14 Ga File type: ova Read More Unified Access Gateway WAG) 2203 for Microsoft Azure DOWNLOAD Now File size: 2.54 GB File type: zip Read More Unified Access Gateway WAG) 2203 PowerShell Scripts DOWNLOAD NOW File size: 79.4 KB File type: zip Read More MDS checksums. SHAI checksums and SdA256 checksums

Check compatibility with your Horizon infrastructure:

Product Interoperability Matrix (vmware.com)

Add to My Favorite List Hide Interoperability Compatible IV Incompatible Com*tible Put End of a Put End of Not S upgnrted VMwere Horizon 2111 2106 2103 2012 T 132 - VMwere Horizon 7 713 1 - VMwere Horizon 7 T 13 0 - VMwere Horizon 7 Hide Legacy Releases O Past End ot General Support Past End at Technical Guidance VMware Unified Access Gateway 2203 and 21112 and 2111.1 and 2106.2 and 2103.1 and 2103 2012 and 2009 3.10

Download the INI file containing the current UAG configuration

  • Access the Unified Access Gateway interface
    • HTTPS://<fqdnUAG>:9443

Using the credentials of the admin user

or VMware Unified Access Gateway dmin Username Admin Password Login

Once logged in, download the .ini file

A picture containing chart Description automatically generated

OCSP Settings Support Settings Support Settings Edge Service Session Statistics Log Archive Log Level Settings Export Unified Access Gateway Settings

Retrieving the information needed to complete the configuration file:

  • Certificate for public access and password
  • Certificate for the admin center and its password
  • SAML component XML if integration with AZURE MFA
  • Information on where to deploy (vCenter, Cluster, virtual network, datastore ) the Virtual Appliance of the new UAG

The data indicated will serve me to fill in the fields of the downloaded ini file

Notepad File Edit Format [General] netlnternet= View Help ipø=192.168.247.54 diskMode= ip1=192,168,246.54 defaultGateway=192.168.247.1 target= ds= routes 2.168.246.1,192.168.4.0/24 192.168.246.1,172.25.2.0/23 192.168.246.1,172.25.6 netmaskØ=255.255.255. or netManagement etwor net3ackendNetwork • pØA110cationMode=STATICV4 name= deploymentOption=twonic forceNetmaskØ=255.255.255. or forceNetmask1=255.255.255. or

I summarize the info required in this table

Sector Field Description
General netInternet PortGroup on which to certify the network card that communicates to the internet world *
General diskmode Thin or Thick
General Source Absolute path where the ISO resides
General Target Path of the vSphere infrastructure where we will deploy the virtual appliance
General Ds Datastore where the VM will be created
General netManagementNetwork Portgroup on which to certify the network adapter for UAG management *
General netBackendNetwork Portgroup on which to certify the network adapter for UAG management *
General Name Virtual Machine Name
General uagName Hostname of the UAG (normally to be left that of the UAG to be replaced)
SSLCert pfxCerts Property Path where the SSL Certificate generated by a public CA in password protected PFX format used to access VDI by Horizon Clients resides
SSLCertAdmin pfxCerts Property Path where the SSL Certificate generated by a CA (normally Microsoft and Private) used to secure and validate access to the UAG Management Interface resides
IDPExternalMetadata1 metadataXmlFile Property XML file of the Identity Provider (In this case Azure AD) to enable Azure MFA for access

*VMware recommends at least two network adapters in two different segments for production environments

  • One for internet traffic (I call it the EXT-DMZ)
  • One for traffic to the internal LAN (I call it the INT-DMZ)

It is possible to create environments with 1 or 3 network adapters, in the first case VMware recommends only one card only for test environments, and in the second to also differentiate the management traffic that otherwise, in the two-card configuration would pass through the card that communicates with the internal LAN.

Notepad File Edit Format View Help l[Generate1] net Internet—DPG - EXT•4Zjjj) ipe=192.168.247.55 diskMode—thick source—E : - unified - access - gateway- 22.03. 1955Ø 91_OVFI Ø. Ova ip1=192,168,246.55 default-Gateway=192.168.247.1 target—vi : / /vcaØ7 ds=vsanDatastore routes1=172.16.e.Ø/16 192.168.246.1,192.168.4.0/24 192.168.246.1,172.25.2.0/23 192.168.246.1,172 netmaskØ=255.255.255. and netManagementUetwork net8ackendNetwork=DPG - INT - C*IZ ipeA110cationMode=STATICV4 name-VilJAGØ3-22Ø3 deploymentOption=twonic forceNetmaskØ=255.255.255. and forceNetmask1-255.255.255. and ip1A110cationMode=STATICV4 net-maski=255,255,255. and authenticationT imeout—3ØØØØe fipsEnab1ed—fa1se sys L ogType=UDP uagName=viuage3 clockSkewT01erance=6Øe

At this point we can proceed with the deployment of the virtual appliance:

  • The first step is Shutdown the old UAG Virtual Appliance (I suppose do you have at least two UAGs with a Load Balancer in front and at least a DNS round-robin for balancing the traffic to the Connection server)

.\uagdeploy.ps1 -iniFile UAG_Settings_VIUAG04.ini

Administrator: Windows PowerShell uag ep oy2203> uag ep oy. PSI

Allow CEIP

Insert password for PFX Certificate File

Insert a new (or reuse the old) password for the Root account (for access to UAG OS) and Admin account (for access to UAG WEB admin console)

Waiting to complete the UAG Deploy (You can check the process from the vCenter task)

Now the new UAG virtual appliance is up and running!! Test it and apply the same step for all UAG virtual appliances of your VMware Horizon Infrastructure.

Upgrade Unified Access Gateway

Upgrade Standalone ESXi 7.0 to 7.0b

fabio, , , , , , , Leave a comment

 Check ESXi version:

Check on https://my.vmware.com/group/vmware/patch if there are new patches

There is a new patch (7.0b), download it

After download upload file to ESXi host

Create a SSH connection to ESXi Host

Put in maintenance mode

esxcli system maintenanceMode set --enable true

Update Host 

esxcli software vib update -d /vmfs/volumes/5ed278ae-6001ab57-ac5b-1c697a61ab69/ISO/VMware-ESXi-7.0b-16324942-depot.zip

and finally

After reboot the version is:
exit to maintenance mode….
#####

or update from internet

esxcli software profile update -p ESXi-7.0b-16324942-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Upgrade Standalone ESXi 7.0 to 7.0b

AKS – Aggiornamento in arrivo a inzio Luglio

fabio, , , , , , Leave a comment

Come ogni 3 Mesi sono in arrivo degli aggiornamenti per il servio AKS (Azure Kubernetes Services):

  • Nuova versione la 1.17  disponibile dal 1 Luglio (Sempre da quella data non saranno più in supporto le versioni 1.14)
  • L’annuncio che a breve verranno rilasciati i nodi AKS con ubuntu 18.04 (Una volta rilasciata la nuova versione dei nodi tutti i successivi aggiornamenti di AKS si porteranno dietro anche l’aggiornamento di versione di Ubuntu)
Tutti i dettagli in questo link
AKS – Aggiornamento in arrivo a inzio Luglio

AKS upgrade come verificare se dobbiamo aggiornare

fabio, , , Leave a comment

Cluster Kubernetes, ormai sappiamo tutti di che cosa stiamo parlando.

Questa tipologia di cluster possiamo trovarla in tanti ambienti.. Cloud o on-prem, su VMware ecc.

Come tutte le infrastrutture si devono però mantenere ed è molto importante tenerle aggiornate …anche sotto questo aspetto l’idea del “funziona e quindi perchè aggiornarla” è ormai obsoleta.

 

Mi è capitato ultimamente di confrontarmi con la soluzione AKS (Azure Kubernetes Services) ed essendo un servizio PaaS  è necessario rimanere al passo delle versioni che Microsoft rilascia per il suo cloud.

 

Quindi entriamo nel dettaglio:

 

Ogni 3 mesi vengono rilasciate delle versioni minori (La struttura  d[major].[minor].[patch])  e l’attuale 1.16.x è stata rilasciata a Marzo  2020 per cui:

·         La 1.17 mi aspetto che venga rilasciata a Giugno 2020

·         La 1.18 mi aspetto che venga rilasciata a Settembre 2020

Per verificare che versioni sono disponibili nella region su cui abbiamo il nostro cluster  il comando è il seguente:

 

   az aks get -versions –location <Region>  –output table

 

 

 

 

Se ad esempio la nostra infrastruttura è alla versione 1.15.7 e posso verificarlo con il seguente comando:

 

   az aks get-upgrades –resource-group  <Resource Group>  –name <nome del cluster AKS> –output table

 

 

Per la regola del N-2 la nostra versione va fuori supporto a Settembre 2020

 

A settembre come detto esce la 1.18, la regola del N-2 si applicata alla minor e quinti 18-2 = 16  quindi fino alla 1.16  siamo in supporto per quelle precedenti ( per cui la 1.15) siamo fuori supporto.

 

Per aggiornare una infrastruttura AKS  da  una versione fuori supporto a una in supporto…..  bisogna reinstallare il nostro cluster !

 

AKS upgrade come verificare se dobbiamo aggiornare