vCSA 5.1u1b Login Timeouts

Had an interesting thing happen in an environment. Not sure which knob I tweaked did the actual fix so I thought I would point out the problem and all three modifications.

• vCSA pointing directly to a Windows 2008 R2 AD DC/GC.
• SysAdmins add a Windows 2012 AD DC/GC into the domain.
• Timeouts on vSphere logins suddenly start: "The command has timed out as the remote server is taking too long to respond."

Frequently with the C# client but also with the web client. There are so many chatty logs that damned if I wasn't going to be able to figure out what was going on by log checking. Trial and error was the quickest way to a solution.

Fix 1) We have a main *.domain.com and a *.ad.domain.com. Turns out that while my primary DNS servers and hostname for the VM at hostname.domain.com was all well and good, some part of ldap  (/var/log/ldapmessages) was trying to contact hostname.ad.domain.com which did not have an A record. A record created in subdomain.

Fix 2) Swapped URL from port 636 (LDAPS) to 3269 (Secure Global Catalog). Same 2008 AD DC.

Fix 3) Bumped client timeout from default 30 seconds to 60 seconds.

Now, if you look at the readme for 5.1u1b it states pretty close to the top of the page that they've fixed timeout issues. Har. It was probably the LDAPS to SGC port change that fixed the issue, so if you are reading this I would start there.

Also, while you're looking through the readme files, look at 5.1u1c. How many items are fixed? 1.
How many known issues are there? 99. How many of those known issues are listed as new? 2/99.  Make your own choice if you want to update to 5.1u1c or just wait for an upgrade that actually does something.

Update to latest 5.1 build on vCSA

Thanks to Virtual Aspects for a smooth second attempt at updating to the latest build of the 5.1 vCSA. My search term of vami-sfcb was surprisingly good. After watching vami-sfcb fumble in the logs repeatedly I was just trying to find out what the service did.. but there was the fix.

Distributed vswitch security policies PowerCLI

Whatever your chosen acronym for distributed vSwitches, the default security policy is to accept MAC address changes and forged transmits. Even the hardening guides think this is a bad idea (and we know how checking those security those checkboxes from the hardening guide spreadsheet makes us feel, miright?).

GeekAfterFive has the code from his vCloud deployment that also works handy for 5.0 VDS's (and probably 5.1 and 5.5).

Even the 5.0 and 5.1 hardening guides don't have PowerCLI code to change the setting from the default insecure to reject this traffic. Pretty awesome resource there, GeekAfterFive. Good and bad that you're not blogging anymore from "the mothership".

5.0 -> 5.5

Per VMWorld session on vCenter, recommendation to stick with 5.0 and wait for 5.5 in order to not deal with the crap SSO in 5.1. Still no GA release date. Crossing my fingers that 5.5 is that much better...

VCAP5-DCA

Tooting my own horn here. VCAP5-DCA passed, even while giving AudoDeploy the finger. Thank you VMware for the super fast turn around on results (rather than the 3 weeks of dread last time). VCP5-Desktop next up.

vCSA 5.1u1b saves the day

Windows shop install of a "simple install" vCenter. Piece of cake and the local IT staff should be able to manage it in the long term. Except they don't put the new vCenter server into DNS and I don't realize it. >_< "Error 29155.Identity source discovery error" but install of SSO continues so I think it's something we can work with. Turns out, not so much but it was a pair of bad decisions by me that turned into a 5 hour headache and wanting to do bodily harm to the manager who decided that SSO should be required for all vCenter deployments. Hindsight #1: It's a VM. Use snapshots before mucking with things or installing. "Nah, it'll be fine, simple install...right?" Hindsight #2 and a bit: Do not uninstall SSO. Do not try to re-install everything from the "simple vCenter install" and expect it to work. Clean system or nothing. vCSA 5.1u1b (which the local IT staff won't know what to do with) was downloaded, installed, configured in about an hour. Setting the appliance for AD auth automatically set the AD domain in SSO (although with insecure settings) but it worked and I didn't have to muck with it. Saved the day. So thank you VMware for investing time into the vCSA and screw you for bad SSO error messages (or just SSO in general) and uninstall procedures that don't clean the system correctly. You cost me an entire Saturday afternoon and into the evening. Should I manually check DNS for the new vC server that I was handed? Yes. Should the SSO installer have continued upon error? NO.

New Cluster Name

While I've seen a whole host of boring cluster names in my travels, I like to open it up to voting. The ESXi cluster name is just a fairly arbitrary text value in the database that can be changed anytime so why not have some fun with it. :)

Please vote once, you can choose as many names as you like. Obvious ballot stuffing will disqualify the entry.