mirror of
https://github.com/KelvinTegelaar/CIPP.git
synced 2026-04-25 08:16:01 +03:00
Labels
No labels
API
Feature
NotABug
NotABug
Planned
Sponsor Priority
Sponsor Priority
bug
documentation
duplicate
enhancement
needs more info
no-activity
no-priority
not-assigned
pull-request
react-conversion
react-conversion
roadmap
security
stale
unconfirmed-by-user
unconfirmed-by-user
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/CIPP#1928
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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
@rvdwegen commented on GitHub (Jun 13, 2025):
Added action to change displayname on CA policies. POST to EditCAPOlicy with the newDisplayName property.
@rvdwegen commented on GitHub (Jun 13, 2025):
Groups can be done through EditGroup.
@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.
@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.
@HappyEarthDay commented on GitHub (Jun 16, 2025):
Just noting it here - I confirmed with @rvdwegen via Discord that this doesn't exist just yet
@swissbuechi commented on GitHub (Feb 16, 2026):
Is this still the case or did they eventually implement it?