Video Screencast Help

Unable to connect to the server specified when first replicating

Created: 07 Mar 2013 • Updated: 07 Mar 2013 | 5 comments

We are creating an additiional server for Asia Pacific, the current database is about 16GB. So, whenever I do the first installation, the server will need to replicate with our US server. Unfortunately, everytime when we do the replicating, it will show "Unable to connect to the server specified" after 15 mins of replication and then it failed.

Question, is there a way for me to setup the server first and replicate the database later?

Operating Systems:

Comments 5 CommentsJump to latest comment

Rafeeq's picture


Try this document

Make sure all the ports are opened on the firewall ( 8443 for replication)

if it fails post the scm-server0.log found under the sepm\logs folder

How to perform offline replication between 2 remote sites when normal replication is failing due to bandwidth issues
Sachin Sawant's picture


Best practices for replication server sizing

How to add "Replication Partners" and Schedule Replication

Best Practice for setting replication frequency

How to install the Symantec Endpoint Protection Manager(s) for replication

How to Perform Offline Replication between 2 Remote SEPM

A. Wesker's picture

Hi Kian,

As you described your issue, it might come from a very simple thing, however it needs to be confirmed.

It would be great if you can confirm exactly when the issue occurs because you mentioned it failed after 15 minutes but I guess you mean it fails 15 minutes after the has been successfully created on your SEPM Master Site (US Server), Is it correct ?

Anyway you can verify that very easily.

Check on the SEPM install folder of your US Server, you will have basically the file located to the following directory.

%Symantec\Symantec Endpoint Protection Manager\data\replication\outbox\

Then a folder with a very long ID and then inside you'll find a folder data or depending if it's successfully created until the end of the process.

At least you can even try to run again the replication from your ASPAC Server and see if the is successfully created on your US Server in the outbox subfolder of replication folder.

On your ASPAC server then you can see if you're receiving or not progressively in the Inbox subfolder of replication folder your

From what you described, I would say your replication issue may come from 3 different and possible sources.

1) Special caracters used on SEPM and Database password.

If you're using special caracters on the password of your SEPM and your Database. The connection to the remote will fail straight way. If you're in this situation. I would advise you to reset your SEPM password and dba password as well with only digits and letters and try to run the replication again from scratch on your ASPAC server.

Please note that using special caracter on your database will make you unable to perform a load Database tasks like restoring a Database from a Backup and Replication.

In later releases it will not be a problem anymore.

2) Network bandwidth issue/Packet loss during transfer

You're already using a simple password for your current US SEPM and Database server, there is some packet drops that occurs during the transfer of the which results a time out during the replication.

In this situation, I would recommend to follow the instructions from the KB that Sachin already mentioned on the post before.

How to Perform Offline Replication between 2 Remote SEPM

/!\ Note that if you have a sort of proxy or firewall set on the network that use your both servers to communicate each other, ensure the time out settings have been increased because replication performs TCP connection with port 8443 and may stay in idle during all the replication process (especially during transfer) and it even might take a long time as your current database size is 16Gb so the to transfer between the both server during the first replication will be for sure over 8~10Gb.

3) LiveUpdate/Replication Conflict

If a Live Update session is running on your US Server during the replication, as Live Update is using a common process with the replication which may result that Live Update forces the unlock of this common process used by the replication in order to run in priority over it.

In this situation, just change the schedule of your Live Update on your US Server and run it once manually in order the changes performed on the schedule are applied and then wait to run your replication during hours when Live Update is not supposed to be running.

Hoping that helps cool

Kind Regards,

A. Wesker

AjinBabu's picture


Weather the ports are open for replication. And please make sure the bandwidth while replication time.




Weather the ports are open for replication. And please make sure the bandwidth while replication time.



Dogan Akyildiz's picture

it's may be about disk size .

if there is no enought size on parent site replication will be start bu not finish with successfully.