The fault you indicated means the manager was not able to successfully connect to https://menshen.intruvert.com and authenticate with pre-defined credentials (not user editable after 220.127.116.11).
The first step we recommend when trying to troubleshoot this type of issue is to use a web browser on the manager server and attempt to access the same site.
Your grant number can be used for the username and password. Be sure to type NAI in all caps and include the hyphen.
If that is succesful, check if you have a proxy configured in the browser and if so, what credentials you are using.
The manager server can be configured to use a proxy also. Note that there was a problem with the proxy config at an older version of 6.x. Are you at the latest version?
The ems.log files will give the response code that the server or any intermediary device is throwing. Search on menshen and you should see it.
Another possible cause of this issue is an SSL decryption device in the path between the manager and the update server. The manager is verifying the SSL certificate matches what is configured, so if you are using SSL decryption you will need to exempt the manager IP to the menshen server.
A wireshark capture on the manager server may be helpful if you are still having issues.
On systems that do not have access to the internet (or at least not to the update server) the NSM will generate this fault message every 10 minutes. The message is by default assigned a severity of “Critical”.
There is currently no way in the application or even within the configuration files or database to completely turn off the NSM’s Update Server Check nor the check for the “Messages from McAfee”. That will change in the near future from what I understand. Several customers submitted Product Enhancement Requests (PER) through the https://mcafee.acceptondemand.com site which were reviewed and accepted for inclusion in an upcoming release of the NSM. I don’t know if it will make it into the next maintenance release but I do know they have this in their supportability matrix to be investigated and included if possible. So I’ll just have to leave that as a “hopefully soon” answer.
While you cannot completely turn it off as I said – You CAN change the severity from "Critical" to “informational” [Step One] … and you CAN *manage* how often it is generated [Step Two/Three].
Change the severity of the fault to “Informational” This stops it from being forwarded if you have it set to send “Critical” faults to your syslog, snmp, or email. This is done via editing the NSMAPP$\config\faultnameandtext.properties file.
Change the line:
It will now show up as an Informational fault instead of Critical.
This change is effective immediately after the changes are saved.
No reboot or Restart of NSM Services is required.
Now the alert will still appear but the severity will show as “Informational” instead of Critical.
Go to the NSM Update Server Automation page and make sure that the Automatic Downloading of Signature Sets is set to “NO”. Save the change.
The next step is to tell the NSM not to check the update server. You thought you did that in step one? Not quite - That only told it to not download any new signatures that it found. The NSM will still check to see if there ARE new releases available but it will not automatically download them.
In addition, there is no “Disable” button for the “Messages From McAfee” update checks.
To handle that condition will require running a couple MySQL queries.
WARNING: The Following section describes making changes to the NSM Database tables. It is strongly recommended to perform an NSM Backup before you do so!
Open a command prompt and log into MySQL. Make sure you select the NSM Database before running the scripts. By default the NSm Database is named “LF”.
Here are the MySQL queries that will turn off the Messages from McAfee and the Update Server Checks and change how often the NSM does performs its ‘behind the scenes” checks.
update iv_schedulers set isActive = 'FALSE' where type = 'IUS_MESSAGE_DOWNLOAD';
update iv_schedulers set isActive = ‘FALSE’ where type = ‘UPDATE_SERVER’;
update iv_schedulers set schedule = "weekly: 0,0.0;0,4.0;1" where type = 'UPDATE_SERVER';
update iv_schedulers set schedule = "weekly: 0,0.0;0,4.0;1" where type = 'IUS_MESSAGE_DOWNLOAD';
Now the NSM will only check for the Update Server ONCE PER WEEK ON SUNDAY.
You will still see the error pop up now and then but now instead of getting it once every 10 minutes.. it will be once a week. Also, due to the changes in Step 2, even when it does happen – it is marked as “Informational” instead of “Critical”.
PLEASE NOTE: If you open the Update Server Page on the NSM for Signature Sets or Sensor Software the NSM will attempt to reach out to the Update Server to see what new Signature Set(s) and/or Sensor Software is available - That attempt will generate this fault.
Hope this helps you!
I REPEAT: Please perform an All-Tables or Config-Tables Backup before starting the steps in this set of instructions.