I'm troubleshooting this ATM, and the fact that setting the FQDN isn't sufficient, resulting in OU errors, looks like a defect. More explicitly, it looks the parts of the appliance code are either ignoring the change to the FQDN in the static network config and/or are deciding that reverse lookups of the host name are more authoritative than the assigned FQDN:
vcenter:~ # hostname
vcenter.ad.example.com
vcenter:~ # cat /etc/hosts
10.3.101.58 vcenter.example.com vcenter
vcenter:~ # find /etc -type f | sed -e 's/^/"/g; s/$/"/g;' | xargs grep 'example.com' | egrep -v 'ad\.example\.com'
/etc/hosts.orig:10.3.101.58 vcenter.example.com vcenter
/etc/hosts.orig:127.0.0.1 vcenter.example.com vcenter localhost
/etc/hosts.orig:::1 vcenter.example.com vcenter localhost ip6-localhost ip6-loopback
/etc/vmware-identity/sso.properties:ownerId=vcenter.example.com@vsphere.local
/etc/vmware-identity/sso.properties:endpoint0.url=https://vcenter.example.com:7444/sts/STSService/vsphere.local
/etc/vmware-identity/sso.properties:endpoint1.url=https://vcenter.example.com:7444/sso-adminserver/sdk/vsphere.local
/etc/vmware-identity/sso.properties:endpoint2.url=https://vcenter.example.com:7444/sso-adminserver/sdk/vsphere.local
/etc/vmware-identity/sso.properties:endpoint3.url=https://vcenter.example.com:7444/sso-adminserver/idp
/etc/vmware-identity/sso.properties:endpoint4.url=https://vcenter.example.com:7444/websso/SAML2/Metadata/vsphere.local
/etc/vmware-identity/sso.properties:endpoint5.url=https://vcenter.example.com:7444/websso/HealthStatus
/etc/vmware-identity/hostname.txt:vcenter.example.com
/etc/hosts:10.3.101.58 vcenter.example.com vcenter
/etc/vmware-vsphere-client/SerenityDB/solution-id:vsphere-client-vcenter.example.com-e8b6bbfb-a806-4ff1-be82-1399e529051c
/etc/vmware-vsphere-client/SerenityDB/MNNextVcDirectory:<?xml version="1.0" encoding="UTF-8" standalone="no"?><VcDirectory directoryVersion="5.1"><com.vmware.vise.usersession.ServerInfo><serviceUrl>https://vcenter.example.com:443/sdk</serviceUrl><serviceGuid>E0CA6381-5440-4A6F-9837-FC1A629F858D</serviceGuid></com.vmware.vise.usersession.ServerInfo></VcDirectory>
/etc/vmware-vpx/proxy.xml~: <serverNamespace>vcenter.example.com:8089</serverNamespace>
/etc/vmware-vpx/vpxd.cfg: <name>vpxd-vcenter.example.com-a98bba71-c237-4efc-b7b4-9f046146e724</name>
vcenter:~ # dig -x 10.3.101.58
; <<>> DiG 9.9.4-P2 <<>> -x 10.3.101.58
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64258
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;58.101.3.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
58.101.3.10.in-addr.arpa. 86400 IN PTR vcenter.example.com.
;; Query time: 1 msec
;; SERVER: 10.3.101.15#53(10.3.101.15)
;; WHEN: Sat Feb 28 17:24:38 UTC 2015
;; MSG SIZE rcvd: 91
Caveat: I've edited the output to limit exposure of site info.
I've tried editing /etc/hosts to make the line for the host reflect the assigned FQDN and restarting services, and that's not sufficient--the name is reverted to what's in DNS. Fundamentally, if I explicitly configure an FQDN for the system's network config, that imperative should override anything else from the environment. The FQDN was changed in reading up on this, and the previous FQDN was the same as the reverse lookup name. Equally to the point, it seems to me fundamentally wrong that I have to do anything more than pre-emptively change the FQDN to accomplish a join, as it's the join itself that should result in changes to forward and reverse resolution.
In short: letting DNS dictate looks like a bug and make this much more of a headache than it should be.