Well... yes, but QA would come over and break my knees if I pushlished the info. It's not a registry hack... it's a bit more complicated than that.
We set limits on the number of concurrent SA and AA sessions that can be active at any given time. If we let any number of folks be in the system pounding around, making changes etc... it could chew up the CPU too much and affect our ability to handle calls. The current limits are 5 SA and 20 AA sessions going at the same time. This may get bumped up for the 2.4.6 release, however the lab testing on higher limits under load test conditions has a ways to go before we do that.
One thing folks trip up on here is they just close the IE window out when they're done. You should always hit the "log off" link in the lower right (for both SA and AA). This will terminate the session right away and make it availalble for someone else to use. If you don't do that it will keep the session open for as long as IIS is configured to do so (20 minutes by default). Unless you have a good reason for needing more than 5 administrators in the system at the same time, just using the log off capability should help you out here.
We are having the same problem. In out case we can only have a single session open. I checked the IIS setting and it is 15 minutes but yesterday afternoon we could not get into any session, last night 1 session, and today 1 session. So the not logging out does not seem to be the problem. If it is a problem there is no possable way to train hundreds of users to consistently logout of AA. On the SA side we have a little more control and could live with a simple training issue. Is there any other reason that we could get the: Access denied You cannot access the Unity System Administration web pages.
There are too many active sessions. Please try again later.
Please see your system administrator for more details.
error message? Thanks
Jackie R. Miller Director, Information Systems Whitworth College 509 777-4486
The logic we use is pretty simple here, I dont see how it could be a problem on our side. When an AA or SA session is requested, we simply check to see how many sessions are currently reported open by the web server in the case of AA if its 20 or more, we throw the error you see there, for SA its 5. Theres no other reason wed throw that particular message.
There might be some reason why IIS is not terminating the sessions after timeout or something I suppose... I don't know of any such issues off the top of my head but Ill poke around MSDN a bit and see if anything pops up. Perhaps if you cycled the IIS Admin service (which will shut down the WWW service with it) it might clear any stuck connections just a thought.
The reason we put such restrictive limits on there is we dont want too many folks making changes at the same time since theres no way we can throttle IIS. It will snag the CPU when it wants to and if lots of folks are on the web server it could potentially impede our ability to process calls in real time in general a no-no for a voice server.
What would be nice is if IE sent a proper exit message back to the server when a user simply exited our site or closed IE unfortunately thats not the case (at least the last time I twisted someones arm to look at this on IE 5). Thats why we have the special log off link so we can manually terminate the session. I know folks dont see it.
When push came to shove we decided to error on the side of caution on this one. If youre in a real jam and want to crank up the number of allowable AA sessions by a few I could do that for you, but Im very reluctant to do this in general (and we dont support folks doing this in the field as a rule). We came up with the 20/5 limits based on testing and you have to understand the performance risks youre taking there on the call processing side.
One possibility is to shorten the amount of time that an IIS session "lives for". The default value is 20 minutes. If you feel that your users always get in, do their business, then leave without logging off, this may be reasonable. However, if your users are less directed, this may not work out.
For example, a user goes into the AA, and gets interupted, perhaps by a phone call, a shorter time of say 10 minutes could easily lapse, while they transact their business. When their attention returns to the AA, they've left unsaved changes which are now lost when they hit save as the session has timed out. (The "unsaved data has been lost" msg is shown, then the "session timed out" error msg is given -- the user's frustration level on this would be much higher than the "too many sessions" difficulty).
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...