Lesson 4	Restricting OS Deployments with Configuration Manager
Objective	Explain how to restrict operating-system deployments to selected users or computers using Configuration Manager task sequences, device collections, and role-based administration

Restricting OS Deployments to Selected Users and Computers

In an enterprise environment, not every computer or user should receive every operating-system deployment. A domain controller build should not be available to a web server collection, a development lab image should not reach production servers, and a junior administrator should not be able to deploy an OS to systems outside their scope of responsibility. Controlling which deployments reach which targets — and which administrators can manage those deployments — is a core OS deployment governance task.

In Windows Server 2025 environments, this requirement is implemented through Microsoft Configuration Manager task-sequence deployment targeting, combined with device and user collections and role-based administration. This lesson explains the model, its two distinct permission layers, and how to implement collection-based deployment control in practice.

The Two Layers of Deployment Control

Deployment control in Configuration Manager operates at two distinct levels that are often confused but must be understood separately.

Layer 1: Who May Receive a Deployment

A Configuration Manager task sequence encapsulates the complete deployment definition for a server role. It references:

The boot image (a custom WinPE environment with appropriate drivers)
The OS image (install.wim or a previously captured WIM)
The unattended Setup answer file (unattend.xml)
Driver packages specific to the target hardware
Application installations required for the role
PowerShell scripts, role-configuration steps, and post-installation tasks

Once a task sequence is defined, it is deployed to a collection. A collection is a named, managed group of computers or users. Only the devices or users whose membership matches the collection receive the deployment or see it as available through the Software Center. A computer that is not a member of the targeted collection cannot access the deployment at all — there is no permission to deny, because the deployment is simply not visible to non-members.

Layer 2: Who May Administer the Deployment System

Role-based administration controls which administrators can create, modify, distribute, or deploy OS images. This is entirely separate from which computers receive deployments. Three Configuration Manager objects define administrative boundaries:

Object	Purpose
Security role	Defines the actions an administrator is permitted to perform — for example, creating a task sequence, adding a boot image, or deploying to a collection
Security scope	Limits which deployment objects (task sequences, images, packages) an administrator can see and manage
Collection	Limits which users or devices an administrator can target with a deployment

Microsoft provides an Operating System Deployment Manager security role for administrators who need permission to create and manage OS deployments without holding full Configuration Manager administrator rights. Combining this role with a limited security scope and a specific collection gives a regional or departmental IT team exactly the access they need — and nothing beyond it.

Collection-Based Deployment Targeting in Practice

The practical implementation assigns a separate task sequence to each server role, and deploys each task sequence only to the collection representing the computers authorized to receive that build. The base OS image is never duplicated — the same install.wim is referenced by all task sequences; only the answer file, driver packages, application installations, and configuration steps differ.

Domain Controllers collection
    → Windows Server 2025 Domain Controller task sequence
      unattend.xml: ADDS role, DNS, specific OU join, DC hardening policy

Web Servers collection
    → Windows Server 2025 IIS task sequence
      unattend.xml: IIS role, web platform components, TLS configuration

Database Servers collection
    → Windows Server 2025 SQL Server task sequence
      unattend.xml: SQL prerequisites, storage layout, service accounts

Development Lab collection
    → Windows Server 2025 Lab task sequence
      unattend.xml: development tools, relaxed policies, lab OU join

A computer in the Web Servers collection will not see or receive the Domain Controller task sequence. A computer in the Domain Controllers collection will not see or receive the SQL Server task sequence. Deployment visibility is determined entirely by collection membership.

Collection Membership Rules

Collections can be built using several membership criteria, or a combination of them:

Query-based rules — dynamically include computers that match an AD query, such as all computer objects in a specific organizational unit or security group
Direct rules — manually add specific named computers to the collection
Hardware attribute rules — include computers by manufacturer, model, chassis type, or other hardware inventory attributes
IP subnet or AD site — scope a collection to a specific network location, useful for branch-office deployment management

Query-based rules update automatically as computers are added to or removed from AD groups or OUs, making them the preferred approach for large or frequently changing environments.

Role-Based Administration: Scoping Administrator Access

The role-based administration layer controls who can manage the deployment infrastructure itself. Practical examples of how this is applied:

A regional IT team is granted the Operating System Deployment Manager role scoped to their region's collections only — they can deploy OS images to their assigned computers but cannot modify deployments targeting other regions
A helpdesk team is granted permission to initiate deployments to workstation collections but not to server collections, preventing accidental server reimaging
A junior administrator is granted read-only access to task sequences and collections, allowing them to review deployment configurations and report on deployment status without being able to modify or trigger deployments
An application packaging team is granted permission to manage application packages and task-sequence steps related to software installation, but not to modify the OS image or answer-file components of a task sequence

Security roles, scopes, and collections work together to create a least-privilege administrative model — administrators have exactly the access their role requires, and no more.

WDS Prestaging and PXE Approval

Traditional Windows Deployment Services offered two access-control mechanisms that provided a degree of deployment restriction within the WDS model. These are referenced here for context, but are not the recommended approach for Windows Server 2025.

Prestaged computers: An administrator creates a computer object in Active Directory and associates it with a specific WDS server and unattended answer file. When the prestaged computer PXE boots, WDS recognizes its network adapter MAC address and assigns the designated answer file automatically. Unknown computers — those without a prestaged AD object — receive a different response, which may be a denial, a prompt for administrator approval, or a default image.

PXE response policy and auto-add approval: WDS can be configured to require administrator approval before an unknown computer receives any PXE response. This prevents unauthorized machines from initiating a deployment. Administrators review and approve queued computers through the WDS console, optionally assigning each an answer file and server before approval.

These mechanisms addressed the same business requirement as collection-based targeting, but within the narrower WDS model. The installation-media WDS deployment workflow is not supported for Windows Server 2025 for operating systems after Windows Server 2022. Microsoft recommends Configuration Manager or another deployment product using a custom boot image for current OS deployments.

Comparison: Legacy RIS vs. Configuration Manager

Windows 2000 RIS	Windows Server 2025 / Configuration Manager
All images available to all users by default	All task sequences unavailable by default until explicitly deployed to a collection
NTFS read permissions on answer files control image visibility	Task-sequence deployment scoped to a device or user collection
AD security groups control which image menu a user sees	Collections (AD group, OU, hardware query, subnet) determine deployment targets
RIS server administers all images uniformly	Role-based administration scopes admin access by security role and scope
Separate answer file required for each image variation	One task sequence per deployment profile; same base WIM reused across all
No separation between deployment permissions and admin permissions	Security roles, scopes, and collections provide granular separation

The underlying requirement is unchanged: different computers or groups of users should receive different OS configurations, and unauthorized targets should not receive deployments not intended for them. The implementation has shifted from NTFS permissions on a shared folder to collection membership and role-based administration in a centrally managed deployment platform.

The next lesson covers how to create a PXE boot environment and boot a client computer into the deployment workflow on Windows Server 2025.

Restrict Image - Exercise

Click the Exercise link to apply your knowledge of deployment targeting and image restriction in a problem-solving exercise.
Restrict Image - Exercise