One Automation Engine for Circana's Physical, Virtual & Multi-Cloud Estate

Overview

Circana — a global leader in market research and consumer intelligence — runs a large, mixed infrastructure estate: physical servers and virtual machines in the on-prem data centre, plus a growing footprint across four public clouds. SharkOps designed, built, and now operates an end-to-end automation platform that provisions and configures servers across the entire hybrid estate from a single, catalog-driven workflow.

Every server — whatever platform it lands on — is built, joined to the domain, secured with the right agents, added to monitoring, hardened, and recorded in the CMDB before it is handed to an application team. The same pipeline provisions on-prem bare-metal, on-prem VMs, and Unix/Windows VMs across Azure, OCI, AWS, and GCP.

The Challenge

Before automation, each new server was a manual, multi-team effort with a different process for every platform and OS combination. That created three recurring problems:

• Slow, inconsistent builds. A single server could take days to move from request to handoff, and no two builds looked exactly alike.
• Easy-to-miss steps. Servers occasionally went live without an EDR agent, without monitoring, or without being registered in the CMDB — silent gaps that only surfaced during an incident or an audit.
• Platform sprawl. Physical (iDRAC), virtual (vCenter), and four clouds each had their own runbooks, credentials, and quirks, so knowledge lived in individual engineers' heads.

Circana needed a single, repeatable, catalog-driven way to provision and configure servers consistently across the whole estate — not eight parallel processes.

Engagement Scope

The automation covers eight platform targets. On-prem spans Unix and Windows on both bare-metal and virtual; each cloud covers Unix and Windows VMs. Every target runs through the identical pipeline, so a server lands identically configured regardless of where it runs.

Solution Architecture

The platform is built as a set of catalog-integrated workflows and skills, each tied to an ITSM Service Request (SR) and organised into three lifecycle stages. A single SR can fan out to multiple servers behind an approval gate; each server then flows independently through the same three stages.

Stage 1 — Prebuild

Prebuild is the guardrail stage. Before a single resource is touched, the workflow validates the SR and catalog inputs, resolves credentials securely from a vault (no secrets are ever written into scripts), generates the hostname, and checks it against DNS for conflicts and stale records. It also detects the target environment — physical vs virtual, and whether the target sits in an interconnected or an isolated network zone — so the later stages pick the right execution path.

• SR and catalog input validation with early, human-readable failure messages.
• Vault-based credential resolution; nothing sensitive is persisted.
• Hostname generation plus DNS / IP conflict and stale-record detection.
• Target-environment detection (physical/virtual, interconnected/isolated zones).
• Approval-gated fan-out so one request can safely drive many servers.

Stage 2 — Build

The Build stage provisions the actual compute, branching by target while keeping a single interface to the catalog:

Physical (Unix & Windows) — iDRAC

• Out-of-band power control, virtual-media boot, and BIOS / RAID configuration.
• Unattended OS deployment onto bare metal.

# Attach the OS image over virtual media, set one-time boot, then power on.
POST /redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia
POST /redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset
     { "ResetType": "On" }

Virtual (Unix & Windows) — vCenter

• Clone from a golden template, apply guest customization, and size CPU / memory.
• Attach disks and place the VM on the correct network / port group.

Cloud (Unix & Windows VMs) — Azure, OCI, AWS, GCP

• Native API instance creation with disk initialization.
• VNet / subnet placement and consistent resource tagging for cost and ownership.

Stage 3 — Postbuild

Postbuild is what makes a freshly-built server actually usable — and safe. It is the stage that closes the "server went live without an agent" gap, because none of these steps are optional or manual:

• Hostname and local / service account creation; Active Directory domain join.
• Disk initialization and partitioning; NFS mounts where required.
• CrowdStrike Falcon — EDR sensor install, AID registration, and host-group assignment.
• Trend Micro Deep Security / Cloud One — anti-malware & IPS with policy assignment.
• SolarWinds Orion — monitoring onboarding via the SWIS REST API.
• Palo Alto — policy and address-object handling for network security.
• SCCM client, OS hardening, and Windows activation.
• CMDB write-back, then a final reboot-and-validate before handoff.

# CrowdStrike Falcon: install, set the CID, and confirm the sensor registered an AID
sudo /opt/CrowdStrike/falconctl -s --cid="$FALCON_CID"
sudo systemctl start falcon-sensor
sudo /opt/CrowdStrike/falconctl -g --aid   # verify Agent ID is present

# SolarWinds Orion: add the node for monitoring via the SWIS REST API
curl -s -u "$SWIS_USER:$SWIS_PASS" -X POST \
  "https://$ORION_HOST:17778/SolarWinds/InformationService/v3/Json/Create/Orion.Nodes" \
  -H "Content-Type: application/json" \
  -d '{ "IPAddress": "'"$HOST_IP"'", "EngineID": 1, "ObjectSubType": "SNMP" }'

Scenario Handling

The difference between a demo and a platform Circana can trust in production is how it behaves on the bad days. The workflows were deliberately built to survive real operating conditions rather than only the happy path:

• Isolated vs interconnected networks. Detected in Prebuild; the workflow selects the right jump path and package/agent source per zone.
• Stale DNS records. Flagged and reconciled before the hostname is reused, avoiding "phantom host" collisions.
• Agent re-registration. When a hostname changes, CrowdStrike and monitoring agents are re-registered cleanly instead of leaving orphaned entries.
• Credential edge cases. Platform-specific credential handling (iDRAC, vCenter, per-cloud, WinRM vs SSH) resolved centrally, so one server type failing doesn't block the rest of the fan-out.

Tools & Platforms Integrated

Results

• Unified provisioning across 8 platform targets (4 on-prem + 4 cloud), Unix and Windows, from a single catalog-driven workflow — replacing eight separate manual processes.
• Every server arrives production-ready — domain-joined, EDR- and IPS-protected, monitored, hardened, and CMDB-registered before handoff. The "server went live without an agent" gap is closed by design.
• Build turnaround dropped from days to hours, because the slow, hand-offs-heavy manual path was replaced by an approval-gated, fan-out pipeline.
• Consistent, auditable builds tied to each Service Request, with status tracked end-to-end in ITSM and a definitive CMDB record for every host.

Provisioning is now a request-and-approve action in the service catalog rather than a multi-day, multi-team ticket. A server built on AWS looks exactly like a server built on bare metal in the data centre — same agents, same hardening, same record of truth.

Key Takeaway

In a hybrid estate, the hard part isn't provisioning any single server — it's making a physical box, a vCenter VM, and a cloud instance all arrive identically configured and secure, every time, without an engineer remembering step 14. Modelling the work as one catalog-driven Prebuild → Build → Postbuild pipeline — and hardening it for the messy real-world scenarios — is what lets Circana treat "on-prem or any cloud" as an implementation detail rather than eight different problems.