[GH-ISSUE #4261] [Feature Request]: Ability to rename CAPs, Intune policies, and groups in CIPP (Copy of stale #3924) #1928

Closed
opened 2026-03-02 13:48:14 +03:00 by kerem · 6 comments
Owner

Originally created by @HappyEarthDay on GitHub (Jun 11, 2025).
Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/4261

Originally assigned to: @rvdwegen on GitHub.

Please confirm:

  • I have searched existing feature requests (open and closed) and found no duplicates.
  • **me or my organization is currently an active sponsor of the product at the $99,- level.

Problem Statement

Copy of #3924 and this FR for the PS module is waiting on this as well https://github.com/BNWEIN/CIPPAPIModule/issues/43

As an MSP, we rely on CIPP’s Standards policy templates to efficiently deploy Conditional Access policies, Intune templates, and Groups across client tenants. However, a key limitation is the inability to programmatically rename existing tenant objects to match the standardized naming conventions used by CIPP. This creates duplicate policies and groups when the existing ones serve the same purpose but have non-standard names.

For example, if a tenant already has an Intune policy called “BitLocker Enforcement,” deploying the CIPP standard “MSP Standard - BitLocker Enforcement” results in two similar policies instead of updating or aligning the existing one. This forces us to manually log in via GDAP and rename the policy before using CIPP, slowing down onboarding and standardization.

The same issue applies to Groups—if a functionally correct group exists with a non-standard name, we must manually rename it to prevent duplication.

Exposing an API endpoint to handle renaming of existing policies and groups would be a significant improvement. It would allow us to automate naming standard enforcement via the CIPP PowerShell module, enabling bulk renaming and seamless alignment with MSP standards at scale.

Benefits for MSPs

Enabling the ability to rename existing policies directly within the CIPP interface—or via exposed API endpoints—would drastically improve operational efficiency for MSPs managing multiple tenants. This functionality would allow us to align existing tenant policies and groups with CIPP-deployed standards without duplication or manual rework.

One of the key reasons we can’t simply delete and replace old policies is the need to preserve manually configured exclusions (e.g., for specific users or groups). Since CIPP doesn’t currently modify exclusions during deployment, removing a policy would require us to manually rebuild those exceptions. A rename function would retain those critical configurations while ensuring consistency in naming and standards compliance.

In addition, exposing API endpoints for renaming policies and groups in bulk would allow us to script mass updates across tenants using the PowerShell module—saving time, reducing human error, and enabling true scalability of policy standardization efforts across our client base.

Value or Importance

This feature is critically important for MSPs managing dozens—or hundreds—of tenants with varying configurations. Consistent policy naming is essential for enforcing standards, maintaining clarity across environments, and enabling efficient automation through tools like CIPP and PowerShell.

Without the ability to rename existing policies and groups, we’re forced to choose between duplicating policies (leading to confusion and potential misconfiguration) or manually renaming them via GDAP access—an inefficient and error-prone process. This severely limits the scalability and effectiveness of CIPP in multi-tenant environments.

Even beyond the interface, exposing API endpoints for policy renaming would unlock automation opportunities that are currently impossible. It would allow MSPs to perform tenant-wide or even org-wide standardization tasks with a single script, enhancing both speed and consistency.

While the feature may seem like a convenience at first glance, it actually removes a critical blocker to full automation and reinforces CIPP’s role as a centralized, scalable policy management tool for MSPs.

PowerShell Commands (Optional)

No response

Originally created by @HappyEarthDay on GitHub (Jun 11, 2025). Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/4261 Originally assigned to: @rvdwegen on GitHub. ### Please confirm: - [x] **I have searched existing feature requests** (open and closed) and found no duplicates. - [x] **me or my organization is currently an active sponsor of the product at the $99,- level. ### Problem Statement Copy of #3924 and this FR for the PS module is waiting on this as well https://github.com/BNWEIN/CIPPAPIModule/issues/43 As an MSP, we rely on CIPP’s Standards policy templates to efficiently deploy Conditional Access policies, Intune templates, and Groups across client tenants. However, a key limitation is the inability to programmatically rename existing tenant objects to match the standardized naming conventions used by CIPP. This creates duplicate policies and groups when the existing ones serve the same purpose but have non-standard names. For example, if a tenant already has an Intune policy called “BitLocker Enforcement,” deploying the CIPP standard “MSP Standard - BitLocker Enforcement” results in two similar policies instead of updating or aligning the existing one. This forces us to manually log in via GDAP and rename the policy before using CIPP, slowing down onboarding and standardization. The same issue applies to Groups—if a functionally correct group exists with a non-standard name, we must manually rename it to prevent duplication. Exposing an API endpoint to handle renaming of existing policies and groups would be a significant improvement. It would allow us to automate naming standard enforcement via the CIPP PowerShell module, enabling bulk renaming and seamless alignment with MSP standards at scale. ### Benefits for MSPs Enabling the ability to rename existing policies directly within the CIPP interface—or via exposed API endpoints—would drastically improve operational efficiency for MSPs managing multiple tenants. This functionality would allow us to align existing tenant policies and groups with CIPP-deployed standards without duplication or manual rework. One of the key reasons we can’t simply delete and replace old policies is the need to preserve manually configured exclusions (e.g., for specific users or groups). Since CIPP doesn’t currently modify exclusions during deployment, removing a policy would require us to manually rebuild those exceptions. A rename function would retain those critical configurations while ensuring consistency in naming and standards compliance. In addition, exposing API endpoints for renaming policies and groups in bulk would allow us to script mass updates across tenants using the PowerShell module—saving time, reducing human error, and enabling true scalability of policy standardization efforts across our client base. ### Value or Importance This feature is critically important for MSPs managing dozens—or hundreds—of tenants with varying configurations. Consistent policy naming is essential for enforcing standards, maintaining clarity across environments, and enabling efficient automation through tools like CIPP and PowerShell. Without the ability to rename existing policies and groups, we’re forced to choose between duplicating policies (leading to confusion and potential misconfiguration) or manually renaming them via GDAP access—an inefficient and error-prone process. This severely limits the scalability and effectiveness of CIPP in multi-tenant environments. Even beyond the interface, exposing API endpoints for policy renaming would unlock automation opportunities that are currently impossible. It would allow MSPs to perform tenant-wide or even org-wide standardization tasks with a single script, enhancing both speed and consistency. While the feature may seem like a convenience at first glance, it actually removes a critical blocker to full automation and reinforces CIPP’s role as a centralized, scalable policy management tool for MSPs. ### PowerShell Commands (Optional) _No response_
kerem 2026-03-02 13:48:14 +03:00
Author
Owner

@rvdwegen commented on GitHub (Jun 13, 2025):

Added action to change displayname on CA policies. POST to EditCAPOlicy with the newDisplayName property.

<!-- gh-comment-id:2970308307 --> @rvdwegen commented on GitHub (Jun 13, 2025): Added action to change displayname on CA policies. POST to EditCAPOlicy with the newDisplayName property.
Author
Owner

@rvdwegen commented on GitHub (Jun 13, 2025):

Groups can be done through EditGroup.

<!-- gh-comment-id:2970388378 --> @rvdwegen commented on GitHub (Jun 13, 2025): Groups can be done through EditGroup.
Author
Owner

@rvdwegen commented on GitHub (Jun 13, 2025):

API support for Intune Policy displayname edits added. Note that the body will need to contain the type of policy ie configurationPolicies or windowsFeatureUpdateProfiles as the policyType property.

<!-- gh-comment-id:2970485418 --> @rvdwegen commented on GitHub (Jun 13, 2025): API support for Intune Policy displayname edits added. Note that the body will need to contain the type of policy ie configurationPolicies or windowsFeatureUpdateProfiles as the policyType property.
Author
Owner

@rvdwegen commented on GitHub (Jun 13, 2025):

Note, front end policy name changes with the same wide support are a bit complicated because we currently use a hodgepodge of ListGraphRequest and policy specific functions.

<!-- gh-comment-id:2970500430 --> @rvdwegen commented on GitHub (Jun 13, 2025): Note, front end policy name changes with the same wide support are a bit complicated because we currently use a hodgepodge of ListGraphRequest and policy specific functions.
Author
Owner

@HappyEarthDay commented on GitHub (Jun 16, 2025):

Groups can be done through EditGroup.

Just noting it here - I confirmed with @rvdwegen via Discord that this doesn't exist just yet

<!-- gh-comment-id:2977211989 --> @HappyEarthDay commented on GitHub (Jun 16, 2025): > Groups can be done through EditGroup. Just noting it here - I confirmed with @rvdwegen via Discord that this doesn't exist just yet
Author
Owner

@swissbuechi commented on GitHub (Feb 16, 2026):

Groups can be done through EditGroup.

Just noting it here - I confirmed with @rvdwegen via Discord that this doesn't exist just yet

Is this still the case or did they eventually implement it?

<!-- gh-comment-id:3910661647 --> @swissbuechi commented on GitHub (Feb 16, 2026): > > Groups can be done through EditGroup. > > Just noting it here - I confirmed with @rvdwegen via Discord that this doesn't exist just yet Is this still the case or did they eventually implement it?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/CIPP#1928
No description provided.