the use of lostandfound is to group all systems that could not be sorted with group IP or tag sorting.
So are your systems showing up at all in ePO?
Maybe you are thinking of rogue system detection (RSD)? RSD's purpose is to detect unmanaged systems. For this to work you need sensors in each broadcast domain that listen to broadcast from systems to identify which are unmanaged. THen from there you can push an agent to your detected systems, with the proper credentials.
No, no systems are showing up in the ePO yet. I haven't set up any tags yet, because I thought I could do that later - and just start out by moving the found computers (albeit currently none) into groups manually.
Right now I have the ePO server installed in its own DMZ (lets call it ePODMZ) - and a RAH installed in another DMZ (with a domain, lets call it DMZ1), with (I believe) all the proper ports opened in the FWs so it installed fine and shows up in the ePO Agent Handlers list.
Currently, the RAH server only has the services "McAfee ePolicy Orchestrator 5.1.0 Event Parser" and "McAfee ePolicy Orchestrator 5.1.0 Server" installed, so I guess in order to have the RAH "scan" the LAN of DMZ1 for unmanaged domain computers and populate them into the ePO, I at least need to manually install the McAfee Agent onto the RAH server - is that correct...? It will need the McAfee Agent anyway for protection of itself, but I thought that bit came with the RAH components...
- Will I not be able to scan for and propagate the domain computers from DMZ1 into the ePO without making a server on DMZ1, fx the RAH itself, a RSD Sensor?
- Is it not possible for the RAH to obtain a list of the domain computers from the domain in DMZ1?
- Or is the only option to add a RSD sensor to the RAH after having installed the McAfee Agent manually? I guess the RSD will probably also return all non-server equipment (network devices and such)?
Thanks a lot,
the McAfee agent needs to be installed on all your devices including the AH and ePO. You can creat an agent installation package (frampkg.exe) from the system tree then use that to install the agent. This package contains all the agent needs to communicate to ePO or the AH.
You can see the AH as a mini ePO: it is ePO without the management portion, So only two services. Don't infer anything else out of the role.It receives events and machine state; sends config updates (policy and tasks) and is a master repository copy.
Rogues System Detection (RSD) is an add-on that talks to the local McAfee agent which then talks to ePO/AH. It can be installed on any device with the MA (McAafee Agent). It needs to be able to see broadcasts. Its role is to send the system that it sees to ePO and to do minimum port scanning, nothing else. It won't install the agent. It just makes ePO aware of those systems. It will return everything that broadcasts.
AD Sync is also possible to make epo aware of systems. You need to define a registered LDAP server in ePO first. Then, from where you want to sync the systems in the system tree, you define what you want to sync (systems, OU). Once the systems are in the system tree, you can push the agent to them, with the proper credentials. Or it can be done as you sync with AD or detect with RSD.
The easy way to get you protected quickly might just be to import a list of IP in the system tree and then push the agent. Once the agent is there, then you can install the protection products.
First thing first, install your MA on the AH and get it to show in the system tree. If that fails then you have communications issues.
Thanks a lot for taking the time to clarify things.
I installed the MA on the RAH (from the FramePkg.exe on the ePO server) and it quickly apeared in Lost&Found below the domain name of the DMZ.
So just to cut it out for me: No computers will ever appear in the System Tree unless:
- I install FramePkg.exe (in which case I don't need to deploy the agent to it)
- If I enable a RSD sensor on the RAH
- If I add them manually by import (name, IP, whatever)
- If I setup AD integration
Ergo, there is no scanning of NetBIOS domain and computers within a network.
- I think I will setup LDAP integration to a DC in the domain, to see how that goes.
- And probably also enable a RSD sensor on the RAH to see what shows up.
Does that sound ok? I want to ensure that I continously get all running machines populated into the System Tree, so I'll see any unmanaged servers.
From F-Secure Policy Manager or SCOM I'm used to be able to scan a domain and return the unmanaged servers for easy deployment (albeit the version of FSPM we run don't work across DMZs).
Thanks again, really appreciate the help!
Glad that worked, now your next struggle will be how tomove the systems from lost and found to the proper group.... system tree sorting based on IP or tags, ldap sync or a combination of both,
1. framepkg.exe is the agent, it enablescommunication to epo. You always need the MA to communicate with a device, Once installed it provides you local sytem rights.
2. You have to install the RSD sensor on a device and configure it. It will start sending information that will show under "detected systems".There are automation steps, but basically once in detected system you can add them to the sytem tree and push the agent from ePO/AH or instal the MA manually
3. If youadd/import manually, then show up in the system tree as unmanaged, From there push the MA with proper credentials
5. also consider that you can install the MA using a startup script, integrate it in your image or use another system management tool (sccm ?)
So no scanning with ePO, but if you own mcafee vulnerability manager it does do scanning and that can integrate in ePO.
Your plan sounds go, connect to all your AD and sync the systems remembering you might sync systems that are down or have not been cleaned of AD. Try a push after that using domain specific credentials.. Setup RSD on a server in each of your zone, that will give you great visibility... in detected system, you'll be able to sort out computers from other devices based on the vendor information.
Don't hesitate to ask if you have other questions (and mark the question answered if it does answer your questions)
Btw. looking at the port requirements, the RAH should also have access via LDAP to the DC.
- Does this mean that bothe the local RAH and the central ePO should have network access via LDAP to the local DC?
- Or is it possible to have the RAH do the local LDAP lookups, so we don't have to open up in the firewalls?
When adding the registered server, it seems like all access is made from the central ePO, so I'd need to open up in the firewalls from the ePO DMZ to the other DMZs - it would be nice if this was not neccessary
The AH only talks to agents and to the SQL DB. The MA installed on it talks to the ePO server or the AH. Only the app server (that other serivce running on ePO) talks to LDAP.
The ePO server is the key it is the one that talks to everything.
Different organization have different setups: Operations zone or a more restricted security zone.
Thanks again, really appreciate your help a lot! Sorry to be such a McNoob.
Our networks are segregated and consists of many secure zones, some small and some large, so actually the only client on the central ePO LAN will be the ePO server itself (ePO App and ePO DB on the same server). Because all DMZ's will be "talking" into the ePO server we wanted to isolate the ePO server, i.e. not place it within an existing network with other servers around it. Currently we are looking at around 800 servers in total (but growing) shared across 30 DMZs or so, no clients. So agentwise a "small" setup, but networkwise probably a bit complex or at least very distributed. All DMZ's have highspeed LAN, so no WAN is involed.
The thought was to have all agents in each DMZ to talk to a local RAH in the same DMZ - and each local RAH talk to the central ePO server and DB. So in theory we will only have 30 connection into the ePO, one for each RAH on each DMZ. No agents will talk directly to the central ePO. I don't know it this is sensible but that was the thought, since we thought the RAHs could make both deployment and discovery easier.
To recap on LDAP = To have LDAP integration we need to open LDAP from the central ePO server to a DC in each DMZ / AD domain. The RAH's is not of any use in this configuration.
1) If this is the case I don't understand the port requirements, because it mentions "Outbound connection from the ePO server/Agent Handler to an LDAP server."
2) You wrote that the RAH "is a master repository copy". When looking locally on the RAH server I currently don't see a copy of the Master Rep. the same place as on the ePO server (no \McAfee\ePolicy Orchestrator\DB\Software folder). The RAH install folder only takes up around 40 mb of space.
2a) Do I miss some configuration that will enable the Master Rep. being copied to and cached on the RAH?
2b) Or should I setup a distributed repository on each RAH server, and then configure the agents in each DMZ to use both the AH and the new distr. repo. on the RAH server by policy?
3) If I need the agents on each DMZ to only talk to the local RAH on their own DMZ, I need a FramePkg.exe that will point them to the RAH server instead of the central ePO server, right? If I just transfer the FramePkg from the ePO server to the agent computer and install, it will point to the central ePO in the SiteLIst.xml and that will not work.
3a) If I import the servers into the System Tree and deploy the McAfee Agent specifying the RAH in "Push AGent using select Agent Handler" I guess (hope) the agent will automatically point to the selected RAH when installed rather than the central ePO (specifed in the default FramePkg.exe)?
3b) If I want to create a new FramePkg.exe that points to a local RAH, I create a new System in the System Tree for each DMZ and download a seperate FramePkg.exe (like detailed in KB51661), transfer to DMZ and install on all servers?
Sorry about all the questions, but still somewhat confused and don't seem to be able to find the right ansvers on the McAfee PDF's.
FYI I did create a Distributed Repository on the central ePO server that is accessible from the RAH server on the DMZ via HTTP, so the FramePkg.exe can be pulled down that way.
I don't know if this might have interferred with the Master Repository Cache not being replicated to the RAH as described in 2) above.
When reading up in the Master Repository Cache it seems there should be no configuration involved, so kinda perplexed in why the cache seemingly don't get replicated.
In Server Tasks there is an "Update Master Repository" task, but nothing about caching or sync'ing the repository onto RAH's.
I most overlook something...