Recently had an deployment with a customer who has a mandate core o/s deployments are preferred unless the product doesn’t support a core o/s installation.
Well for this deployment we created two core o/s subordinate ADCS servers with the enrollment server software installed and configured. Everything is working fine and dandy, no issues and seems like its golden for production deployment.
Guess again.. all the Horizon products aren’t supported for a core o/s installation, yes it will work most of the time but if you’ll find any errors or in need of GSS support then most likely you would need to install a GUI variant. I’ve had two support cases open and both of them state it’s not supported even though the documentation isn’t explicitly stating that.
Take a look at https://docs.vmware.com/en/VMware-Horizon-7/7.10/horizon-installation/GUID-30AA88CF-8CDF-42E5-97D4-D75B2171434B.html for the ESB release and https://kb.vmware.com/s/article/78652 for the Horizon 8 2006 release.
I’ve asked for a documentation update in the support case and also left feedback that the articles need updating. Please do the same so that we can prevent others from installing a unsupported setup.
Hope it helps!
Quite recently I’ve encountered a random synchronization error that VMware Access connector could not synchronize and would error out with the following error: “Connector communication failed because of invalid data: The specified Bind DN and password could not be used to successfully authenticate against the directory”
At first I stumbled upon the known issues list: https://docs.vmware.com/en/VMware-Workspace-ONE-Access/19.03/rn/VMware-Identity-Manager-1903-Release-Notes.html#knownissues and checked if the computer name was the same as the name in the domain field and that was all correct.
Eventually it came to light that the LDAP Signing and Channel Binding hardening were implemented according to the latest Microsoft update. Well then you can also get this sort of behavior. The solution is present in an hotfix for the connector software.
Knowledge base article can be found here: https://kb.vmware.com/s/article/77158 and the hotfix can be found after logging in at my vmware and the components of Access/Identity Manager
This was quite a nice one to troubleshoot, turns out there is a new configuration point for per app VPN and iOS devices, at least it was for me.
If you follow the configuration at https://www.citrix.com/blogs/2016/04/19/per-app-vpn-with-xenmobile-and-citrix-vpn/#:~:text=With%20the%20iOS%20per%20app,applications%20installed%20on%20the%20device. you’ll end up with a config that won’t open up a VPN when accessing the browser. Solution for this is to change the default provider type in the policy from App Proxy to Packet tunnel also mentioned here https://docs.citrix.com/en-us/xenmobile/server/policies/vpn-policy.html and explained it means the following:
Provider Type: A provider type indicates whether the provider is a VPN service or proxy service. For VPN service, choose Packet tunnel. For proxy service, choose App proxy.
Hope it helps!
Just thought of leaving a quick win here. Did you ever had the firewall profile of Windows not correctly mapped after reboots etc.?
This is because after a reboot the Domain Controllers put it in e.g. public profile and this will get passed on to other servers as well. This will effect in not being able to manage machines because of firewall blocks etc.
Solution is to restart the “Network Location Awareness” service and dependent “Network List Service”.
This will reset it to domain profile and after reboots of the other machines which have this it will be updated to domain profile as well. Or restart the service as above that will also do the trick.
Hope it helps!