Summary
When an OfficeScan (OSCE) client starts the upgrade process, it creates a local log file named as "upgrade_yyyymmddhhmmss" in ..\Trend Micro\OfficeScan Client\Temp\ folder. In this process, you encounter the following symptoms:
- About a hundred of these log files in the above folder with similar date but different generation time are created.
- When performing the Update Now action via the OSCE client system tray icon, the OSCE client does not upgrade without getting any error messages.
You can find below sample log information from an OSCE client:
Upgrade_yyyymmddhhmmss.log
2012/02/24 19:41:44 - [getInstalledClientVersion] Version number = 10.5
2012/02/24 19:41:29 - [UpdateOfficeScanNTModule] Can't Find pccntupd ..
2012/02/24 19:44:27 - [CheckAllUpdateEnvironmentOK] [PccNTMon] Check PccNTMon Service state...
2012/02/24 19:44:37 - [CheckAllUpdateEnvironmentOK] [PccNTMon] Check PccNTMon Service state...Failed!
2012/02/24 19:44:37 - [CheckAllUpdateEnvironmentOK] Client environment is not qualified to do upgrade or hotfix.
2012/02/24 19:44:37 - [CheckAllUpdateEnvironmentOK] The upgrade or hotfix action will abort, This OSCE client processes will be launched letter on.
2012/02/24 19:44:37 - HandleHotfixProgramFailure: HotfixProgramFailLogTry=3, HotfixProgramFailureCount=1
2012/02/24 19:44:37 - HandleHotfixProgramFailure: UpgradeRetryEnd=0
ofcdebug.log
2012 02/24 19:38:40 [17d4 : 0c24] (00) (D) [-L-][tmlisten.exe][NeedToUpdatePccNtUpd] new version is 11.5(C:\Program Files (x86)\Trend Micro\OfficeScan Client\pccntupd.ex_) - [cnttmlis_Service.cpp(6861)]
2012 02/24 19:38:40 [17d4 : 0c24] (00) (D) [-L-][tmlisten.exe][NeedToUpdatePccNtUpd] old version is 11.5(C:\Program Files (x86)\Trend Micro\OfficeScan Client\pccntupd.exe) - [cnttmlis_Service.cpp(6862)]
2012 02/24 19:38:40 [17d4 : 0c24] (00) (D) [-L-][tmlisten.exe][NeedToUpdatePccNtUpd] pccntupd.ex* are identical, no need to update. - [cnttmlis_Service.cpp(6868)]
This means that even the OSCE client gets proper upgrade notification from the OSCE server, the upgrade process does not happen because the file comparison between the source and its local files is identical. When the upgrade process terminates, the OSCE client reports back to the OSCE server. In this case, the OSCE server is notified that the OSCE client is still out-of-date. This then makes the OSCE server to resend the upgrade notification that results to an upgrade loop.
This issue happens when the source (most likely an Update Agent) is out-of-date with the new program version to be deployed. To ensure that OSCE clients can download new program files from the source, the Update Agent needs to be upgraded first before it can deploy new program files to target machines. To do this, set the OSCE server as the update source for the Update Agents:
The OSCE server must always be the update source for Update Agents and NOT any other sources.
- Log on to the OSCE web console.
- Go to Updates > Networked Computers > Update Source tab.
- Under Customized update source, tick "Update Agents update components, domain settings, and client programs and hot fixes, only from the OfficeScan server" checkbox.
- Click Notify All Clients to save.
