Community
Vault Forum
Welcome to Autodesk’s Vault Forums. Share your knowledge, ask questions, and explore popular Vault topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Vault Collaboration 2012 Multi site communication failure.

10 REPLIES 10
Reply
Message 1 of 11
michael.horsler
523 Views, 10 Replies

Vault Collaboration 2012 Multi site communication failure.

We currently have Vault 2012 Collaboration. I have setup a Vault on our main site and wish to replicate onto another site.

Site 1: Vault 2012, Full SQL 2008 R2.

Site 2: Full SQL 2008 R2 with Autodesk Instance defined. No ADMS.

 

When attempting to setup a workgroup from Site 1 it states it cannot find the SQL instance on site 2. I have tried the default sa account, and my network account of which I'm administrator to both servers.

 

However if I use the SQL Management studio, I can successfully logon to both site instances ok. (In both directions)

 

I have the alias defined for AUTODESKVAULT. Both sites are set for remote connections.

Sharing is enabled via TCP-IP. I have preset to port 1433.

Using a port scanner Port 1433 is open on both servers. Connecting via SQL Management studio the scanner shows port 1433 with successful communication.

Obviously Port 1433 is required for SQL, port 80 for IIS and UDP Port 1434 for SQL. Are there any others I am missing or do you have any other suggestions for my communications failure?

 

We do not have any local firewalls setup on the servers, and we use a cloud hosting service to provide the communications between sites. 

 

Many thanks in advance..

10 REPLIES 10
Message 2 of 11

Update: It transpires UDP1434 is blocked between our sites. This is specified as a company security policy and not negotiable.

However as I understand it UDP comms is a destinationless communication protocol so it floods the network. Therefore it is often common practice to block UDP comms anyway on a WAN. So the practice of using a specified SQL instance gets around the requirement to use the browser service to locate an instance. Therefore seeing as its only the browser service using the UDP comms, why is it required since the Vault SQL instance is always called AUTODESKVAULT?

Is there another route around creating a replicated environment without the use of UDP comms?

Message 3 of 11
paul.gunn
in reply to: michael.horsler

Hi,

 

In general the sql browser service is needed any time you have a named instance. It is needed to determine the correct TCP port to use for that named instance.

 

I think it may be possible to circumvent the browser service if you are using a static port for the named instance and then set up an alias on the application server to specify that port:

http://www.rdacorp.com/2008/07/use-sql-server-alias-to-connect-to-a-named-instance-through-firewall/

 

That said, the simplest solution if possible would be to get an exception for the 1434 traffic. This is normal SQL server functionality so wouldn't seem to objectionable - and going with the mainstream solution would simplify your life.

 

Paul

Message 4 of 11
michael.horsler
in reply to: paul.gunn

Thanks for your reply, unfortunately they are unwilling to open UDP1434. As you say, the standard solution would have simplified things greatly.

I already have an alias on the client which allows connection via SQL Management studio with a static port. Plus specifying the port in the connection string also connects ok. However Autodesks Vault replication doesn't provide an option to specify a port (unless I'm missing something! 😉 ) so I cannot create a workgroup or connect to the remote database.

Message 5 of 11
paul.gunn
in reply to: michael.horsler

Hi,

 

You're right that the connected workgroups UI doesn't take a port but it seems like if the alias matches the target connected workgroup then the alias should be used automatically (e.g. make the alias name remotemachine\autodeskvault).

 

That said, this will get really complex with connected workgroups . Each subscriber SQL machine would also need to have an alias for the publisher. Each ADMS would need an alias for their SQL server, The publisher SQL machine would need aliases for all of the subscribers. This is assuming that SQL replication even uses the aliases correctly.

 

Given all this I'm not sure I can really recommend the alias route if you are using connected workgroups. For better or worse, SQL was really designed to use the browser service in these cases.

 

Paul

Message 6 of 11
michael.horsler
in reply to: paul.gunn

I've tried creating aliases on the subscriber and publisher but still no joy.

The alias works with SQL Management Studio, but not the workgroup UI or remote database setup so it does prove the alias appears to work in some respects.

Message 7 of 11
paul.gunn
in reply to: michael.horsler

Hi,

 

SQL replication has its own special requirements. One is that the SQL server netbios names remain static - i.e. you cannot change the server name of a replicating machine. Given this, it isn't too surprising that replication might not play well with aliases. There are a few threads online regarding inability to use aliases with replication.

http://social.msdn.microsoft.com/Forums/en-US/sqlreplication/thread/1ac8a8ff-2cec-4595-b2ed-75463679... 

 

I'm afraid that in order to use the connected workgroup functionality, the SQL browser (1434) functionality looks like a necessary requirement.

 

Paul

Message 8 of 11

No problem, I'll attempt the remote filestore process instead.

 

I've preinstalled SQL Express on the subscriber just to be able to create the alias, however the Vault install still states it is unable to locate the AutodeskVault instance on the publisher, which also has an alias to the subscriber server.

 

I've ensured server & alias names match. Again the alias works via SQL Management Studio.

Message 9 of 11
paul.gunn
in reply to: michael.horsler

Hi Michael,

 

I am a little confused by your intentions at this point. If you are still talking about having a publisher and subscriber, then that is a connected workgroup scenario which involves sql replication (which would be problematic as discussed).

 

Are you talking about just multi-site without connected workgroups? ie. one SQL server and multiple ADMS servers?  If so, do you have a sense of the latencies involved between ADMS and SQL? Multisite doesn't perform very well with high latency (one reason connected workgroups were created) so I'd hate to see you spend effort creating a configuration that won't work well for you.

 

Paul

 

 

Message 10 of 11
michael.horsler
in reply to: paul.gunn

Hi Paul,

 

I was only using the description to highlight which server I was refering to. 

 

Preferrably I wanted to create a connected workgroup scenario as you say to maintain speed / useabiltiy etc. However with our WAN setup it doesn't appear as though that is going to be possible.

So in one way or another, I need to create some kind of replication between our sites to allow collaboration on design projects as our design team is now split between the sites. My intention was now to run one SQL and multiple ADMS servers. However mentioning this multi-site setup doesn't operate very well with high latency, what level of latency are you refering to?

 

Is there a different approach I could take to attempt to achieve my goal?

 

Thanks,

 

Michael

Message 11 of 11
paul.gunn
in reply to: michael.horsler

Hi,

 

As a rule of thumb, latency between ADMS and SQL should be under 100ms. If latency gets much higher than that it may be more performant for client applications to just connect remotely to a single ADMS (close to SQL) over WAN.

 

Paul

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report