I'm after some advice on how to best set up repo's for our network.
We have 1 main "HQ" site where the EPO Server is installed, which resides on a Management VLAN (it has access to all other VLAN's on the physcial network). All other Nodes on this site are on their own VLAN which has no visiblity to other VLAN's (it's a business park if that helps you understand).
We also have several other remote sites, ranging from 10-50 nodes.
Some points to take in:
The remote sites are completely seperate to the main network - i.e no VPN's or anything like that.
The remote sites are generally low bandwidth (mainly ADSL)
The remote sites run completely seperate AD domains, some are Workgroups.
We are providing AV as kind of like a MSP role.
My goal is to get all the systems showing in the main EPO system tree so we can report and create policies for each customer centrally. I also want each site to have a repo of some kind to minimise bandwidth use.
I am reading through the manual but I still dont really undersstand the differences between a SuperAgent Repo and the rest. As far as I am aware the other types of repo's are essentially just a specified location with the transport protocol defined as HTTP/FTP or UNC (SMB/CIFS?).
As the EPO is installed on a server in a Workgroup, we are having to manually run the "FramePkg.exe" file on each node on the rest of the machines on this site which then installs the Agent to pick up the install task/policies - this is ok on the main site (albeit very manual) - is there a way to configure EPO to deploy instead? I.E Browse systems via an IP range (I am aware we will have to provide credentials to install but that is ok) and select them to deploy.
Furthermore, if we run this FramePkg on nodes on remote sites I am guessing it will not work as it will not be able to see the central EPO. How should the agents be deployed in this case?
Wow, what a setup. This is not an answer, just a suggestion and more questions...
I've included two links to documents that I don't know if you've read or not but they should help with figuring out bandwidth usage for those remote sites and whether you need a Distributed Repository (DR) or not depending on how many systems you actually have in those environments.
If there are only 10 to 50 nodes, you might not need to use a repository because that would actually take more bandwidth depending on what the DR is storing and how often you decide to make changes to your software versions or policies.
The agents must be able to contact the main ePO server. The ePO server tells the DR to install a specified product which takes the load off the ePO so it needs to be able to communicate with the ePO. The only other way to make this work is to deploy an ePO in each remote VLAN which doesn't fit into your plans.
Even if you setup the DR, how do you expect the DR to contact the HQ ePO server to get the updates? That is a lot of configuring, good luck!!!
At 10 to 50 Nodes per site it is my experience you will not need remote repositories. Unless the links a very slow (256MB or less). I use Super Agent repositories with the Lazy Caching turned on. All my network bandwidth issues went away. No more pushing 100MB every night. Nothing to manage or worry about.
For DAT and other content update you need lots more than 50 nodes to worry about nightly bandwidth issues for normal updates.
The only time having remote repositories really helps is during product updates. Or new builds with VSE needing the 100MB original DAT file.
You can deploy the Management Agent (framepkg.exe) from within ePO. You will need an account that has Administrator Privledges on the target machine. You can manually do by selecting the machine in ePO. Or as I have done set up a nightly server task. It runs a report that finds all machine that report no ePO client, and then deploys the agent to them. We get all new machines into ePO by a sync with AD.