Lync MVP

Lync MVP
MVP AWARD

Tuesday, April 15, 2014

Manually fail over or fail back a Lync SQL mirrored database

In several cases you need to manually organize or switch databases on your mirror database/ SQL Server. Either after a reboot or simply some other issues.

The SQL queries are the most efficient solution and can be scheduled as well. But you need access to the SQL database. You can do this from remote, if you have the SQL Management Console installed

You need to execute a SQL QUERY as following:



You have to use and execute a SQL Query:

USE master;
ALTER database_name SET PARTNER FAILOVER

database: name of the DB to fail over
Server where to execute: the primary server, where the database is active

What I personally do is, I save SQLQuery on my Primary SQL and run this script every time I need to fail back the databases.

For those who think well, I could do this with Lync Management Shell. Sure you can do to.

Invoke-CsDatabaseFailover -PoolFQDN -Databasetype "TYPE" -NewPrincipal "PRIMARY"

Where NewPrincipal is the Primary SQL (PRIMARY) or the Mirror SQL (MIRROR).

The Databasetype is the installed database associated with this SQL setup:
* Application
* Archiving
* CentralAdmin
* CentralMgmt
* Cls
* Edge
* Lyss
* Monitoring
* PersistentChat
* PersistentChatCompliance
* Provision
* Registrar
* User



 

 

Monday, April 7, 2014

Polycom HDX or GROUP: SIP/2.0 409 Conflict: publication version out of date

Issue:
You will not be able making call to Lync Clients. SIP/2.0 409 Conflict

Error on the Client side might be:
"call was not completed or has ended"
and
"video was not accepted"

You might also see in the SIP protocol that the Polycom System is communication with itself in the FROM and TO Header.


Solution:
Reboot the HDX or GROUP, due to deleting the Cache on the conferencing System

(Beside, this only applies if you had the HDX/ GROUP working before)

Monday, March 31, 2014

Dialin Simple URL in Lync 2013 (Change of Default SIP Domain)

WARNING: Do NOT change the default SIP Domain in Lync!

As Microsoft wrote in the article Planning for Simple URLs, you will also see during your Topology setup, if you use multiple SIP domains, you only have one (1) active DIALIN URL.

This is by design and normal.

If you default SIP domain should be different from that you want to use in your simple URL.
Say your default SIP domain is CONTOSO.COM, you are able to Change your DIALIN and also MEET URL to say: CUSTOMER.COM.

If you need to do this, you have to add, as Best Practice, CUSTOMER.COM as additional SIP domain. Even if this domain will not be used for user SIP addressing.

If you want to make those changes after certain times, meens after you deployed Lync 2013.

Be Aware about the Impact.
You need to change your DNS and all related certificates.

1. NEVER DELETE nor CHANGE your Default SIP Domain
2. after you changed the simple URL, you MUST run Enable-CsComputer on all Frontend and Director Servers.


Wednesday, March 19, 2014

Export Lync User Configuration (former DBIMPEXP)

You for your information, with Lync 2013 some former tools are depreciated.

While in LCS, OCS and Lync 2010 exporting the user data was done with the dbimpexp.exe utility.

Now with Lync 2013 new EXPORT-CSxxx commands are integrated within the Lync Management Shell.

Convert-CsUserData
Import-CsUserData
Sync-CsUserData
Update-CsUserData

As we now from former days, we had to use DBIMPEXP to extract the user data, e.g. the Lync buddy list, to export data directly out of the RTC database.

Lync 2013 made the export functions more convenient and added PowerShell commands to do a more simplified export. With this EXPORT-CSxxx commands, you can export:
  • User Data
  • Conference Directories
  • LIS (Location Information Service) - E911 Data
  • RGS - Response Group Data
  • Persistent Chat Data

With the Convert-CsUserData command, you are able to convert former XML formats into the actual Lync 2013 format. But if you need to convert Lync 2013 data backward to Lync 2010, you need to do this during the Export-CsUserData command with the option parameter: -LegacyFormat

Other helpful parameter are:
-UserFilter: filter for dedicated user or bulk users
-ConfDirectoryFilter : Filter for Conference Directories, with you should first identity with Get-CsConferenceDirectory and than use the number display as the identifier.

NOTE/ WARNING:
The Export-CsUserData command also exports Lync Application User.
If you for example had a deployment, where you changed the default SIP domain and deleted this default SIP domain (Which by the way is UNSUPPORTED), you will have to clean up the XML file or you make sure, that only Lync Users are exported, which you need for this.

Best Practice:
You run a command and export the User names:
Get-CsUser | fl *sip* > C:\CsUser.txt
and
Export-CsUserData -PoolFqdn "frontend.pool.fqdn" -FileName C:\UserDataExport.zip
Than if you import, do so selective, that means write a script, which will use the CsUser.txt to import only the user you need and make sure you excluded the Lync Application users.
Make sure the txt file has the SIP identifier in first row.
SIP
usera@sip.com
userb@sip.com

Import-csv C:\scripts\CsUser.txt | ForEach-Object {Import-CsUserData -PoolFqdn "frontend.pool.fqdn" -FileName C:\UserDataExport.zip -UserFilter $_.SIP}

Wednesday, March 12, 2014

Lync 2013 Edge Server - DNS Resolution, cannot resolve IP addresses

A new topic came along my way, even I personally work with windows server since NT 3.5, but in very tight configured network environments you might run into server DNS resolution issues.

Principals regarding Lync Edge Server DNS resolution.
It is recommended to resolve DNS queries on the Internet, which means via the external NIC.
For internal DNS resolution, best practice is a dedicated hosts file, or make it possible to resolve intern DNS.

Therefore a common practice is to simply let even external DNS names resolve by the internal DNS servers.


NOTE:
Make sure you have the put in the DNS Servers on the correct network interface!

What and how Windows Server really works:

A we know, each IP setting for every NIC allow us to specify a DNS Server entry.

As I figured out and very important to know, DNS resolution will work ONLY on the network adapter, where DNS servers are configured. While we still keep in mind, if a hosts file is used, the hosts entries are loaded into the DNS Client Cache.


Let's tap into several possible setups:

Also: NetBIOS and LMHOSTS should be disabled.

1. Only a internal DNS Server is used.
You need to configure a DNS Server on the internal network card
Firewall: PORT 53 TCP/UDP configured for internal DNS Server and Edge Server internal IP


2a. A HOSTS file and a external DNS server is used.
The HOSTS is used for internal Lync Server only, so specify all Lync Server in your internal Topology, configure the DNS Server only on the external NIC
Firewall: PORT 53 TCP/UDP configured for external DNS Server and Edge Server external IP (primary IP, the Access Edge)


2b. A HOSTS file and a internal DMZ DNS server is used.
The HOSTS is used for internal Lync Server only, so specify all Lync Server in your internal Topology, configure the DNS Server on the internal NIC, which has a route into the DMZ net.
Firewall: PORT 53 TCP/UDP configured for external DNS Server and Edge Server external IP (primary IP, the Access Edge)


3. Split DNS resolution, two DNS server are used
Configure the DNS Server for external resolution on the external NIC and the internal DNS server on the internal NIC.
Firewall: PORT 53 TCP/UDP configured for external and internal DNS Server and Edge Server external (primary IP, the Access Edge) and internal IP

Also the routing is very important.
However, make sure the routes have als o assigned the correct interface.
Recommendation:
alway use the ROUTE ADD -P command to manually set the routes.This ensure the correct METRIC as well as the corrcet INTERFACE.

Assume this IP addresses:
NIC: Interface 11
ACCESS Edge: 192.168.10.10
WEBCONF Edge: 192.168.10.20
AV Edge: 192.168.10.30

NIC: Interface 12
INTERNAL  Edge: 192.168.20.10

LAN Segement: 10.0.0.0

Default Route:
ROUTE ADD -P 0.0.0.0 MASK 0.0.0.0 192.168.10.254 METRIC 10 IF 11
ROUTE ADD -P 10.0.0.0 MASK 255.0.0.0 192.168.20.254 METRIC 50 IF 12

If now your DMZ DNS Server is used, make sure which path (interface and route) can be used to reach the DNS server. You might have to admit the route.

Saturday, March 1, 2014

Polycom VVX 600 with Color Expansion Module (Business Unit Phone)

Amazing the actual Polycom VVX series.
The first Lync Design Phone System for Lync.

The VVX series has the black+white screen based models (VVX 300 / VVX 400) and the color screen models (VVX 500 / VVX 600). Another model is the executive model VVX 1500.

As this is manly well know, i want to highlight the VVX extension module.
This module is also available in black+white or color.

What's use full is for attendants, the simple way how it can be configured. You simple need to add some more Lync user into your Lync client and it is simple sync'ed with the Expansion Module.

This Unit can support 3x28 Lync users and can be expanded with 3 modules, this means you have more then 3x3x28 = 252user on the Expansion Module, plus the 15 users on the VVX 600 phone. this is quite a lot, i think.


Note the VVX Camera is not yet supported with Lync, but should be quite soon.

Two more features which are amazing, the "Better together over Ethernet" and the touch screen usability with you PC mouse and keyboard.
The "better together" feature is the same feature as you know from your other desktop phones, like the CX600 via USB.


Lync Room System (LRS) - Polycom CX8000

Today i like to show you the simple setup for Polycom's CX8000 Lync Room System

First, the CX8000 is combination build with Polycom CX5100 new Round Table camera in combination with Crestron LRS components.
This combination from Polycom has the advantage of a really professional camera, since Microsoft has made the requirements, that Crestrons system is only allowed to work with any Lync certified USB camera.
Personally, I'm not so happy here, since a professional Video Conferencing System should make us of a professional camera instead of any Desktop cam. Additionally the system is quite expensive, another reason for need of better cameras. Since the newly developed CX5100 with 5 HD cams, this is acceptable solution. Polycom, as I was informed, is still working on a solution making use of their Eagle Eye III cam. Lets hope this will be available soon.

First you need to setup up the system physically, so the cabling.
Important is, you need a large touch screen. I recommend the Crestron systems, due to at this moment they will be proper recognized a touch USB device. With other monitors we had issue the Crestrons Windows based LRS system was recognizing the touch screen not a usual mouse.

The LRS can be setup with a single or dual screen touch screen.

Note - Idea:
Another option is the Crestron LRS in combination with a Polycom GROUP 300. What you need here is a Polycom DMA and RMX Video Conferencing Bridge. If you do so, you make use of the highest possible HD Video experience. The Group 300 will here provide the the conferencing video and the Crestron LRS the better work together touch based content sharing.

You need the USB device from the touch screen and the CX5100 to be connected with the Crestron unit.
 

The cabling looks like this:
As you see, the perfect power adapter plate is well organized and the Polycom CX 5100 is integrated with its power unit also quite well.


 Polycom CX 5100 Round Table and the Crestron LRS unit:

Now it is time to configure the LRS. When you login with the local administrator, the system will first reboot, than it allows the setup.
I spare here the very details, since you can see the simple establishment.

LYNC SETTINGS:
provide the LRS with its login credentials and this are the same as you will define with the Microsoft Lync Room System Management (see my other blog)

SYSTEM SETTINGS:
You will activate the Tutorial Slide Show

WEB UPDATES:
You can configure the WSUS Server (Lync Updates) and OEM Server (System Update). Other required updates can be applied automatically.

PASSWORD RENEWAL:
This settings depend on if you are on-premise or on Office 365.

NEXT SETTINGS:
Here you will have to configure all relevant information, like IP Address, Routings or Join to Domain options. Important to remember here is the Diagnostic Logging options.


Once this has all be setup, you will Apply the settings and the system will reboot. Afterwards the LRS is ready and can be used with Lync.

On the table unit, you have the touch panel where you will operate the LRS, you can join conferences, start adhoc calls or change the video screen presentation setup.

While you are not in a conference, the large (here 65 inch) touch screen will show you the same Exchange calendar view as the desk unit.

On the desk unit you can operate the LRS with the same user experience as you are familiar with from your desktop or App Lync client.

Under Display, you can change the view of your singel/ dual screen solution to best match your conference requirements.

You are also able to use IM or invite adhoc Lync users into your conference:

Once the conference is established, you are provide e.g. with the preview of your CX 5100.


Since we had only a single screen setup to play with, we use the desk unit to change to view and presented our content.


At last I also want to say thanks to Wolfgang Matheus from Polycom for his kindly help and providing the opportunity to present the Polycom CX 8000 LRS.

Friday, February 28, 2014

Lync 2013 installation on Windows Server 2012 R2

Even if this article comes a bit late.

Yes Lync Server 2013 is supported on Windows Server 2012 R2. You must have installed Lync 2013 CU 3 from October 2013.
Please refer: http://technet.microsoft.com/en-us/library/gg398588.aspx

  • Windows Server 2008 R2 SP1 or latest service pack
  • Windows Server 2012
  • Windows Server 2012 R2

The Active Directory Servers are also supported with Windows Server 2012 R2 AD.

Please feel free to deploy 2012 R2 AD.
Beside this, Exchange 2013 will only run on W2k12 R2 Servers, if SP1 is used for installation.
Refer: http://blogs.technet.com/b/rmilne/archive/2013/09/17/exchange-support-for-windows-server-2012-r2.aspx

NOTE:
If you encounter errors in the event log, ID 32402 and ID 61045 the is  work around to solve this issue.
Refer: http://support.microsoft.com/kb/2901554

QUESTION:
If you ask for an server in-place upgrade from Windows Server 2012 to 2012 R2. Microsoft did not stated any information regarding this. Windows in-place upgrade itself is fully supported, without any information regading the application.
Refer: http://technet.microsoft.com/en-us/library/dn303416.aspx


Sunday, February 9, 2014

Demystify HLB and DNS Load Balancing - Lync 2013 Topology with High Availability (POOLs, DNS LB vs HLB)


Lync 2013 Topology with High Availability (POOLs, DNS LB vs HLB)


© 2014 - Thomas Pött, MVP Lync

Download PDF: here

The most misunderstood topic in Lync is the high availability. This is regardless of server count, positioning or DNS versus hardware load balancing.

Note:
This document is neither a sizing nor a configuration guide. You should use this document only for your environment planning’s purposes.

In my first chapter I need to drive into the different understandings of high availability.


Client-to-Server and Server-to-Server traffic high availability:


First I need to explain some generic settings bout load balancing.

And one word before you read this article:
My personal recommended opinion is the DNS+HLB 1-armed solution, this makes trouble shooting much more simplified and do not require so much network knowledge for the Lync admins. On the Edge server recommend only 1-armed and purely HLB. 

Client-to-Server

The only part, were the both option DNS+HLB and HLB come into place is for the Client to Server traffic ONLY.

 

Server-to-Server

Lync Server traffic is much different. As we setup the server first in the topology, Lync servers are aware about the entire topology setup with in the CMS or XDS database. This source will be queried to load balance server-to-server traffic fully automatically. That’s one part we have later to consider with LB 2-armed solution.
 

Lync Server Roles entitled for High Availability:

Lync Server 2013 can be made high available by using redundant servers, which means we have to deploy multiple server in an array. This array in Lync topology is named POOL. A pool can have assigned 1 up to 12 server, regardless if we are talking about the different server roll, which are directors, frontends, mediations, group chat or edge servers. Beside Lync server, where the Lync application is installed on, we also have several other components, which I describe later in this passage.

Note:
You should also understand the difference between High Availability and Resiliency. Please do not mess around with this differences
 

POOL Servers

All four server rolls described next are entitled for POOL based high availability.

Director Server

The incoming, general SIP requests from external and internal Clients will be redirected to its responsible Frontend system, most likely a Pool. Authentication is part of this server too.

The Director Server host both, Lync Application and IIS for Web Services.
 

Frontend Server

The core component of Lync. It hosts the users and every of their responsible functions Lync offers. They also will always have collocate the Conferencing part. Beside this, Archiving and Monitoring truly its hosted as well.

Optional, if it makes sense, the Meditation feature could be added to this system too.
 

Edge Server:

Lync component for external SIP related traffic. This is one of the only servers, which are not responsible for any kind of Web Services Lync has to offer.

But what’s about this server? Well, Lync Edge Server is a standalone, Non-Domain Joined System, designed to act as a true Application Proxy and Application Reverse Proxy.
 

Let me repeat some basic requirement:
You MUST have 2x NICs and 2x dedicated/ separated/ isolated Networks and the internal DNS Suffix of your Active Directory Domain must be present, else Edge cannot work!
 

Mediation Server:

As described, the Meditation server can also be separated from the Frontend Server. It is responsible for translating SIP to ISDN (also SIP Trunk), second it also doing transcoding from Lync codecs into G.711.
 

Other Server:

All of the server named above are pool servers, which can be configured under a single, addressable name space. All other system Lync need to operate with are different and will have different requirements to operate in high availability mode.
 

SQL

The SQL server, also called “Lync Backend” can be operated in two high availability modes. One is the well-known cluster, where we have two SQL servers in an active-passive mode. The other option the better choice, SQL server mirroring. Mirroring exists with two SQL server, where the primary server hosts the active database and do log shipping of all its transaction to the second, independent SQL server. Therefor a logical independent database copy exists.

Why this is even better than a cluster? First, we have a second database copy, independent from the other and second, if you only operate the mirror server for Lync, you do not need to pay the SQL server license.
 

File Share

Lync also need file storage for several features. Here we are able to utilize the most system opportunities. We can simply cluster the file storage, or we make use of Distributed File System (DFS) and its replication technology.

Other third party solutions as NetAPP or EMC can be used to. But you need to ensure the correct Lync requirements are full filled.
 

WAC

Office Web Application (former Office Web Companion) the server rendering in Lync 2013 all Power Point presentations into HTML5. Regarding high availability, we make use of “FARMS”, a farm are multiple WAC server installed and joined the farm, receiving the identical configuration. Since it is a Web based service, we can load balance this servers. The two methods are: hardware load balancing, or windows load balancing. (Note: this is the only system, which is entitled for Windows Load Balancing)
 

Gateways

At last, we have the Audio transcoding and protocol changes to ISDN or others. This is for some the most complex systems if we are talking about high availability.

Since the Gateway cannot be deployed in a Lync related pool, we need to create another kind of system collection.

In Lync 2013 we have several components/ elements in the IP flow. Starting with the mediation server, the mediation server has two sites and one of them is associated with the ISDN gateway. This does not mean we need two dedicated NICs, but it is in some circumstances possible or even necessary. In between of this path, we associate both sites with a Lync 2013 TRUNK. This are the three components involved.

Now we have to opportunity for high availability with a backup gateway (alternative gateway), the other option native in Lync if we deploy multiple paths and the third option is a load balanced solution between the mediation server and the gateways as bidirectional communication flow.

 

Lync High Availability:


POOL:

Every Lync pool servers are capable of both load balancing solutions, as long a supported client is used. The supported clients are Lync 2010, Lync 2013 and the App Store, as well the mobile clients.

Before I dig into the both scenarios, lets have a quick discussion about the two relevant components in Lync. Beside the Lync applications, we have web related services. Those service are e.g. Address Book Distribution, Distribution Group resolution, Meet and Dialin page, or Lync Mobile Clients Autodiscover and others. We remember the setup of our external facing systems, in our case the Reverse Proxy. Here a special mapping of the related http port 80 and 443 is needed within the redirection process, the port mapping will be 80 -> 8080 and 443 -> 4443. Why is this so?

The Lync Web Services are running inside the IIS, due to security reasons, Lync segregates all web traffic onto internal and external web sites. Since we have only a single IP address on the Lync servers, the only possibility is if its using different ports. Therefore the external connections run on the Lync external site under port 8080 and 4443.

After this excurse let’s come back to the main topics. In other words, we talk about SIP, server function and web services in Lync. All of them have to be high available. While SIP can be considered as a so call “persistent” protocol, if we use simple load balancing mechanism like DNS Round Robin, a TCP connection will with the “supported” Lync client always stay with its initiated Lync server. Well this is a very simple and rudimentary explanation, but should be solvent enough for this article. I more like to high light the word “persistent”, means continuously established IP session. Web Services in general are different. Web service must not and cannot be persistent. This is because of the IP session will always be reestablished after an http request is finished. In Lync we need to submit web requests on a session basis, but how this can be done, if we e.g. use a round robin process? Each time a client would start a new request and the server is not aware that within the same session and we would hit another server in a pool, the information stream within this session would have got lost. Therefore web services must stick to the same server. To do this and enable the client hitting the same server again, a supporting technology must be in place. Here we have several options, cookie based sessions or source IP address affinity. Now, since we understand this requirements, the recommendation for hardware load balancing is clearer. In the same way we can now understand why Windows Load Balancing cannot be used with Lync pool. Windows load balancing is based on shared information within the WLB cluster and communicated via multi/ unicast. This is never sufficient for the requirements of Lync.
 

NOTE:
Windows Load Balancing can neither be used for Web service, nor Lync application services, even due to those services exist on the same server and cannot be separated.
 

Count of servers in a pool: 1, 2 or 3+ server in a pool

Very often I’m asked by other consultants: Why Microsoft recommends 3+ server in a pool.

I want to have a look what is happened to the pool with different server counts.

But this discussion is only related to Lync Frontend server pools, other pool follow the simple principals of at least 2 servers and +1 for each high availability user count. Say you have 10.000 users , so you need 2+1 Director server, since 1 server is allowed to fail until the load cannot be handled anymore. If you add more than +1 you increase the high availability but more related to SLAs since more server can fail.
 

Lync Frontend server are different, for user load and associated quorum. Truly the server to user count is quite similar. If you have 30.000 user for a single pool, you need at least 3 server +1 or more for high availability.

What is if you say, we have only 7.000 users on a single pool?

1.) Single Frontend server in a pool
this single server is fully sufficient for 7k user and will run with this load. Also the necessary quorum is simple, it’s a single node system equivalent to what we understand from single node clusters.

2.) Dual Frontend server
this is a working configuration, even if its not recommended. This also does not mean it would be unsupported. BUT:
If we assign this solution, we need to keep in mind that under some circumstances we might run into issues. Those issues are probably happened, if one server fails and the left one is restarting. In this scenario when the server is restarted, the server is in an inconsistent state and will need up to 1 hour before the services will have started. The Lync Frontend quorum need to be rested.
Command: Reset-CsPoolRegistrarState –ResetType QuorumLossRecovery
As we can see, if we only install a pool of Frontend servers with 2 nodes, we need to be prepared handling cases like described.

3.) 3+ more Frontend server
This is the recommended setup for high availability. If you are planning so for customers you will have the best in class solution with all necessary automated processes and less impact during system failtures.
Disadvantage is still the cost factor, since the server license count is higher. 

I will now have the look into the high availability technology required to support those setups.


Hardware Load Balancing


We identified three components, the both IIS web site and the Lync application. Therefore a full hardware load balancing solution will cover all components for Lync. Sure the setup of HLB is a little bit more complex and requires more port which need to be load balanced. Also the load balancer will have more load compared with a setup of only web services. Since the Lync application do not need to off-load TLS encryption to the HLB, the impact is quite less.

I personally prefer this way of setup due to a more clearer setup and we know also in case of issues with load balancing, where to look for issues. The support process is straighter forward.

Other to this is, if we setup a fully load balance solution, we are able to implement 1- or 2-amred setup of load balancers. 

Note:
Another advantage of hardware load balancing is, if you need to take a pool server offline, this is purely done on the HLB and do not require DNS changes, which also need time to be replicated.
 

DNS Load Balancing:

If you decide for DNS based load balancing, this setup make use of Lync application only. Due to the point we discussed more early, even if we decide for DNS based load balancing, the web services required a hardware load balancer.

For session based load balancing, it is a must that we have a look into the HTTPS data stream, which than require a SSL off-load to be configured.

If we do so, the shared pool server certificate must be copied and used on the hardware load balancer.

NOTE:
Web Services must be HLB, it is necessary to change the INTERNAL and EXTERNAL Web Services to a dedicated name. Example: PoolName: FEPOOL01.<ad fqdn>, internal Web Services: intFEPOOL01.<sip domain>, external Web Services: extFEPOOL01.<sip domain>

  • Use TCP idle timeout of 1800 seconds

Web Services External
  • Ports 8080 and 4443 for external web traffic
  • set cookie-based persistence on a per port basis
    • Cookies must not be marked httpOnly.
    • Cookies must not have an expiration time.
    • Cookies must be named MS-WSMAN.
Web Services Internal
  • Ports 80 and 443 for internal web traffic
  • set source_addr persistence
  • Exception for internal Lync Mobile clients » use cookie persistence instead
 

Specialties

Regardless with load balancing solution we chose, there are still more consideration we have to take in place. I separated this into three chapters
 

Generic Information Lync Mobility Services
Cookie-based persistence required for Lync Mobilityservices
  • Marked httpOnly, named MS-WSMAN and no expiration


Edge server

Edge pool server can also either be load balanced on hardware basis or via DNS. Important are here two points:

  1. If you decide for one of the both possibilities, you MUST stick to the same setup on both site of the Edge pool. Which means, the external and the internal site (NICs) must make use of the identical process.
  2.  DNAT Load Balancing (half-NAT) for A/V Edge (external)
  3. If you decide for DNS based load balancing you have some restrictions:

This restriction apply if the “core” server of the pool will fail.
  • Exchange Unified Messaging:
If EUM is deployed and Exchange 2010 prior SP1 is used, the user will have no access to their voice mail
  • Office 365 and Public Instant Messaging (PIC):
  • Federation with partners with Office Communication Server 2007 / 2007 R2
The communication is broken, since both systems do not support DNS load balanced Edge pool. DNS load balancing was not available with OCS
 

Mixed of DNS+HLB and HLB

Beside of the provided information for Edge servers and the internal and external site, you are entitled to make use of both solutions with in your Lync topology.

As a simple example:
If you have a topology with 2x Edge, 2x Director and 3x Frontend servers, you can do a setup of DNS LB for the Edge server, DNS LB+HLB for the Directors and HLB for the Frontend server.

Also this scenarios are supported
 

1-Armed or 2-Armed solution:

Load balancer setup can vary in two different deployment, either 1-armed or 2-armed. The difference between both is how the IP flow has to run. While in a 1-armed solution the IP traffic will first hit the LB, than redirected based on the LB algorism directly to the pool server. Afterwards the IP traffic is a direct communication between the source and target.

In a 2-amred setup the IP flow is different, the source will always communicate with the LB and the LB than starts, based on the algorism again, with the target pool server.

A specialized setup if a LB between the PSTN site of a Mediation server and its associated gateways. I will describe this later.
 

Routing vs redirect
What is now this difference between a redirected and a routed setup? If we decide for the 1-armed solution, we enable the source for a direct traffic exchange with the target and we do not need a isolated network. The setup is more simplified compared with the 2-armed solution. Here we need the IP flow to be routed to its target.

This has a direct impact on the high availability setup we can chose. If a 2-armed is the choice, we cannot use DNS LB, this is because we can use multiple A records in DNS pointing to the different pool servers, because we can address them directly due to the LB with acts as a router.

 

PICTURE

 

If 2-armed only than u make use of server load analysis
Say, we decided for this option. We have a huge advantage coming from the LB. We are now able to fully control the traffic flowing through the LB. Since the LB continuously know the amount of data routed to the target pool server. The LB is aware of its load.

In scenarios, where we have to consider higher load on the pool, this might be the best choice, since we are able to redirect traffic much more efficient.

Say, one pool server host a huge conference and it load is now quite high, the LB is aware of this traffic and able to redirect other traffic to member server in this pool, which have lesser load.

Truly, this is not described in the Microsoft deployment guides, since this is comes from the networking prospective.
 

NOTE:
If you are using a 2-armed solution, you cannot use DNS load balancing and you need to ensure, that server-to-server communication is possible and the HLB works for this fully transparent.
 

PICTURE!!!

 

Mediation server and gateways

The most complex setup is a load balancer in between of the Mediation server and the gateway. We have reduced ports we are utilizing here, mostly a single port 506x. But we need to plan the Mediation server, load balancer and gateway positioning in conjunction with the Lync TRUNK configuration. So it’s a more advanced config which provides the highest availability and routing of call to ISDN.
 

PICTURE
 
  • SNAT Load Balancing (Full-NAT) for gateway/PBX side of Mediation Server Pool
  • Use if Gateway doesn’t support DNS LB to simplify Gateway/PBX configuration 

Resiliency:

I leave this chapter a bit shorter since it should be only understood as generic knowledge. If you design Resiliency it requires another longer article….
 

Backup Pool:

Some consultants try to avoid HLB balancers at the customers and recommend a two standard edition server deployment, where the second standard server servers as a backup registrar. Sure you can consider, but this is not a god choice and requires much more knowledge for the customer as compared to the little knowledge of HLB.


SBS/SBA:

Its really the most recommended solution, if you have branch offices with no admins and you preferable need resiliency for VOICE.
 

Pool:

Assuming you have two datacenter, possibly far away from each other. Here you have the best option setting up this both dedicated pool in a relationship, acting as backup for each other. Combined with GEO-LB this is a solution of amazing high availability.


Technical requirements and ports for load balancing

More early I wrote an article about load balancing, you might consider this in your learning path too.


 

Certificates:

Certificate requirements can become complex in mind of security. If you need to separate the certificates assigned in pools, you have so many choices how to define the certs for all services. But what I want to highlight here are the certificate for Web services.

You are able to assign each Web service an individual certificate, this means internal and external site of the IIS. If you do so or not, you MUST be able to export the certificate to the HLB for SSL OFF-LOADING, this also requires you to have the SAME certificate with the same private key assigned onto all pool servers.

Please note about this else you will run into serious issues.

OAuth protocol is not mentioned here, since this not an option to be load balanced. Just keep in mind, you should have assigned the same OAuth certificate on all pool server as well.
 

Ports:


External Port Settings Required for Scaled Consolidated Edge, Hardware Load Balanced: External Interface Virtual IPs

Role/Protocol/TCP or UDP/Port
Source IP address
Destination IP address
Notes
XMPP/TCP/5269
Any
XMPP Proxy service (shares IP address with Access Edge service)
XMPP Proxy service accepts traffic from XMPP contacts in defined XMPP federations
XMPP/TCP/5269
XMPP Proxy service (shares IP address with Access Edge service) Any XMPP Proxy service sends traffic to XMPP contacts in defined XMPP federations
Access/SIP(TLS)/TCP/443
Any
Access Edge service public VIP address
Client-to-server SIP traffic for external user access
Access/SIP(MTLS)/TCP/5061
Any Access Edge service public VIP address SIP signaling, federated and public IM connectivity using SIP
Access/SIP(MTLS)/TCP/5061
Access Edge service public VIP address
Federated partner
SIP signaling, federated and public IM connectivity using SIP
Web Conferencing/PSOM(TLS)/TCP/443
Any Edge Server Web Conferencing Edge service public VIP address Web Conferencing media
A/V/STUN,MSTURN/UDP/3478
Any
Edge Server A/V Edge service public VIP address
STUN/TURN negotiation of candidates over UDP/3478
A/V/STUN,MSTURN/TCP/443
Any Edge Server A/V Edge service public VIP address STUN/TURN negotiation of candidates over TCP/443

Firewall Summary for Scaled Consolidated Edge, Hardware Load Balanced: Internal Interface Virtual IPs

Role/Protocol/TCP or UDP/Port
Source IP address
Destination IP address
Notes
Access/SIP(MTLS)/TCP/5061
Any (can be defined as Director, Director pool virtual IP address, Front End Server or Front End pool virtual IP address)
Edge Server Internal VIP interface
Outbound SIP traffic (from Director, Director pool virtual IP address, Front End Server or Front End pool virtual IP address)to Internal Edge VIP
Access/SIP(MTLS)/TCP/5061
Edge Server Internal VIP interface Any (can be defined as Director, Director pool virtual IP address, Front End Server or Front End pool virtual IP address) Inbound SIP traffic (to Director, Director pool virtual IP address, Front End Server or Front End pool virtual IP address) from Edge Server internal interface
SIP/MTLS/TCP/5062
Any (can be defined as Front End Server IP address, or Front End pool IP address or any Survivable Branch Appliance or Survivable Branch Server using this Edge Server)
Edge Server Internal VIP interface
Authentication of A/V users (A/V authentication service) from Front End Server or Front End pool IP address or any Survivable Branch Appliance or Survivable Branch Server using this Edge Server
STUN/MSTURN/UDP/3478
Any Edge Server Internal VIP interface Preferred path for A/V media transfer between internal and external users
STUN/MSTURN/TCP/443
Any
Edge Server Internal VIP interface
Fallback path for A/V media transfer between internal and external users if UDP communication cannot be established, TCP is used for file transfer and desktop sharing
STUN/MSTURN/TCP/443
Edge Server Internal VIP interface Any Fallback path for A/V media transfer between internal and external users if UDP communication cannot be established, TCP is used for file transfer and desktop sharing

Director Ports and Protocols for Firewall Definitions (DNS-HLB)

Role/Protocol/TCP or UDP/Port
Source IP address
Destination IP address
Notes
HTTP/TCP 8080
Reverse proxy internal interface
Director Hardware Load Balancer VIP
Initially received by the external side of the reverse proxy, the communication is sent on to the Director HLB VIP and Front End Server web services.
HTTPS/TCP 4443
Reverse proxy internal interface Director Hardware Load Balancer VIP Initially received by the external side of the reverse proxy, the communication is sent on to the Director HLB VIP and Front End Server web services.
HTTPS/TCP 444
Director
Front End pool or Front End Server
Inter-server communication between the Director HLB VIP and the Front End Server or Front End Servers.
HTTP/TCP 80
Internal Clients Director Hardware Load Balancer VIP The Director provides web services to internal as well as external clients.
HTTPS/TCP 443
Internal Clients
Director Hardware Load Balancer VIP
The Director provides web services to internal as well as external clients.
SIP/MTLS/TCP 5061
Edge Server internal interface Director SIP communication from the Edge Server to the Director, as well as the Front End Servers.
MTLS/TCP/50001
Any
Director
Centralized Logging Service controller (ClsController.exe) or agent (ClsAgent.exe)commands and log collection
MTLS/TCP/50002
Any Director Centralized Logging Service controller (ClsController.exe) or agent (ClsAgent.exe)commands and log collection
MTLS/TCP/50003
Any
Director
Centralized Logging Service controller (ClsController.exe) or agent (ClsAgent.exe)commands and log collection
 

Director Ports and Protocols for Firewall Definitions (HLB)

Role/Protocol/TCP or UDP/Port
Source IP address
Destination IP address
Notes
HTTP/TCP 8080
Reverse proxy internal interface
Director Hardware Load Balancer VIP
Initially received by the external side of the reverse proxy, the communication is sent on to the Director HLB VIP and Front End Servers web services
HTTPS/TCP 4443
Reverse proxy internal interface Director Hardware Load Balancer VIP Initially received by the external side of the reverse proxy, the communication is sent on to the Director HLB VIP and Front End Servers web services
HTTPS/TCP 444
Director
Front End Server or Front End pool
Inter-server communication between the Director HLB VIP and the Front End Servers
HTTP/TCP 80
Internal Clients Director Hardware Load Balancer VIP The Director provides web services to internal as well as external clients.
HTTPS/TCP 443
Internal Clients
Director Hardware Load Balancer VIP
The Director provides web services to internal as well as external clients.
SIP/MTLS/TCP 5061
Edge Server internal interface Director Hardware Load Balancer VIP SIP communication from the Edge Server to the Director, and Front End Servers.
MTLS/TCP/50001
Any
Director
Centralized Logging Service controller (ClsController.exe) or agent (ClsAgent.exe)commands and log collection
MTLS/TCP/50002
Any Director Centralized Logging Service controller (ClsController.exe) or agent (ClsAgent.exe)commands and log collection
MTLS/TCP/50003
Any
Director
Centralized Logging Service controller (ClsController.exe) or agent (ClsAgent.exe)commands and log collection

 

Frontend Hardware Load Balancer Ports if Using Only Hardware Load Balancing (HLB)

Load Balancer
Port
Protocol
Front End Server load balancer
5061
TCP (TLS)
Front End Server load balancer
444 HTTPS
Front End Server load balancer
135
DCOM and remote procedure call (RPC)
Front End Server load balancer
80 HTTP
Front End Server load balancer
8080
TCP - Client and device retrieval of root certificate from Front End Server – clients and devices authenticated by NTLM
Front End Server load balancer
443 HTTPS
Front End Server load balancer
4443
HTTPS (from reverse proxy)
Front End Server load balancer
5072 TCP
Front End Server load balancer
5073
TCP
Front End Server load balancer
5075 TCP
Front End Server load balancer
5076
TCP
Front End Server load balancer
5071 TCP
Front End Server load balancer
5080
TCP
Front End Server load balancer
448 TCP
Mediation Server load balancer
5070
TCP
Front End Server load balancer (if the pool also runs Mediation Server)
5070 TCP
Director load balancer
443
HTTPS
Director load balancer
444 HTTPS
Director load balancer
5061
TCP
Director load balancer
4443 HTTPS (from reverse proxy)

 Frontend Hardware Load Balancer Ports if Using DNS Load Balancing (DNS+HLB)
Load Balancer
Port
Protocol
Front End Server load balancer
80
HTTP
Front End Server load balancer
443 HTTPS
Front End Server load balancer
8080
TCP - Client and device retrieval of root certificate from Front End Server – clients and devices authenticated by NTLM
Front End Server load balancer
4443 HTTPS (from reverse proxy)
Director load balancer
443
HTTPS
Director load balancer
444 HTTPS
Director load balancer
4443
HTTPS (from reverse proxy)

References