Scope Groups and Naming Conventions in Intune and Entra ID

This document details the structure and naming conventions of scope groups within Intune and Entra ID, ensuring clarity and efficiency in managing devices, users, policies, roles, and permissions.

---

🔑 Prerequisite: Administrative Units (AUs) for Scope Group Creation

Before creating any of the scope groups detailed in this document, it is essential to understand the role of Administrative Units (AUs) in Entra ID.

• All scope groups (which are Microsoft Entra security groups) MUST be created within the respective unit's designated Administrative Unit.
• The naming convention for these particular Administrative Units is AU-[FAMIS CODE]-Groups. For example, if a unit's FAMIS code is VPOP, its Administrative Unit will be named AU-VPOP.
• To create or manage scope groups within a specific AU, personnel must have the Groups Administrator role assigned to them for that particular AU. This often requires an elevation of privileges (e.g., through Privileged Identity Management - PIM).
• This practice ensures that the management and membership of scope groups are controlled by the authorized personnel within each unit, maintaining a delegated administrative model while operating within a unified system.

---

📌 Scope Group Types

Each scope group serves a unique function in the organization. This section defines each group type, its purpose, use cases, and key details.

---

🖥️ Device Scope Group (DSG)

Purpose: Manages all devices enrolled in Intune, such as Windows desktops and Android devices, specific to a unit. Members: Contains device objects (e.g., DSG - CLED - Faculty Laptops). These are the foundational groups for device collections. Use Case: Used for direct device targeting when needed, but more commonly nested into Experience Scope Groups (ESGs). Key Details: Enables grouping devices for simplified configuration and deployment. Must be created within the unit's AU.

---

👥 User Scope Group (USG)

Purpose: Organizes user accounts by roles or departments within the organization, specific to a unit. Members: Contains user and service accounts (e.g., USG - CLED - Faculty Users). These are the foundational groups for user collections. Use Case: Supports role-based access and policy targeting, primarily by being nested into Experience Scope Groups (ESGs). Key Details: Aligns user permissions with roles, streamlining access management. Must be created within the unit's AU.

---

🌐 Experience Scope Group (ESG)

Purpose: Defines a specific user or device "experience" by grouping together relevant User Scope Groups (USGs) and/or Device Scope Groups (DSGs) from the same unit. ESGs act as the target for a collection of policy and application assignments delivered via Policy Scope Groups (PSGs). Members: Composed of one or more USGs and/or DSGs from the same unit (FAMIS Code). For example, ESG - CLED - Faculty Standard Experience might contain USG - CLED - Faculty Users and could also contain DSG - CLED - Faculty Standard Devices if a combined user/device experience is defined. Use Case: Simplifies the assignment of a consistent set of policies and applications to a defined cohort. Instead of adding many USGs/DSGs to many PSGs, you add the USGs/DSGs to one ESG, and then that one ESG to multiple PSGs. This ESG then represents the "package" of configurations for that cohort. Key Details: Essential for configuring consistent and intentional user/device experiences. An ESG represents a "bundle" of settings and software. Must be created within the unit's AU.

---

📑 Policy Scope Group (PSG)

Purpose: Manages specific policy and application assignments within Intune. Members: Primarily composed of Experience Scope Groups (ESGs). An ESG (which contains specific USGs or DSGs) is added as a member to one or more PSGs to apply the defined policies or applications to the cohort represented by that ESG. Use Case: Controls the deployment of individual policies and applications. For example, the ESG - CLED - Faculty Standard Experience would be a member of PSG - Required - User - CLED - Microsoft Office 365 and PSG - Included - User - CLED - OneDrive Compliance Policy. Key Details: Uses specific naming conventions to indicate assignment type, target, and unit. Crucially, all User PSGs should incorporate a filter to exclude shared devices. Must be created within the unit's AU.

PSG Structure and Assignment Types:

(This section remains largely the same but is now better contextualized by the ESG explanation above)

Shared Device Exclusion Filter: To prevent user-assigned policies and applications from deploying to shared machines (e.g., lab devices, shared workstations, kiosks), all User PSGs (Required, Available, Uninstall for applications; Included for policies) must have an Exclude filter applied when the members are ESGs containing USGs, or direct USGs.

• The filter to use is named "Shared Device - Filter".
• Rule Syntax: (device.enrollmentProfileName -ne "_TAMU User Driven with Pre Provision")

For Applications:

• PSG - Required - User - [FAMIS Code] - (Application Name)
• PSG - Required - Device - [FAMIS Code] - (Application Name)
• PSG - Available - User - [FAMIS Code] - (Application Name)
• PSG - Available - Device - [FAMIS Code] - (Application Name)
• PSG - Uninstall - User - [FAMIS Code] - (Application Name)
• PSG - Uninstall - Device - [FAMIS Code] - (Application Name)

For Policies (all types other than applications):

• PSG - Included - User - [FAMIS Code] - (Policy Name)
• PSG - Included - Device - [FAMIS Code] - (Policy Name)
• PSG - Excluded - User - [FAMIS Code] - (Policy Name)
• PSG - Excluded - Device - [FAMIS Code] - (Policy Name)

Example Assignments Illustrating Nesting:

Let's consider the "College of Education Faculty" (FAMIS Code: CLED):

1. Base Groups:

   • USG - CLED - Faculty Users (Contains all faculty user accounts for CLED)
   • DSG - CLED - Faculty Laptops (Contains all faculty-assigned laptop device objects for CLED)

2. Experience Definition Group:

   • ESG - CLED - Standard Faculty Experience
     • Members: USG - CLED - Faculty Users (and/or DSG - CLED - Faculty Laptops if policies are device-specific for this experience)

3. Policy & Application Assignment Groups (PSGs) targeting the ESG:

   Assignment Type	Target	Group	Members (Example)	Filter Mode (if User)	Filter Name (if User)
   Required	User	PSG - Required - User - CLED - Microsoft Office 365	ESG - CLED - Standard Faculty Experience	Exclude	Shared Device - Filter
   Included	User	PSG - Included - User - CLED - OneDrive Compliance Policy	ESG - CLED - Standard Faculty Experience	Exclude	Shared Device - Filter
   Available	User	PSG - Available - User - CLED - Adobe Acrobat Pro	ESG - CLED - Standard Faculty Experience	Exclude	Shared Device - Filter
   Included	Device	PSG - Included - Device - CLED - Standard Laptop Configuration	ESG - CLED - Standard Faculty Experience	None	None

This structure clearly shows that by managing the membership of USG - CLED - Faculty Users, and then ensuring this USG is in ESG - CLED - Standard Faculty Experience, the entire suite of policies and applications assigned via the various PSGs is consistently applied to define the CLED faculty's IT experience.

---

🔐 Role Scope Group (RSG)

Purpose: Provides custom role-based access, often linked to temporary privilege elevation through PIM (Privileged Identity Management). Members: Specific users or USGs requiring elevated access for certain tasks. Use Case: Manages permissions for sensitive or administrative roles, such as BitLocker recovery. Key Details: Often tied to PIM to manage temporary privileges. Must be created within the unit's AU.

---

🗂️ File Scope Group (FSG)

Purpose: Manages file permissions for cloud-based storage like SharePoint. Members: User accounts or roles needing specific access to files/folders. Use Case: Controls folder and file-level access in environments like SharePoint Online. Key Details: Offers fine-grained access control, securing sensitive data. Must be created within the unit's AU.

---

☁️ Cloud Scope Group (CSG)

Purpose: Grants access to cloud-based resources such as SharePoint Online sites/pages, Microsoft Loop, Microsoft Planner, or other cloud services. Members: User accounts or roles requiring access to specific cloud resources. Use Case: Provides permissions to SharePoint Online sites/pages or other cloud resources like Loop and Planner. Key Details:

• Naming Convention: CSG - [FAMIS Code] - [Site Name] - [Access Level].
• Hub Sites: Include "Hub" in the site name for hub sites (e.g., CSG - VPOP - Research Hub - Read).
• Descriptions: Include the full URL of the SharePoint Online site or the cloud resource it grants access to in the group's description. Must be created within the unit's AU.

Example Names:

• CSG - VPOP - Research Hub - Edit
• CSG - CLED - Marketing Planner - Owner
• CSG - ENGR - Project Loop Site - Contributor

---

📖 Naming Conventions for Scope Groups

Adhering to clear naming conventions helps keep scope groups identifiable, organized, and consistent. Remember, all scope groups must be created within the unit's Administrative Unit (e.g., AU-[FAMIS CODE]-Groups) by personnel with the appropriate Groups Administrator role for that AU.

Policy Scope Group (PSG) Naming Format

Format: PSG - [Assignment Type] - [Target] - [FAMIS Code] - [Policy or Application Name]

Element	Description
PSG	Identifies the group as a Policy Scope Group.
Assignment Type	Specifies the group’s role: Required, Available, Uninstall (for Apps); Included, Excluded (for Policies).
Target	Specifies if the assignment is for User or Device.
FAMIS Code	Department code for tracking purposes, indicating the responsible unit.
Policy or Application Name	The name of the managed policy or application.

Example Names:

• PSG - Required - User - VPOP - Microsoft Visio
• PSG - Available - Device - CLED - 7-Zip
• PSG - Uninstall - User - ENGR - Old Plugin
• PSG - Included - Device - VPOP - BitLocker Encryption Policy
• PSG - Excluded - User - CLED - Beta Features Access Policy
• PSG - Included - User - ENGR - Standard User Restrictions

---

Standard Naming Format for Other Scope Groups (DSG, USG, ESG, FSG, RSG, CSG)

Format: [Scope Group Type] - [FAMIS Code] - [Descriptive Name]

Element	Description
Scope Group Type	The group type (DSG, USG, ESG, FSG, RSG, CSG).
FAMIS Code	Code for tracking based on business or department.
Descriptive Name	Clear description of the group’s purpose or members.

Example Names:

• DSG - VPOP - Technology Services Windows Devices
• USG - CLED - TLAC Faculty Users
• ESG - ENGR - Student Lab Experience
• CSG - ENGR - Project Hub - Owner

---

📋 Implementation and Usage: Defining and Applying Experiences

The power of this model lies in the structured nesting of scope groups:

1. Foundation (USG/DSG): Create User Scope Groups (USGs) for distinct populations of users (e.g., USG - CLED - Staff, USG - CLED - Students) and Device Scope Groups (DSGs) for distinct collections of devices (e.g., DSG - CLED - Lab Computers, DSG - CLED - Staff Laptops) within the appropriate AU-[FAMIS CODE].
2. Define Cohorts (ESG): Create Experience Scope Groups (ESGs) to represent a specific cohort that should receive a common set of configurations. An ESG will contain one or more USGs and/or DSGs from the same FAMIS code. For instance, ESG - CLED - Standard Staff Experience would have USG - CLED - Staff and potentially DSG - CLED - Staff Laptops as members.
3. Assign Policies and Applications (PSG): Create Policy Scope Groups (PSGs) for each specific policy or application you want to deploy. The members of these PSGs will be the ESGs. For example, PSG - Required - User - CLED - Microsoft Teams would have ESG - CLED - Standard Staff Experience as a member. The same ESG can be a member of many different PSGs.
4. Filtering for User PSGs: Remember to apply the "Shared Device - Filter" in Exclude mode to all User PSGs (or to the assignment if the PSG is directly assigned to users/user ESGs) to ensure user-specific settings do not apply on shared devices.

This approach provides scalability and simplifies management. To change the experience for all CLED Staff, you primarily adjust the policies/applications linked to the ESG - CLED - Standard Staff Experience by adding or removing this ESG from relevant PSGs, or by modifying the policies themselves. To onboard a new staff member, you simply add them to the USG - CLED - Staff.

Creating Scope Groups When creating any scope group, ensure it has a clear purpose aligned with its intended use and follows the defined naming convention. Crucially, all scope groups must be created within the unit's designated Administrative Unit (e.g., AU-VPOP) by personnel who have elevated to the Groups Administrator role for that specific AU.

---

🔄 Managing Cloud and File Permissions

• Cloud Permissions: Cloud Scope Groups (CSGs) grant access to entire SharePoint Online sites, pages, or other cloud services like Loop and Planner. Include the URL of the resource in the group description for clarity.
• File Permissions: File Scope Groups (FSGs) provide granular control over document libraries or folders within SharePoint Online. Regular audits are recommended for sensitive data security.

---

🏁 Conclusion

Consistent and structured scope groups and naming conventions, built upon the foundation of Administrative Units and leveraging a nested approach with USGs/DSGs, ESGs, and PSGs, establish a robust framework for efficient and compliant IT operations. This model, including the diligent application of FAMIS codes and filters like the "Shared Device - Filter," facilitates scalable, secure, and clearly defined management of user and device experiences across the organization.

---