CPM - Apply Automatic Updates task not being applicable to clients

(imported topic written by SystemAdmin)

None of my clients are showing as being applicable for the “Core Protection Module - Apply Automatic Updates” task. I am pretty darn sure I have run the tasks to enable automatic updates for the server and the endpoints. What gives? How can I troubleshoot this?

(imported comment written by Danny_Leung91)

Hi D8taSlay3r,

Here are some things you can check to troubleshoot the CPM automatic update setup process. We plan to provide more information like this in knowledge base articles in the BigFix support site.

===========================

After running the CPM automatic update setup script

http://CPMAutoUpdateSetup.vbs

check the following to ensure each successfully complete.

*It’s assumed that you have already followed the steps described in the CPM Automatic Update setup process --> http://support.bigfix.com/cpm/cpm_update.html


  • On the BES Server ***

  • Check in BESAdmin that the CPM custom operator was created. If the default username was used in the setup script, this will be ‘cpm_admin’

  • Check that the propagation credentials and site authorization is created for the custom operator

  • Propagation credentials folder for the custom cpm operator

Location: C:\Program Files\BigFix Enterprise\TrendMirrorScript\Credentials

  • publisher.crt

  • publisher.pvk

  • Authorization file allows the custom cpm operator to write to the custom cpm site:

Location: C:\Program Files\BigFix Enterprise\TrendMirrorScript\FileOnlyCustomSiteAuthorization_CPMAutoUpdate

  • Check existence and correctness of automatic update related registry entries:

*Note: the PropagationUser and PropagationPassword are the default values.

HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\CPM\server

“PropagateManifest”=dword:00000001

“ManifestSiteName”=“FileOnlyCustomSite_CPMAutoUpdate”

“PropagationUser”=“cpm_admin”

“PropagationPassword”=“trendmicro”

“PropagationDSN”=“bes_bfenterprise”

“CredentialsPVK”=“C:\Program Files\BigFix Enterprise\TrendMirrorScript\Credentials\publisher.pvk”

  • After the above criteria are satisfied, a pattern-set will be published to the CPM custom site the next time a recurring policy action from task ‘Set ActiveUpdate Server Pattern Update Interval’ runs. To verify that new pattern-sets are successfully published check the following:

CPM Automatic Update custom site folder

Location:

C:\Program Files\BigFix Enterprise\BES Server\wwwrootbes\bfsites\CustomSite_FileOnlyCustomSite_CPMAutoUpdate_10

Files contained in the CPM custom site folder:

  • filelist_srv.txt --> referenced in the ‘Apply Automatic Updates’ task to determine if the CPM client has any out-of-date patterns

  • server.ini --> used by the CPM client updater component

  • manifest.ini --> metadata containing information about this pattern-set

Each time a new pattern-set is downloaded, a corresponding folder named ‘CustomSite_FileOnlyCustomSite_CPMAutoUpdate’ is created. There may exist multiple versions of the same folder, each appended with an incremental number. Each folder corresponds to the number of times the CPM custom site has been published. The folder with the highest number contains the most recently published pattern-set information.

We can use the information contained in the manifest.ini to verify what pattern-set version is currently served for automatic updates at the BES Server.

  1. If there are more than one CustomSite_FileOnlyCustomSite_CPMAutoUpdate_## folder, open the most recent one as signified by the highest incremental value appended to the folder name

  2. View the manifest.ini in a text editor and examine the ‘version’ field:

version=“20090803_170903”

This value corresponds to the pattern-set version that is currently available for automatic updates

  1. Cross-check the automatic update pattern-set version with the most recently available pattern-set stored in the pattern-set cache on the BES Server. You can check this in two places. It is worth mentioning that this pattern-set cache is the same source that is used to deploy manual updates.

a. Pattern Updates Wizard:

CPM Dashboard > Updates > Update/Rollback Patterns > New Pattern Update/Rollback

When the wizard loads, the most recent pattern-set will display at the top of the pattern-set list

b. BES Server file system:

C:\Program Files\BigFix Enterprise\BES Server\wwwrootbes\cpm\patterns\20090803_170903


  • On the BES Client ***

  • How can we tell if the client machine has automatic updates enabled?

After the automatic update process is validated on the BES Server, we can check whether the BES Client has the most recent pattern-set information available.

After deploying task ‘Core Protection Module - Enable Automatic Updates - Endpoint’, it will subscribe the BES Client to the CPM automatic update custom site

Similar to any other BES site, you can find it at the following location:

C:\Program Files\BigFix Enterprise\BES Client__BESData\CustomSite_FileOnlyCustomSite_CPMAutoUpdate

When automatic updates are setup properly, this folder will contain the same contents as the most recent verion of the custom site on the BES Server.

  • filelist_srv.txt --> referenced in the ‘Apply Automatic Updates’ task to determine if the CPM client has any out-of-date patterns

  • server.ini --> used by the CPM client updater component

  • manifest.ini --> metadata containing information about this pattern-set

On the BES Client view the manifest.ini file and search for the version field. This value should be the same and represent the latest pattern-set that is available on the server. You can cross check this value with that on the BES Server. Please refer to step 3 in the section above.

  • Now that automatic updates are enabled on the BES Client, how can we tell if it is setup properly?

The task ‘Core Protection Module - Apply Automatic Updates’ references information in the ‘filelist_srv.txt’ file in its applicability relevance to determine if the CPM client has outdated components or pattern files.

Namely, it is Relevance statement 6 of the ‘Apply Automatic Updates’ task that ultimately determines the clients applicability. There are client session inspectors used within that relevance that restrict it from evaluation within the Relevance Debugger.

A sample tool that allows manual testing of the relevance, locally on the client machine is the BES Client API tester. You can view and download it here -->

http://forum.bigfix.com/viewtopic.php?id=2756

Copy and paste Relevance statement 6 into the Client API tester. If it evaluates true, then the CPM client has outdated components whereas false indicates all components and patterns are up-to-date with respect to that pattern-set that is currently available.

Please let us know if you have additional questions or feedback.

Thanks,

Danny

(imported comment written by Elaine91)

Hello,

I just noticed that the propagation password in HKLM\Software\Bigfix\CPM\server is not encrypted. I feel like this should be secured or some sort of encyption is impossed on password. Your comment on this one is very much appreciated.

thanks,

elaine

(imported comment written by jessewk)

Hi Elaine,

Basically we don’t consider this an issue primarily because that password is not tied to rights over any computers in your deployment. Access to that password (and the corresponding keys) does not enable anybody to effect changes on an endpoint. The worst that could happen is you could get clients that are setup for automatic updates to download a file other than the manifest of available pattern updates. The file would then be rejected by the updater component on the endpoint and would get deleted when the next action runs or the client is restarted. Secondly, we expect the BES Server to be a highly secured computer. While our architecture (in contrast to some of our competitors!) is designed so that endpoints can’t be compromised by owning the server, there is still a lot of potentially valuable information on the server and it is expected that only authorized admins will have access and the machine will be locked down.

That said, I agree it’s generally not a good idea to rely on plain text passwords, but in this case we decided the risk was minimal and it was worth the architectural trade off to allow us to focus on other aspects of the design.

Hope that helps ally your concerns.

Jesse