Hi, in the first replication, the entire DB would have to be replicated over. MR4 allows resume on download, have you got the oppportunity to give it a try?

In addition, your main SEPM should be configured to keep more than the default amount of Content to ensure only the delta changes is downloaded.

I will give it a try once more, but the database file on the main SEPM is over 1 GB in size.

So a little patience is recommended :)

No joy :0(

After a little while i get "Unable to connect to the server specified"

Sorry, wasn't clear in my last reply. The Resume on download is meant for Content (e.g. virus definition) update.

If the vessel has more than one computer, you should create a group and assign a computer as a Group Update Provider (GUP), this will be use to distribute content to the rest  of the computers on the vessel.

Do take note that the clients still does regular heartbeat to the SEPM, and it is advisable to increase this value to an appropriate value.

The initial replication is always the entire DB, and will timeout if the link is broken. Subsequent would be the delta.

Refer to Page 108 on the Administrator Guide on GUP for more details.

OK.

I guess I must have a local management server on each boat.
I have tried the GUP and it fails. :o(

Think the problem would be solved if I were able to set the timeout value to 10000.

But now I have waited long enough,I were hoping MR4 would solve this issue.

How many clients are at each remote site?

Could you use an internal liveupdate server?

Why does the GUP fail to work?

Can they be setup to get updates from the internet?

Can they be setup to connect to a SEPM in a dmz?

Could you utilise third party tools to distribute updates?

Have you tuned the log settings?

If you give us more detail I am sure we can help :)

Z

On each site there is approx. 10-50 computers.

It is not the live update feature i am looking for.

The GUP times out because of the low bandwidth.

When I use one management server onboard, it recieves updates from symantec.

But the replication to the onshore SEPM server fails cause of the bandwidth.

Unless there is some way to tweak the timeout.

Hi All,

I have a similar problem (cant do two servers replicate). I have two servers and a link of 2Mbps.

When i install the second server (Additional site), the database starts replicating. It takes a long time to replicate (3GB of database). So, i leave the server replicating during the night, and in the morning i open the console and see:
    "JZ006: Cauth IOException:
     com.sybase.jdbc2.jdbc.SybConnectionDeadException: JZ0C0
     Connection already closed"

A offline replication would be a great deal (something like make a backup and restoring it in the remote site).

Regards
Vinicius

The break even point for installing a SEP Manager is probably around 200 clients at a single site.

This is assuming that all clients get updates every day and are only recieving 50-100KB

Heartbeat = 3KB/s
Policies = 20-80KB
AV sigs = 50-100KB if incrementaly updated each day
Logs = Compressed on the client with approx 800 log entries equal to 1KB
IPS Sigs = 50-100KB per quarter

- The SEPM will pull down a large amount of updates in a single download.

- Clients will pull updates down incrementally and also at random times.

The traffic is spread across a greater time period and as such doesnt max out your bandwidth for a long period.

I would just run the clients at each site reporting back to a central server in pull mode with a 1-4 hour check in.

Do some log tuning if you are still experiencing issues.

Z

"JZ006: Cauth IOException:
     com.sybase.jdbc2.jdbc.SybConnectionDeadException: JZ0C0
     Connection already closed"

I have this same problem.  I have yet to see any resolution.  Someone please at least recognize the problem even if just to say that there is no solution.

Folks,

I agree with zer0. For the portent's environment, a GUP maybe solve the problem. Besides, there's the possibility of a liveupdate server be installed. Unfortunately, GUP wont work for me. I have a remote site with more than 300 workstations.

Ive already checked everything (switches, routers, link, nics...). The replication stops and give me the "JZ006: Cauth IOException". I give up, because i have no idea why this is happening. Support didnt help either.

Next week ill try to replicate the server using the following procedure:
Ill make a virtual machine with the same settings of the remote server (same IP address and hostname). I will put this virtual machine in the same network of the Local server. So, VM will replicate fast (because they're in a LAN).

Then, ill make a backup VM's database, and copy it to the remote site (via wget or something that provides resume) and restore this backup in the remote server. I hope this work.
Later, i post the results.

Regards,
Vinicius

Great, looking forward to see how it ends up :)

ViniciusBarcellos,

Since MR3 a GUP can now support 1000 clients....This would be dependant on the resources on the GUP itself, like bandwidth, memory, cpu, disk, etc.

I would be tempted to make it a dedicated GUP and treat it like a SAV 10.x secondary server.

MR4 also introduced bandwidth throttling for GUP's, although you need to change some reg keys to configure it.

I havent tried it out yet, but am sure to run into a client that wants a GUP to handle hundreds of endpoints soon :)

Z

Vinicius,

Let us know how it works out.  i also have a case in with support and am still struggling.  This is a Major bug for me.  I have 12 sites that I want to replicate with the datacenter but only three have worked.  Testing is slow because of the replication times.  There needs to be an alternate method to add sites for replication.

QuadDog

I have exprienced this error and have tried more than 10 times without success. But I found out that the communication port to DB via port 2638 during the initial sync will close when sync time takes more than 4 hours. I assumed there is a Time-to-Live (TTL) for the DB during the sync process.

Currently still looking for the solution but I suggest performing everything at the local site and restore back the image file at the remote site will save you more time.

Sunny