If you click on that error, you’ll see at the bottom where it shows comparisons of hosts and the advanced configurations:

It shows VSAN.DomMaxLeafAssocsPerHost and VSAN.DomOwnerInflightOps as being different between a few of my hosts. Looking at the image above, you’ll see node 09 has values of 36000 and 1024, respectively, while the other nodes 10-12 show 12000 and 0.

I immediately went to the host configuration advanced settings in the web client, searched VSAN and don’t see either of those. I even checked through PowerCLI and can’t see those:

Or in the GUI:Lost connection to remote SRM server. Unable to login. The maximum number of SRM users has been reached.RJ, from RJApproves.com, & I had been plagued by these messages for weeks, maybe even months. Well, we finally got it all figured out!

On May 25th, I published this post covering some scenarios on how to use Site Recovery Manager & Active Directory. Michael White from VMware responded with some good info. He had an awesome suggestion of using a script to cold clone a DC daily to use for testing.

To include Active Directory or not to include Active Directory, that is the question.

I’ve been reading a lot around VMware’s Site Recovery Manager and considerations surrounding Active Directory. Most of what you will read says ‘NEVER’ protect AD with SRM, only use native AD replication, especially since SRM & vCenter at your Recovery Site require AD to be running anyway.

But what if you have multiple domains for different uses? This is where the lines become blurred. Think about this for a second:

A second AD environment (also single forest/domain, no trusts) for your application servers, call it application AD

You have infrastructure AD at both sites, SRM & vCenter authenticate accordingly

Protected site has application AD

Recovery site has nothing

Now here is where I say ‘why wouldn’t you protect AD with SRM?’ In a true disaster, the protected site is gone, no AD exists anywhere, so using SRM to bring them up on the recovery site makes sense. Is my logic flawed?

However, if I had my application AD living at both sites, using native replication, I agree 100% in not including your Domain Controllers in your SRM Recovery Plan. This leads to my concern…

If you click skip from there, it’ll fail to create the tables, and eventually get to the point where you’ll have to roll back.

As it turns out, it was due to a c0mp73x”P@s$w0rd! that caused the problem. I’m not sure what characters killed it, but going to a less complex pAs5w0rd worked fine. ODBC worked fine, user & permissions were set up properly, it just came down to SRM not being able to handle the special characters. What’s strange is a similarly complex password works for vCenter.

I recently had this problem, but forgot to take a screenshot for the blog, sorry guys.

I was patching an HA/DRS cluster using VUM and none of the VMs would migrate off one specific host. The error it gave was “A general system error occured: Failed to start migration pre-copy Error 0xbad010d. The Esx host failed connect over the VMotion network”.

So you’re still using ESX 3.5 and need to patch it manually? Bummer, I know, I’m in that boat right now, or was. I ran “esxupdate -a query” to find out the latest patch and saw, “ESX Server 3.5.0 Update 4”. Then went to VMware’s downloads site to download Update 5a, and when it prompted me to download all dependencies, I did.

What did that give me? Nineteen (19) bundles/depots/zip files, one of which was ‘ESX350-Update05a.zip’