The Tenable Patch Server Logs and Client Logs are available to monitor the solution and troubleshoot issues. When working with Tenable Customer Support, please copy the logs out of their home folder and compress them before sharing with your support agent.

Server Logs

Location: %ADAPTIVASERVER%\logs

Note: The %ADAPTIVASERVER% environment variable points to the Tenable Patch Management (On-Premises) Server installation path. The default location is C:\Program Files\Tenable\PatchServer.

• adaptiva.err: Records any errors during the running of the tenable-patch-server service.

• adaptiva.log: Records almost all data regarding tenable-patch-server service.

• AdaptivaNativeUtils.log: tenable-patch-server to windows access logging.

• AdaptivaNativeUtilX.log: tenable-patch-client FIPS cryptography operations using OpenSSL.

• AdaptivaServerNativeUtils.log: Logs from native library such as addition and removal of SMB connections for networked filesystems.

• AdaptivaService.log: AdaptivaService service start/stop logging.

• AdaptiveProtocolTransport.log: tenable-patch-server data transfers using Adaptive Protocol.

• messagingMonitor.log: Logs all RVP advertisements.

• ntlmauth.log: Logs NTLM and Kerberos authentication for SQL Server from native library.

• revision.properties: Contains the timestamp, git commit id, and full version of the code for this install.

• sqlMonitor.log: Call to SQL logging.

• VCDiff.log: Logs generated by the native component responsible for creating diffs between two files. These files typically belong to different versions of application-level content for which differences (diffs) are computed.

• VCDiffDecoder.log: Logs generated by the native component responsible for applying a diff to a previous file version in order to reconstruct the updated content.

Server Component Logs

Location: %ADAPTIVASERVER%\logs\componentlogs

• Akka.log: Logs from the server's REST API.

• BlobServer.log: Logs for internal system used for blob downloads.

• BlobVersionAuditor.log: Used for blob system auditing. Blob system is used when integrated with Microsoft Configuration Manager.

• ByteLevelP2PPublisher.log: Logs publication of content using the byte-range peer-to-peer protocol.

• CdnService: Catch-all log for anything to do with accessing the CDN service. Typically this covers service initialization, obtaining credentials from the operations manager, and upload and download of content.

• ClientUpgrade.log: Client auto upgrade system logs.

• ContentSQLQuery.log: Logs content receipts.

• DeltaSeries.log: Tracks download and assembly of delta series content, i.e. content for which an earlier version may already exist locally. Typically useful when monitoring feeds, for which it handles content download before consumption. On customer servers, this log also covers distribution of delta series to client systems.

• Feeds.log: Tracks the receipt of feeds from the operations manager, and their subsequent consumption or distribution to client machines. Download of feed content is handled by the delta series system, which logs that part in more detail.

• HTTP.log: Used to monitor the health of the application's HTTP clients and connection managers.

• IntentHistory.log: Logs server-side changes made to Intent Schema objects.

• License.log: Records the status of the licenses enabled on the server.

• MASFileActivity.log: Covers direct content uploads from MAS to the public CDN. Note that this is distinct from feed publication, which also uploads content.

• MemoryManager.log: Current server memory usage and changes in memory usage.

• MetadataCommon.log: Logs CVE mapping updates for metadata objects.

• MetadataOperations.log: Logs patch blocklisting operations.

• MultiTenancy.log: Logs when tenants are created, updated and deleted on multi-tenant systems.

• OperationsManagerRequests.log: Logs requests sent to Operations Manager.

• P2PRing.log: Logs information about P2P ring system which is used for uploading the status messages from clients.

• Patching.log: Miscellaneous patching-related logs.

• PatchingApprovals.log: Logs when patch approvals are created or updated.

• PatchingStatusCollection.log: Logs receipt of patch statuses from clients and persistence to the database.

• Provisioning.log: Logs server activation via Operations Manager.

• PayloadActivation.log: Logs the arrival of new policy payloads from the server pending activation, including their policy ID, payload ID, and scheduled activation time.

• RelayDetailed.log: Detailed logging for Relay connectivity and Security protocols on HTTP. RelayDetailed are the previous HttpTransport, Security, and Relay logs combined into one file. This includes detailed error messages with stack traces as well as verbose logging for tracing requests end to end.

• RelaySimple.log: Provides an overview of handshakes and HTTP messaging from a more conceptual standpoint. Instead of logging through the train of classes and method executions involved in the process, it is intended simply to say the handshake completed successfully. It can be used to confirm that the system is working as intended, or that something broke and the detailed logs may need digging through.

• RestApiFoundry.log: Logs requests and authentication used by the API Foundry tool.

• SensorOfflineCache.log: This system does scheduled collection of data on clients and uploads diffs to the server.

• SqlDataProvider.log: Logs interactions with the system used to author and execute SQL for dashboards and analytics.

• SQLUploader.log: Logs when payloads of data are sent to the server to be inserted into the database in bulk.

• ThreadInfo.log: Output for logging current thread state information when slm.logthreadstates or slm.log_thread_cpu_info is set to true.

• TwilioSendGrid.log: Logs interactions with third-party APIs for communication providers such as Twilio, SendGrid and Microsoft Teams.

• UserDashboardSubscription.log: Logs export of dashboards to Excel.

• Utils.log: Generic utility logs.

• VulnerabilityManagement.log: Logs receipt and processing of vulnerability data from vulnerability management integrations.

• WebUINotifications.log: Notifications delivered and received from the frontend Web UI.

• WindowsPatching.log: Progress and results of scans and patches for Windows Update and Office365.

• WorkflowStatus.log: Execution status, progress and errors related to workflow invocations.

Server Workflow Logs

Default Folder: %ADAPTIVASERVER%\logs\workflowlogs

• <workflowname>-<workflowid>-<sequencenumber>.log: All server and business workflows execution logging.

For similar descriptions of Tenable Patch Client logs, please see our Tenable Patch Client Logs page.