IT Management Suite

We upgraded to ITMS 7.6 HF3 over the weekend and now we're getting some very strange behaviors. We're getting a lot of session timeout errors on different pages and subpages throughout the console. The biggest culprit is if we go into a job and then drill down on the details of the job, we get the message "The Session has timed out or the server has been reset. Please reload the page" It happens all over the place and is really getting in the way of doing work.

Any help or ideas would be appreciated. I will open a support case if no one has any good ideas.

Server 2012 R2, ITMS 7.6 HF2, SQL 2012 running on Server 2008 R2

Hi jpellet2,

I believe that you are on ITMS 7.5 SP1 HF3, since HF3 isn't released for 7.6 and there is only 7.6 HF2 latest released version.

Did you check this thread?

• https://www-secure.symantec.com/connect/forums/timeouts-and-slow-performance-smp-71-asset-screens
• https://www-secure.symantec.com/connect/forums/reporting-woes-smp-71

Question:

1. This behavior occurs for all different logged on accounts from different roles or for specific account from specific role?
2. These timeouts appears only in specific places within SMP Console? Same occurs if you will open same SMP console page using I.E on remote PC?
3. How is a health of NS and SQL Server machines? There is enough of available RAM and CPU?
4. What says Altiris Log Viewer or SQL log? Any deadlocks or errors?
5. Is there something useful in "NT Event" application/security logs?

Thanks,

IP.

It is HF2. Was confusing it a bit so to clarify, ITMS 7.6 HF2.

The timeouts are from different accounts, different browsers (Safari works well, and better in some cases, now in 7.6 for the short amount of testing we've done.)

No deadlocks that we see and no errors relating to any timeouts in the Altiris log.

Session timeouts have now been fixed. After spending some time with IIS it appears that when server 2012 R2 was installed and then IIS added to it, IIS was set to use 4 worker processes for the main app pool. This would have an issue since they session keys are not being stored in the database so whenever a new process picked up communications, the session was no longer valid. By switching the app pool back to a single process, the session issues went away.