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”

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

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

 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

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

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