We have a workstation where the solid core agent is no longer communicating with our EPO server. The windows solidifier had been removed using add\remove programs, by our service desk. Since its removal the agent was manually reinstalled to the workstation, the agent was installed directly, not though EPO. But I still can't get it to communicate. What is the best method to reinstall the windows solidifer and how do you get it to reinstall back from EPO. EPO is automaticaly set to deploy the windows solidifier to work station that are placed into the correct container.
I would suggest troubleshooting the McAfee Agent and Solidcore Agent components separately, then work backwards from there based on the success/failures of the individual agents.
I had a very similar issue in my lab when I was first configuring Solidcore and EPO. I did a manual Solidcore upgrade outside of EPO and something went South. My eventual fix was to disable and then uninstall the locally installed Solidcore agent and I re-managed (delete/add the system, or just add the system and remove any dupes later) the system in EPO. Once I re-established communication with the McAfee Agent, I pushed Solidcore to the system and everything worked beautifully.
1 of 1 people found this helpful
As the Solidifier was removed and then re-installed outside of ePO, it is most likely in an unmanaged state. I would check the following:
1. Presence of scormapl.dll file in the Solidcore install directory
2. Presence of required Solidcore reg keys and values:
a. HKLM\System\CurrentControlSet\Services\swin\Parameters - look for value IsSystemControllerEPO=1
b. HKLM\Software\Network Associates\ePolicy Orchestrator\Application Plugins\SOLIDCOR5000_WIN
plugin path= (installdir)\scormapl.dll
product name=McAfee Solidifier
When installing Solidcore via an ePO task, ePO automatically creates these keys and copies the required .dll files into the Solidcore installation directory. It is possible to install Solidcore outside of ePO and bring an unmanaged system into ePO by copying the .dll file and manually creating the registry keys; we have created a customized software package that installs the Solidcore 5.x client and scripts the creation/copying of reg keys and files and it works just as if ePO installed it.
If these files/reg keys are missing they will need to be added. If they are present, I would restart the McAfee Framework service, then restart the Solidifier service so the agent can "see" Solidcore and Solidcore knows it should look to the ePO server as it's system controller. Additionally, these steps are detailed in KB69408.
Agreed with dppcmsj.
When you do a manual install - you have to add those registry keys and copy the scoremap.dll to solidcore dir.
Hmm... great info dppcmsj.
I've got a handful of systems (about 20ish that I have ID'ed so far) which are running Solidcore which was pushed via ePO, but are missing scormapl.dll. So using your helpful info, I checked out the registry keys and the scormapl.dll. The registry keys outlined above are all there and all correct. Bouncing the services (multiple times and in various orders at this point) yields no change in "System Controller" status and they aren't reporting they are running Solidcore to EPO.
It almost appears that the systems were managed at one point, then somehow Solidcore decoupled itself. For example, Solidcore has been enabled but is currently in update mode which suggests that it received the initial "enable" task and was rebooted.
Any other ideas on how to "re-manage" a Solidcore instance? Let me rephrase that - any other ideas on how to re-manage a Solidcore instance without rebooting the client system?
That's quiet strange.
If you pushed solidcore from ePO - you don't have to manually add those keys and copy scoremap.dll file. I would suggest the following:
- First check if MA is communicating with the systems properly (Remember if you enabled App control without adding the default McAfee rule group to your policy that might create some agent communication/update problem)
- The other option is to put solidcore in update mode and check if everything is all right with the MA
- Try upgrading the solidcore version to 5.1.1 - you can upgrade your solidcore agents without rebooting.
A follow up on my specific issue: I ended up pursuing an incident with McAfee and got a slightly revised process than what was outlined in the KB article mentioned above.
I removed scormapl.dll and then polled the device, which subsequently removes the HKLM\Software\Network Associates\ePolicy Orchestrator\Application Plugins\SOLIDCOR5000_WIN key. I then re-added the registry key, copied scormapl.dll and repolled via EPO. This resolved the issue. It seems there is an order of operations to things and my broken deployment somehow violated the order, thus causing me further woes.
I'm still curious how my installs were broken/decoupled, but this works around the major roadblock so we can finish up the deployment.
Thanks for the follow up AB. I do have the MacAfee rule group policy in place - it just looks like my deployment broke down on a group of systems.