HI,

I have 3 customers reporting this, only one pc per site.

We have been through the usual profile/temp files clean ups, anitvirus, IPV6, make sure its only connected by one network connection. But the problem persists.

Whilst playing around and looking at the IIS logs for sage 200 services i found some entries around the time I could see in screen shots of the errors, There seemed to be a sequence of "session has expired" repeated a few times then "Access is denied".

I then found in the logs in the users\appdata\local\sage\sage200 folder these errors were repeated in the desktop log.

Here is a snip

<snip>
2019-08-13 14:13:34,159 ERROR 0 Sage.MMSAdmin.DBLayer.SessionManager ValidateSession, Session not found
2019-08-13 14:13:34,159 ERROR 0 Sage.MMS.Admin.SystemAdminClientService.SystemAdminClient Sage.Common.Exceptions.SessionExpiredException: Session has expired. Please close the application.
at Sage.MMSAdmin.DBLayer.SessionManager.ReportError(String message)
at Sage.MMSAdmin.DBLayer.SessionManager.ValidateSession(String sessionID)
at Sage.MMSAdmin.DBLayer.SessionManager.KeepSessionAlive(String sessionID)
at Sage.MMS.Admin.SystemAdminClientService.SystemAdminClient.KeepAlive(KeepAliveRequest request)
at SyncInvokeKeepAlive(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage41(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
2019-08-13 14:13:34,174 ERROR 0 Sage.IdentityModel.Claims.Sage200.WCFServiceClaimsAuthorizationManager WCFServiceClaimsAuthorizationManager.CheckAccess ACCESS DENIED: Res=tobydesktop.microssit.local:10443/.../SystemAdminClientService.svc , Act=ISystemAdminClient/DisconnectCompany
2019-08-13 14:13:34,174 ERROR 0 Sage.MMS.Admin.SystemAdminClientService.SystemAdminClient System.ServiceModel.FaultException: Access is denied.
at System.ServiceModel.Dispatcher.AuthorizationBehavior.Authorize(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
</snip>

i have found this behaviour in all three sites in the IIS loging and the Desktop logging.

I have not told sage this yet.

I can also kind of replicate this at will but i have to use cheat.

I do development as well as support, and when I develop and test my bespoke, I don't run the bespoke through the Sage 200 Desktop, I have a launcher program that connects me to sage 200, and then run sage forms from there. This makes it very easy to debug the code. What I have noticed a while ago was that if I am debugging code and I create a break point, or hit a bug in my own code that causes execution to stop (unhandled exceptions are good for this), if I then leave the application effectivly running, but stopped at the break point for about 30 mins, when I come to close my bespoke, I will get a "type initializer" error when my code tried to disconnect from Sage. Now after upgrading to 2018, the error no longer says "type initilizer" it says "Access is denied", and I get the same entries in the IIS log to do with Sessions expiring and Access Is Denied.

I have several thoughts about this whole thing, and one is that this issue that is now being surfaced as an "Access is Denied" message has been there for a long time, but sage has swallowed it and dealt with it, now sage have changed something that is now surfacing the message out. Part of me thinks it the new logging they have done that is ironically causing the message to be surfaced.

Anyway to me it looks like the connection from the client to the IIS webservices is expiring, eihter because the program has halted, or the keep alive heartbeat is not happening, this then causes an access is denied message when the client tries to make a call to IIS webservices.

I have not taken this to Sage support as of yet, mainly because as soon as i mention the bespoke side of it, i suspect they will ignore the rest and try to push me to development support!!

Thanks for sharing, Toby. What precisely would you log with Sage as the issue?

Thanks for sharing, Toby. What precisely would you log with Sage as the issue?

I would probably go down the route of showing the log entries, wander down the Web services rabbit hole, and take it from there. then if i could spark interest i would bring up the bit about my developer experience.

i would be interested if others are getting the same log entries.

I'm off next week, so will probably have another stab at garnering some support interest when I return.

Toby,  Did you get anywhere else with this?  We have a customer who is experiencing this issue constantly and it seems to stem from them leaving their PCs for a length of time.

Hi, never had any serious investigation by Sage because its so hard to replicate, and then get them to look at.  It seems mostly linked to inactivity, as you have noticed.  So we usually try and get IT to look at powersaving, particularly, some powersaving settings on network adapter in the advanced settings. but it his and miss if you have the setting available.