Scenario E: DevOps & Automated Pipelines
Who this fits
Build agents and automated pipelines that need a pinned, reproducible VM — not the latest image Microsoft happens to publish this month. The guest OS can be Windows or Linux; what matters here is that the image doesn't drift.
Architecture at a glance
This scenario still uses the Management Portal, Golden Images, and Policies — same system as Scenarios A–C — but with Deployment method set to VM image instead of Declarative, and no Intune enrollment step. However your build Macs get Parallels Desktop installed (Jamf app catalog, manually, or by invitation email), once the installation activates against the pipeline's sublicense, the Portal pushes the assigned Golden Image the same way it does elsewhere.
Attention: If your build fleet includes Intel Macs, the latest version of Parallels Desktop 26 is the last release with Intel support. Plan your pipeline's Parallels Desktop version accordingly — those agents can't move to version 27 or later.
Deployment method and why
VM image. Declarative deployment can pull the latest Windows Enterprise image from Microsoft, or a Custom ISO you supply yourself — but either way, it's Windows-guest only, so it's off the table for Linux build agents regardless of installation source. VM image is where Linux fleets go: build, sysprep (or the Linux equivalent), and upload the .pvmp yourself. You can host it on a direct URL, or through the Portal's Azure Storage integration (with more options to come) instead of managing your own download link. Either way, you're responsible for keeping the image patched and re-uploading a refreshed .pvmp and checksum on your own schedule — there's no automatic refresh like Declarative gets from Microsoft.
For Windows pipelines that want a pinned, reproducible build rather than whatever gets produced at first launch, VM image still gives you that full control: you decide what's baked in, sysprep it yourself, and nothing changes underneath you until you choose to re-upload.
Intune enrollment isn't part of this scenario: it's specific to Windows guests provisioned Declaratively and doesn't apply to VM image Golden Images generally — nor would it help for a Linux guest.
Management Portal policy settings
Create a policy for the build-agent/pipeline group with a Golden Image set to VM image, using the pinned image and checksum from Stage 2. Recommended settings for this group:
Security Controls: Do not allow upgrading to the next major Parallels Desktop version · Do not allow removing provisioned VMs.
VM Settings: Clipboard/Drag-and-drop: Disconnect · Disable sharing Mac folders with VM · Disable sharing VM apps with Mac · VM startup: Ready in background.
See Stage 3: Management Portal & Remote Policy Setup for how to create the policy, and the full comparison across scenarios.
Role handoffs
Portal Admin — creates the policy and Golden Image, applies the Security Controls above.
Build Infrastructure Admin — builds, syspreps, and re-uploads the pinned VM image on its own patch schedule. (There's no Windows-Identity Admin role in this scenario, since there's no Intune enrollment step.)
Verification
In the Management Portal, confirm the build agents' VMs show as provisioned from the correct Golden Image version. Run a pipeline job against a newly provisioned agent and confirm it boots the pinned image and completes successfully.
Where to go next
See Stage 1: Account, SSO & Licensing Configuration for the pipeline group's sublicense setup, and Stage 5: Day-2 Operations for keeping the pinned image patched over time.
Last updated