Tuesday, January 26, 2016

Finding IP on a problematic vCenter session (10 second version)

A user complains vCenter is locking him out. He "turns off everything" but still the domain controller reports the vCenter IP for the lockout source (this is a 5.0 vCenter, I don't know if this changed later).

Checking vCenter the user doesn't have any processes (hey, it could be the case) but he does show up in the vCenter logs. Alas, I don't see an IP in the logs. I google why and I find these links:



The great William Lam offers awesome explanations (he is really awesome) on how to enable verbose logging and finding out everything about each session. In the first link, however, a simpler/much faster/no change required answer appears by user aorady (which wasn't labeled as the answer).

The vCenter event view always shows IP for failed logins in form of

"Cannot login domain\username@XXX.XXX.XXX.XXX"

So, if you just needed the IP, you are good to go. There's lots of ways to do things, but finding a fast and simple way can be a big help.

No disrespect to William - I bet his explanation will come handy for a much wider variety of cases, especially if the user is having several sessions and you just need to track one.

Thursday, January 21, 2016

Things to note when upgrading to 5.5u3b and 6.0u1 (SSLv3 now disabled)

I'll focus on 5.5u3b since it's the most popular ESxi version out today.

This is verbatim from the 5.5U3b release note

What's New

  • Updated Support for SSLv3 protocol is disabled by default
    Note: In your vSphere environment, you need to update vCenter Server to vCenter Server 5.5 Update 3b before updating ESXi to ESXi 5.5 Update 3b. vCenter Server will not be able to manage ESXi 5.5 Update 3b, if  you update ESXi before updating vCenter Server to version 5.5 Update 3b. For more information about the sequence in which vSphere environments need to be updated, refer KB 2057795.

  • VMware highly recommends you to update ESXi hosts to ESXi 5.5 Update 3b while managing them from vCenter Server 5.5 Update 3b.

    VMware does not recommend re-enabling SSLv3 due to POODLE vulnerability. If at all you need to enable SSLv3, you need to enable the SSLv3 protocol for all components. For more information, refer KB 2139396
This of course causes issues which you need to be aware of:

1) You HAVE to patch vcenter first! Yes this is a best practice, but I know a lot of people just patch their hosts. Revisit this and plan patching your vCenter first, then your host
2) This has consequences with other software! For example, Veeam has a KB out (KB2063) that explains you have to upgrade to Veeam 8 update 3 for TLS to be supported.
3) If you don't do this today, always read the release notes. When 5.5u3b first came out, there weren't big warning signs like the above. VMware has done a good job of putting alerts now when you download this version and in updating KBs, but no one does the job of preparing for this but yourself, the system administrator.

Thats's one of the biggest gotchas i've seen in a good while - keep up to date :D