Interesting changes to Arc Agent 1.34 with expanded detected properties

Microsoft just pushed out a change in Azure Arc Connected Agent 1.34 and with this comes some enrichment of Hybrid Servers detected properties.

This is what the properties looked like prior to the update.

Agent 1.33 and earlier

Okay… so what’s new and different?

New detected properties for Azure Arc Connected Agent 1.34

serialNumber, ProcessNames and totalPhysicalMemory

resources
| where ['type'] == "microsoft.hybridcompute/machines" 
| extend processorCount = properties.detectedProperties.processorCount,
    serialNumber = properties.detectedProperties.serialNumber,
    manufacturer= properties.detectedProperties.manufacturer,
    processorNames= properties.detectedProperties.processorNames,
    logicalCoreCount = properties.detectedProperties.logicalCoreCount,
    smbiosAssetTag = properties.detectedProperties.smbiosAssetTag,
    totalPhysicalMemoryInBytes = properties.detectedProperties.totalPhysicalMemoryInBytes,
    totalPhysicalMemoryInGigabytes = properties.detectedProperties.totalPhysicalMemoryInGigabytes
| project name,serialNumber,logicalCoreCount,manufacturer,processorCount,processorNames,totalPhysicalMemoryInBytes,totalPhysicalMemoryInGigabytes

This unlocks organizations to collect processor, serial number and memory information in a simple fashion via Azure Arc infrastructure. This can be used to look at things like consolidation and migration planning, perhaps decommissioning aging hardware even warranty lookup if you don’t have current hardware CMDB.

VS Code: one liner to install on a Windows system

This is just a quick post on how to quickly download and install VS Code for an x64 Windows system.

# One liner to install VS Code to Windows System 
$ProgressPreference = 'SilentlyContinue'; $Path = $env:TEMP; $Installer = "vscode_installer.exe"; $installerArgs = "/silent /mergetasks=!runcode,addcontextmenufiles,addcontextmenufolders,associatewithfiles,addtopath"; Invoke-WebRequest "https://code.visualstudio.com/sha/download?build=stable&os=win32-x64" -OutFile "$Path\$Installer"; Start-Process -FilePath "$Path\$Installer" -Args $installerArgs -Verb RunAs -Wait; Remove-Item "$Path\$Installer"

Here’s some background on how I obtained the URL, which was hidden away, somewhat.

Using the official page to download VS Code, it provides links to the various installers, but it doesn’t allow you use the links directly from the page to use in a script.

In order to get it, I used the dev tools from within Edge (works the same in Chrome). I pressed F12 from within the browser session, and moved to the Network tab. I clicked on the link and it allowed me to inspect what was going on with the network.

With a little trial and error, I could determine which URL would work. Check out the animation below to see the flow.

View fullsize

Link to the gist:

* Updated so that VS Code does not auto open. Ref: https://gist.github.com/EmmanuelTsouris/00bcaa9a3787a6451af5567f74b4e1c6

Azure CLI: Determining location of CA certs to work with Azure Stack Hub/ASDK

I’ve been doing some work on Azure Stack HUB (ASH) and ASDK recently, and the perennial problem with certificates has raised it’s head again. This is a quick blog post for anyone using Linux and Azure CLI to administer to figure out where you should store the CA root certificates, as the documentation is somewhat vague.

• First, make sure you install the latest version of Az cli and not version 2.29, as that version has CVE’s (versions prior to 2.40.0 are affected)

• Once installed, check the version and what Python version is used (We need to make sure that any Python commands we are running uses this version. )

az --version

View fullsize

• Next, install pip for the python version the az cli is using (in this case it’s Python 3.9. but future versions could change)

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3.9 get-pip.py

• Install the Certifi module:

pip install certifi

• Now you can determine where the cacert.pem file is located as used by az cli:

python3.9 -c "import certifi; print(certifi.where())"

• Now you can add the ASH or ASDK CA certs to the store for use by Azure CLI:

cat <CA Cert>.pem >> ~/.local/lib/python3.9/site-packages/certifi/cacert.pem

You can use the docs here to obtain the CA root certificate, or if you’re running a Linux VM from within ASH/ASDK, simply run:

sudo cat /var/lib/waagent/Certificates.pem >> ~/.local/lib/python3.9/site-packages/certifi/cacert.pem

- If you were to follow the Microsoft docs, I found az cli would still not be able to communicate successfully.

It is necessary to run the following:

export REQUESTS_CA_BUNDLE=~/.local/lib/python3.9/site-packages/certifi/cacert.pem
# RECOMMENDED: set the env var automatically for your subsequent sessions
echo 'export REQUESTS_CA_BUNDLE=~/.local/lib/python3.9/site-packages/certifi/cacert.pem' >> ~/.bash_profile

As you can see above, I have been able to run az cli targeting ASDK, whereas before, it would throw the SSL error.

Tested on CentOS 8 and Rocky Linux 8.5

The process cannot access the file psconfig.json because it is being used by another process

If you have been having issues deploying Azure Arc Resource Bridge on AKS and running into various issues like the one above for Azure Stack HCI. Microsoft has recently published new guidance. Some pages still have conflicting messaging. I hope this pointer might help someone else.

We do NOT recommend or support running AKS on Azure Stack HCI and Azure Arc Resource Bridge on the same Azure Stack HCI or Windows Server cluster. If you have AKS on Azure Stack HCI installed, run Uninstall-AksHci and start deploying your Azure Arc Resource Bridge from scratch.

Microsoft Learn Reference

https://learn.microsoft.com/en-us/azure/aks/hybrid/troubleshoot-aks-hybrid-preview#issues-with-using-aks-hci-and-azure-arc-resource-bridge

Feature Parity for Azure Arc Server Resource Types?

This is an Azure Arc Server (Server)

This is an Azure Arc Server (VMware)

This is an Azure Arc Server (HCI)

Introduction

Yes! Yes, Same Same… but different. Okay, so what? Not all Azure Arc Server VM objects are created equal. If we look a little closer at the Azure Resource Types we can see there are three different types listed here;

• (Server) "type": "Microsoft.HybridCompute/machines"

• (VMWare) "type": "microsoft.connectedvmwarevsphere/virtualmachines"

• (HCI) "type": "microsoft.azurestackhci/virtualmachines"

Each of these types connecting via different methods to your Azure subscriptions, and along with this comes different functionality.

---

Server Blades

Let’s take a cursory look at (Server) using the standard connected Azure Connected Machine Agent. Lots of information, server, patch level, settings, operations, monitoring, big buttons to click great, appears feature rich and has the feel of Azure…. what’s your point?

Take note of the menu options on the left. You can also click on an image to enlarge it.

View fullsize

Okay, how about (VMWare)? It seems to be missing a few options and capability compared to the Server.

View fullsize

Well, what about (HCI)? Huh … It seems like its missing even more options.

View fullsize

---

VM Extensions

Unfortunately, this isn’t where the differences end. Taking a closer look at the Extensions available for each resource type. In particular, let’s say you want to start taking advantage of the new functionality around Arc-Enabled SQL Servers. Now the Arc SQL Extension is meant to Auto install… but only if you are using the (Server) type that is "type": "Microsoft.HybridCompute/machines"

View fullsize

Extension for (Server)

For the other two types, that Arc SQL Server extension is missing.

Extension for (VMware)

Extensions for (HCI)

---

HCI and VMWare

It is touted that it is easy to install Azure Arc for for your entire vSphere farm, and they are not wrong, you can import up to a maximum of 9500 VMs if you like with very little effort… up front. But you are not being offered all the benefits of an Azure Arc Server. You cant have the Arc SQL extension to monitor, operate and control your SQL Servers anywhere.

Digging into an HCI Cluster, you can Arc-enable the host nodes. These actually appear as first-class citizens of Azure as Azure Arc Servers.

View fullsize

Here is the cluster

and here is one of those nodes.

Here is where you would start the setup for the HCI Resource Bridge Setup, and through this is where you connect servers the HCI clusters guests.

but while the hosts have the full feature set of an Arc Server the HCI cluster guest VMs don’t.

VMware and HCI types are seriously lagging behind Arc Server and missing features and are essentially second-class citizens of Azure compared to the original HybridCompute resource type. You can See Updates, Azure Monitor, and SQL Extensions are all only available for Azure Arc (Server).

---

Resource Explorer

Through the Resource Explorer in the Azure Portal we can see the different types and more specifically the different ways they have been enabled. (Server)

View fullsize

We can see the (VMWare) which has a number of operations at the cluster level

View fullsize

and (HCI) which also has more operations at the cluster level than at the VM level.

View fullsize

---

Conclusion

Of course, you can’t install multiple types on the same server. I believe Azure Arc (Server) is the only way to go. Seeing the lack of parity in functionality between these types, it’s worth creating a method to deploy Azure Connected Agent directly on the machine yourself and at scale rather than leveraging time savings tools with the Resource Bridge that allow easy onboarding of vSphere and HCI cluster guests which leverage the Arc Resource Bridge.

That’s not to say the Resource Bridge isn’t useful for K8s or Arc Data Services. However, you should be aware of the lack of feature parity for HCI or VMWare installations of Arc Server Resource Type and make an informed decision about which Resource Type of Azure Arc Server you need or want in your environment.