Introduction

SCCM ServiceNow integration is commonly implemented when an organization wants to bring endpoint-management information from Microsoft System Center Configuration Manager (SCCM), also known as Microsoft Endpoint Configuration Manager (MECM), into the ServiceNow Configuration Management Database (CMDB).

In a typical enterprise, SCCM already knows a considerable amount about Windows endpoints: computer names, operating systems, processors, disks, network adapters, installed software, hardware scans, and related inventory information. ServiceNow, on the other hand, needs reliable configuration-item information to support incident management, change management, asset management, software asset management, security operations, and CMDB reporting.

The integration connects these two worlds.

For example, imagine an organization with 25,000 Windows laptops. An employee raises an incident saying that a business application is failing. Instead of manually asking the employee for the computer name, operating system, installed software, and hardware details, the ServiceNow agent can use the corresponding CI in the CMDB.

The important point is that SCCM remains the source of endpoint inventory information. ServiceNow consumes that information and uses its CMDB capabilities to identify and reconcile configuration items.

ServiceNow’s current Service Graph Connector for Microsoft SCCM imports data into CMDB and supports SCCM/MECM environments. It can pull information about computers, processors, operating systems, disks, networks, and software.

What Is SCCM ServiceNow Integration?

At a technical level, SCCM ServiceNow integration is a one-way data ingestion process:

Microsoft SCCM / MECM
        |
        | SQL Server
        |
        v
   SCCM Database
        |
        | JDBC
        |
        v
    MID Server
        |
        |
        v
ServiceNow Service Graph Connector
        |
        | Identification & Reconciliation
        v
     ServiceNow CMDB

The SCCM database is not modified by ServiceNow. The connector reads relevant SCCM information and imports it into ServiceNow.

This distinction is important during architecture discussions.

SCCM is responsible for

• Endpoint discovery and inventory
• Hardware information
• Operating-system information
• Installed software information
• Network information
• Endpoint configuration data

ServiceNow is responsible for

• CMDB representation
• CI identification and reconciliation
• Relationship management
• ITSM processes
• Incident/change/problem processes
• Service mapping and reporting
• CMDB governance

The current Service Graph Connector also aligns the integration with ServiceNow CMDB practices such as CSDM and uses the Identification and Reconciliation Engine (IRE) to help avoid duplicate CI records.

Why Use SCCM Data in ServiceNow CMDB?

The value of this integration becomes clear when SCCM inventory is connected to ITSM processes.

Consider this example:

A production application server experiences repeated incidents.

The support analyst wants to know:

• Which operating system is installed?
• What hardware is available?
• Which software packages are installed?
• When was the machine last scanned?
• Which business service uses the CI?
• Are there other related CIs?

SCCM can provide endpoint inventory, while ServiceNow provides the operational context around the CI.

This creates a more useful CMDB than manually maintaining computer records.

Real-World SCCM ServiceNow Integration Use Cases

Use Case 1 – Endpoint Inventory Synchronization

A company manages 40,000 Windows endpoints through SCCM.

The CMDB team wants the following information available in ServiceNow:

A scheduled SCCM import keeps this information synchronized.

The ServiceNow team doesn’t need to manually create 40,000 computer records.

Use Case 2 – Incident Management

Suppose an employee reports:

“Microsoft Excel is crashing on my laptop.”

The service desk searches for the employee’s laptop in ServiceNow.

The corresponding CI can contain information imported from SCCM, including:

• Hostname
• Operating system
• Hardware
• Installed applications
• Software installation information

The analyst can therefore investigate the incident using CMDB data instead of collecting everything manually.

Use Case 3 – Software Asset Management

An enterprise wants to understand where a particular software product is installed.

SCCM already collects installed software information.

The SCCM ServiceNow integration can bring relevant software information into ServiceNow. When Software Asset Management is enabled, software installation information can also be populated for appropriate use cases. ServiceNow documents SCCM source data mappings for software and software-installation information.

This can support questions such as:

• Which computers have the application installed?
• How many installations exist?
• Which department owns the machines?
• Which CIs have not reported recently?

SCCM ServiceNow Integration Architecture

A production architecture normally contains the following components.

1. SCCM / MECM

This is the endpoint-management platform.

It collects inventory from managed computers.

2. SCCM SQL Server Database

SCCM stores inventory-related information in its SQL Server database.

ServiceNow does not directly modify this database.

3. Windows MID Server

The MID Server provides the bridge between the ServiceNow instance and the internal SCCM environment.

ServiceNow documentation identifies a Windows MID Server as required for accessing the SCCM environment through this integration.

4. JDBC Connection

The connector uses JDBC to access the SCCM SQL Server database.

5. Service Graph Connector

The Service Graph Connector processes the SCCM data and imports it into ServiceNow CMDB.

6. IRE / CMDB

Identification and Reconciliation determines how incoming records should be associated with existing CIs rather than blindly creating duplicates.

Prerequisites

Before starting the implementation, prepare the following.

ServiceNow prerequisites

You typically need:

• ServiceNow administrator access
• Service Graph Connector for Microsoft SCCM
• Integration Commons for CMDB
• CMDB CI Class Models
• Integration – JDBC
• Appropriate CMDB permissions

ServiceNow lists these dependencies for the connector configuration.

SCCM prerequisites

You need:

• Access to SCCM SQL Server
• SCCM database name
• SQL Server hostname
• SQL Server port
• SCCM database credentials
• Appropriate database permissions

For SQL authentication, ServiceNow documentation specifies a database account with db_datareader access.

Network prerequisites

Validate connectivity between:

ServiceNow
    |
    v
MID Server
    |
    v
SCCM SQL Server

The firewall must allow the required database connectivity from the MID Server environment.

Step-by-Step SCCM ServiceNow Integration

Step 1 – Install the Service Graph Connector

For a new implementation, use the Service Graph Connector for Microsoft SCCM rather than starting with the deprecated legacy SCCM plugin.

ServiceNow’s current documentation recommends the Service Graph Connector, and recent Store releases continue to update it. Version 3.9.0, for example, was released in July 2026.

ServiceNow currently documents version 3.5.0 or later as a prerequisite for configuration through SGC Central.

Step 2 – Prepare the SCCM SQL Account

On the SCCM SQL Server, create a dedicated account for the integration.

For example:

Username: svc_sccm_snow
Database: CM_PROD
Permission: db_datareader

Avoid using a personal administrator account.

The integration account should have only the permissions necessary to read the SCCM database.

ServiceNow specifically documents assigning db_datareader to the SCCM integration user.

Step 3 – Validate the MID Server

In ServiceNow, verify that the Windows MID Server is:

• Installed
• Validated
• Up
• Reachable
• Located appropriately from a network perspective

The MID Server should have network access to the SCCM SQL Server.

A common implementation mistake is to configure the ServiceNow connection successfully but forget that the MID Server itself cannot reach the SQL database.

Always test connectivity from the MID Server network.

Step 4 – Configure the SCCM Connection

For current implementations, ServiceNow provides SGC Central for configuring the connector. ServiceNow indicates that SGC Central should generally be used, while the older guided-setup approach is planned for deprecation.

Typical connection information includes:

ServiceNow documents the Microsoft SQL Server JDBC driver as:

com.microsoft.sqlserver.jdbc.SQLServerDriver

The default SQL Server port is generally 1433 unless the environment uses a custom port.

Step 5 – Configure Authentication

ServiceNow supports connection approaches including:

• SCCM JDBC connection credentials
• Windows JDBC-integrated authentication
• Air-gap configurations for restricted environments

For integrated authentication, the account running the MID Server agent needs the appropriate database access.

From a security perspective, document exactly which identity is being used.

For example:

MID Server Service Account
        |
        +---- Windows Authentication
        |
        +---- SQL Server
        |
        +---- SCCM Database

This becomes especially important when the integration works in development but fails after deployment to production because the production MID Server runs under a different Windows service account.

Step 6 – Test the Database Connection

Run the connection test from the ServiceNow configuration.

Validate:

1. SQL Server is reachable.
2. Database name is correct.
3. Credentials are valid.
4. MID Server is operational.
5. JDBC driver is available.
6. Database permissions are sufficient.

If the connection test fails, do not immediately modify transform mappings.

First isolate the connectivity problem.

Step 7 – Configure Data Imports

Once connectivity is established, configure the required SCCM data imports.

Depending on the implementation, this can include information related to:

• Computers
• Operating systems
• Processors
• Network adapters
• Disks
• Software
• Software installations

ServiceNow’s documented SCCM source mappings show SCCM inventory views being imported through JDBC data sources and mapped to corresponding CMDB tables.

Step 8 – Configure the Import Schedule

Define how frequently the SCCM information should be synchronized.

For example:

Environment: Production
Frequency: Every 4 hours
Import type: Incremental where supported

Do not automatically choose the shortest possible interval.

The correct frequency depends on:

• Number of endpoints
• SCCM database size
• Change rate
• CMDB processing capacity
• Operational requirements
• Network capacity

A 100,000-device environment requires different scheduling considerations than a 2,000-device environment.

Testing the SCCM ServiceNow Integration

Testing should be performed in stages.

Test 1 – Connection Test

Verify the JDBC connection.

Expected result:

Connection successful

Test 2 – Import a Small Dataset

Start with a controlled test environment or limited import scope where supported.

For example:

SCCM Test Computer:
WIN10-TEST-001

Verify that the corresponding CI appears in ServiceNow.

Test 3 – Validate CI Attributes

Compare SCCM and ServiceNow.

The values should reconcile according to the configured mapping.

Test 4 – Validate Duplicate Prevention

This is one of the most important tests.

Run another SCCM import for the same computer.

You should not end up with:

WIN10-TEST-001
WIN10-TEST-001

Instead, the incoming information should reconcile with the existing CI where the identification rules support that match.

The Service Graph Connector uses IRE as part of its CMDB integration approach.

Test 5 – Test Software Data

Choose a known application.

For example:

Application: 7-Zip
Computer: WIN10-TEST-001

Verify that the software information received from SCCM appears correctly in ServiceNow.

Common SCCM ServiceNow Integration Problems

1. MID Server Cannot Reach SQL Server

Symptoms:

• Connection timeout
• JDBC connection failure
• No data returned

Check:

• DNS resolution
• Firewall
• SQL Server port
• Routing
• MID Server status

2. Incorrect Database Permissions

The integration account may successfully connect to SQL Server but fail when accessing the SCCM database.

Verify:

Database User
      ↓
Correct SCCM Database
      ↓
db_datareader

ServiceNow specifically documents db_datareader for the SCCM database account.

3. Duplicate CIs

Duplicate CIs usually indicate a CMDB identification/reconciliation problem rather than simply an SCCM connectivity issue.

Review:

• Identification criteria
• Serial number
• Hostname
• Source information
• Existing CI records
• IRE processing

Do not solve duplicates by blindly adding more transform scripts.

First understand why the identification logic is failing.

4. Stale CMDB Data

Suppose SCCM reports:

Last hardware scan: 10:00 AM

but ServiceNow still displays an older value.

Investigate:

• Import schedule
• Data source execution
• MID Server
• Transform processing
• Import errors
• Data reconciliation
• Source data freshness

ServiceNow provides progress and transform history that can be used during troubleshooting.

5. Large Import Performance

Large SCCM environments can generate significant data volumes.

Instead of immediately increasing processing resources, review:

• Import frequency
• Full versus incremental processing
• Number of data sources
• Query execution time
• SQL performance
• MID Server capacity
• CMDB processing
• Unnecessary attributes

Performance should be designed around actual data volume.

Best Practices for SCCM ServiceNow Integration

1. Use the Current Service Graph Connector

For new implementations, don’t design around the deprecated legacy SCCM plugin.

ServiceNow identifies the legacy SCCM plugin as deprecated for new activations and recommends the Service Graph Connector.

2. Treat SCCM as the Endpoint Inventory Source

Avoid creating conflicting ownership between SCCM and ServiceNow.

For example:

SCCM → Hardware inventory
SCCM → Software inventory
ServiceNow → CMDB
ServiceNow → ITSM processes

Define this ownership in the integration design document.

3. Use a Dedicated Integration Account

Don’t use:

sa
administrator
personal_admin

Prefer a dedicated service account with the minimum required permissions.

4. Don’t Customize Before Understanding the Delivered Connector

A common project mistake is immediately modifying mappings.

First determine:

1. What data is already provided?
2. What target table is used?
3. How is identification performed?
4. What attributes are required?
5. Why does the delivered functionality not satisfy the requirement?

Only then introduce customization.

5. Monitor Data Freshness

CMDB quality isn’t just about whether records exist.

Ask:

“How recently was this CI information verified?”

A computer record last updated six months ago may technically exist but provide little operational value.

6. Establish CMDB Governance

Define:

• Data ownership
• Reconciliation rules
• CI lifecycle
• Stale-record handling
• Duplicate handling
• Source precedence
• Import schedules
• Failure notification

This prevents the integration from becoming another uncontrolled data feed.

SCCM ServiceNow Integration vs Manual CMDB Maintenance

The integration does not eliminate CMDB governance. It automates data acquisition while governance remains essential.

FAQ

1. Is SCCM ServiceNow integration one-way or two-way?

The standard SCCM-to-ServiceNow CMDB integration is one-way. SCCM acts as the source, while ServiceNow consumes the inventory information. ServiceNow does not write the imported inventory back into the SCCM database.

2. Does SCCM ServiceNow integration require a MID Server?

Yes, the documented Service Graph Connector architecture uses a Windows MID Server to access the SCCM environment and database.

3. Should new implementations use the legacy SCCM plugin?

For new implementations, use the current Service Graph Connector for Microsoft SCCM rather than designing around the deprecated legacy SCCM integration. ServiceNow’s current documentation recommends the Service Graph approach.

Summary

SCCM ServiceNow integration is primarily a CMDB data-ingestion architecture connecting Microsoft endpoint inventory with ServiceNow’s configuration-management processes.

The practical architecture is:

SCCM / MECM
     ↓
SCCM SQL Server
     ↓
JDBC
     ↓
Windows MID Server
     ↓
Service Graph Connector
     ↓
IRE / CMDB
     ↓
ServiceNow ITSM

For an enterprise implementation, the difficult part is usually not creating the JDBC connection. The real implementation work is ensuring that the data is accurate, identifiable, reconciled, fresh, secure, and operationally useful.

A successful project therefore starts with source ownership and CMDB design, then moves through connectivity, connector configuration, controlled imports, identification testing, reconciliation, performance testing, and production monitoring.

For current Oracle Fusion Cloud reference material, Oracle’s 26A documentation remains useful for understanding the corresponding 2026 application documentation baseline. Oracle’s 26A documentation hub is available in the official documentation library.

For the requested Oracle Time and Labor reference, see the official Oracle Fusion Cloud Time and Labor 26A What’s New documentation and the Implementing Time and Labor guide. These are separate Oracle Cloud documentation areas and are not prerequisites for SCCM-ServiceNow integration.

Official references:

Oracle Cloud Applications Documentation

Oracle Fusion Cloud Time and Labor 26A

Oracle Time and Labor – Implementing Guide

ServiceNow – Service Graph Connector for Microsoft SCCM