Fabrikam - One Patching Control Plane Across Three Network Zones
Fabrikam runs 120 Windows Server 2019 and 2022 VMs on VMware. Eighty-five sit in the corporate network and reach the internet only through an authenticating proxy. Thirty-five sit in a PCI segment with no internet egress at all; five of those are workgroup machines running SQL Server. All patching today goes through a single WSUS server whose content drive is at 92% capacity, and compliance is reported by pasting WSUS console screenshots into a monthly deck.
Fabrikam has an Azure subscription and wants Azure Update Manager to assess and patch all 120 servers with one compliance view. Change control requires patches to install inside a defined window per region and no server to reboot without recorded approval, but the team refuses to run a second patching tool just for the PCI segment.
1. For each of the three groups - corporate/proxied, PCI/no egress, and workgroup SQL - state whether Azure management is possible, and what connectivity or identity work is required first.
Read the worked answer
| Group | Azure Update Manager possible? | Prerequisite |
|---|---|---|
| Corporate (85) | Yes | Azure Arc-connected machine agent with outbound HTTPS through the proxy |
| PCI (30) | Yes, but only via private connectivity | Arc private link scope + private endpoint reachable from the PCI segment |
| Workgroup SQL (5) | Yes | Nothing extra - Arc does not require domain join |
Reasoning
- The Arc agent is the on-ramp for everything else. It needs outbound HTTPS to a fixed endpoint set. In the corporate network, set the proxy through the agent's proxy configuration (or the documented environment variables) and confirm the proxy passes the required URLs; an authenticating proxy that intercepts TLS will break enrolment until its certificate is trusted on the servers.
- The PCI segment is a network problem, not a feature problem. Because those servers cannot reach the public Arc endpoints, onboard them through an Arc private link scope with a private endpoint in the PCI VNet/segment. Do not punch a hole in the PCI boundary to save a design step - that usually fails the audit.
- Workgroup membership is irrelevant to Arc; management identity comes from the Azure resource and RBAC, not from AD. This is a common trap: teams assume the workgroup SQL boxes are unmanageable.
- Keep the endpoint set and proxy exceptions in one documented place; a missed URL shows up as a machine that enrols and then silently stops reporting.
2. A PCI server is onboarded successfully but shows "no updates available" and never patches. Diagnose the likely cause and the constraints on the fix.
Read the worked answer
Diagnosis
- Azure Update Manager does not host or ship patch binaries. It orchestrates the operating system's own update stack. If the machine cannot reach its configured update source, assessment comes back empty or stale - it looks like compliance, not like a network fault.
- Check in this order:
- Is the machine using Windows Update / Microsoft Update directly, or a WSUS server defined by Group Policy?
- Can it reach that source from the PCI segment (no egress = no Microsoft Update)?
- Does the agent report recent heartbeat and assessment time, or only an old snapshot?
Fix options, in order of preference
- Keep WSUS as the download source for the PCI segment and let Update Manager orchestrate windows, approvals and reporting, with the PCI servers pointed at WSUS. This preserves the air-gapped boundary and reuses infrastructure.
- Publish Windows Update endpoints through the existing controlled egress path with an explicit allow-list.
Constraints to state out loud
- Option 1 still requires the WSUS content drive problem to be solved (the 92% disk); the orchestration layer no longer removes that.
- Never open broad internet egress from a PCI segment to make a tool happy; document whichever path you choose as part of the segmentation evidence.
3. Design the schedule and approval model so that windows are honoured per region and no reboot happens without a recorded approval, and explain how you would detect machines that fall out of compliance.
Read the worked answer
Scheduling
- Use maintenance configurations with explicit schedules, each set to the correct time zone for its region. A schedule expressed in UTC is a recurring cause of patches landing in business hours after a daylight-saving shift.
- Use separate maintenance configurations per region/patch ring rather than one global window, and scope them with dynamic queries (for example, by resource group, tag, or OS) so new servers join the right ring automatically instead of being added by hand.
- Set a maximum reboot time and pre/post tasks where a real approval gate is needed, so the run does not silently overrun the window.
Approval
- Separate roles: the platform team owns maintenance configurations, application owners are granted only what they need to approve an override. Record approvals in change management, not in chat.
- Use automatic assessment for detection, but customer-managed schedules for deployment - automatic patching by policy is incompatible with "no reboot without approval".
Drift detection
- Machine heartbeat age and last-assessment time are the signals. Alert when a machine has not assessed within the expected interval: it is either offline, behind a broken proxy exception, or the agent has crashed. A dashboard showing only "compliant" hides all three.