At several EUC projects we have a testing Workspace ONE environment(s) where desktop image and application packaging takes place, and a production Workspace ONE environment where only tested and approved items from the test are released. The environments are separated into vCenter/NSX managers. Actually, the production ones are even more separated in management and two or more desktop pods. All with their own NSX managers, and with there own management and rules. There is a need for a way to synchronize the approved NSX DFW rule set from testing to production, and between the production pods, without too much effort or human interference. We couldn’t find a cmdlet that does this all, so I wrote up the following script to synchronize the NSX configuration between pods: PowerNSX DFW Synchronization Script. We also have the same need for other projects, and I think it will benefit the next iteration of the NSXHorizonJumpstart I was working on earlier. You can go and grab the first version of the PowerNSX DFW synchronization script at https://github.com/Paikke/NsxSynchronization. In the remainder of this blog post, I will explain some further this script.
What we needed
The following setup has been taken as a source for this script:
- One testing environment where management and desktop are in one cluster with one vCenter NSX manager pair.
- A production management environment with one vCenter NSX manager pair (inventory production is linked though)
- Another production desktop pod with one vCenter NSX manager pair in datacenter one (inventory production is linked though)
- And yet another production desktop pod with one vCenter NSX manager pair in datacenter two (inventory production is linked though)
What actions we need
- Tested and approved management section of the testing environment going to the production management environment.
- Tested and approved desktop section of the testing environment going to both production desktop pods.
- All required objects for the rules to be synchronized between the environments.
- Basic checking for existing objects.
- Logging for reference and troubleshooting
We were Interested in the following
But with NsxObjectCapture script we get much more, I left this in place as we might want to do something with this at a later stage.
Requires PowerNSX and uses https://raw.githubusercontent.com/vmware/powernsx/master/tools/DiagramNSX/NsxObjectCapture.ps1 for the object capturing. Minor change in the script and changed the export from the user profile to the current script location.
Structure of the Synchronization script
- User inputs NSX Manager Source and credentials
- User inputs NSX Manager Destination and credentials
- Connect NSX Manager Source
- Export Source to XML’s and zip bundle
- Connect NSX Manager Destination (on first run answer N on working with multiple servers. For now this works)
- Extract source XMLs
- Import Source XMLs to DFW
- SecurityGroups will only import IpSet. VM or other member types will need to be added manually.
- For Firewall Section ask user input (Y import / N skip section) as not all sections in the testing environment are to go in management or production desktop pods.
- Remove temp XML’s, source zip bundled remain saved for later.
What you get:
- Functions.ps1: Function declaration used in the scripts (for example logging)
- NsxObjectCapture.ps1: Capture script of source NSX manager. Exports to bundle XML zip.
- NsxObjectImport.ps1: Import script that takes the bundled XML zip, extracts and parses through object XMLs. Finally imports in the destination NSX manager.
- NsxSynchronisation.ps1: The run script that asks the user for source and destination NSX manager and runs the other scripts.
- Readme.md: some mumbling about the script.
Download the scripts, put in a directory. Open PowerShell, go to the directory location and run .\NSxSynchronisation.ps1. Don’t walk away as user input is required.
Do note that the script can take some time. When importing a Workspace ONE setup (with local IDM and AirWatch) this took up to 10 minutes to get to the section part where user input is required. But it beats having to manually insert all objects and DFW sections and rules in the right place.
And don’t forget to add members to all those security groups.
If you haven’t tested before running this in a production, don’t start whining if it fsck up your environment. No warranty, use backups. Questions and or suggestions about PowerNSX DFW synchronization script are always welcome.
-Enjoy syncing those pods!