at System.Runtime.Remoting.Channels.Tcp.TcpServerTransportSink.ServiceRequest(Object state)
at System.Runtime.Remoting.Channels.SocketHandler.BeginReadMessageCallback(IAsyncResult ar)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
Authentication to the SQL server/database was set to be done via the domain service account (Application Identity), but an unknown environmental condition was causing the authentication attempt to be translated into the SMP server's system account: "Domain\ServerName$" which the SQL server could not authenticate.
In the case sited the only solution was to employ a workaround wherein the account used to access SQL was set to either use the SQL server's local "sa" account or to create a new local SQL user and give it dbo permissions to the database, and then use the new account for reading and writing to the SQL account.
Symantec Management Platform 7.5 SP1 HF3
Imported Document ID: TECH226940
Subscribing will provide email updates when this Article is updated. Login is required.