In a previous post, I wrote about a toolkit to migrate NSX Distributed Firewall objects like groups and rules. The toolkit consists of five PowerShell scripts that are designed to be run in sequence:

1. Export-NSX-DFW.ps1 — exports all DFW objects from an NSX 4 manager to CSV files
2. Sanitize-NSX.ps1 — orchestrates the sanitization pipeline
3. Sanitize-NSXGroups.ps1 — renames group IDs to match display names and updates cross-references
4. Sanitize-NSXFirewallRules.ps1 — updates firewall rule group references after group IDs are renamed
5. Import-NSX-DFW.ps1 — imports sanitized CSV files into an NSX 9 manager
6. Remove-NSX-ImportedObjects.ps1 — rolls back an import using the original CSV files
7. Remove-NSX-AllCustomObjects.ps1 — removes all custom objects directly from inventory without needing CSV files

However, I’ve created an extra script to handle the migration of services, including the sanitization of the exported csv file. With the introduction of the extra file, the toolkit now looks like this:

1. Export-NSX-DFW.ps1 — exports all DFW objects from an NSX 4 manager to CSV files
2. Sanitize-NSX.ps1 — orchestrates the sanitization pipeline
3. Sanitize-NSXGroups.ps1 — renames group IDs to match display names and updates cross-references
4. Sanitize-NSXServices.ps1 — renames group IDs to match display names and updates cross-references
5. Sanitize-NSXFirewallRules.ps1 — updates firewall rule group references after group IDs are renamed
6. Import-NSX-DFW.ps1 — imports sanitized CSV files into an NSX 9 manager
7. Remove-NSX-ImportedObjects.ps1 — rolls back an import using the original CSV files
8. Remove-NSX-AllCustomObjects.ps1 — removes all custom objects directly from inventory without needing CSV files

How Sanitize-NSXServices.ps1 works

If you’ve ever exported NSX services and cracked open the CSV, you’ve probably noticed something odd — the Id field rarely matches the DisplayName. Instead of clean names like HTTP-8080, you get internal identifiers like application-228. That’s exactly the problem this script fixes.

Sanitize-NSXServices.ps1 renames every Service and ServiceGroup so its Id matches its DisplayName, then makes sure all the internal cross-references stay consistent. The result is a clean, human-readable export that’s much easier to review, audit, and import into a new environment.

Protecting tags you actually need

Before it touches anything, the script does something smart: it queries your live NSX Manager to check which tags are actively referenced by security group conditions. Tags that are still in use get kept (with a warning), while leftover migration artefacts are stripped out. If you run the script without providing an NSX Manager, it skips this check and removes all tags — so it’s worth supplying that parameter if you want to be safe.

Renaming services cleanly

The script builds a mapping table of every oldId → newId pair by scanning the DisplayName column. It handles edge cases too: if two services share the same display name, they each get a numeric suffix (HTTP-8080-1, HTTP-8080-2) so nothing collides.

Once the mapping is built, it runs through every row and updates:

• The Id and DisplayName columns in the CSV
• The "id", "relative_path", and "display_name" fields inside the RawJson
• Any /services/<oldId> path segments in ServiceGroup members arrays — this is important because those paths go stale the moment a service is renamed

What you get

Two output files:

• <InputFile>_sanitized.csv — your cleaned-up services and service groups, ready to import
• <InputFile>_id_mapping.csv — a full audit log of every rename, useful if you need to trace what changed

Where it fits in the pipeline

When run as part of the broader Sanitize-NSX.ps1 orchestrator, this script runs as Step 2 — after groups have been sanitized, and before firewall rules are processed. The ID mapping table it produces gets handed directly to the firewall rules step, so any service references there get updated in the same pass.