SRM Setup Issues

staticz

Limp Gawd
Joined
Feb 19, 2008
Messages
184
I'm building out an SRM 5.1 environment and keep getting the following error when the primary site tries to connect to the secondary -

'The request failed because the remote server (secondary SRM IP) took too long to respond.'

Any thoughts on what might be causing this? If I try the reverse (connecting secondary to primary) I get the same error. I've confirmed the account credentials are correct and that the SRM servers can ping each other. What am I missing?
 
Most likely ports. You using NAT or VPN?

No the sites are actually in the same building and then will be connected via private fiber (no VPN or NAT) once it moves to production. I've got a call scheduled with VMware but they keep pushing it back :mad:
 
PM me your SR number. I'll take care of it.

Wow, thanks for the offer! I was able to get it taken care of, but I do appreciate that.

Today on a whim I went through the 'break connection' and started over...it worked!

One question for everyone - is it safe to use domain accounts with SRM? We have 1 physical DC and the rest are virtual. If the primary site goes down and, hypothetically, the physical DC goes down as well, will SRM still be able to do it's thing?
 
Wow, thanks for the offer! I was able to get it taken care of, but I do appreciate that.

Today on a whim I went through the 'break connection' and started over...it worked!

One question for everyone - is it safe to use domain accounts with SRM? We have 1 physical DC and the rest are virtual. If the primary site goes down and, hypothetically, the physical DC goes down as well, will SRM still be able to do it's thing?

You'll want to have a DC at the DR site. SRM (more specifically, Microsoft) doesn't support failing over Domain Controllers (the database doesn't take kindly to it, and you'll get sync issues). The "right" way to do it is have a single DC at the DR site for the vms that end up there. And then yes, it's safe to use domain accounts (multisite/linked mode in 5.1 requires it, in fact).

edit: and I'd still like the SR number, to make sure the case was handled right :)
 
You'll want to have a DC at the DR site. SRM (more specifically, Microsoft) doesn't support failing over Domain Controllers (the database doesn't take kindly to it, and you'll get sync issues). The "right" way to do it is have a single DC at the DR site for the vms that end up there. And then yes, it's safe to use domain accounts (multisite/linked mode in 5.1 requires it, in fact).

edit: and I'd still like the SR number, to make sure the case was handled right :)

Cool thanks for the info. I spoke too soon because this morning I'm getting the error again

'No client connection to SRM Server for Remote' Request failed because the remote server took too long to respond.

Not sure what is going on.
 
Does anybody got the VMware Site Recovery Manager 5.0 or 5.02 a copy of the installation files somewhere.
im in serius and urgent need of this for testing before buying and vmware doesn't allows me to download version 5.0.2 which is the one i need base on previous talk with colleagues. Help please
 
Finally getting around to setting up SRM, and I'm getting the same error. Been driving me nuts, waiting on an engineer to get a hold of me.

After configuring the site pairing, my remote vCenter looks fine showing both sites. My local vCenter gives an error:
[Tue, 1:04 PM] The request failed because the remote server 'vcenter1.domain.com' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)(The command has timed out as the remote server is taking too long to respond.)

Local site shows Not Connected and remote site shows Unknown. Logs don't seem to indicate anything of relevance either. Anyone been through this error before?

My remote site is actually a rack over right now, just trying to get this up and running and not having much luck.
 
Are you running 5.1? If so are you running 5.1.0b? Seems this was resolved in that version.
 
Running what I believe to be the latest build of SRM - 5.1.1 1082082 on vCenter 5.1.0 880146

Thought at first our temporary VPN tunnel might have been interfering, have since taken that completely out of the mix. All local L2 connectivity now, still the same issue.
 
After an extensive call with an SE this morning, we've narrowed it down to an issue with account permissions.

When I log into the primary site with the account used to establish the site pairing, everything works fine.

Still trying to sort out why a domain admin account works from the remote site but not from the primary site. Pretty bizarre issue.
 
Yes, both windows with local SRM installation & databases. Running internal CA signed certificates.

I think it's a bug, or I don't fully understand the permission requirements for site pairing.

Let's say I have servers VC1 (protected site) and VC2 (recovery site). A Domain user DOMAIN\vcenter1 has administrative rights to VC1, and DOMAIN\vcenter2 has administrative rights to VC2.


I am logged into both VICs with another domain account, with domain administrator privileges.

When I established the site pairing, I did it from the VC2 VIC, and entered DOMAIN\vcenter1 credentials to authenticate with VC1. Took a few seconds and everything came online.

vSphere console on VC1 prompted for credentials to VC2, entered DOMAIN\vcenter2 in and the request eventually hits its timeout limit & drops.

I have since added Domain\vcenter1 as a local administrator to VC2, logging into the VC1 client with vcenter1 credentials will now show an active pair, but logging in with my domain administrator account will not. :confused:
 
Ok, I can almost GUARANTEE your certs are bad or you have an idle connection issue. Which doc did you use for signing the VC certs? I'm in the middle of rewriting all the SRM ones right now.
 
Ok, I can almost GUARANTEE your certs are bad or you have an idle connection issue. Which doc did you use for signing the VC certs? I'm in the middle of rewriting all the SRM ones right now.

I've always followed this KB for VC certs:
http://kb.vmware.com/selfservice/mi...ype=kc&docTypeID=DT_KB_1_1&externalId=2034833

It's always been painful, too. Seems that every support engineer I've engaged with any issues will also agree.

I am almost to the point of a complete wipe & redeploy of three VC environments and going back to self-signed.
 
Back
Top