sccm

README documentation for sccm

stableRepositoryPowerShellprivate

4 min readUpdated Jul 24, 2026@observability-teamObservability

Source: ZoosGlobal/sccm Visibility: Private This page is automatically synchronized from the repository README. Do not edit this generated file directly.

sccm — Datadog Integration Configuration Library 🚀

Central repository of Datadog Agent integration configurations for all monitored services across the organization’s Windows server fleet. This repo is the single source of truth for conf.d integration files, deployment scripts, and role-based configuration profiles used to onboard and standardize Datadog monitoring on Windows infrastructure.

❓ The Problem — Why This Exists

As EXL’s Windows server fleet grew, Datadog monitoring was being configured manually and inconsistently across hosts. This created a number of operational issues:

No standardization — Each server’s Datadog config was set up ad hoc, leading to inconsistent metrics, missing checks, and gaps in visibility across similar hosts.
No single source of truth — Integration configs lived only on individual servers, with no version-controlled record of what was deployed, when, or why.
Role drift — Servers performing the same function (e.g. all Domain Controllers, all SQL Servers) often ended up with different monitoring coverage depending on who configured them and when.
Slow onboarding — Standing up monitoring for a new server meant manually hunting down the right conf.yaml files for each integration and copying them over by hand, which was slow and error-prone.
Difficult auditing & rollback — Without version control, there was no way to track changes to monitoring configs over time or revert a bad change.
No separation between “every server” and “role-dependent” checks — Baseline checks and role-specific checks were mixed together, making it hard to reason about what should run where.

✅ The Solution — What We Built

We built a centralized, version-controlled Datadog configuration library that standardizes how monitoring is deployed across the entire Windows server fleet.

Approach

conf.d/ (master integration configs)
        ↓
 Universal-Configs/  +  Role-Specific-Configs/
        ↓
 Deployment scripts (universal.ps1, dns.ps1, ...)
        ↓
 Datadog Agent conf.d (on target server)
        ↓
 Datadog Logs / Metrics / Dashboards

Key Design Decisions

Decision	Rationale
Single repo for all integration configs	`conf.d/` acts as the master library — one place to find, update, and version every integration’s config
Split into Universal vs. Role-Specific configs	Cleanly separates “every server gets this” from “only this role gets this,” removing config drift between similar servers
PowerShell-driven deployment	Applying configs to a server is scripted and repeatable, not manual copy-paste
Git-based version control	Every change to a config is tracked, auditable, and revertible
Convention-based folder naming	Each integration folder matches Datadog’s native `<integration>.d` naming, so configs map directly onto the Agent’s expected structure

Outcome

New servers can be onboarded with consistent baseline monitoring in minutes, not hours.
Servers of the same role (DC, SQL, IIS, etc.) now have guaranteed, identical monitoring coverage.
Configuration changes are tracked in version control, making audits and rollbacks straightforward.
The separation of universal and role-specific configs makes it easy to reason about, and extend, what gets monitored where.

🧩 What This Repo Contains

`conf.d/`

A mirror of Datadog Agent’s integration config directory (C:\ProgramData\Datadog\conf.d\ on Windows). Each subfolder corresponds to a single Datadog integration (e.g. sqlserver.d, iis.d, netskope.d) and holds the conf.yaml (and any supporting files) that the Datadog Agent loads to collect metrics, logs, or checks for that service. New integrations are added here as new services are onboarded into Datadog monitoring.

`Universal-Configs/`

Configuration applied uniformly to every Windows server in the fleet — baseline checks every host should have regardless of its function (e.g. win32_event_log, windows_performance_counters, system core/disk/memory checks).

`Role-Specific-Configs/`

Configuration scoped to a server’s role — only deployed to hosts that match that role. For example, a Domain Controller gets Active Directory + DNS configs, a database host gets sqlserver.d, a web server gets iis.d, etc. This avoids enabling irrelevant or noisy checks on hosts that don’t run that service.

PowerShell Scripts

universal.ps1 — Applies the contents of Universal-Configs/ to a target server.
dns.ps1 — Sets up DNS-specific monitoring configuration.
Untitled-1.ps1 — Appears to be a work-in-progress/scratch script; recommend renaming or removing before next cleanup pass.

⚙️ How It Fits Together

   Server Role Identified
            │
            ▼
  ┌─────────────────────┐
  │   universal.ps1     │──▶ Deploys Universal-Configs (baseline, all servers)
  └─────────────────────┘
            │
            ▼
  ┌─────────────────────┐
  │  Role-specific       │──▶ Deploys configs matching the server's role
  │  deployment script   │     (DC, SQL, IIS, etc.) from Role-Specific-Configs/
  └─────────────────────┘
            │
            ▼
  Datadog Agent (conf.d) ──▶ Datadog Logs / Metrics / Dashboards

Every server gets the Universal-Configs baseline applied first.
Based on the server’s identified role, the matching Role-Specific-Configs are layered on top.
The relevant integration YAML files (sourced from conf.d/) are placed into the Datadog Agent’s config path, and the Agent is restarted to pick up the new checks.

✅ Usage

# Apply universal baseline config to a server
.\universal.ps1

# Apply DNS-specific monitoring
.\dns.ps1

# Restart Datadog Agent to load new configs
Restart-Service datadogagent

🛡️ Conventions

Each integration lives in its own <integration_name>.d folder under conf.d/, matching Datadog’s native naming convention.
Configs intended for all hosts go in Universal-Configs/.
Configs intended for a specific server role go in Role-Specific-Configs/, organized by role.
PowerShell scripts at the repo root handle deployment/application of these configs to target servers.