it all depends on the firewall rules you'd be willing to put in.
They could have direct access to log on or you could us roll up reporting to copy flattened data table from the new to the old. For this to work, the old ePO need to be able to talk to the new db server.
Thanks Andre, although do you have sample configuration for this?
For the roll up reporting, the roll up server (existing) needs access to the new sql server on tcp 1433, unless using an instance then you need to use the instance's port
Understand that roll up is just flat files:when you click on a system, it is the only thing you can see. You can't drill down to events. Same thing the other way around. So a little bit like export to a csv.
Simplest is to have firewall rules allowing all clients to connect to the new ePO. Managing two ePO is more work than one. Some might suggest an agent handler, but that requires opening up the firewall for ePO and SQL.
It really depends on requirements and constraints
Hi again Andre,
This is basically the architecture, there's an existing Corporate ePO and we are adding 2 more servers for the new plant we are building.
1. DMZ ePO will get update files from Corporate ePO.
2. Office ePO will get update files from DMZ ePO, install agents to clients, monitor and manage clients and enforce policies.
Now we want to know how the Corporate ePO will be able to monitor events on the Office ePO.
You can't real time monitor from one ePO to the other one. Best bet is one ePO server behind the firewall and ensure all your agents can talk to you ePO . An ePO server, properly sized, can handle hundreds of thousands of clients.
Alternatives is to procure a SIEM tool to integrate events from your ePO server, firewall, etc... (Like HP Arcsight, McAfee Nitro, IBM Qradar, etc)
To me a few firewall changes and a single ePO is the easiest and less costly.
Well I guess the best bet I have is the roll-up reporting.
Anyway, thanks again Andre! You've been really helpful.