Introduction
Microsoft Purview Data Loss Prevention (DLP) can use Sensitive Service Domain Groups to organize websites and other network destinations that are referenced by endpoint DLP rules. Administrators can manage these settings in the Purview portal, while PowerShell is useful when changes must be repeatable, reviewed, and validated before they are committed.
This article demonstrates how to retrieve the tenant policy configuration, identify an existing group, add new URL entries only when they are not already present, validate the change, commit it, and verify the final configuration.
|
|
Important The SiteGroupsPsws object contains tenant-wide endpoint restriction settings. Test the script in a non-production tenant first, export the original configuration, and use change control. Microsoft documents Get-PolicyConfig and Set-PolicyConfig for viewing and modifying endpoint restrictions, but the internal shape of individual hashtable entries can evolve. |
Prerequisites
|
Requirement |
Guidance |
|
Permissions |
Use an account assigned the required Microsoft Purview permissions for the configuration being changed. Microsoft states that Get-PolicyConfig and Set-PolicyConfig require permissions in Security & Compliance PowerShell. |
|
PowerShell module |
Install or update the ExchangeOnlineManagement module. Security & Compliance PowerShell uses this module for connectivity. |
|
Connection |
Connect to Security & Compliance PowerShell by using Connect-IPPSSession before running the policy configuration cmdlets. |
|
Existing group |
The target Sensitive Service Domain Group must already exist. This script updates a group named Claude; it does not create the group. |
|
Change controls |
Run the discovery and backup commands first, use -WhatIf before commit, and retain the exported JSON for rollback analysis. |
Step 1: Install the module and connect
|
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser |
Confirm that the policy configuration can be retrieved:
|
Get-PolicyConfig | Format-List |
Step 2: Discover available group names
List the names exposed in SiteGroupsPsws and confirm that the target group exists before making any change.
|
(Get-PolicyConfig).SiteGroupsPsws | |
Step 3: Back up the current configuration
Export the current SiteGroupsPsws representation before modifying the in-memory object.
|
$BackupPath = “.\SiteGroupsPsws-backup-{0}.json” -f (Get-Date -Format “yyyyMMdd-HHmmss”) |
Step 4: Define the target group and URLs
|
$GroupName = “Claude” |
Replace the sample values with the approved production URLs. Use only the domain or wildcard format supported by your DLP design.
Step 5: Retrieve and validate the target group
|
$PolicyConfig = Get-PolicyConfig |
Complete script
|
# Target Sensitive Service Domain Group $GroupName = “Claude”
# URLs to add $NewUrls = @( “claude1.com”, “chatgpt2.com”, “claude3.com” )
$PolicyConfig = Get-PolicyConfig $Groups = $PolicyConfig.SiteGroupsPsws
$TargetGroup = $Groups | Where-Object { $_[“Name”] -eq $GroupName }
$Addresses = $TargetGroup[“Addresses”] | ConvertFrom-Json
foreach ($Url in $NewUrls) { if ($Addresses.Url -notcontains $Url) { $Addresses += [pscustomobject]@{ Url = $Url MatchType = “UrlMatch” } } }
$TargetGroup[“Addresses”] = $Addresses | ConvertTo-Json -Compress
# Validate Set-PolicyConfig -SiteGroupsPsws $Groups -WhatIf
# Commit Set-PolicyConfig -SiteGroupsPsws $Groups |
Step 6: Verify the change
Retrieve a fresh copy from the service rather than validating only the modified local object.
|
$VerifiedGroups = (Get-PolicyConfig).SiteGroupsPsws |
Step 7: Optional full configuration views
|
# Writable PowerShell representation |
Sample output
|
|
The sample is illustrative. Actual service output and formatting can vary by module version and tenant configuration.
Troubleshooting
|
Symptom |
Recommended check |
|
Get-PolicyConfig or Set-PolicyConfig is not recognized |
Confirm that the ExchangeOnlineManagement module is installed and that the session was connected with Connect-IPPSSession. |
|
Access denied or authorization error |
Verify the administrator account has the required Purview role-group permissions, then reconnect after role propagation. |
|
Target group not found |
Run the discovery command and use the exact group name returned by SiteGroupsPsws. |
|
Addresses cannot be parsed |
Inspect the raw Addresses property before changing anything. Restore from the exported JSON if the object shape is unexpected. |
|
-WhatIf succeeds but verification fails |
Retrieve Get-PolicyConfig again, check for service-side errors, and confirm no competing administrator update overwrote the configuration. |
Summary
PowerShell provides a controlled way to update Microsoft Purview DLP Sensitive Service Domain Groups at scale. The safest pattern is to discover the exact group name, export the current configuration, validate the target object, normalize and de-duplicate input, run Set-PolicyConfig with -WhatIf, commit the change, and then verify it through a fresh Get-PolicyConfig call. This validation-first workflow improves repeatability and reduces the risk of unintended tenant-wide configuration changes.
References
- Get-PolicyConfig cmdlet reference
https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/get-policyconfig?view=exchange-ps
- Set-PolicyConfig cmdlet reference
https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-policyconfig?view=exchange-ps
- Security & Compliance PowerShell overview
https://learn.microsoft.com/en-us/powershell/exchange/scc-powershell?view=exchange-ps
- Configure Endpoint DLP settings
https://learn.microsoft.com/en-us/purview/dlp-configure-endpoint-settings

