Licensing and Sizing a Multi-Site XIQ-SE Rollout
Northwind Health is deploying ExtremeCloud IQ Site Engine (XIQ-SE) across a 14-site campus and clinic network: 2,900 access switches, 180 wireless access points, 120 third-party SNMP devices (UPS units and printers), and 40 firewalls. The purchase order funded 3,000 device licenses. Two weeks after go-live the license usage view shows 3,180 consumed and the Unmanaged device count is still climbing. The discovery team enabled an auto-onboarding rule that places any device answering SNMP into Managed state, and a scheduled subnet scan covers 10.0.0.0/8. The 180 APs are adopted by two on-premises wireless controllers; the wireless team insists that APs do not consume licenses. A merger will add roughly 600 switches in six months, and the CIO wants a cold disaster-recovery instance in a second data center. The network team proposes buying 1,000 more licenses immediately and standing up the DR server with no license at all.
1. Before approving the 1,000-license purchase, what would you verify and change in the existing deployment?
Read the worked answer
Start with evidence, not the purchase order. Run the license usage report grouped by device family and by managed state, because the 180-device overage is small enough to be explained by inventory hygiene rather than real growth.
- The 120 third-party SNMP devices are the most likely consumers. UPS units and printers need monitoring, not configuration management. They should be Unmanaged (monitored) rather than Managed, and they should be excluded from the auto-onboarding rule.
- The auto-onboarding rule plus a 10.0.0.0/8 scan is a license leak. Any SNMP responder in that range becomes Managed. Narrow discovery to management VLANs and known subnets, require a matching device profile or manual approval, and exclude printer/UPS address ranges.
- APs: do not accept the wireless team's claim without checking the report. The usage view will show whether the controllers' adopted APs appear as licensed inventory. If they do, that changes the forecast.
- Reconcile stale records. Decommissioned switches and duplicate records created by overlapping discovery profiles still consume entitlement until deleted.
After cleanup, recalculate: 2,900 switches + 180 APs (if counted) + 40 firewalls already exceeds 3,000. The 1,000-unit order may still be justified by the merger, but it should be a phased true-up based on a clean count, not a panic purchase.
2. How should licensing be handled for the proposed cold DR instance, and how does that differ from an HA pair?
Read the worked answer
Separate the two designs and their recovery objectives.
A cold DR instance is powered off or idle until a disaster. Buying a second full license pool for it wastes budget. The practical approach is to confirm the vendor's license rehost process in advance, document the host identifiers that the license is bound to, and rehearse moving the entitlement during a maintenance window. A cold DR plan that has never had its license rehost tested is not a plan; the RTO will be consumed by a support ticket.
An HA pair is different. The secondary must be able to take over immediately, so do not assume a standby is unlicensed. Confirm the HA licensing terms for your release and purchase the secondary entitlement if required. The failure mode to avoid is a secondary that becomes active but runs unlicensed or partially licensed, which can disable management features at the worst moment.
Finally, do not stand up the DR server unlicensed 'temporarily' in production. If it is reachable and managing devices, it must be correctly licensed; otherwise you create a compliance and support problem that surfaces during an audit or an outage.
3. What sizing factors beyond device count should drive the server and DR design for the merger?
Read the worked answer
Device count is only the first dimension. XIQ-SE load also comes from polling frequency, the number of monitored ports and interfaces, syslog and trap volume, flow collection, wireless controller integration, and the number of concurrent operators and reports.
For the merger, build a sizing model from the target state: 3,500 switches, 180 APs, 40 firewalls, plus the new sites' third-party devices, with realistic poll intervals. Check CPU, memory, and database growth against the vendor sizing guidance rather than assuming the current server scales linearly. A pilot that onboards 300-500 merger devices and runs normal polling and reporting for two weeks will reveal more than a spreadsheet.
For DR, size the DR host to match the production host, not to a minimal lab specification. Recovery will fail if the DR server cannot carry the full poll and database load. Also account for the fact that a cold DR restore includes database import time, which can be hours for a large inventory; that is part of RTO and should be measured in a rehearsal.