Skip to main content

Intune Autopilot Deployment Profiles and Enrollment Status Pages

Purpose​

This SOP outlines two key procedures for distributed unit administrators at Texas A&M University:

  1. How to request the creation of Windows Autopilot deployment profiles and enrollment status pages (ESP) via Platform Engineering or UEM.
  2. How to configure and maintain the deployment profiles and ESPs once they have been created.

This dual-purpose approach ensures alignment with TAMU Platform Engineering standards and supports consistent device provisioning across distributed environments.

Scope​

This SOP applies to all distributed unit IT administrators at Texas A&M University who manage devices requiring self-deploying or user-driven Autopilot profiles and who wish to define and manage custom ESP configurations.

Intent​

To streamline and standardize both the request and post-creation configuration processes for Autopilot deployment profiles and ESPs, while ensuring compliance with TAMU Platform Engineering policies and naming conventions.

Essential Core Knowledge​

Procedure and Guidelines​

Part 1: Requesting Deployment Profiles and ESPs​

1. Determine Deployment Profile Requirements​

  • Assess whether the device requires a self-deploying or user-driven Autopilot experience.
  • Standard profile for user-driven deployments: _TAMU User Driven with Pre Provision v2
  • Example custom profile for self-deploying: CLBA_GENERAL_SHARED

2. Determine Enrollment Status Page (ESP) Requirements​

  • Identify whether the ESP is for:
    • Self-deploying devices
    • User-driven devices
  • Decide which applications must install prior to the user accessing the desktop.

3. Submit Request to Platform Engineering or UEM​

  • Open a TDX ticket requesting the creation of either:
    • An Autopilot deployment profile, or
    • An Enrollment Status Page (ESP) configuration
  • Include the following in the request:
    • Desired name of the deployment profile (if applicable)
    • Group tag to be used (e.g., CLBA_USERS)
    • ESP type (self-deploying or user-driven)
    • Requestor contact info and department
  • Note: Platform Engineering/UEM will create the profile or ESP. Configuration and ongoing maintenance will be the responsibility of the distributed unit admin.

Part 2: Configuring and Maintaining Deployment Profiles and ESPs​

4. Create Dynamic Device Group (DSG)​

  • In Entra ID, create a dynamic group using this rule:
(device.devicePhysicalIds -any (_ -eq "[OrderID]:CLBA_USERS"))

  • Note: CLBA_USERS represents the group tag assigned to Autopilot devices. Group tags must be unique, created by the unit, and begin with the unit’s FAMIS code followed by an underscore (e.g., CLBA_, VPR_).

  • Follow naming convention:

DSG - [FAMIS Code] - [Descriptive Purpose] with group tag [GROUPTAG]
e.g., DSG - CLBA - User Tagged Devices with group tag CLBA_USERS
  • Note: All DSGs that are dynamic and used to capture devices by group tag must end with the phrase with group tag [GROUPTAG].

5. Assign Group Tag to Autopilot Device​

  • Use the Microsoft Endpoint Manager admin center or PowerShell to assign a group tag to the Autopilot device before deployment.
  • Group tag must match the format noted above.
  • Refer to Microsoft Documentation for full instructions.

6. Associate DSG to Role Scope Group (RSG)​

  • Add the DSG to a Role Scope Group using the following format:
RSG - [FAMIS Code] - [Profile Type/Assignment Description]
e.g., RSG - CLBA - User Driven Autopilot Group Tag Assigned Groups
  • This ensures the ESP targets the correct devices.

7. Confirm ESP Configuration​

  • Confirm that the RSG is linked to the correct Enrollment Status Page in Intune.
  • Test that required apps install successfully before desktop access.

Additional Notes and References​

  • ESP configurations allow units to enforce app installations before users access the desktop.
  • Errors in group tag syntax or RSG assignments can delay or fail provisioning.
  • Refer to TAMU governance resources for compliance requirements.

Examples​

  • Example 1: A kiosk with the CLBA_GENERAL_SHARED profile installs Adobe Reader and CrowdStrike before login.
  • Example 2: A faculty laptop using _TAMU User Driven with Pre Provision v2 installs Office and VPN client before desktop is shown.