Still technically in "wait and see" mode, but right after the call, it kicked the same error again. I am beginning to suspect it's not java that is the cause (especially after something the tech said - which really didn't make sense as I was not running a java console with the errors occurred)........ I am getting an error that says that certain specific clients that have been offline a while could not apply an IPS library - and gave a serial number, and that policy serial number doesn't even exist!!
In some identical errors, the serial number is never given, in others it is, but the serial number does not match the name, time or date of any policies that show in the groups.
On the other hand - do the IPS and other things have DIFFERENT serial numbers?
Confusion abound here: I asked the tech "so what is java used for on the server - the log errors keep saying "java", is that what compiles the policies before they go out after a change?" He said no - that's not Java at all, Java is for the console.
Quite interesting as the console doesn't normally run on either server - in fact, we seldom even log in to a SEPM server at all, so if Java is ONLY for the console, not for compiling the policies, then why is Java mentioned in all these errors? (see above posts) ?
If Java was only for the console, if there was a Java problem, I'd expect a console problem - the console is working great, and I don't run the console on a server, I run it from a workstation. If I don't run Java on a server since I don't run the console on the servers to access SEP stuff, then technically JAva is sitting doing nothing at all, right? If that's true - why java errors on almost every line in the logs?
If Java doesn't compile the policies and apply them, or Java doesn't build the packages, then what DOES java do on the SEPM server, and why is it a java error on every one of these errors in the logs??
* I'm told Java is on the servers for the console only, no other role, and it must be the correct version.
( I can buy the must be correct version part - but I installed exactly what the document said to install since the document I have says SEP came with a bad Java build included.)
* If the above is 100% true and correct as I was told today, then if I don't launch the SEPM console ON the SEPM server, Java isn't running or at least not active. IS that correct - if it's only for the console, not launching hte console in return doesn't launch the Java.
* If the first two are correct, then because the console is not running locally, so Java isn't running locally, then there should be no mention of Java in any error logs since it's not doing anything, and is for hte console.
Number 3 causes me a problem........ because Java IS mentioned in the logs - every single error is in fact a Java error, and related to policies, and packages.
2013-04-03 13:01:42 Lpr Critical vrdsmsepm1 Apr 3 13:01:15 SymantecServer vrdsmsepm1: PC1234P655,Category: 0,Smc,FATAL: failed to apply a new IPS library . The client may not restart properly if it is stopped. Please see file debug.log for detailed information. Correct the error in the IPS library in the management server before restarting the client.
2013-04-03 13:01:42 Lpr Critical vrdsmsepm1 Apr 3 13:01:15 SymantecServer vrdsmsepm1: PC9876KP656,Category: 0,Smc,FATAL: failed to apply a new IPS library 6AD8-04/01/2013 19:32:59 820. The client may not restart properly if it is stopped. Please see file debug.log for detailed information. Correct the error in the IPS library in the management server before restarting the client.
2013-04-03 13:01:42 Lpr Critical
Problem - we don't have such a policy serial number, no policies start with 6AD8 unless I do not know where to look.
These started due to an error in a custom IPS signature - I didn't get a comma put in the IP address list. I have since fixed that. This other Java and package and HI stuff started weeks ago, many weeks ago, so this isn't the cause, but could be related?