Teams Direct Routing Session Border Controller SIP Port and Media Port Range(s)

SIP Traffic 

There is going to be a time when you are configuring Teams with Direct Routing and you need to configure the Session Boarder Controller (SBC) and someone is going to ask what the port(s) are and or port range that is needed.  This is where things begin to get interesting as we look at these range that is needed.   We are going to break them down into two areas:  SIP Signaling and Media Traffic.

Let’s dive in; let’s look at the SIP Signaling portion:

One of the things that needs to be understood first is from the SBC point of view to the Microsoft tenant (O365) what you will be connecting to via FQDN.   There are three different FQDNs that you could be connecting to and they are the following:

• sip.pstnhub.microsoft.com
• sip2.pstnhub.microsoft.com
• sip3.pstnhub.microsoft.com

Now you will not connect to all of them at the same time but rather in order if the previous one is not available for any reason.   So, look at them like Skype for Business copies with regards to Primary, Secondary and Tertiary.

• sip.pstnhub.microsoft.com (Primary)
• sip2.pstnhub.microsoft.com (Secondary)
• sip3.pstnhub.microsoft.com (Tertiary)

The above FQDNs will resolve to any of the following IP addresses:

• 52.114.148.0
• 52.114.132.46
• 52.114.75.24
• 52.114.76.76
• 52.114.7.24
• 52.114.14.70
• 52.114.16.74
• 52.114.20.29

So, what this means is that if your restricting your SBC(s) to talk to or receive traffic from Microsoft (O365) for Direct Routing to specific IPs, make sure you include all the above IPs.   For you will be sending to and \ or receiving SIP signaling traffic from any of the above IPs.

SIP Signaling: Ports

Traffic	From	To	Source port	Destination port
SIP/TLS	SIP Proxy	SBC	1024 – 65535	Defined on the SBC (For Office 365 GCC High/DoD only port 5061 must be used) 5068
SIP/TLS	SBC	SIP Proxy	Defined on the SBC 5068	5061

 From Microsoft to the Customer SBC

Traffic	From	To	Source port	Destination port
SIP/TLS	SIP Proxy	SBC	1024 – 65535	Defined on the SBC (For Office 365 GCC High/DoD only port 5061 must be used)

What the above figure is saying is the following:

SIP traffic from the SIP Proxy (Microsoft) to the Customer SBC will originate from source port range of 1024 – 65535.    The destination port is what you can define on your SBC.   So, in this case you could specify that you only will accept traffic over port 5061.   Now that is granularly but you could do that.

From Customer SBC to Microsoft

Traffic	From	To	Source port	Destination port
SIP/TLS	SBC	SIP Proxy	Defined on the SBC	5061

Now vice versa, SIP traffic from the Customer to the SIP Proxy (Microsoft) will originate from source port range of 1024 – 65535.    The destination port of the SIP Proxy within (Microsoft) will be listening on port 5061.

=====================================================================================

Media Traffic 

Now let’s dive in and look at the Media portion: The media traffic flows to and from a separate service (Media Processor) in O365. The IP address ranges for Media traffic are as follows:

• 52.112.0.0/14 (IP addresses from 52.112.0.1 to 52.115.255.254).
• 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254).

Media Traffic: Ports

Traffic	From	To	Source port	Destination port
UDP/SRTP	Media Processor	SBC	3478-3481 and 49152 – 53247	Defined on the SBC[SB1]
UDP/SRTP	SBC	Media Processor	Defined on the SBC	3478-3481 and 49152 – 53247

Now we are going to break this down into two sections; Media traffic coming from O365 (Media Processor) to the local SBC and then traffic vice versa which is leaving the local SBC and going to O365 (Media Processor).   We see that media traffic from the Media Processor to the SBC could be between 3478 – 3481 and 49152 – 53247.   The destination port section is where the customer could define the port that they want to listen on for the SBC if they want to.  

Traffic	From	To	Source port	Destination port
UDP/SRTP	Media Processor	SBC	3478-3481 and 49152 – 53247	Defined on the SBC

When we look at the opposite direction of the media traffic leaving the local SBC and traveling to O365   (Media Processor) this where the customer needs to have 3478 – 3481 and 49152 – 53247.   This is where we specify traffic coming from the FW at the customer needs to be open an allowed to travel to.

Traffic	From	To	Source port	Destination port
UDP/SRTP	SBC	Media Processor	Defined on the SBC	3478-3481 and 49152 – 53247

---

 

Determining How Many Front-End Servers to Deploy in Skype for Business Server 2019

I figured it was time to update this article to reflect Skype for Business Server 2019, from the previous Lync Server 2015 version.  For those that would like to reference the previous article I wrote, you can find it here Determining How Many Front-End Servers to Deploy in Lync Server 2013.  Through many deployments of Lync Server 2013 and newly released Skype for Business Server 2015 the calculations haven’t changed all that much, but I still find plenty of confusion in the community regarding planning and sizing the appropriate amount of Front End (FE) servers for a pool deployment.  So I thought it best to go ahead and give another stab at the article, but this time making it relevant to the latest version of Lync Server 2013 being Skype for Business Server 2015.

The Requirements

One of the areas that has changed from Skype Server 2015 is the maximum number of supported FE Servers in a pool has increased from 12 to 16 now with Skype for Business Server 2019.  The total number of users supported per pool still stands at 106,000 users; technically it’s 79,920, but we will come back to that number a little later.  So let’s begin with a few facts:

• Max users per FE server = 6,660 (you will see this number come up again)
• Max users per FE server pool = 79,920 (80,000)
• Max number of FE servers per pool = 16

Recommendations

The recommendation typically is to have no less than 3 FE servers in a pool.  Now mainly we know about this from the fabric and pool quorum which is true; but another area regarding capacity numbers we will see that having at least 3 FE servers is quite more beneficial than going anything less. We know that the more the better, but anything less than 3 FE servers, really doesn’t do us much good.  So for the sake of conversation, let’s say we go with 3 FE servers; let’s start doing the math.

Calculations: 3 FE servers = 19,980 (20,000); so that means each FE server will handle 6,660 users. 

If we are maxing out this Skype for Business pool with 20,000 users, we are going to plan for the N-1 scenario.  That is where we basing our capacity on the fact that if a single FE server goes down out of the 3 total, that the remaining 2 FE servers can handle the load of our total user population.

With that assumption this means we have 6,660 users per FE server across 3 servers; which also means 6,660 is divided into the 2 servers remaining FE servers in the event that a single server goes down.  This leaves 3,330 users per FE server to the already existing 6,660 users already on the FE server which means have a total of 9,990 (10,000) users per FE server, which is over the supported Microsoft limit of 6,660 user per FE server.  As a result, the decision to have only 3 FE servers in a pool if we have 19,980 (20,000) users for the pool is not a good one, considering the N-1 factor of losing a single FE server and still be in a supported state.

Mitigating the N-1 Factor

So what happens if we add a single server to the existing 3 FE server pool to make 4 FE servers?  By adding an additional server to the pool we now can have a max of 26,640 users to the pool.

Calculations: 4 FE x 6,660 users = 26,640

Now by adding just a single extra FE server, this makes each server in the pool of 19,980 (20K) users able to handle 4,995 users per FE server. 

Calculations: 19,980 users / 4 FE servers = 4,995

With each FE server in the 4 FE server pool is handling 4,995 users; if a single server goes down this means 4,995 users will be spread across the remaining 3 FE servers in the pool.  That makes 1,665 users per FE server now added to the existing 4,995 users for a total per server 6,660 user per FE server.

Calculations: 1,665 users + 4,995 users = 6,660 (funny how we come back to the number 6,660 again)

So the calculations tell us if we have 19,980 users in a pool we should deploy 4 FE servers considering the N-1 factor which means that our pool can still handle the load of all the users in a supported manner with respective a single server going down.

Calculations: (N-1) 3 FE servers x 6,660 users = 19,980

Keep in mind that the FE server is at its max with users for 3 FE servers and cannot handle another FE server going down at that time; even to be rebooted for maintenance. If that was the situation the remaining servers shouldn’t even be rebooted with a single FE down and only 3 FE servers remaining.

If 1 of the remaining 3 FE servers where to be rebooted during this time means the 6,660 users on the rebooted FE server would temp have to be moved to another FE server which would make us non-compliant with the supported number of users on a FE server.  For what if the rebooted FE server didn’t come up?

1. N-1 Scenario (Single FE server goes down)
2. FE server A = 6,660 users
3. FE server B = 6,660 users
4. FE server C = 6,660 users
5. Then if FE server A goes down or rebooted for maintenance 6,660 users are evenly spread across the remaining 2 FE servers
6. 3,330 users go to FE server A and FE server B
7. FE server A now has 9,990 users (Supported Max = 6,660)
8. FE server B now has 9,990 users (Supported Max = 6,660)

That would leave 19,980 users on 2 FE servers and I don’t have do the math to show you that would mean there is more than 6,660 users per FE server then.

Take a What-If Approach and Do the Math

Determining the right number of Skype for Business FE servers can be tricky when we don’t take time to do the math.  Take into consideration I tried to keep a simplistic scenario of the N-1 approach; you are more than welcome to go deeper such as N-2 or play the what if game to your heart desires.  Just keep in mind that whatever scenario you use that you end up having enough FE servers to handle the user load adequately and not impact the performance of the IM, conferencing, and Enterprise Voice features.

Skype Server 2015 Conferencing Limits

There’s been many discussions within the Lync community regarding how many conferences Skype for Business Server 2015 on premise can support and \ or handle; ironically enough these are two different topics in their own rights with regards to supported and what will technically work; specially with the adjusted supported number of users per Skype 2015 Front-End server, which is 6660 users if you didn’t know.  We will explore the suggested conferencing meeting size limit of 250 users; and take a look into some additional numbers that might affect conferencing and the quantity of Front End servers you have in your pool or the amount users you have in your organization assigned to a particular pool. For additional information on Front End servers and sizing, check out the article where we discussed that information; Determining How Many Front-End Servers to Deploy in Lync Server 2015.

 

How the numbers add up.

We’ve heard about the number of 250 users per conference and 1250 users per Front End server in a conference before; but how did those numbers come about?  So let’s ease that initial shock of hearing about such a number; 250 users per conference is not a hard limit, but a limit that is recommended by the Microsoft Skype Server team based on how often would and organization host conferences where there are 250+ users in size in a particular meeting. Now could this happen?  Yes, but it’s, but not very practical, and again we are talking about a typical meeting on the Skype Front-End Pool; keep in mind there will always be exceptions but we are going to focus on the majority of conferences that take place.   The majority of Lync ad-hoc conferences are between 4-6 users. Only a small percentage that are hosted on Skype Server would be in an excess of 250+ users, so we can actually say that less than 5% of conferences would be that large.   So to put in perspective we are talking between 1-5% conferences would need to be 250 users are over; so this is where the recommendation of 250 users comes into the picture.
The Microsoft Skype Server team recommends an on-premise conferencing limit not to exceed 250 users in a single conference; anything larger than that should have its own dedicated Skype Front End server pool. Now the Skype user model states that 5% of an organizations user base would be in a conference in a given time for a typical organization that has moderate conferencing needs.  There will always be organizations that require more, but for the sake of the topic we are going to stick with the average.    Keep in mind that there are some hard limits out there such as the following:

• 12 Front End Servers per pool
• 80,000 users per pool

So when we go back to the 5% of users are in a conference at any point in time; And do the math with numbers besides the typical 80,000 users for not everybody’s organizations has that many users, we will see how the numbers turn out.  We will use for the example to follow 7,500 users based on a medium size organization that has users spread across the organization.  So now we have (5% / 7,500) = 375 concurrent users in a conference for that pool.  (375 users / 3 Front End servers) gets us to approximately 125 users per Front End server in a conference.  Then we take the average number of users for an ad hoc conference, which is about 4 taken from the (4-6) users in an ad hoc conference profile.  So now we have (125 users per FE / 4 users per conference) = 31 concurrent conferences per Front End server is the number conferences each Front End server can handle safely.

Lync Server 2013 User Models

 

Users per Conference

The 125 conferencing users per Front end server is considerably lower than the actual limit of what a Front End server can handle which is approximately 333 conferencing users per Front End server taken from the model of 5% users in a conference and the Microsoft max capacity of users in a pool of 80,000 users; (5% / 80,000) = 4,000 users in a pool in a conference at the same time. Then we take (4,000 users / 12 max front end servers in a pool) = 333 conferencing users per Front End server; (4 avg users in a conference/ 333 conferencing users per front end server) = 83 concurrent meetings per Skype Front End server.

Conferences per Front End server

The 31 concurrent conferences per Front End server in our example earlier is also considerably lower than the estimated number of conferences that Skype Server 2015 can handle which is approximately 83 concurrent conferences averaging 4-6 users per conference.

Skype 2015 Conferencing Reaching Capacity

Skype 2015 on-premise conferencing with the inclusion of Audio, Video, IM, and Application Sharing has come a long way in the past few versions (OCS 2007 R2 to Skype 2013).  The key concept to remember is Skype Server 2013 can hold many different types of conferences and users such as remote, federated, and even anonymous ones as well. Scaling Skype Server 2013 out to meet organizations conferencing requirements will vary with each implementation; but based on the technical and business requirements of the deplorer will dictate the quantity of users and Front End servers that are ultimately deployed for the Skype pool. There’s talk with future editions of Skype having the ability to host large standing meetings that would scale far beyond what Skype is handling today, but that waits to be seen.

Codecs of Skype for Business Server 2015

Skype for Business Server 2015 (S4BS) has numerous codecs that can be leveraged in different types of communication, depending on the workload that the end users are engaged with; everything from peer-to- peer calls to conference calls leverage various codecs ranging from G.711 to Siren.  Depending on the type of  codec that is leveraged can end up changing how you design your S4BS infrastructure and can also help you plan going forward on what to expect with regards to bandwidth consumption.   We will take a look at the various different codecs that are involved with S4BS and what scenarios they are used with.

 

Session Description Protocol

Before we get into the codecs that are used, let’s take a look at the Session Description Protocol (SDP) as seen from a snooper trace in figure 1 below.  The SDP capture shows what codecs are available for the client will be used for the communication; in this case I happened to take the capture from a Lync 2013 client instead of a Skype client.  Why?  I just happened to have the Lync 2013 client installed while working with a customer.  The SDP displays all the codecs that capable of being used in the communication from the client and the order in which they will be leveraged.

Note: The term codec is a combination of the words “coding” and “decoding” used to convert an analog voice signal to a digital version of the voice signal.

 

Figure 1: Session Description Protocol

SILK

One of the first things that comes to mind if you have not heard of this codec before is, “When did we start talking about clothing material?”  Yes they are both spelled the same, but they mean two different things; Introduced in the November 2015 Lync 2013 Cumulative Update release, Microsoft S4BS leverages SILK for peer-to-peer (Wideband) conversations.  The plan is to have SILK eventually replace older Microsoft audio codecs used in the Lync 2013 and S4BS platform.

Below in figure 2 is a SDP capture of an egress Skype client call out to the PSTN.  The essence of the picture is not to display the actual call but rather how to identify the SILK codec in the log trace.

Figure 2: SILK Codec seen in a snooper trace

The SILK codec which will eventually replace the Real Time Audio (RTA) codec comes in two distinct patterns wideband and narrowband.

Narrowband

a=rtpmap:103 SILK/8000

a=fmtp:103 useinbandfec=1; usedtx=0

Wideband

a=rtpmap:104 SILK/16000

a=fmtp:104 useinbandfec=1; usedtx=0

 

Both pair of codecs narrowband and wideband can be used for Lync 2013 and Skype audio calling, of course depending on the type of call rather it’s ingress or egress.   SILK supports in-band Forward Error Correction (FEC), denoted by the ‘useinbandfec=1’ parameter.   Whenever a call is made peer-to- peer Skype will try to leverage the wideband codec and when the call is placed to the PSTN the narrowband codec will try to be leveraged.

 

Real Time Audio (RTA)

Microsoft created their own proprietary audio codec back in the days of Office Communicator Server (OCS 2007) and it too comes in both narrowband (8 kHz) and wideband (16 kHz). Since Office Communicator Server 2007, RTA was the primary codec for peer-to-peer calls until November 2015 Cumulative Update release for Lync 2013 when Silk became the default codec for peer-to-peer conversation with the Skype client.  RTA is now the fallback for peer-to-peer and calls to PSTN for Lync and Skype client calls.  Like the SILK codec, RTA calls that are peer-to-peer will leverage the wideband codec and in calls that go to the PSTN the narrowband will be used.

Narrowband a=rtpmap:115 x-msrta/8000

Wideband a=rtpmap:114 x-msrta/16000

 

Figure 3: RTA Codec seen in a snooper trace

 

G.722

Besides peer-to-peer calls, there is also the occasional conference calls with Lync 2013 and Skype (that was an understatement as more and more people are using conferencing with Lync and Skype server).  G.722 is used for conferencing with Lync \ Skype client.  Typically G.722 is used when bandwidth is readily available and offers a significant improvement in audio quality when compared to codecs such as G.711 or Siren.

Figure 4: G722 Codec seen in a snooper trace

G.722/2

With Lync Room system, it too has its own codec that is leveraged when it’s in use.

 

Siren

The Siren codec was developed by Polycom and used when conferencing in Live Meeting or Office Communications Server.  The fact that we don’t see Live Meeting that much anymore is a testament that people have upgraded their Microsoft platform, which is a good thing.  When there are Lync or Skype conferences to endpoints that are still on Communicator the Siren codecs provides wideband audio at a bit rate of (16 kbps) making it well suited for large conferences calls.  Reason is that Communicator client doesn’t support the G.722 codec.  In addition the Siren codec will be leveraged when the Lync or Skype client detect that the available bandwidth is too low for Call Admission Control (CAC) policies.

Last but not least the Lync 2013\ Skype client will leverage the Siren codec if it detects a network round-trip time of greater than 25ms.

 

a=rtpmap:111 SIREN/16000

 

Figure 5: G722 Codec seen in a snooper trace

 

G.711

The industry standard G.711 audio codec is used throughout the PSTN world.  When you make a cell

Phone call to another cell phone, we are using G.711 for the media.  Whenever we make calls to the

PSTN world from our Lync \ Skype client this is where G.711 comes in.  Now you say what happened to

RTA and Silk?  Those codecs don’t relay to the PSTN world; this is where the Mediation server comes

 

into the picture; for the mediation server is responsible for doing the media transcoding codec from RTA

or SILK to G.711 when we are making an outbound call to the PSTN.

 

Figure 6: G711 Codec seen in a snooper trace

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

 

These two codecs represent different calling signals; PCMU represent G.711 µ-Law used exclusively in North America and PCMA for G.711 A-Law used throughout the rest of the world. When the Lync \ Skype client decides to send calls to the Mediation server in G.711 format.  The Mediation server does not have to do any media transcoding due the media format for the intended party is already in the format that it accepts.  When media is sent to the Mediation server from the Lync \ Skype client in the format of RTA or SILK, media transcoding takes place which ends up placing additional CPU cycles on the Mediation server for that particular call.

 

Exchange UM

I figured I would throw Exchange into the conversation since we are talking about codecs.  Exchange leverages three types of codecs:

G.711 u-law

G.7.11 a-law

G.723.1
As we discussed earlier G.711 is a standard that was developed for use with audio codecs. These two codecs represent different calling signals; PCMU represent G.711 µ-Law used exclusively in North America and PCMA for G.711 A-Law used throughout the rest of the world.
The G.723.1 audio codec is mostly used in VoIP applications and requires a license to be used and is a high-quality, high-compression type of codec. A Client Access or Mailbox server and a supported VoIP gateway or IP PBX can offer both the G.711 and G.723.1 codecs.

 

Codecs, Codecs, Codecs

With voice and media being a part of our normal everyday technical lives, codecs will some become

second nature to us.  I can people talking at dinner parties now, “What type of codec do you get on your

cell Phone when you are calling others?” Ok, perhaps to not that extreme but none the less, in the world

of Lync \ Skype, codecs are leveraged any many different scenarios.

Determining How Many Front-End Servers to Deploy in Skype for Business Server 2015

I figured it was time to update this article to reflect Skype for Business Server2015, from the previous Lync Server 2013 version. For those that would like to reference the previous article I wrote, you can find it here Determining How Many Front-End Servers to Deploy in Lync Server 2013. Through many deployments of Lync Server 2013 and newly released Skype for Business Server 2015 the calculations haven’t changed all that much, but I still find plenty of confusion in the community regarding planning and sizing the appropriate amount of Front End (FE) servers for a pool deployment. So I thought it best to go ahead and give another stab at the article, but this time making it relevant to the latest version of Lync Server 2013 being Skype for Business Server 2015.

The Requirements

One of the areas that has changed from Lync Server 2013 is the maximum number of supported FE Servers in a pool has increased from 10 to 12 now with Skype for Business Server 2015. The total number of users supported per pool still stands at 80,000 users; technically it’s 79,920, but we will come back to that number a little later. So let’s begin with a few facts:

• Max users per FE server = 6,660 (you will see this number come up again)
• Max users per FE server pool = 79,920 (80,000)
• Max number of FE servers per pool = 12

Recommendations

The recommendation typically is to have no less than 3 FE servers in a pool. Now mainly we know about this from the fabric and pool quorum which is true; but another area regarding capacity numbers we will see that having at least 3 FE servers is quite more beneficial than going anything less. We know that the more the better, but anything less than 3 FE servers, really doesn’t do us much good. So for the sake of conversation, let’s say we go with 3 FE servers; let’s start doing the math.

Calculations: 3 FE servers = 19,980 (20,000); so that means each FE server will handle 6,660 users.

If we are maxing out this Skype for Business pool with 20,000 users, we are going to plan for the N-1 scenario. That is where we basing our capacity on the fact that if a single FE server goes down out of the 3 total, that the remaining 2 FE servers can handle the load of our total user population.

With that assumption this means we have 6,660 users per FE server across 3 servers; which also means 6,660 is divided into the 2 servers remaining FE servers in the event that a single server goes down. This leaves 3,330 users per FE server to the already existing 6,660 users already on the FE server which means have a total of 9,990 (10,000) users per FE server, which is over the supported Microsoft limit of 6,660 user per FE server. As a result, the decision to have only 3 FE servers in a pool if we have 19,980 (20,000) users for the pool is not a good one, considering the N-1 factor of losing a single FE server and still be in a supported state.

Mitigating the N-1 Factor

Skype For Business 2015 Routing Groups

The days of where does my user account(s) reside are a little more complex compared to the days of Lync 2010 and previous versions of Lync. Now we have terms that Lync \ Skype  Administrators need to get used to such as routing groups, widow’s fabric, replication, etc… Microsoft’s best practice recommendation of going to three servers has an impact on the decision of how users are divided among the Front End servers in the pool now. We will take a deeper look into the routing group architecture with SFB server 2015 and how a Lync Front End server failing impacts the user and the server they are homed on.
• Routing Group Architecture
• Server Outage Scenario
o Pre Front End Server Outage
o During Front End server failure
o Front End server recovery

Routing Group Architecture
In SFB 2015 is the concept of routing groups and user routing groups. A key concept to keep in mind is that users belong to User Routing Groups and Routing Groups are assigned to Front End severs. In Lync 2010 there was a hash algorithm that determined where a user would exist in the Front End pool and it wasn’t anything that an administrator could do to control it. A good thing that came out of was knowing that a user or users where always homed on a particular Front End server instead of hoping around each time they logged and being located on a different Front End server.
SFB 2015  is not using this hash algorithm to determine where a user is going to end up. When a user is provisioned in SFB 2015  immediately they are put into a particular User Routing Group. This information can be seen in the AD object attribute msRTCSIP-UserRoutingGroupId.

Per Front End server
The following scenario depicts four servers that each contains routing groups distributed among the four servers. As each user is enabled in the SFB 2015 environment they are provisioned into a user routing group. Each routing group will belong to a particular Front End server until that a server is rebooted or goes down.

During Front End server failure
SFB 2015 Front End server FE3.Contoso.com goes down due to hardware reasons. As a result, routing groups are shifted to available servers that are running. Group 1 (Copy-3) is sent to FE2.Contoso.com, Group 3 (Primary) copy is sent to FE2.Contoso.com and Group 2 (Copy-3) is sent to FE1.Contoso.com.
Because each routing group has a primary, secondary, and tertiary copy (when at least three Front End servers are deployed) there will be another Front End server for them to relocate to for any reason the routing groups primary Front End server is not available. Windows fabric will try to reallocate the user routing groups that are specified as primary to different Front End servers and not have multiple Primary routing groups contained on a single Front End server while another Front End server has none. The purpose of that is so that in the event that a Front End server goes down, limiting user disconnect. When a user routing group marked as primary is located in a routing group that is located on a Front End server goes down, the SFB client will experience a momentary disconnect. The Skype client disconnects during the reshuffling of routing groups to Front End servers and the SFB client reconnects again once the user’s secondary copy of the routing group establishes connection to another SFB Front End server.

Front End server recovery
After a SFB Front End server outage or maintenance, and the server is restored to its healthy state with Skype related services in a running state and the Skype Front End server is able to act as a SIP Registrar to users again, routing groups will shuffle once again. This time however, the routing groups don’t go back to their previous state of what was in place before the service disruption, but rather the routing groups adjust based their current state. Before the move back, we see from the previous scenario that there are no routing groups on FE3.Contoso.com and each Front End server has three routing groups located on it and at least one routing group marked as a primary.
Once FE3.Contoso.com comes back online routing groups will be shuffled again, but the primary copies of the existing user routing groups would avoid disruption by keeping the existing user routing groups marked as primary to remain in place on the current servers. Group 1 (Copy -2), Group 2 (Copy -2), Group 2 (Copy -2), all move to FE3.Contoso.com. Once the reshuffling of routing groups to available Lync Front End servers that are brought back online, we are at the new current state of routing group location for each Skype Front End server.

Getting Familiar with SFB 2015 Routing Groups
The good thing about the way this technology works is it just works. There is no need during the installation or configuration of a Front End server to ask, “Where did I store that user routing group?” Everything that we just discussed happens in the background. Windows fabric enables the possibility for all the shuffling around of the routing groups. Now what we focused on more was the process of what happens during a server failure, but the same process happens during regular maintenance of a Skype Front End server if has to be rebooted or Skype related services are stopped or restarted.

How many Skype servers can I reboot – “Pool Quorum”?

With the presence of windows fabric used in Skype for Business server 2015 in relation to pool quorum and the existence of routing group quorums, we have to be careful on how many Front-End servers we reboot at the same time as to not affect the quorum on either.   We will take a deep look at both Pool quorum in the article and areas to take into consideration when approached with doing reboots.

Pool Quorum

This area is straight forward with the manner of servers that you can reboot and not lose quorum.   We can see in figure 1 below that as long as we have “more” than the majority of the servers in the pool up and running then its fine for us to reboot.

Note: You define “up and running” by having all the Skype services running, to be more specific the RTCsrv service needs to be running on the Front – End Server.

Fig 1: Pool Quorum to be established at start up.

Total number of servers in the pool	Number of servers that must be running for the pool to be started the first time
2	1
3	3
4	3
5	4
6	5
7	5
8	6
9	7
10	8
11	9
12	10

Fig 2: Pool Quorum to be maintained once the pool is operational

Total number of servers in the pool	Number of servers that must be running for the pool to remain with pool quorum
2 (Do not advise to have just two servers in the Front-End Pool)	1
3	2
4	2 (As long as SQL Mirror is on the primary)
5	3
6	3 (As long as SQL Mirror is on the primary)
7	4
8	4 (As long as SQL Mirror is on the primary)
9	5
10	5 (As long as SQL Mirror is on the primary)
11	6
12	6 (As long as SQL Mirror is on the primary)

So, for the sake of arguments I will illustrate one more example of how this would look with the answer of if we can do a reboot on a particular pool.

Note: This is to protect pool quorum and not routing group quorum

FE 1 | FE 2 | F3 | F4 | F5 | F6 | F7 | F8 = Yes

FE 1 | FE 2 | F3 | F4 | F5 | F6 | F7 | F8 = Yes

FE 1 | FE 2 | F3 | F4 | F5 | F6 | F7 | F8 = Yes

FE 1 | FE 2 | F3 | F4 | F5 | F6 | F7 | F8 = Yes (As long as SQL Mirror is on the primary)

FE 1 | FE 2 | F3 | F4 | F5 | F6 | F7 | F8 = No

FE 1 | FE 2 | F3 | F4 | F5 | F6 | F7 | F8 = No

FE 1 | FE 2 | F3 | F4 | F5 | F6 | F7 | F8 = No

FE 1 | FE 2 | F3 | F4 | F5 | F6 | F7 | F8 = No

 

Lync 2013 – Lync Server 2013 CU1 Released!

Exchange 2010 – Working with Exmon

I ran into an issue recently where we noticed that an Exchange volume was increasing with size at an alarming rate. Digging into the matter more discovered that the log folder had, get ready for this over 700K logs. So yes do the math, with each log being 1mb in size that came to over 700GB worth of logs. So the next thing was to find out what was causing this or who was causing this.

This is where Exmon came in handy for now we could track down which mailbox (if any) was causing this. The next thing that is going to be important for you to figure out is what columns are important. Well the CPU usage which is the % of resources out of 100 that a particular user is using of the Exchange store.

The second thing that was important was the Log bytes column which tells you how many logs that particular person is generating on the Exchange server. If you find a particular user that has a out of the ordinary high count in the log bytes column you should look into it for that could be your answer.

So now that you have identified the user now what?  There are two options you can try, 1) You can try to move that user to another database and see if the issue follows the user.  2) Have the user recreate his profile.  Now why would you have the user recreate his profile?  Because a message is corrupt in his mailbox which is causing the excessive logs files in the log folder of your storage location.  Another thing you can do to confirm that you have found the problem user is have the user close out of outlook and look at Exmon again.  If you notice that the selected user drops off the CPU usage column and their Log bytes goes to O, then you might have identified your user.   What we did was look in the log folder and see if your logs stop increasing at the alarming rate once the user shuts down outlook.

Hopefully this helps you out.

Byron Spurlock

Lync Server 2010 Tool

There will be times when you need to find out which users are on which servers.  I have run into this many times and it was upsetting that I couldn’t find the information like I could in OCS 2007 R2.  So there are some cmdlets to a point that will allow you to find a single person, but what about an entire server?  This is where it gets tricky and challenging.

Here is a sample of the output of the tool where I was able to run the tool and get some data back about user’s and what their client version is.  In addition I was able to see if this person was connecting remotely, their IP address, and the server they reside on.

Now what about finding the different clients connected to the Lync servers?  The tool allows for that type reporting as well, see below.

So I will save you the suspense and tell you where to find this amazing tool….http://www.stumper66.com/software/lync.html

Hopefully this helps many of the Admins out there.

Byron Spurlock