VMware – Joining an ESXi 5.5 Host to Active Directory with PowerCLI

I spoke about restarting some ESXi services when joining a domain in this post. Here’s how you might want to do it with PowerCLI. Firstly, you may need to modify the execution policy for PowerCLI. It’s worth checking out the Microsoft URL in the test here, as it’s very useful background on what you’re actually doing by setting this policy. Also, big thanks to my colleague Michael for coming up with the syntax here, he’s really the brains behind the operation.


PowerCLI C:\Windows\system32> Set-ExecutionPolicy RemoteSigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust.
Changing the execution policy might expose you to the security risks described
in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the
execution policy?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):


Then when you connect to your vCenter host, you’ll get warned about the certificate. This assumes that you’re not using the right certificates in your environment (why are you like this?).


PowerCLI C:\Windows\system32> Connect-VIServer
WARNING: There were one or more problems with the server certificate for the

* The X509 chain could not be built up to the root certificate.

* The certificate's CN name does not match the passed value.

Certificate: [Subject]
CN=localhost.localdom, [email protected], OU=VMware vCenter Server
Certificate, O="VMware, Inc.", L=Palo Alto, S=California, C=US

  [email protected], CN=localhost.localdom CA af1bb298, O="VMware,
Inc.", L=Palo Alto, S=California, C=US

[Serial Number]

[Not Before]
  17/10/2013 12:22:09 PM

[Not After]
  16/10/2023 12:22:10 PM


The server certificate is not valid.

FUTURE RELEASE. To ensure scripts are not affected by the change, use
Set-PowerCLIConfiguration to set a value for the InvalidCertificateAction

Name                           Port  User
----                           ----  ----                 443   root


You can then get down to it. Firstly, you can join the domain with this command.


#To Join the domain: 
#get cred for joining the domain

get-vmhost | Get-VMHostAuthentication | Set-VMHostAuthentication -JoinDomain -Domain "network.internal" -Credential $cred


Once you’ve done that, you might need to restart those services I spoke about at the end of a previous post.


#To restart these pesky services:

Get-VMHost | Get-VMHostService | ?{"lsassd","lwiod","netlogond" -contains $_.Key} | Restart-VMHostService


Once you’ve done that, you can check if it’s all working with this command.


#check to see if you have any auth issues

get-vmhost | Get-VMHostAuthentication


And you should be good to go.

VMware – SRM 5.8 – You had one job!

The Problem

A colleague of mine has been doing some data centre failover testing for a customer recently and ran into an issue with VMware’s Site Recovery Manager (SRM) 5.8 running on vSphere 5.5 U2. When attempting to perform a recovery, and you’re running Linked Mode, and the protected site is off-line, the recovery may fail. The upshot of this is “The user is unable to perform a recovery at the recovery site, in the event of a DR scenario”. Here’s what it looks like.



The Reason and Resolution

You can read more about the problem in this VMware KB article: Performing a Recovery using the Web Client in VMware vCenter Site Recovery Manager 5.8 reports the error: Failed to connect Site Recovery Manager Server(s). In short, there’s a PowerShell script you can run to make the recovery happen.




I don’t know what to say about this. I’d like to put the boot into whomever at VMware is responsible for this SNAFU, but I’m guessing that they’ve already had a hard time of it. At least, I guess, there’s a workaround, if not a fix. But you’d be a bit upset if this happened for the first time during a real failover. But that’s why we test before we handover. And what is it with everything going pear-shaped when Linked Mode is in use?


*Update – 29/10/2015*

Marcel van den Berg recently pointed out that updating to SRM 5.8.1 resolves this issue. Further detail can be found here.