Microsoft Teams is Part of the Default Installation for Office 365 Business Starting with 1901

In case you missed it, Skype for Business Online is no longer included in Office 365 for new customers. Instead, Microsoft Teams is now the primary client for meetings and calling in Office 365.


January Update Includes the New Skype for Business Client

Skype for Business 2015 users are getting a January 2019 update for the communication system. The update became available on January 2 and contains the usual amalgam of fixes and performance enhancements, but this particular update includes the new Skype for Business client software.

Microsoft has released an update for Microsoft Skype for Business 2015 (Lync 2013) on January 2, 2019. This update also includes the new Skype for Business client. The version number of this update is 15.0.5101.1002.

More information: January 2, 2019, update for Skype for Business 2015 (Lync 2013) (KB4461557)

Skype For Business Server 2015 Conferencing Limits

There have been many discussions within the Lync community regarding how many conferences Lync Server 2013 on-premise can support and \ or handle. Ironically these are two different topics in their own rights with regards to supported and what will technically work especially with the adjusted supported number of users per Lync 2013 Front-End server (which is 6660 users, if you didn’t know). In this article, I 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, read through the article where I discussed that information: Determining How Many Front-End Servers to Deploy in Lync Server 2013.

How the numbers add up:

So, maybe you’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? 250 users per conference is not a hard limit, but a limit that is recommended by the Microsoft Lync 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? The majority of Lync ad-hoc conferences are between 4-6 users.

Only a small percentage that is hosted on Lync 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 Lync 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 Lync Front End server pool. The Lync 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, let’s stick with the average. Keep in mind that there are some hard limits 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 beside the typical 80,000 users for not everybody’s organizations has that many users, you can see how the numbers turn out. For the example, we’ll use 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.

Now 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. That gives us (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 Lync 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 Lync Server 2013 can handle which is approximately 83 concurrent conferences averaging 4-6 users per conference.
Lync 2013 Conferencing Reaching Capacity
Lync 2013 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 Lync 2013).

The key concept to remember is Lync Server 2013 can hold many different types of conferences and users such as remote, federated, and even anonymous ones as well. Scaling Lync 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 number of users and Front End servers that are ultimately deployed for the Lync pool. There’s talk with future editions of Lync having the ability to host large standing meetings that would scale far beyond what Lync is handling today, but that waits to be seen.

Skype for Business 2015 – Confirmation of Pool Failover and Failback

One of the things during the midst of either a disaster recovery exercise or performing the real thing is confirmation if you have truly failed over and / or failed back.   Running the cmdlet Get-CsUserPoolinfo username does not really tell you, that you have failed over and or failed back. In addition, once you have run the Invoke-CsPoolFailover and Invoke-CsPoolFailback cmdlets you can dig around and find the cmdlet logs to see what occurred through the process. But what about a simple notification that you have failed over or failed back and the pool is functioning well?  Without such notification, we are left wondering, “How do I truly know if I failed over or failed back with my Skype pool?”

In this article, we will look at the following areas:

  • Get-CsUserPoolinfo
  • Failover
  • Failback



The Skype cmdlet Get-CsUserPoolinfocan be leveraged to find out what pool a user belongs to; in addition to finding out what are the secondary and tertiary front-end servers for the specified user.  If we continue to look further, we can also see the backup pool information for the user along with the primary, secondary and tertiary front-end servers for the paired pool as well.

While this information is useful to us, during the mist of a failover, the information does not change.  You will not see anything here that tells you, “You are now registered to the backup pool.”   Yes, you could look at the configuration information of your Skype client, but running the Get-CsUserPoolinfo cmdletwill not tell you definitely, where you are located at that exact moment.


Figure 1:



Now I am going to assume that you have just performed a failover to your paired pool, someone is going to eventually ask you one, if not all of the following questions:

1) Did you failover the affected pool?

2) Was it successful?

3) How can you tell?

I will not bring up in conversation about the Central Management Store (CMS); I will save that for a later article. We will just assume that this pool does not contain the CMS and you are just performing a failover. Besides looking at the output of the log file that will be generated when you run the Skype cmdlet Invoke-CsPoolFailover -PoolFqdn -DisasterMode –Verbose.  The event ID you are looking for to get confirmation that you did indeed perform the failover and it was successful is event ID 32155 in the Lync event logs. Once identified you will see that the event notifies you that the pool failover is complete as seen in figure 2 below.


Figure 2: Pool Failover Complete



Now just as we have performed the failover and have received confirmation, we will want to do the same thing for the failback.   Soon as your affected datacenter becomes stable and online again, you may be asked to failback the users that were in the affected pool.  Once you have performed the failback by running the Skype cmdlet Invoke-CsPoolFailback -PoolFqdn -DisasterMode –Verboseyou are going to ask yourself these questions or someone else is going to ask you the following questions:

1) Did you failback the pool?

2) Was it successful?

3) How can you tell?

The event ID you are looking for to get confirmation that you did indeed perform the failback and it was successful is event ID 32157 in the Lync event logs.  Once identified you will see that the event notifies you that the pool failback was complete as seen in figure 3 below.

Figure 3: Pool Failback Complete


A little confirmation is always nice; At the end of the day, failing over a pool and then failing it back can be a little nerve-racking, especially when under pressure, not matter if you have 20,000 users on the pool or a few hundred.   What we are looking for at the end, is confirmation that the procedure we just went through with either the Invoke-CsPoolFailoverorInvoke-CsPoolFailback cmdletwas successful and our users are safe and sound in their respective pool we were trying to locate them on.

Looking for an awesome, no-nonsense technical conference for IT Pros, Developers, and DevOps? IT/Dev Connections kicks off in Dallas, Texas in 2018!

IT/Dev Connections

Skype Business Server 2015: Difference Between Active and Concurrent Users

There are two key words when working with Skype for Business server 2015 that you should be aware of and those are: Active and Concurrent. These particular words will come up quite a bit when you are working with design, capacity planning, or troubleshooting an issue. At the end of the day, regardless of the scenario you are working with, its important to understand what these words mean and how to use them accordingly.

What is considered Active?

Active can be considered as what is happening at an exact moment in time; such as “How many active Peer-to-Peer or Skype to PSTN calls are taking place right now?”   In this instance, this would mean that calls are actually taking place at that exact moment.   Another scenario is “How many active users of Enterprise voice are enabled for your environment?”   This might be confusing because depending on what sort of results the person who is asking the question is looking for the question could be interpreted in a few ways.

The last question could be interpreted as the following:

  • How many people are enabled for Enterprise voice?
  • How many people are actively using Enterprise voice in the environment?

This leads to the usage report example below.

Figure 1: Usage Report

This report shows how many people performed an action of one of the key modalities who made an IM, Conference, or Call.   There is a difference between being logged on and not doing anything versus logged in and performing an action.  You could say that it depends on the question that is being asked again.

Figure 1 displays the following information:

Total Logons– Total logons (rather, the users did anything or not once logged in) internal and external to the environment.   This could mean that a user signed in and out ten times that single day and it would be counted in the total logon value.

Internal Logons– Users who signed in on the internal network or through a VPN connection. Unfortunately a single user can sign in multiple times and it counts in this value.

External Logons – Users who signed in from a remote connection (not VPN or internal network). Unfortunately a single user can sign in multiple times and it counts in this value.

Unique logon users– Pertains to unique individual people that logged into the environment.  They don’thave to necessarily do anything once logged in.

Unique active users– Pertains to unique individual people that logged into the environment and performed an action stated above such as IM, Conference, or Call.

What is considered Concurrent?  Here is an example of something that I run into all the time when working through the design of the Front End servers and Edge servers.  Concurrent usage relates to the number of users that will be performing a task or service for the particular role at the same time.  The edge server can handle up to 15,000 remote SIP connections concurrently.  This mean that 15,000 users can be remote and the max supported connections for SIP that can be handled is 15,000 concurrent connections per Edge server. In my opinion that is a lot of connections.

Then, add to the equation that most deployments today consist of two edge servers for resiliency.  So that means that the edge pool (if it consist of two edge servers) can handle 30,000 concurrent SIP connections.  By definition, these numbers assume that the 15,000 connections have the capability to perform an action. So, in reality they are not talking about 15,000 connections that are just sitting idle, but rather assuming that those 15,000 connections are idle and ready to perform an action at any time. These are considered an active SIP connection.

Understand the Question

To be successful, you need to understand the question that is being asked and in what context the person is asking it.  If all else fells you can use this article as a baseline to assist others with understanding the difference between Active and Concurrent.

Skype for Business Server 2015 Codecs

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, you can end up changing your S4BS design infrastructure and can also help you plan going ahead 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


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.


      a=rtpmap:103 SILK/8000

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


      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.

      Narrowbanda=rtpmap:115 x-msrta/8000

      Widebanda=rtpmap:114 x-msrta/16000

Figure 3: RTA Codec seen in a snooper trace


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



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


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


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; PCMUrepresent 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

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.

How Many Skype Front-End Servers Can I Reboot in a “Routing Group” Quorum?

The routing group quorum is a  particularly interesting one because its what is used to decide if a user will see the message “Limited Functionality” message on their Skype client when a pool failover is “NOT” taking place.   We can use the example that we have 12 Front – End servers in a pool.    The fact that our user routing group could actually exist on any three of the twelve Front-End servers is where this becomes interesting.

F1| F2F3 F4| F5F6 | F7F8 F9  | F10F11 | F12

I’ve use color-coded numbers in the scenario above to show a 12 server Front – End Pool and how there could be various user accounts that are a part of a routing group that sits on various servers.  For the sake of the conversation, imagine that my routing group where my Skype user account resides sits hypothetically on servers F3, F6, and F8 which are the servers that are colored black.

If I were to reboot nodes F1 and F2 at the same time it wouldn’t have any effect on my Skype account.  If I were to reboot nodes F1, F2, and F3 at the same time my routing group wouldn’t be affected (remember, my routing group is marked by the black servers) either.  In addition, rebooting servers F1-F3 wouldn’t have any affect of the pool quorum either due to the fact that I would still have 9 out of the 12 nodes available in the quorum which is more than the majority.

Rebooting nodes F1, F2, F3, and F4 at the same time would be a risky move.   I wouldn’t be affecting the pool quorum due the fact that I still have the majority nodes up and running with 8 out of the 12 nodes up and running.   However, by doing this I run the risk of losing routing group quorum for particular Skype accounts which could be assigned to those servers that are rebooted at the same time.

The routing groups in question that I could lose would be the Red routing groups because they sit on nodes F1 and F4, which means the only remaining server node that the Red routing groups has still standing would be on node F9.   With the loss of 2 out of 3 replicas a routing group goes into “Limited Functionality” mode and the client is in a degraded state.

Lesson learned from this: We should now understand why Microsoft’s suggested approach is to reboot Skype Front – End servers one at a time to avoid any potential feature functionality loss for Skype users even if it doesn’t impact the Pool quorum itself.

How Many Front-End 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 about how many Front-End servers are rebooted at the same time as to not affect the quorum on any of them. Here we’ll take a look at both Pool and Routing Group quorum and areas to take into consideration when reboots are requested or required.

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 Yes or No,  if should do a reboot on a particular pool.

Note: This is to protect pool quorum and not routing group quorum; Each bold item represents that server being rebooted out of the pool.

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 | F 3 | 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

Skype for Business 2015 – Even or Odd Number of Front End servers

Lync server 2013 started the concept of needing a minimum of three Front End (FE) servers to make a pool and routing group quorum. Over the course of versions from Lync 2013 to Skype 2015, stories have changed (apparently), not really quite sure why.  I have heard talks of needing to have an odd number of servers in a Lync 2013 or Skype environment, which is not true.     The specific need to have three for FE servers came about due to how the Windows fabric works and the necessity to make quorum; however needing to stay at an odd number of FE servers is not true.  Microsoft has stated that the maximum number of FE servers in a pool is 12.   First off, that is not an odd number, in addition we can have anywhere from 3-12 FE servers in a pool to make pool or routing group quorum.

The only difference with having an even number of FE servers in a pool (4, 6, 8, 10, or 12) is that the SQL backend server comes into play to be the deciding factor for “pool” quorum decisions.  If you have an odd number of servers in the pool (3, 5, 7, 9, or 11) then SQL is already coming into play as a voter in those scenarios.

What makes a Pool Quorum?

SQL server when it comes to being a tiebreaker or decision maker for an even number of FE servers in a pool is not a difficult job; its main function in that scenario is to be ready if called upon.  The perfect way to explain this would be to understand what makes quorum.   The chart below explains from the pool point of view how many FE servers are need to make quorum.


Total number of Front End Servers in the pool Number of servers that must be running for pool to be functional
2 1
3-4 Any 2
5-6 Any 3
7 Any 4
8-9 Any 4 of the first 7 servers
10-12 Any 5 of the first 9 servers


What makes a Routing Group Quorum?

A routing group quorum almost follows the same line of thought as a pool quorum, one the key differences is the need to have three replicas (copies) of data and nothing more.   What we have now since Lync 2013 and Skype 2015 are routing groups.  A user is assigned to a routing group once their Skype account is created; which routing group they belong to is beyond the control of the administrator.  We have what we consider a primary routing group for a user and two secondary copies.   Routing groups prefer to have three copies and if they don’t have three the users routing group is still functional.  However if a user where to fall to a single routing group then the user would be in “Limited Functionality Mode”.   This could occur to rebooting too many FE servers in a single pool at the same time.


Where does SQL come into play?

Let us take a scenario where we have three FE servers in a pool, the SQL server does not come in to play then. Why not?  Well we have an odd number of FE servers so if one FE server goes down we still have quorum with the two remaining FE servers.  If the second FE server goes down then we lost quorum.   The important factor here is that SQL server is a voter in the scenario.

Let us take another example where we have four FE servers in a pool and lost one.  Even with losing a single FE server, we still have quorum, but if we lost two then we do not have quorum, for quorum is majority and we do not have that.   That is where the SQL server comes into play for it is the decision maker or tiebreaker.

So in second example where we had four FE servers,  if we lose two FE servers and have 2 FE servers left then SQL is a decision maker and has a vote and it states that its vote counts and now there are 3 voters in the pool.  With three votes out of five (recall we lost 2 FE servers) then majority rules and we still have pool quorum.


Let me see this “Fabric”

During installation, Windows Fabric creates a local configuration file at C:\ProgramData\Windows Fabric\<>\Fabric\ClusterManifest.current.xml.  This is a location change from Lync Server 2013 which stored the file at C:\Program Files\Windows Fabric\bin\ClusterManifest.current.xml.






        <Node NodeName=”FE01.CONTOSO.COM” IPAddressOrFQDN=”” IsSeedNode=”true” NodeTypeRef=”FrontEndNode” FaultDomain=”FD:/FAULTDOMAIN1″ UpgradeDomain=”UD:/UPGRADEDOMAIN1″ />


        <Node NodeName=” FE02.CONTOSO.COM ” IPAddressOrFQDN=”” IsSeedNode=”true” NodeTypeRef=”FrontEndNode” FaultDomain=”FD:/FAULTDOMAIN2″ UpgradeDomain=”UD:/UPGRADEDOMAIN2″ />


        <Node NodeName=” FE03.CONTOSO.COM ” IPAddressOrFQDN=” ” IsSeedNode=”true” NodeTypeRef=”FrontEndNode” FaultDomain=”FD:/FAULTDOMAIN3″ UpgradeDomain=”UD:/UPGRADEDOMAIN3″ />








Odd or Even Shouldn’t Matter

At the end of the day, whether I have three FE servers of eight should not matter if I want to go with odd or even number of servers in my pool, but rather based on capacity reasons and justifications.   The more we deal with the Skype FE pool the better understanding many of us who skipped the clustering class began to understand that the underlying layer of “Fabric” and how it relates to Skype is a core Windows concept of how clustering is and what makes up a quorum.  So the next time someone mentions clustering with regards to Windows, take head for you don’t know down the road the next application that could use some of those important key concepts.

Looking for an awesome, no-nonsense technical conference for IT Pros, Developers, and DevOps? IT/Dev Connections kicks off in Dallas, Texas in 2018!

IT/Dev Connections

Office 2019 – Including Exchange, SharePoint – Coming in Mid-2018

At Microsoft Ignite today, Microsoft has announced that it will deliver Office 2019 next year. Some have speculated that the company would begin to deliver only Office 365 versions of its collaborative suite, but the company today stated that previews of the products will be ready by the middle of 2018.

Products include both apps and servers:

  • Word
  • Excel
  • PowerPoint
  • Outlook
  • Exchange
  • SharePoint
  • Skype for Business


Additionally, though an update for Skype for Business will be included, Microsoft confirmed on Monday that its Teams product will eventually replace Skype for Business completely.


Looking for an awesome, no-nonsense technical conference for IT Pros, Developers, and DevOps? IT/Dev Connections kicks off in San Francisco in 2017!

IT/Dev Connections

Microsoft Confirms Teams Product Will Eventually Replace Skype for Business

Today at its Enterprise product announcement conference, Ignite, Microsoft finally confirmed officially that it will be replacing Skype for Business with its newest Office 365 gem, Teams.

For customers to prepare for the change, Microsoft will not be renaming Skype for Business, as some have suggested, but instead will be promoting Teams as the preferred communication tool for enterprise licensees.  Skype for Business will still exist – and even get an update next year – but Microsoft will be suggesting that companies move to Teams. Teams will also be architected to work with Skype for Business to give customers time to make the switch.


Looking for an awesome, no-nonsense technical conference for IT Pros, Developers, and DevOps? IT/Dev Connections kicks off in San Francisco in 2017!

IT/Dev Connections

Lenovo Uses Microsoft Ignite to Announce a Skype for Business Hub

With the product name “Skype for Business” in question these days (apparently Microsoft will rename the product), its interesting that a cooperation between Microsoft and Lenovo has produced hardware that is being promoted as a hub for Skype for Business in the boardroom.

Today Lenovo has announced the ThinkSmart Hub 500 which is a touchscreen kiosk that gives customers a single an accessible console to kick-off and manage meetings. Here’s what the system contains:

  • Purpose-built Skype Room System
  • All-in-One Design Compute Power, Display and Audio
  • 11.6″ Rotatable Display and compact footprint to fit everywhere
  • 360 Degree LED status indicator
  • Dolby Audio Premium
  • Secure Cable Management
  • Runs Microsoft Windows IoT Enterprise


Details on the product page:

You can also use the product page to be notified when the system will be available. Lenovo says pricing and availability will be announced sometime in the first quarter of 2018.

Looking for an awesome, no-nonsense technical conference for IT Pros, Developers, and DevOps? IT/Dev Connections kicks off in San Francisco in 2017!

IT/Dev Connections