Video Screencast Help

SEPM event ID 7203 when checking in the latest virus defs

Created: 25 Mar 2013 • Updated: 17 Apr 2013 | 6 comments
This issue has been solved. See solution.

Given I run SEPM on a closed network I download the latest virus defs from the FTP site

The files where all checking in fine up until a few days ago, now in the event logs on the SEPM server we use to put the jdb file we are getting a warning event 7203 at the time of the file check in and the checkin is failing ?

Any ideas as to what the event ID actually means ?



Operating Systems:

Comments 6 CommentsJump to latest comment

ᗺrian's picture

Is there an error message along with event ID being shown?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

K33's picture


Check one of symantec artical

Setting alerts for SEPM Server Content Update using the Symantec Endpoint Protection Kaseya plug-in
Article:TECH187494 | Created: 2012-04-26 | Updated: 2012-04-30 | Article URL
SebastianZ's picture

Error 7203 means the content could have not been installed.

Do you have similar issues with any other packages available on that FTP?

Can you try same package from here:

Falaendor's picture

The Warning message isnt very helpful heres the details :

nfo:Content install failed on the server.
Product:Virus and Spyware definitions Win32 12.1
Source:Public LiveUpdate Server (Symantec LiveUpdate Server)
Size(in bytes):471649535

Falaendor's picture

Thus far I have tried the following solutions to resolve the issue.

- Putting the JDB file onto one of the other SEPM servers in the imcoming folder

- Stopped the SEPM service on all the server and rebooted the SQL back end server, then started the SEPM services on the servers and tried to check in the jdb file.

- Used the JDB file from the location that Sebastian linked above.

None of these have worked :(


Falaendor's picture

Just an update to close this off.  The issue was infact a hard coded default in SEPM that had a maximum size for a 'Content' table within the database.

Therefore because we had it set to 42 revisions and the file increases day by day it had reached its limit.

My SQL guy then increased the size and the problem was resolved.