Entire sections of Control Compliance Suite standard evaluating to "unknown"

book

Article ID: 156702

calendar_today

Updated On:

Products

Control Compliance Suite Windows

Issue/Introduction

Evaluations show "unknown" for entire sections of checks for a particular target assets or set of assets.

 

       On examining the DPS Service verbose log files (confer with Symantec for help in gathering verbose logs) you identify errors such as the following:

********************************************

FaultErrorHandler - Unhandled Exception: System.ServiceModel.CommunicationException: There was an error writing to the pipe: The pipe is being closed. (232, 0xe8). ---> System.IO.PipeException: There was an error writing to the pipe: The pipe is being closed. (232, 0xe8).

   at System.ServiceModel.Channels.PipeConnection.StartSyncWrite(Byte[] buffer, Int32 offset, Int32 size, Object& holder)

   at System.ServiceModel.Channels.PipeConnection.WriteHelper(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, Object& holder)

   --- End of inner exception stack trace ---

   at System.ServiceModel.Channels.PipeConnection.WriteHelper(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, Object& holder)

   at System.ServiceModel.Channels.PipeConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)

   at System.ServiceModel.Channels.BufferedConnection.WriteNow(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, BufferManager bufferManager)

   at System.ServiceModel.Channels.BufferedConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)

   at System.ServiceModel.Channels.ServerSessionPreambleConnectionReader.ServerFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)

   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

   at System.ServiceModel.Channels.CommunicationObject.Open()

   at System.ServiceModel.Dispatcher.ChannelHandler.OpenAndEnsurePump()

**********************************************************

RetryHelper.Call(SendData) - failed [This request operation sent to net.pipe://localhost/Symantec.DispatchProtocol.Service/RemoteObject/141c9d703d2c41c59749ba692660abc7 did not receive a reply within the configured timeout (00:01:00).  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.], context [Dispatcher.SendSingleCallPayload], stop retry flag [False], failed retry counter [0 of 5] : System.TimeoutException: This request operation sent to net.pipe://localhost/Symantec.DispatchProtocol.Service/RemoteObject/141c9d703d2c41c59749ba692660abc7 did not receive a reply within the configured timeout (00:01:00).

 **********************************************************

When clicking the View Data Collection Details button on the Data Collection tab for an asset (that was part of the job run)in the Asset System, the data collection does not include the particular datasource that the "unknowns" in the evaluation are part of.  

 

Cause

When a Reporting and Analytics standard job run is sent to the Information server, the DPS breaks the standard's various checks into groups of checks that are from the various datasources defined in the Information server.   When passed the checks, the information server runs the separate checks as part of one datasource job, targeting the various assets.   However if the Information server, for whatever reason, cannot deliver the datasource job results to the Blade Worker processes (subprocesses for the DPS), the entire result set for checks within the datasource can be discarded or never make it back to the DPS.  This can cause the "unknown" evaluations for multiple checks in the Reporting and Analytics evaluation.

An over busy or underpowered Information server can often exhibit this behavior.

 

Resolution

The best and recommended solution is to move the DPS  to a separate server, relieving the stress on the Information server resources. 

An alternative would be to configure the DPS Blade Worker processes to wait longer before closing the pipe between itself and the Information server.  A change can be made to the Blade.WorkerProcess.exe.config  file inside of the <install path>\Symantec\CCS\Reporting and Analytics\DPS  folder to accomplish this.

WARNING: Ensure to backup the Blade.WorkerProcess.exe.config file prior to making any changes.

Navigate in this file to the section looking like the following:

<netNamedPipeBinding>
        <binding name="netNamedPipeConfig" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" transactionFlow="false" transferMode="Buffered" transactionProtocol="OleTransactions" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288" maxBufferSize="98304" maxConnections="50" maxReceivedMessageSize="98304">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="92160" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="Transport">
            <transport protectionLevel="EncryptAndSign" />
          </security>
        </binding>
      </netNamedPipeBinding>

Increase the value for the various timeout values for the pipe to a number greater than 00:01:00.  You might first try doubling the number to 00:02:00. 

Note: You may have to stop the Symantec Data Processing Service (DPS) to save this change to the file.

Once you have made the change, restart the DPS service and re-run the job to see if the increase in timeout helped.  If doubling or tripling the number did not help, this will further indicate that the server is being over taxed with too many processes on the same machine or could indicate some type of communications issue on the server itself....possibly Domain Name Services (DNS) not responding fast enough during data fetch operations.  In this latter case the entry of the hostname and IP address of the server in the server's own host file may help.

 


Applies To

Data Processing Server (DPS), Information server, and Master Query engine are all installed on the same machine.