Symantec Management Platform (Notification Server)

SMP 7.5 SP1 on Server 2012 R2

JRE 7 U60

Is anyone finding the java applet used in the Actions > Edit Package option for a software package really slow to open and display the usual security warning?  I'm waiting 10+ minutes for it to appear when accessing this directly on the SMP server.

There was a previous similar discussion here : http://www.symantec.com/connect/forums/java-7-update-51-breaks-software-import-unsigned-java-applet

In my case there is no error given and it does eventually open.

Hi,

Do you use virtual machine as NS server?

If so, please ensure that it hasn't 1 processor, as it can causing sporadic hangs in many places not limited to software resource editor.

Regards,

Dmitri

Does it same slow load in case if you will use I.E. browser from remote PC?

If it helps at all I can tell you I don't have that issue in my configuration.  I'm on 7.5 SP1 running on Server 2008 R2.  Client is Win 7, IE9, JRE 7u60.  I have other users using newer IE versions and have not heard that complaint.

Due to issues we had before we upgraded to 7.5 we have the SMP url listed in the exception list on the security tab in the java client.  you may want to try that to see if it is a Java security check interfering.

The SMP in question is a virtual server but it has 4 vcpu.  The rest of the console runs very quickly.

The applet loads within a reasonable time on other remote IE sessions. (W7 IE11, Java U55)

We tried rolling back to a previous version of the JRE (update 55) and it still takes a long time to load on the 2012 R2 server.

Yes it does help to hear if its working for others JoeVan - thanks!

Just to update this, we're seeing this issue on a clean 2012 R2 Standard server install.  No group policy applied or unusual settings.  JRE U60 and prior versions.

Try enabling all the debug options in the advanced tab of the JRE control panel applet.  Also check the "show console" option.   This will generate detailed client-side Java logs which may show your problem.  Could be Java proxy settings or that the client can't get to the cert revokation list URL or something like that.

The java logs show the following at the time the delay occurs:

cache: Resource http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar has expired
network: Connecting http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar with proxy=DIRECT
network: Connecting http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar with cookie "ASP.NET_jeiqe1vv5kuvkdfs24dfskl"

At this point there is a 10+ minute delay where both the java console and IE are completely locked up, and then..

network: Connecting http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar with cookie "ASP.NET_jeiqe1vv5kuvkdfs24dfskl"
network: Connecting http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar with proxy=DIRECT
network: Connecting http://[SMP]:80/ with proxy=DIRECT
network: Connecting http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar with cookie "ASP.NET_jeiqe1vv5kuvkdfs24dfskl"
network: ResponseCode for http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar : 304
network: Encoding for http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar : null
network: Disconnect connection to http://[SMP]/Altiris/SoftwareManagement/Dialogs/PackageDefinition.jar

At this point two security warnings appear and I am able to continue.

I can also see later references in the log to it attempting to connect to http://ocsp.verisign.com which it cannot do because we restrict internet access to specific white-listed sites for the SMP.  Could this be related?

I'd be willing to bet the inability to connect to ocsp.verisign.com is causing the delay.  This sounds like Java is attempting to validate the JAR certificate.  If you are blocking this at a firewall, it probably goes through multiple timeout cycles before it gives up.  I'd recommend opening up access to that URL.  If you are opposed to that, there may be a way to disable certificate / revocation checking within Java itself but I'm not certain.

Alas no - we opened up the proxy to allow un-restricted internet access for the SMP and there was no change in behaviour - still a huge delay.

Please check this information:

1. http://www.symantec.com/docs/TECH212033
2. Is there a latest version of SilverLight?
3. Java x86 or x64 is installed?
4. Try to clear Internet temp files

Close the browser completely, and clear all temporary Internet Files via the Java control panel application (Start -> Control Panel -> Java->General tab -> Temporary Internet Files ->Settings ->Delete Files -> OK to Applications and Applets and Trace and Log Files), then restart browser.

Lark, you say you opened access in the proxy but it doesn't appear your JRE is configured to use a proxy.  Even though the SMP console is run in your browser, JAR files use the JRE proxy settings.  Do you have an explicit proxy that requires the browsers / apps to be configured with proxy information or do you have a transparent inline proxy?  If you have an explicit proxy, check the network settings in your JRE to ensure it is set properly for your envioronment.

We have an explicit proxy.  The JRE is set to use the browser's proxy settings as per default.  When I change the proxy settings in IE I can see the proxy information change in the JRE verbose logs so that seems to be passing through ok.  When we opened the proxy up to allow all sites I could also see the JRE validate with that verisign site.

I have also tried comepletely removing all proxy details - still no change.

Something else that is strange is that other jar files such as the one that runs when you browse to "Settings > Deployment and Migration > Sysprep Imaging Configuration" open just fine.

Thank Igor I will test the suggestion in the KB article

Installed Silverlight is the latest version

Java x86 is installed but we also trialed x64

Clearing the Temp internet files didn't help either

Did you find a solution for this problem?   We have exactly the same

HELP !

Sadly no - that customer wasn't to bothered by it as they tended to use a remote browser which was not showing the same symptom.  It looked to be entirely environmental in their 2012 R2 server build but we never identified the cause.

I opened a case today about it.   If we can resolve it be sure I'll let you know.

thanks

Did you try to open a "Altiris Profiler" to reproduce the problem and then check this profiler log output?

Not sure if this helps at all, but I've got the same exact build environment and simply had to add http://localhost to the Java Exception Site List to make this work quickly.