Hi I am trying to join virtual center appliance 5.5 to AD 2012 R2 but its giving me error while joininh the domain : The OU format is invalid
command:
/usr/sbin/vpxd_servicecfg ad write ucpadmin <password> podd.local
log output
2014-07-07 22:21:02 24055: START locking... /usr/sbin/vpxd_servicecfg ad write
2014-07-07 22:21:02 24058: [24055]BEGIN execution of: /usr/sbin/vpxd_servicecfg 'ad' 'write' 'ucpadmin' CENSORED 'podd.local' 'Users'
2014-07-07 22:21:02 24058: Testing domain (podd.local)
2014-07-07 22:21:02 24058: Enabling active directory: 'podd.local' 'ucpadmin'
2014-07-07 22:21:04 24058: ERROR: Enabling active directory failed: Joining to AD Domain: podd.local
With Computer DNS Name: testVC.podd.local
Error: Lsass Error [code 0x0000000b]
The OU format is invalid.
2014-07-07 22:21:04 24058: VC_CFG_RESULT=302
2014-07-07 22:21:04 24058: END execution
Any idea ? any one seen this error before ?
shouldn't matter, but check the uppercase/lowercase to match the netbios name. I am always suspicious of linux and microsoft ever playing nice.
Have confirmed I'm using the same case as the netbios name.
Have tried in the following formats:
domain\user.name
Have recreated the account and also tested with another account but still not working.
Is the appliance and the domain in the same vlan? Try disabling the firewall on the domain controllers. If that works, then you know you need to adjust it's settings.
If you are still having issues, post your vpxd_cfg.log (located in /var/log/vmware/vpx)
usage: tail -f vpxd_cfg.log
The appliance is on the same VLAN as the domain controllers. Have ran another test with the DC firewall turned off but this didn't fix the issue.
I've attached the log for just today. I've made a few changes to the system which is reflected in the logs. I can confirm that domain\user.name is not a usable format and it must be user.name@domain.name.
Please note I've replaced the domain name with the word domain for the log that I've uploaded. Please let me know if you would like more info.
The very last bit of the log has the following:
2014-11-13 05:24:05 8207: START locking... /usr/sbin/vpxd_servicecfg ad write
2014-11-13 05:24:05 8210: [8207]BEGIN execution of: /usr/sbin/vpxd_servicecfg 'ad' 'write' 'svc.vmad@domain.local' CENSORED 'domain.local'
2014-11-13 05:24:05 8210: Testing domain (domain.local)
2014-11-13 05:24:05 8210: Enabling active directory: 'domain.local' 'svc.vmad@domain.local'
2014-11-13 05:24:27 8210: ERROR: Enabling active directory failed: Joining to AD Domain: domain.local
With Computer DNS Name: domainmanage01.domain.local
Error: ERROR_GEN_FAILURE [code 0x0000001f]
2014-11-13 05:24:27 8210: VC_CFG_RESULT=302
2014-11-13 05:24:27 8210: END execution
I will be off line until tomorrow.
I am getting exactly the same and have just started a new thread...any takers ??
So the issue is the NetBIOS has at least one lower case letter. In my case mines was all lower case.
So I just ran rendom to change it to all uppercase. FYI, since I was not rename the domain name or the NetBIOS name I was allow to do this with exchange.
Just some notes on my network: Windows 2012, Windows 2012 R2, Windows 2008 R2 and Exchange 2013.
I am currently ill.
I have limited access to my email or phone.
For other urgent matters please send me a SMS or contact Vincent Weberink.
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.
If you have followed the 2012 R2 BPA for your DC, you may have applied the recommendation to set srv.sys to start on demand. This breaks the vcsa domain join. You can check the registry key at HKLM:\System\CurrentControlSet\Services\srv\ if it is set to 3, change it back to the default of 2 and retest.
I'm having the exact same issue. According to KB 2085616, it's due to the NETBIOS domain name having lower case characters. I checked in AD to see how my NETBIOS domain name looked and sure enough it is all lower case (I don't remember doing that intentionally when I created the domain a year ago, but that's how it is). Also according to the KB, there is currently no resolution. So I guess the only possible resolution at this point is to rename the NETBIOS domain name to the same name, but all upper case. Has anyone tried this?
My AD domain is Windows 2012 R2 (installed fresh, not upgraded from previous versions). My VCS appliance is 5.5.0 Update 2e.