New VMware VCP Recertification Policy

Today, VMware Certification announced a change to the VMware Certified Professional (VCP) program with the institution of a recertification policy. The recertification policy is posted here:

http://mylearn.vmware.com/mgrReg/plan.cfm?plan=46667&ui=www_cert

In the policy post, it states that any VCP certification earned before March 10, 2013 needs to be recertified by March 10, 2015. Here are the three options for recertification:

Take the current exam for your existing VCP certification solution track. For example, if you are a VCP3, you could take the current VCP5-Data Center Virtualization (VCP5-DCV) exam.
Earn a new VCP certification in a different solution track. For example, if you are a VCP-Cloud, you could recertify by earning VCP5-Desktop (VCP5-DT) certification.
Advance to the next level by earning a VMware Certified Advanced Professional (VCAP) certification. For example, if you are a VCP5-DCV you could earn VCAP5-DCA certification.

As is described in the recertification policy, VMware has added a note to our Mylearn transcripts:

In my case, I earned my VCP5-DCV in September of 2011, so I need to recertify within the next year. My transcript shows the expiration date:

Here are use cases for recertification that were provided by VMware education:

I also have a VCP5-DT and a VCAP4-DCD that were earned in 2011. For me, I am looking at this as motivation to get my VCAP-DCD updated and make good on a goal of getting a VCAP-DCA before March 2015.

I support this kind of recertification requirement and appreciate the value of keeping in touch with the current technology.

Posted by

vminstructor

Posted on

March 10, 2014

Posted under

ESXi, Security, training, VMware, vSphere

Comments

New VMware vSphere Blog post on ESXi console lockdown

This week I am back in the classroom teaching a vSphere 5.5: Install, Configure and Manage class for VMware in Sacramento, CA. During the first few sections of the class, the ESXi user interfaces and basic configuration tasks are presented, including an overview of the tasks that can be accomplished with DCUI (Direct Console User Interface). The topic of lockdown mode is mentioned as well as how to configure an ESXI host to use Active Directory for user authentication and a little advice on user account best practices. As part of the discussion, I bring up the use of an “ESX Admins” group in Active Directory, the treatment of the Root user password as an “in case of emergency” item to be tightly controlled and the use of lockdown mode.

Today when I was leaving class, I was happy to see a new blog post from Kyle Gleed of VMware entitled: “Restricting Access to the ESXi Host Console – Revisiting Lockdown Mode” and in particular his 5 step recommendation on restricting access to ESXi with version 5.1 or later:

1. Add your ESXi hosts to Active Directory. This not only allows users to use their existing active directory accounts to manage their ESXi hosts, but it eliminates the need to create and maintain local user accounts on each host.

2. Create the “ESX Admins” Group in Active Directory and add all your admins as members to this group. By default, when an ESXi hosts is added to active directory the “ESX Admins” group is assigned full admin privileges. Note that you can change the name of the group and customize the privileges (follow the link for information on how to do this).

3. Vault the “root” password. As I noted above, root is still able to override lockdown mode so you want to limit access to this account. With ESXi versions 5.1 and beyond you can now assign full admin rights to named users so it’s no longer necessary to use the root account for day-to-day administration. Don’t disable the root account, set a complex password and lock it away in a safe so you can access it if you ever need to.

4. Set a timeout for both the ESXiShellTimeOut and the ESXiShellInteractiveTimeOut. Should you ever need to temporarily enable access the ESXi Shell via SSH it’s good to set these timeouts so these services will automatically get shutdown and idle SSH/Shell sessions terminated.

5. Enable Lockdown Mode. Enabling lockdown mode prevents non-root users from logging onto the host console directly. This forces admins to manage the host through vCenter Server. Again, should a host ever become isolated from vCenter Server you can retrieve the root password and login as root to override the lockdown mode. Again, be sure not to disable the root user . The point is not to disable root access, but rather to avoid having admins use it for their day-to-day activities.

Terrific advice and I appreciate the timing, I will definitely refer to this in class this week and in the future!