VMware Cloud Community
gaurav_singh1
Contributor
Contributor

vCenetr Virtual Appliance 5.5 : AD: The OU format is invalid

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 ?

Reply
0 Kudos
29 Replies
antonmajor
Enthusiast
Enthusiast

shouldn't matter, but check the uppercase/lowercase to match the netbios name. I am always suspicious of linux and microsoft ever playing nice.

Reply
0 Kudos
Mark_B2
Contributor
Contributor

Have confirmed I'm using the same case as the netbios name.

Have tried in the following formats:

user.name@domain.name

domain\user.name

Have recreated the account and also tested with another account but still not working.

Reply
0 Kudos
antonmajor
Enthusiast
Enthusiast

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

Reply
0 Kudos
Mark_B2
Contributor
Contributor

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.

Reply
0 Kudos
AceT
Contributor
Contributor

I am getting exactly the same and have just started a new thread...any takers ??

Reply
0 Kudos
gjackson2434
Contributor
Contributor

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.

Reply
0 Kudos
Mart
Contributor
Contributor

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.

Reply
0 Kudos
buffyg
Contributor
Contributor

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.

Reply
0 Kudos
sludgeheaddf
Contributor
Contributor

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.

Reply
0 Kudos
RomolandUSD
Contributor
Contributor

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.

VMware KB: Connecting VMware vCenter Server Appliance versions 5.1 and 5.5 to an Active Directory do...

Reply
0 Kudos