As i am reading in the EPO 4.5 the person who is resposible to just administrate the EPO server and agents ont he network has to be a domain administrator, so in the forest root domain this means he is also a schema administrator by default... What a poor design.Please prove me wrong.
Deploying the agent via push technology
Use this task to deploy agents to your Windows systems using ePolicy Orchestrator.
This method is recommended if large segments of your System Tree are already populated.
For example, if you created System Tree segments by importing domains or Active Directory
containers, and you chose not to deploy the agent during the import.
Before you begin
To use this method, these requirements must be met:
• Systems must already be added to the System Tree.
If you have not yet created the System Tree, you can deploy the agent installation
package to systems at the same time that you add groups and systems to the System Tree.
However, McAfee does not recommend this procedure if you are importing large domains
or Active Directory containers. Those activities generate significant network traffic.
• The account specified must have local administrator privileges on all target systems. Domain
administrator rights are required on a system to access the default
Admin$ shared folder.
The ePO server service requires access to this shared folder in order to install agents.
Am i asking the question in the right location?
I've moved this to our ePO area. Hopefully an expert can chime in here.
Thanks, but our research team dont have long as it looks like the other research team will win the project for the 34 site locations. They are researching the solution from symantec as were are getting support from them.
have you considered deploy the agents initially by other means as push? E.g.you can create a custom agent package with embedded (domain admin) credentials and deploy it via login script?
Thanks for the post,
As we are not respocible for the deployment of the agent or packages but we are respocible for the security of the domain and what patch and dat version is allowed to be deployed on the domain we have no access to the patches or engines to do this. We have the right to insist on the virus application to deploy over the 34 locations but we need to point out all te security pro's and con's of doing this currently for McAfee they have a large red wording of they require domain administration.
However we are looking at deploying the agent with a login script, but the 3rd party companies argumant is, ATM they want to be able to push the agent out from the Web interface which needs domain administration.
Currently we are having to build a new domain because they crashed the schema the last time they had domain administration access, so the client has said they are not to have domain administration rights, but due to the contract they are still the Antivirus and backup administrators.
I have read through the documentation and understand most of it and understand most of the solutions but looking for help from the experts.
Pushing the agent to existing placeholder nodes really requires knowledge of a domain admin account and password (although knowledge of one does not require being of one).
Another option could be using rogue system detection, because you can define a rogue system action for detected nodes, which involves an agent push, fairly automatic, and the domain admin id and password need only be entered once (possibly without the presence of the 3rd party contractor) in the action definition.
Apologies for coming to the thread late...
The primary issue here appears to revolve around the permissions required to perform a push agent install - where the agent is sent to a client machine from the ePO server / agent handler via the console. (Please correct me if that's not correct.)
If this is the case, then as far as I know, domain admin rights are not required: local admin rights are, however. I'm not sure why the product guide specifies domain admin rights for accessing the admin$ share: I'll try and clarify that - it may be a documentation error.
KB 60351 details the requirements for push installs - it's not completely up to date but it's still relevant. Permissions are only part of the picture for push installs to succeed - as per the article lots of other things can affect pushes, such as removal of admin$ share, windows firewall settings and so on.
1) I believe only local admin rights are required
2) I'll try and confirm this as soon as possible
3) Rights are not the only issue affecting push installs