Horizon upgrades are usually straightforward: create a VDM backup and upgrade the primary connection server and you should be good to go.
But recently I got a strange assembly error which took me down a loophole in figuring out what was happening.
So some context, the customer was running a fairly simple deployment on Horizon 2111 and wanted to upgrade to the latest version back then.
Which was Horizon 2306 (it took me a while to write this blog), to have the possibility to migrate their legacy Persistent Disk Desktop pool to Horizon 8.
I will try to write a follow-up blog on this as well on how we eventually did the entire migration.
Environment:
As mentioned in the intro, the customer’s deployment was straightforward forward: two connection servers running on Horizon 2111.
They were in a healthy state and ADAM replication was running perfectly.
Issue:
When upgrading the connection servers, the horizon installer did continue at first without any problems but when trying to load the LDS schemas.
It performed a rollback of the installation without any clear error. So let’s check the installer logs to see what happened during the schema load.
Here we got a strange assembly error: A component version required by the application conflicts with another component version already active.
So after checking the CBS and DISM logs, no real new insight into why the upgrade failed was found.
I did eventually install all remaining Windows updates and started tinkering with different versions of the Dot Net framework and C++.
But nothing worked…
To save you a couple of days of intense troubleshooting, this is what we tested:
- Remove node from ADAM + delete from disk, and redeploy old version and retry the upgrade = FAIL
- Disable and even remove all software installed on the machine (AV) + updates = FAIL
- Redeploy a vanilla template of the customer and install fresh 2306 instance = FAIL
This is where things became weird, as we were having the same issue with a vanilla deployment. So our testing continued:
- Deploy Vanilla server utilizing Volume-License ISO = FAIL
- Utilizing global domain administrator to see if it’s a permission issue = FAIL
- block all GPO’s from the machine = FAIL
Eventually, we did find a clear reference in the adamutillog within the installer on what exactly was going wrong:
11:51:00 Running schema update for Local ldap. 11:51:00 LDAP bind failed (Strong Authentication Required) 11:51:00 ERROR: Could not acquire schema master lock. 11:51:00 End Logging |
|---|
Solution
Eventually, after reading about LDAP binding and enforcement, it was clear to me that the LDAP enforcement policies within the customer’s domain had been tweaked.
This caused the internal ADAM LDAP binding with the horizon service to fail within the connection server itself. Causing the weird “assembly error”
Based on the following Windows KB, we needed to tweak the LDAP registry settings:https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entryhttps://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008
So after checking the findings with VMware support, they also suggested changing the following registry keys and setting the value to 1:
Before changing these parameters, please check with your Active Directory team if this is compliant with the organisation’s rules.
“LdapEnforceChannelBinding” at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters“LDAPServerIntegrity ” at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters“ldapclientintegrity ” at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\Parameters
After modifying the registry keys make sure to reboot the OS.
Succes! After modifying the LDAP enforce channel binding registry, we were able to install/upgrade the connection servers to 2306 and eventually to 2309.
I hope this blog has helped you in any way!
Read more on other connection server issues like VMware TrueSSO – Certificate renewal error