A large enterprise customer transformed their infrastructure provisioning from manual IP management to fully automated self-service. This is the story of building a production-ready BlueCat IPAM integration for VMware Aria Automation—from initial challenges through deployment success—and how we open-sourced the result for the community.
The Challenge
The customer had built their VMware private cloud automation around legacy vRealize Orchestrator (vRO) workflows triggered via ServiceNow. These workflows handled Windows and Linux VM deployments through complex, multi-step orchestration—dozens of decision points, error handling paths, temporary file creation, domain joins, and system configurations all hardcoded into visual workflows.
The problems were compounding. These workflows were static, monolithic, and deprecated. Manual IP address management created bottlenecks, with network teams fielding 200+ IP allocation requests every week. More critically, the workflows were incompatible with the customer’s planned VCF 9 upgrade. Years of patches and workarounds had created a fragile automation layer that couldn’t evolve with modern CI/CD practices.
The customer faced a choice: continue patching an unmaintainable system, or modernize to Aria Automation with proper IPAM integration. They chose modernization.
What the Legacy Environment Looked Like
The existing automation lived in vRealize Orchestrator workflows like “TX-SDDC – Windows Workflow”—massive visual workflows with 50+ steps covering VM template cloning, domain joins, MAC address management, system logging configuration, error handling, and temporary file creation. These workflows were triggered via ServiceNow catalog items, creating a long chain of dependencies that was difficult to troubleshoot and impossible to version control.
The problems were clear. Technical debt had accumulated over years of patches, creating unmaintainable complexity. The workflows wouldn’t survive a VCF 9 upgrade. There was no path to CI/CD because static visual workflows are incompatible with infrastructure-as-code. IP allocation happened through workflow scripts rather than true IPAM integration. And vRO itself had become a bottleneck—every provisioning request depended on it.
Modernizing to Aria Automation required more than just a platform migration. It demanded proper IPAM integration. VMware’s native IPAM was too basic for the environment. Third-party solutions lacked the needed flexibility. And no production-ready open-source alternative existed for BlueCat and Aria Automation. Manual IP management within the vRO workflows was creating 2–4 hour delays per provisioning request.
Architecture and Approach
The solution: a Python-based IPAM provider integrating with Aria Automation’s Third-Party IPAM SDK. The SDK provides a framework for building custom IPAM providers that run as extensibility actions (ABX) within Aria Automation’s container-based architecture.
Key architectural decisions included using Python for BlueCat API compatibility, RESTful API integration for reliable communication with BlueCat Address Manager (Proteus), stateless design for scalability, comprehensive logging for troubleshooting, and graceful error handling with meaningful feedback messages.
The core capabilities we designed: allocate IPs from specified network blocks, deallocate IPs and clean up DNS records on VM decommission, validate BlueCat connectivity, discover available networks for Aria Automation, and enumerate DHCP and static ranges.
Development: Where Things Got Real
What appeared straightforward became complex quickly.
BlueCat API Quirks
The BlueCat REST API had behaviors that weren’t well documented. Configuration IDs are required for every call but aren’t clearly exposed through the API. View IDs need specific navigation patterns through the configuration hierarchy. The properties string format uses a non-standard pipe-delimited format. And error messages from the API tend to be cryptic, making troubleshooting difficult without extensive logging.
Solutions required reverse-engineering API behavior through testing, creating helper functions to abstract the complexity of navigating BlueCat’s hierarchy (Configuration → View → Zone → Network), and building comprehensive error translation layers.
Aria Automation IPAM SDK Challenges
The IPAM SDK documentation was sparse in several areas. Required JSON response schemas were not thoroughly documented. Callback patterns between Aria Automation and the provider were unclear. Error handling expectations were ambiguous. And there were no built-in testing frameworks.
We built local testing harnesses that simulated Aria Automation callbacks, created JSON schema validators to catch response format issues before deployment, and developed a unit test suite to catch regressions.
DNS Integration Complexity
DNS integration went well beyond simple record creation. Forward and reverse zones required synchronization—when you allocate an IP, you need both the A record and the corresponding PTR record in the reverse zone. PTR records needed special handling for CIDR-to-reverse-zone mapping. TTL values required proper configuration with sensible defaults. And FQDN validation was critical to prevent malformed DNS entries.
We implemented a DNS orchestration layer that handles forward and reverse record synchronization automatically, with configurable TTL settings and proper hostname validation.
Hardening for Production
Real-world testing revealed issues that only appear under load and over time.
Concurrent provisioning requests sometimes conflicted—two VMs requesting IPs from the same subnet simultaneously could theoretically receive the same address. BlueCat API tokens expired during long operations, causing stale session failures. Slow BlueCat responses during peak usage caused Aria Automation timeouts. And international hostnames occasionally broke DNS registration through character encoding issues.
Hardening measures included mutex locks for concurrent IP allocation, automatic token refresh with retry logic, tuned timeout values with exponential backoff, proper UTF-8 handling and hostname validation, comprehensive logging for every API interaction, and health check endpoints for monitoring.
Deployment: Phased Rollout
Deployment followed a phased approach over two weeks to minimize risk.
The pilot phase targeted the development Aria Automation environment, connected to production BlueCat with an isolated test network. We ran 100+ test provisioning cycles validating IP allocation, DNS record creation, deallocation, logging, error handling, and failover scenarios.
Production rollout deployed the IPAM provider to the production Aria Automation instance, configured 50+ network profiles pointing to BlueCat, updated Cloud Template catalog items, trained the platform team on troubleshooting procedures, monitored the first 500 production VM provisions, and documented operational runbooks.
The Results
The integration fundamentally changed how the customer provisions infrastructure and enabled their migration from legacy vRO to modern Aria Automation.
Platform Modernization
The vRO dependency was eliminated entirely. Fifty-step visual workflows were replaced with declarative Cloud Templates stored in Git—version controlled, peer reviewed, and compatible with CI/CD pipelines. The new architecture is VCF 9 ready, removing the upgrade blocker that had been looming over the legacy system. And the ServiceNow catalog integration was preserved, giving end users the same self-service experience with a modern, maintainable backend.
Measurable Outcomes
VM provisioning time dropped from 4 hours to 8 minutes—a 95% reduction. Network team IP requests fell from 200 per week to zero. IP conflict incidents went from approximately 5 per month to zero since deployment. The system handles 1,000+ VM provisioning requests monthly across 50+ network segments with a 99.8% automated allocation success rate.
Technical Capabilities
The provider delivers dynamic IP allocation from BlueCat Address Manager, automatic DNS A and PTR record creation, full IP and DNS cleanup on VM decommission, network discovery for Aria Automation, multi-tenant network isolation, comprehensive operational logging, session management with automatic refresh, concurrent provisioning support, and health monitoring endpoints.
Lessons Learned
Several lessons from this project are worth sharing for anyone facing similar integration challenges.
Confront technical debt honestly. The legacy vRO workflows represented years of accumulated workarounds. Each patch had solved an immediate problem while making the overall system more fragile. You can’t “lift and shift” deprecated workflows to a new platform. The BlueCat IPAM integration succeeded because we rebuilt the automation foundation rather than porting the old complexity forward.
Modern platforms enable better practices. The old vRO workflows were impossible to version control effectively, difficult to test, and required the vRO UI for any changes. Moving to Aria Automation Cloud Templates stored in Git transformed quality. Peer reviews caught issues before deployment. Rollbacks became simple. The IPAM integration benefited directly from this approach—we could iterate quickly with confidence.
Comprehensive testing is non-negotiable. The multi-phase testing approach identified race conditions and concurrency issues that would have been disastrous in production. These problems only appear under load, so isolated unit testing alone isn’t sufficient.
Log everything from day one. Detailed logging of every API call and decision point made troubleshooting straightforward when production issues occurred. This was a direct lesson from debugging complex vRO workflows where operational visibility was poor.
Deploy incrementally. Piloting in development, then to an isolated test network in production, then gradual rollout across all networks minimized risk and built confidence. Especially important given the customer’s history with fragile automation.
What We’d Do Differently
Earlier load testing would have caught the race condition issue sooner. Better upfront study of the BlueCat API documentation would have saved reverse-engineering time. And building comprehensive automated test suites from the very beginning would have accelerated development—testing was always the weak point in the old vRO approach, and we should have prioritized it even more in the new one.
Open Source: Available on GitHub
This integration has been published to GitHub as open-source software under the GPLv3 license for the VMware and BlueCat community.
Download the BlueCat IPAM Provider on GitHub →
The repository includes the complete Python IPAM provider source code, a deployment guide for Aria Automation integration, configuration examples and templates, a troubleshooting runbook, API reference documentation, and a unit test suite.
The provider is designed to be production-importable. Download the bundle, import it into Aria Automation, configure your BlueCat endpoint credentials, and you’re running. The README documents any configuration values you’ll need to set for your specific environment.
Quick Start
Prerequisites: VMware Aria Automation 8.x or later, BlueCat Address Manager with API access enabled, and API user credentials for BlueCat.
- Clone the repository:
git clone https://github.com/noah-farshad/bluecat-ipam-provider.git - Install dependencies:
pip install -r requirements.txt - Configure your BlueCat connection details in
config.json - Deploy to Aria Automation following the included deployment guide
- Configure network profiles in Aria Automation
- Test with a VM provision
Detailed deployment documentation, including Aria Automation configuration screenshots and troubleshooting steps, is included in the repository.
IP Allocation Flow: How It Works
For those interested in the technical details, here’s the allocation flow when Aria Automation provisions a VM:
- Aria Automation sends an allocation request with the network CIDR and hostname
- The provider authenticates to the BlueCat API
- It resolves the network CIDR to a BlueCat network block ID by navigating the Configuration → View → Network hierarchy
- It requests the next available IP from the identified network block
- It creates a DNS A record with the proper FQDN in the forward zone
- It creates a PTR record in the appropriate reverse zone
- It returns the allocated IP address and DNS details to Aria Automation
On VM decommission, the process reverses: the provider removes the DNS A and PTR records and deallocates the IP address back to the available pool in BlueCat.
Conclusion
Building production-ready IPAM integration required persistence, thorough testing, and deep understanding of both the Aria Automation IPAM SDK and the BlueCat Address Manager API. The result transformed infrastructure automation for this customer and enabled their migration from legacy vRO to modern Aria Automation.
Technical debt accumulates silently—those “temporary” workarounds in vRO workflows became permanent obstacles to modernization. Confronting that honestly enabled a clean break to better automation. Real-world API integration is harder than documentation suggests. Comprehensive testing under load is non-negotiable. And modern platforms like Aria Automation with Git-backed Cloud Templates prevent the complexity spiral that plagued legacy approaches.
For organizations facing IPAM automation challenges with BlueCat and VMware Aria Automation—especially those migrating from legacy vRO workflows—this integration provides a battle-tested foundation. The code, documentation, and lessons learned are all available to accelerate your implementation.
Get Started
Deployment guides and API reference documentation are included in the repository. Questions or need help? Reach out through GitHub Issues or contact me at noah@essential.coach.
If you’ve implemented this integration or have improvements to contribute, pull requests and feedback are welcome.