Screencasts - Hilfsvideos

SEPM event ID 7203 when checking in the latest virus defs

Created: 25 März 2013 • Aktualisiert: 17 Apr. 2013 | 6 Kommentare
Dieses Problem wurde gelöst. Siehe Lösung.

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:

Kommentare KommentareZum neuesten Kommentar

das Bild der Brɨans

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.

das Bild der K33s


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
das Bild der SebastianZs

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:

das Bild der Falaendors

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

das Bild der Falaendors

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 :(


das Bild der Falaendors

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.