Latest posts

PoE and LLDP

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.

TypesCommon NameMaximum Power
Type 1PoE aka 802.3af15.4 Watts
Type 2PoE+ aka 802.3at30 Watts
Type 3PoE++ aka 802.3bt60 Watts
Type 4PoE++ aka 802.3bt90 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.

ClassesPoE TypesMaximum Power
Class 0Type 1 aka PoE aka 802.3af15.4 Watts
Class 1Type 1 aka PoE aka 802.3af4 Watts
Class 2Type 1 aka PoE aka 802.3af7 Watts
Class 3Type 1 aka PoE aka 802.3af15.4 Watts
Class 4Type 2 aka PoE+ aka 802.3at30 Watts
Class 5Type 3 aka PoE++ aka 802.3bt45 Watts
Class 6Type 3 aka PoE++ aka 802.3bt60 Watts
Class 7Type 4 aka PoE++ aka 802.3bt75 Watts
Class 8Type 4 aka PoE++ aka 802.3bt90 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.

32-bit on Windows 64-bit

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 Reset FlexFlash Controller

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.

I will select chassis 2 and blade 1.

PowerShell ProgressPreference Issue

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.

ProgressPreference Continue

To help illustrate this issue, I created a PowerShell script called download-tester on my GitHub https://github.com/thedxt/Download-Tester

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 ProgressPreference Continue download slowdowns have been resolved in newer versions of PowerShell. However, PowerShell 5.1 is left behind with this issue.

VMware vCenter Native Key Provider

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.

Disable Windows Server 2025 Diagnostic Data Screen

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.

Omnissa Horizon Connection Server Backup

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.

In this post, I will show you step-by-step how to backup an Omnissa Horizon Connection Server (Formerly VMware Horizon Connection Server), including how to schedule the backup, how to run the backup on demand with the GUI or CLI, how to change the data recovery password, and how to test the data recovery password.

Scheduled Backup

  • Log in to the Horizon Admin Console.
  • Click on Setting > Servers.
  • Click on Connection Servers.
  • Select the Connection Server and click on Edit.
  • Click on Backup.
  • Change the backup setting as needed.

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.

Omnissa Horizon Client Default Server

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

.\Omnissa-Horizon-Client.exe VDM_SERVER="Horizon.1company.com;Horizon.2company.com" /l C:\temp\HorizonInstall.logCode language: PowerShell (powershell)

Omnissa Horizon Client prefs.txt

There’s not a lot of official information about the prefs.txt file that the Omnissa Horizon client (formerly the VMware Horizon client) creates and uses.

I’ve figured out that the prefs.txt text file is in XML format and is generated by the Horizon client, usually once the user changes a setting in the Horizon client. It seems that prefs.txt is used to store all the user settings that the user has configured within the Horizon client.

Here’s an example of the contents of a prefs.txt file.

<?xml version="1.0" encoding="utf-8"?>
<Root>
  <RecentServer serverName="horizon.company.com" isSyncShortcutsEnabled="false">
    <SecondaryServerList />
    <ShortCuts />
    <FileRedirection>
      <AppExtensionInfo AppId="cn=microsoft_edge,ou=applications,dc=vdi,dc=vmware,dc=int" AppName="Microsoft Edge">
        <Extension Name="htm" Display-name="Microsoft Edge HTML Document" />
        <Extension Name="html" Display-name="Microsoft Edge HTML Document" />
        <Extension Name="mht" Display-name="Microsoft Edge MHT Document" />
        <Extension Name="mhtml" Display-name="Microsoft Edge MHT Document" />
        <Extension Name="pdf" Display-name="Microsoft Edge PDF Document" />
        <Extension Name="shtml" Display-name="Microsoft Edge HTML Document" />
        <Extension Name="svg" Display-name="Microsoft Edge HTML Document" />
        <Extension Name="webp" Display-name="Microsoft Edge HTML Document" />
        <Extension Name="xht" Display-name="Microsoft Edge HTML Document" />
        <Extension Name="xhtml" Display-name="Microsoft Edge HTML Document" />
        <Extension Name="xml" Display-name="Microsoft Edge HTML Document" />
      </AppExtensionInfo>
    </FileRedirection>
    <RecentDesktop desktopID="cn=vdis,ou=applications,dc=vdi,dc=vmware,dc=int" autoSyncToggleKeysMode="7">
      <LastDisplaySize displaySize="Fullscreen" height="0" width="0">
        <SelectedMonitors />
      </LastDisplaySize>
    </RecentDesktop>
  </RecentServer>
  <DataSharingSettings Allowed="1" />
  <BlastSettings allowClientH264YUV444="true" allowClientHEVCYUV444="true" allowClientHDR="true" DisableDisplayNetworkState="false" DisableDisplayNetworkStateManually="true" />
  <BrokerJumpList>
    <BrokerJump BrokerName="horizon.company.com" BrokerArguments="horizon-client://horizon.company.com/" />
  </BrokerJumpList>
  <AutoCheckForUpdate autoCheckForUpdate="false" />
  <sharingList allowAccessRemovable="true" shareHomeDirectory="true">
    <sharingItem from="C:\Users\daniel" />
    <sharingItem from="T:\" />
  </sharingList>
  <GeolocationSharingSettings GeoSharingAllowed="true" />
  <WebrtcSettings WebrtcScreenSharePerm="1" enableWebRTCRedirection="true" WebrtcSuppressScreenSharePrompt="true" />
</Root>Code language: HTML, XML (xml)

The prefs.txt file is stored in the user’s AppData Roaming folder.

The file will be in the following locations depending on which version of the Horizon client you use.

  • For Horizon clients version 2412 or newer, it is stored in %AppData%\Omnissa\Omnissa Horizon Client
  • For Horizon clients older than version 2412, it is stored in %AppData%\VMware\VMware Horizon View Client

Horizon-Prefs Script

Because the contents of the prefs.txt file are predictable, I created a script called Horizon-Prefs. You can find the script on my GitHub https://github.com/thedxt/Omnissa#horizon-prefsps1. The Horizon-Prefs script can place the prefs.txt file in the correct location for all users, just a single user, or both.

I’ve used my script to deploy the prefs.txt file to systems to configure some Horizon client settings that don’t have GPO options. I’ve also used it to configure Horizon client settings on systems that aren’t joined to a domain.

Windows Default User Profile

With Microsoft Windows installations, there’s a hidden user profile called Default. Anything in that user profile is copied directly to any new user account that logs into the computer. It is a template for each user who logs onto that system.

The default user profile is located C:\Users\Default

List of users in C:\Users showing the Default user profile.

When a user logs into a Windows system for the first time, a user profile is created for that user on that system. As part of the first logon process, Windows uses the Default user profile to build the user’s profile on the system. This process only happens the first time a user logs into that system.

Files and folders located in the Default user profile.

The fact that the default user profile exists gives us the power to tweak it. Any files we place in that Default user profile will be copied to each user who logs into that system for the first time.

For example, I will create a text file called I am text.txt and place it in C:\Users\Default\Desktop

Text file placed in the Default user profile.