A nice feature with QSFP (Quad Small Form-factor Pluggable) is that you can turn a single QSFP port into 2 or 4 independent ports using a breakout cable.
In my home lab, I have an Nvidia/Mellanox SN2100 switch running Onyx (MLNX-OS), which I use for my iSCSI network. I also have an HPE MSA 2040 SAN. The HPE MSA 2040 SAN only has 10GB SFP (Small Form-factor Pluggable) ports.
I will use a breakout cable to use the SN2100 with the MSA 2040. The breakout cable will connect to the QSFP port on the SN2100 and give me 4 SFP connections that I will connect to the MSA 2040 SFP ports.
QSFP+ 40GB to SFP+ 10GB DAC cable
In this post, I will show you step-by-step how to split and unsplit an interface on an Nvidia/Mellanox SN2100 switch running Onyx (MLNX-OS).
Split Port
SSH into the switch.
Enter configuration mode with the command configure terminal
Shutdown the interface you want to split out.
The interface I will be splitting is ethernet 1/1. The command I will run is interface ethernet 1/1 shutdown.
To split the interface, we will use the command module-type qsfp-split-4 or the command module-type qsfp-split-2
Split 4 will split the QSFP module into four 25 Gbps ports. Split 2 will split the port into two 50 Gbps ports.
With the upcoming retirement of the MSOnline PowerShell module, Microsoft created a new version of Azure AD Connect, which is now rebranded as Entra Connect Sync.
In this post, I will show step-by-step how to manually upgrade Microsoft Azure AD Connect to Microsoft Entra Connect Sync.
Prerequisites
Local admin rights on the Azure AD Connect Server.
Member of ADSyncAdmins.
Account with the Hybrid Identity Administrator or Global Administrator role.
IE Enhanced Security Configuration turned off.
.NET Framework 4.7.2 or higher
TLS 1.2
With the new version of Microsoft Entra Connect, TLS 1.2 is now mandatory. We will check if TLS 1.2 is enabled and enable it if needed.
You will see an output similar to the image below.
Reboot the server so the changes take effect.
Auto Upgrade
Typically, the auto upgrade option for Azure AD Connect helps keep it up to date. However, I’ve seen multiple setups where Azure AD connect was only auto-upgraded to 2.3.6.0, which was released in February of 2024.
An important item about Azure AD Connect and Entra Connect Sync is that not every version is an auto-upgrade release. Version 2.4.129.0 is a version marked as an auto-upgrade release, but I haven’t seen any servers upgrade from 2.3.6.0 to 2.4.129.0, and if you check the event logs. There’s nothing about it, not even trying to auto-upgrade. It’s just radio silence.
Strangely, the auto-upgrade isn’t even triggering on one of the servers I looked at. I know auto upgrades work because that server has completed previous auto upgrades.
Manual Upgrade
Given that the auto-upgrade is not working, we will do a manual in-place upgrade.
Backup
Typically, manual upgrades work without any issues. However, it’s always good to have a backup. We will export our Azure AD Connect settings to a JSON file that we can use to rebuild everything on a new server if needed.
Open Azure AD Connect.
Click on Configure.
Select View or export current configuration and click on Next.
For the most part, PoE (Power over Ethernet) works perfectly with LLDP (Link Layer Discovery Protocol). I recently ran into a bizarre issue with a UniFi AP and an HPE Aruba switch where the AP would reboot under load.
In this post, I will cover how I fixed it and everything I learned in this rabbit hole.
The Setup
In my setup, I have an HPE Aruba 2930F switch, specifically the JL256A version. I also have a UniFi U7 Pro Max AP. The UniFi AP is plugged directly into the Aruba switch.
Initially, everything seemed to work fine. I could configure the UniFi AP and everything, but when I was testing the speed of the UniFi AP, I noticed that the AP would reboot, which is strange. I thought at first that maybe I had a faulty AP and would need to RMA it. However, the problem could be with my switch. To rule out the switch, I moved the AP to a PoE injector, and everything worked. I was now able to put the AP under load without it rebooting.
I started digging into my Aruba switch logs and noticed that I was getting PD over current errors on the port that the UniFi AP is plugged into, port 47. The log entry I saw was 00562 ports: port 47 PD Over Current indication.
I double-checked to make sure everything was fully compatible with each other. The power delivery method for the UniFi U7 Pro Max AP is PoE+, with a maximum power consumption of 25 watts. The Aruba 2930F has a PoE budget of 370 watts and is capable of PoE+, and I have room in the PoE budget to power the UniFi AP.
I started thinking that maybe the Aruba switch didn’t want to give the AP enough power for some reason. So I started down the rabbit hole of how PoE works and discovered that much of the magic is LLDP, specifically LLDP-MED (Link Layer Discovery Protocol – Media Endpoint Discovery).
LLDP and LLDP-MED
LLDP is similar to Cisco’s CDP (Cisco Discovery Protocol). The main difference between LLDP and CDP is that LLDP is vendor-neutral. LLDP is used by networking devices to provide information about themselves, such as port description, management address, system name, system capabilities, and system description.
LLDP-MED is an extension of LLDP and is commonly used by devices such as APs, VoIP phones, computers, and others. A very common use of LLDP-MED is to detect VoIP phones and place them on a voice VLAN because this lets you configure an access port with a data VLAN for computers and a voice VLAN for VoIP phones.
The LLDP information is transferred in an LLDPDU (Link Layer Discovery Protocol Data Unit). Inside the LLDPDU is a TLV (type-length-value). The TLV holds most of the information about the device.
PoE
With PoE, there are PSE (Power Sourcing Equipment) devices, which are basically your switches or PoE injectors, and then there are PD (Powered Device) devices, which are the devices that need PoE power, like a VoIP phone or an AP.
When a PoE device is plugged into a PoE switch, the PoE device uses LLDP-MED to communicate with the PoE switch to tell it what kind of power it needs, and the switch provides that. This is done using TLV in the LLDPDU and PoE types and classes.
PoE Types
There are a few types of PoE. The PoE type dictates their name and available power. Below is a chart of the PoE types.
Types
Common Name
Maximum Power
Type 1
PoE aka 802.3af
15.4 Watts
Type 2
PoE+ aka 802.3at
30 Watts
Type 3
PoE++ aka 802.3bt
60 Watts
Type 4
PoE++ aka 802.3bt
90 Watts
PoE Classes
In addition to PoE types, there are a few PoE classes. Classes dictate the PoE type they need and how much power could be required. Below is a chart of the PoE classes.
Classes
PoE Types
Maximum Power
Class 0
Type 1 aka PoE aka 802.3af
15.4 Watts
Class 1
Type 1 aka PoE aka 802.3af
4 Watts
Class 2
Type 1 aka PoE aka 802.3af
7 Watts
Class 3
Type 1 aka PoE aka 802.3af
15.4 Watts
Class 4
Type 2 aka PoE+ aka 802.3at
30 Watts
Class 5
Type 3 aka PoE++ aka 802.3bt
45 Watts
Class 6
Type 3 aka PoE++ aka 802.3bt
60 Watts
Class 7
Type 4 aka PoE++ aka 802.3bt
75 Watts
Class 8
Type 4 aka PoE++ aka 802.3bt
90 Watts
PoE Allocation
With PoE, you can allocate the power based on the device’s usage or class. Typically, the default is based on usage, and then LLDP will communicate if the device needs more power.
I tried changing between usage and class, and neither setting resolved my issue.
For the most part, 32-bit applications just work on the 64-bit version of Windows. However, I was curious about how it all works behind the scenes.
In this post, I go down a rabbit hole exploring what makes 32-bit applications work on Windows 64-bit.
WoW64
When Microsoft transitioned from 16-bit to 32-bit, they created a compatibility layer emulator named WoW (Windows on Windows). WoW made 16-bit applications run effortlessly on Windows 32-bit. As part of creating WoW, Microsoft also created the System32 folder %windir%\System32 aka C:\Windows\System32 for all the 32-bit libraries and executables, and WoW would keep using the System folder %windir%\System aka C:\Windows\System as the location for the 16-bit libraries and executables.
Logically, for the transition from 32-bit to 64-bit, Microsoft would create a System64 folder for all the 64-bit libraries and executables. That did not happen. Instead, Microsoft created the SysWOW64 folder %windir%\SysWOW64 aka C:\Windows\SysWOW64. The SysWOW64 folder is the location for the 32-bit libraries and executables, and the System32 folder is the location for the 64-bit libraries and executables. That is not a typo that is actually the way it is. The SysWOW64 folder is just one part that makes up WoW64, which stands for Windows (32-bit) on Windows 64-bit.
Cisco UCS can sometimes trigger a false positive alert of FFCH_ERROR_CARDS_ACCESS_ERROR on the FlexFlash controller, which typically has the fault ID of F1262.
Cisco UCS with the FFCH_ERROR_CARDS_ACCESS_ERROR alarm.
Depending on your setup, you should investigate the alarm appropriately. If, after your investigation, you determine that the fault is a false positive, the first step is to reset the FlexFlash controller.
In this post, I will show you step-by-step how to reset the FlexFlash controller to clear the FFCH_ERROR_CARDS_ACCESS_ERROR alert.
The Process
Log in to the Cisco UCS Manager.
Click on the Equipment tab.
Select the chassis and blade that has the FlexFlash fault.
PowerShell is a wonderful tool built into Microsoft Windows. Both Windows and Windows Server come with PowerShell version 5.1 pre-installed.
PowerShell version 5.1 was initially released in 2016. Since then, there have been many improvements to PowerShell. However, many of those improvements are only available in newer versions of PowerShell and aren’t always backported to PowerShell 5.1, even though PowerShell 5.1 is still actively supported.
PowerShell has a variable called ProgressPreference. This variable tells PowerShell how to handle progress updates, such as rendering progress bars when downloading a file.
By default, ProgressPreference is set to Continue, which will display progress bars when possible, and usually isn’t an issue until you start running your scripts outside of PowerShell ISE, as even a headless script needs to calculate a progress bar even if it isn’t displayed, which can cause significant slowdowns.
The script will download a 512MB test file from ThinkBroadband and will calculate how long the download took.
In PowerShell ISE, the script ran in 35 seconds.
In PowerShell 5.1, the script ran in 5 minutes and 35 seconds.
In PowerShell 7, the script ran in 32 seconds.
From the results, we can see a significate slowdown in downloads in PowerShell 5.1 when used outside of PowerShell ISE.
The ProgressPreferenceContinue download slowdowns have been resolved in newer versions of PowerShell. However, PowerShell 5.1 is left behind with this issue.
VMware vCenter can be a key provider, which is perfect for using a vTPM (Virtual Trusted Platform Module). With VMware vSphere, you can configure a native key provider that VMware vCenter fully manages. No external key provider is needed. The native key can even be used to encrypt your VMs.
In this post, I will show you step-by-step how to add a Native Key Provider (NKP) to VMware vCenter.
The Process
Login to VMware vCenter.
Click on your vCenter.
Click on the Configure tab.
Under the Security section, click on Key Providers.
With Windows Server 2025, Microsoft is more in your face about sending your diagnostic data to them. I am okay with sending them the data if it helps make their products better.
What I have a problem with is that the send diagnostic data to Microsoft screen is displayed on every first logon on each Windows Server 2025 system even if you have settings defining what diagnostic data to send to Microsoft.
This is the send diagnostic data to Microsoft screen you see on Windows Server 2025 desktop experience on first logon.
This is the send diagnostic data to Microsoft screen you see on Windows Server 2025 core on first logon.
In this post, I will show you step-by-step how to turn off the prompt to send diagnostic data to Microsoft.
The Process
Make a new GPO.
I will call mine Disable Send Diagnostics Data Prompt.
Go to Computer Configuration > Policies > Administrative Templates > Windows Components > OOBE.
At the very core of Omnissa Horizon is an ADAM (Active Directory Application Mode) LDAP (Lightweight Directory Access Protocol) database. Even though Horizon servers are typically domain-joined, they still maintain their own ADAM LDAP database for all the configurations in Horizon. It’s a good idea to back up the ADAM LDAP database as it can help you get out of some sticky situations.
The default setting is that the backups run every day at midnight, 10 backups are kept, and the backups are saved in C:\ProgramData\Omnissa\Horizon\backups.
Change Data Recovery Password
When you install the Horizon connection server, you define the data recovery password, which is used to encrypt the backups of the Horizon ADAM LDAP database. Fortunately, if the password is unknown, it’s possible to change it.
There are a few ways to preload the Omnissa Horizon client (formerly the VMware Horizon client) with a default Horizon Connection Server.
One method is to deploy the Horizon prefs.txt file with the Horizon connection server. For more information about the prefs.txt file method, my blog post, Omnissa Horizon Client prefs.txt, goes into detail.
Another method is the VDM_SERVER property. When you install the Horizon client, you can define the VDM_SERVER property. Omnissa does have some documentation about the VDM_Server property. However, it only says that you can use it to set a default horizon connection server for the users. It doesn’t go into detail on how it works. If you run the help command on the Horizon client installer, it doesn’t go into much more detail either.
Horizon client installer help dialog
Given that there isn’t a lot of info about the VDM_Server property, I needed to know more, and down the rabbit hole I went.
How does the VDM_Server property work, and is it better than using the prefs.txt file to preload the Horizon connection server? If the VDM_Server property works better, it could simplify how I’ve been deploying the Horizon client. I also needed to know if it works only for the user that installed the Horizon client or all users. I wanted to see if it did the same thing I did manually with the prefs.txt file.
If you install the Horizon client using the logging command /l or /log, everything the Horizon client install does is logged to a log file.
With logging enabled, I ran the Horizon client install with a value for the VDM_SERVER property. The command I ran was
