joukiejouk
asked on
How do I use the ePolicy Orchestrator 4.6 to remediate outdated workstation's DAT file?
I need to learn how to use the console to do this. I am a newbie to it. If anyone has instructions, please provide.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
also need to ensure the supported version of the client component for VirusScan Enterprise (VSE) in the Support Version, Patch/Hotfix and Extension Build, see table in below.
https://kc.mcafee.com/corporate/index?page=content&id=KB69814
Some of them faced same issue due to lacking extension installed
https://community.mcafee.com/thread/34252?tstart=0
Besides that
https://kc.mcafee.com/corporate/index?page=content&id=KB69814
Some of them faced same issue due to lacking extension installed
https://community.mcafee.com/thread/34252?tstart=0
Besides that
to fix this at the moment is to delete the machine from ePO - do not select the "unistall agent" option - and then wait for the machine to communicate with ePO again. When it does, it will reappear with the correct values and should then show up as compliant.https://community.mcafee.com/message/188325#188325
ASKER
in the ePO, how do I check if machines have auto-update set daily to check in with ePO?
The autoupdate task that you can see in the VSE console is the default task created by VSE when it is installed. Also it is It's not possible to modify this task from ePO and all we can do is disable it.
I understand that even if we create update tasks in ePO which is sent down to the client machines as new, separate tasks, there is nothing we can see in the VSE console. Apparently, the way to see if they are running is to check the agent log. E.g. if the task created was called "Daily Update for VSE", then upon task running we should see an entry like "Invoking task 'Daily Update for VSE'" in the agent log. For client machine, the agent task folder is typically in C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Task by default.
I understand that even if we create update tasks in ePO which is sent down to the client machines as new, separate tasks, there is nothing we can see in the VSE console. Apparently, the way to see if they are running is to check the agent log. E.g. if the task created was called "Daily Update for VSE", then upon task running we should see an entry like "Invoking task 'Daily Update for VSE'" in the agent log. For client machine, the agent task folder is typically in C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Task by default.
ASKER
I removed machines that have the latest .DAT, in which were listed in the non-compliant list. However, they re-appeared as being non-compliant again after communicating back with the ePO server. How can we fix this? Should the dashboard be re-created or refreshed? If so, can you please provide instructions?
Maybe to verify following
- Check the extensions for VirusScan are installed in EPO (Menu=>Software=>Extension
- Check the DAT version running query, you can run saved queries on-demand. e.g. Click Menu | Reporting | Queries & Reports, select VSE: DAT Deployment in the Queries list, then click Actions | Run.
- Check the query being used in the dashboard to display the compliance check, some query can be hard coded to specific version of releases. We can either change the query to see if it corrects or upgrade the machine accordingly to the query criteria stipulated. E.g. under the Criteria from The Compliance Report under Reporting
- Dashboard monitors are refreshed automatically on a user-configured interval (five minutes by default). You should be able to Dashboards, and Edit its Dashboard Preferences from the Options drop-down list. The Dashboard page refresh interval is available and you can adjust as the number of minutes you want between refreshes.
Another to refurnish the client
- (can be tedious) Manually in each non-compliant station re-install the client package
- from EPO, create a schedule to do uninstall, then a re-install, then run an AD Sync. Some may go to extend of creating a server task to automate such that clients failing in certain areas like not checked in for 3 days to redeploy new agents, this force push can be option.
Admin guide - http://www.mcafee.com/us/resources/misc/guides/ms-epo-product-guide.pdf
- Check the extensions for VirusScan are installed in EPO (Menu=>Software=>Extension
- Check the DAT version running query, you can run saved queries on-demand. e.g. Click Menu | Reporting | Queries & Reports, select VSE: DAT Deployment in the Queries list, then click Actions | Run.
- Check the query being used in the dashboard to display the compliance check, some query can be hard coded to specific version of releases. We can either change the query to see if it corrects or upgrade the machine accordingly to the query criteria stipulated. E.g. under the Criteria from The Compliance Report under Reporting
- Dashboard monitors are refreshed automatically on a user-configured interval (five minutes by default). You should be able to Dashboards, and Edit its Dashboard Preferences from the Options drop-down list. The Dashboard page refresh interval is available and you can adjust as the number of minutes you want between refreshes.
Another to refurnish the client
- (can be tedious) Manually in each non-compliant station re-install the client package
- from EPO, create a schedule to do uninstall, then a re-install, then run an AD Sync. Some may go to extend of creating a server task to automate such that clients failing in certain areas like not checked in for 3 days to redeploy new agents, this force push can be option.
Admin guide - http://www.mcafee.com/us/resources/misc/guides/ms-epo-product-guide.pdf
ASKER
I removed a large number of machines from the non-compliant list, but did not remove the agents. Now, it appers they re-registered and still ended up on the non-compliant list, but with no info. Is this a problem? If so, how can i fix this? I just did a "wake-agent" and "update now." See screenshot attached.
ePO.png
ePO.png
ASKER
Just to add, we had a server that ended in the 'lost and found' container. It was a server that had been removed from the non-compliant list, but I did not remove the agent. We moved the server back to it's appropriate container. Now I am am tasked with finding a root cause, as to how it ended up in the lost and found container. How would I check the log for this? i had a feeling this happened when I deleted it from the non-compliant list.
wondering if we can query the sql on the state for those "empty" version workstation, see this
One suggested the below in reinstallation VSE steps
https://community.mcafee.com/message/252308#252308
As for those in Lost and Found, it is likely ePO cannot match the entry in the system tree with the machine in question. That is "intermediate though. Generally should be able to delete any "duplicate" entry (if any), and move the "interested" entry from Lost&Found to where you want it to be. Also run through L&F and purge all the empty groups...one shared the possibility of sorting and IP conflict as below
Use this Query to see machines which DO NOT have the update in SQL-Management Studio. Remember that the SQL Express on the EPOin this example, it is listing the HF793640. I am suspecting if there is such "DAT Date 0/0/0" OR "DAT Version 0.0000" OR "Engine Version 0.0000" as empty in your image shared. It is odd and maybe also need to reinstall agent which I believe you did so already. https://kc.mcafee.com/corporate/index?page=content&id=KB67406
Server has/is an instance. So you may have to connect to it:
YOU_SERVERNAME\EPOSERVER
Then new query:
SELECT ln.NodeName AS Hostname, pp.ProductVersion AS Version, pp.Hotfix AS Patch, ps.Value AS Hotfix
FROM EPOLeafNode AS ln INNER JOIN
EPOProductProperties AS pp ON ln.AutoID = pp.ParentID INNER JOIN
EPOProductSettings AS ps ON pp.AutoID = ps.ParentID
WHERE (ps.SettingName = 'Fixes') AND (ps.Value NOT LIKE '%793640%')
ORDER BY hostname
One suggested the below in reinstallation VSE steps
https://community.mcafee.com/message/252308#252308
As for those in Lost and Found, it is likely ePO cannot match the entry in the system tree with the machine in question. That is "intermediate though. Generally should be able to delete any "duplicate" entry (if any), and move the "interested" entry from Lost&Found to where you want it to be. Also run through L&F and purge all the empty groups...one shared the possibility of sorting and IP conflict as below
A machine connects with an IP address of 192.168.10.1: ePO can't find a matching group so it places it in L&F.https://community.mcafee.com/thread/29619?start=0&tstart=0
The machine then gets given 192.168.1.1, and updates its properties. You have a server task that resorts the tree: this now moves the machine to the "correct" location, leaving the empty group under L&F.
ASKER
So with data not being shown, does that mean something is broken? Will they re-appear after a certain time? I don't know how to run queries. All I want to know is with data no longer appearing, what will happen?
should be if the (supposedly non-compliant) workstation is running the same VSE (as example) version similar to the other compliant workstations. It can be the ePO agent comms to EPO, the central server management configuration for polling info for reporting, the report details displayed in wrong criteria for polling, the systems are not updated due to hotfixes and patches, and etc. But mainly, running custom report hope to achieve aid in below "anomalies" fact finding where possible in the troubleshooting phases.
-Clients not communicated with the McAfee ePO server in a while
-Clients suspected not working properly when attempt wake up
-Clients requires a new agent deployed to them directly from EPO
..the T-SQL query above is to go to the SQL db (due to the query engine in 4.6 only uses a subset of the T-SQL command set) for EPO to really ascertain what is display on the server UI. This is already shared in the steps for the link in prev post
...if really that is not viable (because you have no access), I am thinking to retry with running a new (not in built) query from EPO. E.g. choose queries, new query, select managed systems, set it to a table, choose those columns to have your wanted version patches etc data to return for. This is just "duplicate" check to see the built in reporting accuracy (likely same state..).
Regardless, as long as the local manual means to keep client station is still viable or re-assign it to another EPO (if there is one) to manage it the even if this "misinformed" EPO is still getting the right info from those workstation. The key is the VSE is running fine and client can still get update and remain protected (but just with more effort)...
It maybe time to trigger the tech support since it should be supporting your company to better advice and log it down...
-Clients not communicated with the McAfee ePO server in a while
-Clients suspected not working properly when attempt wake up
-Clients requires a new agent deployed to them directly from EPO
..the T-SQL query above is to go to the SQL db (due to the query engine in 4.6 only uses a subset of the T-SQL command set) for EPO to really ascertain what is display on the server UI. This is already shared in the steps for the link in prev post
Copy and paste the following Microsoft SQL, and then run it on the Microsoft Query Analyzer or Microsoft SQL Server Management Studio.(Ref - https://kc.mcafee.com/corporate/index?page=content&id=KB67406)
...if really that is not viable (because you have no access), I am thinking to retry with running a new (not in built) query from EPO. E.g. choose queries, new query, select managed systems, set it to a table, choose those columns to have your wanted version patches etc data to return for. This is just "duplicate" check to see the built in reporting accuracy (likely same state..).
Regardless, as long as the local manual means to keep client station is still viable or re-assign it to another EPO (if there is one) to manage it the even if this "misinformed" EPO is still getting the right info from those workstation. The key is the VSE is running fine and client can still get update and remain protected (but just with more effort)...
It maybe time to trigger the tech support since it should be supporting your company to better advice and log it down...
ASKER