"ERROR_GEN_FAILURE [code 0x0000001f]" when AD-joining VCSA 8.02

[marauli]

Been trying to AD-join a newly deployed VCSA 8.02.0100 and not having much luck (see more here )

root@vcenter [ ~ ]# /opt/likewise/bin/domainjoin-cli join mydomain.com first.last
Joining to AD Domain:   mydomain.com
With Computer DNS Name: vcenter.mydomain.com

first.last@MYDOMAIN.COM's password:

Error: ERROR_GEN_FAILURE [code 0x0000001f]

Stumbled upon a very weird issue that may explain it:

root@vcenter [ ~ ]# nslookup badname.mydomain.com
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find badname.mydomain.com: NXDOMAIN

... however pingng the same address (or any hostname for that matter, whether valid or not) gives me this:

root@vcenter [ ~ ]# ping badname.mydomain.com
PING badname.mydomain.com (208.91.***.***) 56(84) bytes of data.
^C64 bytes from 208.91.***.***: icmp_seq=1 ttl=238 time=84.4 ms

--- badname.mydomain.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 84.399/84.399/84.399/0.000 ms

Where is this IP coming from? I don't see this behavior on any of our devices, whether AD-joined or not.

Why does it even ping it if "server can't find" it in nslookup?

Our production VCSA 7.03 with identical DNS config - no such behavior.

Googling that IP:

208.91.***.*** was found in our database!
ISP	Network Solutions LLC
Usage Type	Data Center/Web Hosting/Transit
Domain Name	networksolutions.com
Country	Virgin Islands (British)
City	Road Town, Virgin Islands, British

Nothing in our DNS setup points to that IP, far as I could tell...

Questions:

• Any ideas why the VCSA would behave that way? (resolve any hostname - valid or not - to the same weird IP even though nslookup would not find it, and the DNS config seems identical to other devices that don't exhibit this behavior)
• How do I fix it?

Thanks!

[RajeevVCP4]

This is not a VMware issue. This issue may occur when port 445 is blocked on an external firewall or other device in the path from the vCenter to the Domain Controllers.

https://kb.vmware.com/s/article/77531

[marauli · Accepted solution]

Set VCSA IP to static (same value as it was on DHCP) - and it worked - joined the domain.

The behavior is reproducible in our environment - i.e. if I deploy a fresh VCSA from scratch with a DHCP-provided IP and manually set DNS servers - it will be doing the same thing - at least in our environment.

Looks like a VMware bug, although there is a (small) chance it's something with our environment - although yet again, I've not seen this behavior in a gazillion of other scenarios, from freshly deployed ESXi 7 to Ubuntu 22.04 to non-VMware appliances (Dell OME), to a variety of Windows flavors - whether AD-joined or not.

Given I was able to successfully join the domain on a VCSA that was originally set up using an IP as the hostname

P.S. This may also mean VMware docs (Join or Leave an Active Directory Domain) could use a refresh:

• Verify that the system name of the appliance is an FQDN. If, during the deployment of the appliance, you set an IP address as a system name, you cannot join vCenter Server to an Active Directory domain.

The above snippet seems to indicate that a VCSA originally set up with an IP (as its hostname) cannot join a domain, period - which in my case wasn't true.

[marauli]

---

This is not a VMware issue. This issue may occur when port 445 is blocked on an external firewall or other device in the path from the vCenter to the Domain Controllers.

https://kb.vmware.com/s/article/77531

---

Not the case. The article does not apply.

root@vcenter [ ~ ]# openssl s_client -connect dc01.mydomain.com:445
CONNECTED(00000003)

P.S. Whether or not it's a VMware issue, it only happens with a VCSA appliance. (Not with ESXis configured the same way, not with any other of hundreds of devices and appliances we have.)