none
Operations Manager 2012 SP1 - Console [The requested operation timed out]

    Question

  • I recently installed and configured a new SCOM 2012 environment to monitor our production servers. Periodically when I attempt to resolve or change the status of alerts the console will stall for awhile and eventually I'll receive this error message:

    Date: 1/31/2013 4:55:00 PM
    Application: Operations Manager
    Application Version: 7.0.9538.0
    Severity: Error
    Message: 
    
    System.TimeoutException: The requested operation timed out. ---> System.TimeoutException: This request operation sent to net.tcp://scom1p:5724/DispatcherService did not receive a reply within the configured timeout (00:29:59.9994999).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.
    
    Server stack trace: 
       at System.ServiceModel.Dispatcher.DuplexChannelBinder.SyncDuplexRequest.WaitForReply(TimeSpan timeout)
       at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
    
    Exception rethrown at [0]: 
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at Microsoft.EnterpriseManagement.Common.Internal.IDispatcherService.DispatchUnknownMessage(Message message)
       at Microsoft.EnterpriseManagement.Common.Internal.OperationalDataServiceProxy.UpdateAlerts(Byte[] alerts, String comments, Nullable`1 modifyingConnectorId)
       --- End of inner exception stack trace ---
       at Microsoft.EnterpriseManagement.Common.Internal.ExceptionHandlers.HandleChannelExceptions(Exception ex)
       at Microsoft.EnterpriseManagement.Common.Internal.OperationalDataServiceProxy.UpdateAlerts(Byte[] alerts, String comments, Nullable`1 modifyingConnectorId)
       at Microsoft.EnterpriseManagement.Monitoring.MonitoringAlert.UpdateAlertsInternal[T](IList`1 alerts, String comments, Nullable`1 modifyingConnectorId, ManagementGroup managementGroup)
       at Microsoft.EnterpriseManagement.OperationalDataManagement.UpdateMonitoringAlertsInternal[T](IList`1 alerts, String comments, Nullable`1 modifyingConnectorId)
       at Microsoft.EnterpriseManagement.OperationalDataManagement.UpdateMonitoringAlerts[T](IList`1 alerts, String comments)
       at Microsoft.EnterpriseManagement.Mom.UI.AlertView.SetResolutionState(Object sender, ConsoleJobEventArgs e)
       at Microsoft.EnterpriseManagement.Mom.Internal.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)
    System.TimeoutException: This request operation sent to net.tcp://scom1p:5724/DispatcherService did not receive a reply within the configured timeout (00:29:59.9994999).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.
    
    Server stack trace: 
       at System.ServiceModel.Dispatcher.DuplexChannelBinder.SyncDuplexRequest.WaitForReply(TimeSpan timeout)
       at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
    
    Exception rethrown at [0]: 
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at Microsoft.EnterpriseManagement.Common.Internal.IDispatcherService.DispatchUnknownMessage(Message message)
       at Microsoft.EnterpriseManagement.Common.Internal.OperationalDataServiceProxy.UpdateAlerts(Byte[] alerts, String comments, Nullable`1 modifyingConnectorId)
    


    Exchange 2010 Outlook 2007 (cache mode)

    Friday, February 01, 2013 5:12 PM

Answers

  • Hello SACIT,

    Please follow the following article if you did install the SCOM server properly.

    OpsMgr 2012: a quickstart deployment guide
    http://blogs.technet.com/b/kevinholman/archive/2011/07/26/deploying-opsmgr-2012-a-quick-start-guide.aspx

    Especially, did you grow the database size. A small size database always causes no responding problem.

    Manually grow your Database sizes and configure SQL

    • When we installed each database, we used the default of 1GB (1000MB). This is not a good setting for steady state as our databases will need to grow larger than that very soon.  We need to pre-grow these to allow for enough free space for maintenance operations, and to keep from having lots of auto-growth activities which impact performance during normal operations.
    • A good rule of thumb for most deployments of OpsMgr is to set the OpsDB to 30GB for the data file and 15GB for the transaction log file. This can be smaller for POC’s but generally you never want to have an OpsDB set less than 10GB/5GB.  Setting the transaction log to 50% of the DB size for the OpsDB is a good rule of thumb.
    • For the Warehouse – you will need to plan for the space you expect to need using the sizing tools available and pre-size this from time to time so that lots of autogrowths do not occur.

    Thanks,


    Yog Li
    TechNet Community Support

    Wednesday, February 06, 2013 9:28 AM
    Moderator

All replies

  • Hi,

    Do you have a clock time sync problem between the client  and the server ? Please verify that the clock is almost the same on the client and the server


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, February 01, 2013 6:07 PM
  • Thanks for the reply dktoa. I did check the NTP source on both the SCOM server and my desktop and they both pull from AD, each showing the exact time.

    I wanted to add that I recently resolved (2) issues and the console was stuck at "Updating Alert" and now the console is not responding.


    Exchange 2010 Outlook 2007 (cache mode)

    Friday, February 01, 2013 6:17 PM
  • Hello SACIT,

    Please follow the following article if you did install the SCOM server properly.

    OpsMgr 2012: a quickstart deployment guide
    http://blogs.technet.com/b/kevinholman/archive/2011/07/26/deploying-opsmgr-2012-a-quick-start-guide.aspx

    Especially, did you grow the database size. A small size database always causes no responding problem.

    Manually grow your Database sizes and configure SQL

    • When we installed each database, we used the default of 1GB (1000MB). This is not a good setting for steady state as our databases will need to grow larger than that very soon.  We need to pre-grow these to allow for enough free space for maintenance operations, and to keep from having lots of auto-growth activities which impact performance during normal operations.
    • A good rule of thumb for most deployments of OpsMgr is to set the OpsDB to 30GB for the data file and 15GB for the transaction log file. This can be smaller for POC’s but generally you never want to have an OpsDB set less than 10GB/5GB.  Setting the transaction log to 50% of the DB size for the OpsDB is a good rule of thumb.
    • For the Warehouse – you will need to plan for the space you expect to need using the sizing tools available and pre-size this from time to time so that lots of autogrowths do not occur.

    Thanks,


    Yog Li
    TechNet Community Support

    Wednesday, February 06, 2013 9:28 AM
    Moderator
  • Hi,

    As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as "Answered" as the previous steps should be helpful for many similar scenarios.

    In addition, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems.

    Thanks,


    Yog Li
    TechNet Community Support

    Wednesday, February 13, 2013 9:01 AM
    Moderator