Latest posts

Upgrade Azure AD Connect to Entra Connect Sync

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.

Checking TLS 1.2

  • Connect to your Azure AD Connect server.
  • Open PowerShell ISE as administrator.

If your output looks like the image below, then you are all set.

TLS 1.2 is enabled.

If you get an output that says the value is not found, then you need to enable TLS 1.2.

TLS 1.2 is not enabled.

Enabling TLS 1.2

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.

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.