Reporting from the field Issue #2: Active Directory/DNS Changes post implementation of vSphere – Lessons Learned


I love working with customers.  It’s challenging and rewarding at the same time.  Sometimes it can be more challenging but how you rise above those challenges is where the rewards are really noticeable.   Working with a customer recently, they had some challenges around their current Domain.  The Domain consisted of a couple of Windows Server 2003 systems running a Windows 2000 Native Domain.  After my implementation, one of the recommendations I provided was a migration away from the Legacy 2k Domain and to modernize and re-architect their Domain/DNS Structure.

Fast forward a couple of weeks, and I started receiving emails about loss of access into their vSphere Infrastructure I had just installed.  The first question I always ask when I get on the phone in situations like these is “Did anything change?”  The answer to this question was  yes…which is typically what I find.  This customer took my advice and they did implement and upgrade with two new Windows 2008 R2 Domain Controllers and a change to a Windows 2008 R2 Native Domain.

Two things that popped in my head.  One, this must have broke Single Sign On as the Identity Source must not be valid.  The second, the Domain I joined for the vCSA is more than likely invalid.

I logged into the vSphere Web Client with an SSO admin account and when I went to look at the Identity Sources, I received this error:

 ‘alias’ value should not be empty

I immediately connected to the Admin Console of the vCSA: https://yourvCSAHostname or IP:5480

CapturevCSA

 

 

 

 

 

 

 

 

I then selected Configure SSO

CapturevCSA1

 

 

 

 

 

 

 

 

I noticed that the SSO Deployment Type was showing UNCONFIGURED.

I setup SSO again then moved on to rejoin Active Directory here:

CapturevCSA2

 

 

 

 

 

 

 

 

I then rebooted the vCSA logged back in as SSO Adminstrator, reconfigured the Identity Source, and removed and re-added my user permissions.

CapturevCSA3

 

 

 

 

 

These steps resolved the issues.  Customer could now connect and work within vCenter.

Lessons Learned: In this case I made my recommendations to my customer which they happily followed, however, I was not thorough in explaining the impact that this would have on their Shiny new VMware vSphere Infrastructure.  Of course, this should have been explained in detail to them and the upgrade should have been scheduled in cooperation with us.

Take away: Communication with the customer is key.  Point out risk, and always be upfront as to how changes can impact the environment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s