Deployed and administered Lync Server across a pan-European multi-site environment, covering SIP/VoIP architecture, load balancing, and messaging platform stabilisation.
The European Patent Office operated a unified communications environment serving staff across three principal sites — Munich (headquarters), The Hague, and Vienna — with additional sub-offices distributed across member states. The Lync Server deployment had grown without a consistent architecture to govern it. Front-end pool assignments were inconsistent across sites: users in The Hague and Vienna had been homed to pools in ways that did not reflect the actual network topology, resulting in suboptimal routing for presence and instant messaging traffic. Load balancing configuration for the front-end pools had not been validated against real traffic patterns — hardware load balancer health probes were configured with incorrect port and protocol parameters, meaning that pool members were reporting as healthy to the load balancer while generating errors visible only at the application layer.
The SIP/VoIP integration presented a more operationally visible problem. Voice services were exhibiting intermittent call registration failures and degraded call quality specifically on the non-Munich sites — The Hague and Vienna — during peak usage periods. The root cause had not been systematically traced: the SIP trunk configuration had been replicated from the Munich site without accounting for differences in the local PSTN gateway models, dial plan normalisation requirements, and the WAN latency characteristics between sites. The Lync-Exchange integration for Unified Messaging — providing voicemail deposit and retrieval through the Exchange UM role — had configuration drift between the documented topology and the deployed state. Subscriber access numbers, UM dial plans, and the SIP URI format used for UM routing had diverged from their original design through a series of undocumented changes, leaving voicemail functionality unreliable for a subset of users at the remote sites.
The architecture review began with the front-end pool topology. Each site's pool membership, Director role assignments, and Lync Server Standard versus Enterprise Edition topology were mapped against the actual hardware and DNS configuration. The design consolidated pool assignments to align with the physical site topology: users at each site were homed to the local front-end pool where Enterprise Edition pools existed, with explicit survivable branch appliance or survivable branch server configuration for smaller offices that could not justify a full pool deployment. Load balancer configuration was redesigned with correct health probe definitions — HTTP probes on port 5061 for SIP, TCP probes on the web services ports — with probe intervals and thresholds matched to the Lync Server's expected response behaviour rather than generic load balancer defaults.
The design aligned front-end pools, SIP trunks, Edge services, and Exchange UM so the three-site communications estate could operate with consistent routing, survivability, and validation procedures.
The SIP trunk architecture was addressed site by site. Munich's existing trunk configuration was treated as the validated baseline and its parameters documented in full — codec negotiation order, DTMF handling, session timer configuration, and the specific INVITE and OPTIONS exchange behaviour expected by the carrier. The Hague and Vienna trunks were then re-examined against this baseline: each had diverged in codec preference order and in the way in which the Mediation Server was presenting the SIP URI to the PSTN gateway. Normalisation rules within the Lync dial plan were reviewed against the national dialling conventions for the Netherlands and Austria, as the Munich-derived rules were applying German E.164 formatting assumptions to numbers in those countries, producing malformed outbound INVITE messages that succeeded intermittently depending on the gateway's tolerance for non-conforming URIs. The Edge Server configuration was reviewed for external federation, A/V authentication, and the certificate bindings used for TLS between the Edge and the reverse proxy — each of which had its own certificate validity timeline and SAN requirements.
The Exchange Unified Messaging integration design required reconciling the deployed UM dial plans with the Lync dial plan structure. UM dial plans were documented, and the SIP URI format — whether E.164 or extension-based — was standardised across all sites to match the Lync normalisation output. Subscriber access numbers were updated in the Exchange UM dial plans to correspond to the correct DDI ranges at each site. The UM IP gateway objects in Exchange were verified against the actual Mediation Server FQDNs, and the hunt group pilot number assignments were corrected to match the Lync trunk routing configuration. The full call flow — inbound call to Exchange UM, voicemail deposit, MWI notification back to the Lync client, and subscriber access for retrieval — was traced end-to-end in the design before any changes were applied to production.
Implementation was structured as a series of controlled change windows executed site by site, starting with The Hague as the secondary site with the most clearly documented failures, and completing with Vienna before returning to validate the Munich baseline. Each change window was preceded by a pre-change validation step — capturing the current state of pool membership, certificate bindings, SIP trunk statistics, and Exchange UM call logs — and followed by a post-change validation that repeated the same checks and confirmed the expected improvement in each metric.
Front-end pool remediation at The Hague began with correcting the user homing assignments for the site's population. Users incorrectly homed to the Munich pool were moved to the local pool in batches of fifty, with presence and IM functionality confirmed for each batch before the next was processed. The load balancer health probe configuration was updated during a maintenance window following the user homing correction — changing health probe parameters without first correcting pool membership would have produced misleading results, as the pool was receiving traffic from users it was not correctly serving. After the probe update, pool member health status was monitored for forty-eight hours before the Vienna site changes were scheduled.
SIP trunk stabilisation at each remote site involved updating the Mediation Server's trunk configuration within the Lync topology, publishing the updated topology, and then reconfiguring the PSTN gateway's SIP parameters to match. At The Hague, the codec preference order was corrected to prioritise G.711 over G.729 for intra-European calls — reversing the Munich-inherited preference that had been causing codec renegotiation failures on the Dutch carrier's trunk. The dial plan normalisation rules were rewritten for each national context: the Netherlands rules were updated to correctly handle the Dutch national dialling format with 0 prefix stripping and E.164 conversion, and the Austrian rules were corrected to handle the Vienna area code and the range of subscriber number lengths present in the EPO's directory. Edge Server certificates at both sites were renewed with correct SANs covering the external access FQDN, the A/V FQDN, and the web conferencing FQDN — the existing certificates had been issued with the Munich external access FQDN as the primary subject, which was causing TLS validation failures for external federated partners attempting to connect to the remote site Edge Servers directly.
The Exchange UM integration rebuild was executed after the Lync topology stabilisation was complete at all three sites — attempting to repair UM routing before the underlying SIP trunk and dial plan configuration was stable would have made it impossible to distinguish UM-specific failures from trunk-level problems. UM dial plans were updated to reflect the standardised E.164 SIP URI format, subscriber access numbers were corrected in each dial plan, and the UM IP gateway objects were updated to point to the correct Mediation Server FQDNs. End-to-end voicemail call flow was validated for a test user at each site: inbound call to voicemail, message deposit, MWI indicator visible in the Lync client, and retrieval via subscriber access — all confirmed before operational sign-off.
Voice service quality was restored across all three principal sites. The intermittent call registration failures at The Hague and Vienna were eliminated following the SIP trunk reconfiguration and dial plan normalisation corrections — call setup success rates measured over the two weeks following implementation showed no registration failures attributable to the previously identified causes. Inbound and outbound call quality, measured through the Lync Server QoE database, showed Mean Opinion Score averages within the expected range for WAN-connected sites, compared to the degraded scores recorded during the diagnostic phase.
The Exchange Unified Messaging platform was returned to full operational status across all sites. Voicemail deposit, MWI notification, and subscriber access retrieval were confirmed working for users at Munich, The Hague, and Vienna. The operational documentation produced during the engagement — covering pool topology, load balancer configuration, SIP trunk parameters, dial plan normalisation rules, and UM dial plan assignments — was handed to the EPO's infrastructure team as a complete as-built record. The documentation included a change procedure for each component, written to allow future modifications to be made by engineers without requiring re-engagement, and a validation checklist that could be used after any future change to confirm that call flow remained intact across sites.
For the EPO, the main gain was not simply technical remediation but operational consistency across a distributed European estate. Voice, presence, and voicemail services moved from a fragile configuration shaped by local exceptions to a documented platform that could be administered with the same standards across Munich, The Hague, and Vienna.
That consistency materially reduced service desk dependency and change risk. Future topology adjustments, certificate renewals, and carrier-facing changes could be evaluated against a clear reference design and validation checklist, which is the difference between a platform that functions today and one that can be supported responsibly over time.
Book a discovery call to discuss your Microsoft environment.