Tag: Edge Server

How the Load Balancer Fits into Skype for Business

Our fourth entry in the “How It Fits” series is…the Load Balancer!

Load balancers show up in every level of a Skype for Business deployment. They’re an integral component of effective Skype for Business Online tenants as well.

If a load balancer does its job right, it’s pretty much invisible. If it doesn’t, it’s a loud and persistent pain. Which it is all depends on your configuration. As such, you’re most likely to work with a load balancer when first deploying Skype for Business.

This post is meant as an overarching take on the load balancer’s function and value. If you’re looking at a new Skype for Business deployment, on-prem or hybrid, this is a quick read that could help a lot!

The Load Balancer’s Primary Role

A load balancer distributes traffic among servers in a pool. In Skype for Business, this means it distributes traffic between role-based server pools. For example, between two Front End Servers.

It’s similar in some ways to a Reverse Proxy. (Some hardware load balancers even include reverse proxy functionality.) But instead of worrying about authenticating traffic from outside the network, it focuses on optimal traffic management inside the network.

Why use load balancing in the first place?Load Balancing Diagram from F5

  • Bolsters reliability. The load balancer helps prevent any one server from becoming overwhelmed.
  • Increases overall Skype for Business stability. Smart traffic management helps avoid traffic bottlenecks.
  • Some Skype for Business services require load balancing to function (e.g. managing HTTP traffic).

Main Components of a Load Balancer

At its core, a load balancer consists of:

  • A Distribution algorithm, and
  • A server pool monitor/health check

The distribution algorithm determines to which server it should send traffic requests. The server pool monitor, well, monitors the assigned server pool’s health and traffic responses.

What kind of traffic are we talking about? All kinds: HTTP/HTTPS, SIP, TCP, UDP. Basically, if you use server pools for any of the Skype4B Server Roles, you should use a load balancer for each.

Other Servers a Load Balancer Communicates With

In Skype for Business, you can load balance any Server Role which has (or can have) multiple servers in a pool. That includes:

  1. Edge Server
  2. Front End Server
  3. Director
  4. Office Web Apps Server

Load Balancers must communicate not only with the servers they’re balancing, but with the servers sending traffic to them. That means they’ll talk with the Mediation Server, PSTN Gateways, and our last “How it Fits” role, the Reverse Proxy.

What about Office 365? If you’re running a hybrid deployment, you’ll need load balancing on the on-prem side. From Plan for Network Devices that Connect to Office 365 Services:

Your organization needs to use a hardware load balancer (HLB) or a Network Load Balancing (NLB) solution to distribute requests to your Active Directory Federation Services (AD FS) servers and/or your Exchange hybrid servers.

In other words, load balancing between Office 365’s servers and your network!

What Kind of Load Balancer Should You Use?

Two types of load balancing exist in Skype for Business.

  1. DNS load balancing, and
  2. Hardware load balancing

This is an important distinction. It’s also the source of most load balancing grief.

DNS Load Balancing:
This is more a technique than a device. It involves mapping server pool names to not one, but a set of IP addresses in DNS.

Let’s say you have a Front End pool named “Headquarters.” The Headquarters pool has three IP addresses mapped to it –,, and

When your Skype for Business client tries to connect to “Headquarters,” DNS sends it all three IPs. The client tries connecting to the first IP, But this IP already has another client connected and cannot respond. So the client tries That works.

Connections stable. Traffic load balanced.

DNS Load Balancing – Microsoft Docs

Hardware Load Balancers:
A hardware load balancer is a dedicated device which distributes traffic requests to a server pool. I think of these like a “Traffic Cop” inside your network.

We use an F5 hardware load balancer for our Skype for Business Server. Cost us a bit, but wow did it help with call quality!

Since hardware load balancers actively listen to incoming & outgoing traffic, they can mitigate traffic bottlenecks. Preventing call drops, static, and external connection troubles.


When setting up load balancing in your topology, keep these restrictions in mind:

  • If your Edge pool uses load balancing, the internal Edge interface and external Edge interface must use the same type. Can’t use DNS load balancing on one, and hardware on the other. You’ll experience some serious traffic errors!
  • Some traffic types require a hardware load balancer (e.g. HTTP traffic). DNS load balancing does not work with client-to-server web traffic either.

Our experience confirms these restrictions. In Skype for Business Server’s early days, we observed that combining both load balancing types in one deployment caused havoc. Inconsistent delays, strange errors with no apparent cause, bottlenecks, etc. When we standardized on one load balancing type topology-wide, these issues evaporated.

Traffic Load Balancing

Traffic, nice and organized.
Photo by Fahrul Azmi on Unsplash.

Here’s a nice setup/overview video from A10 Networks if you’d like more.

Load Balancers Reduce TCO By Easing the Burden on Skyep4B Server Pools

Which load balancing method should you choose? There’s no universal standard. But we go by this rule of thumb: The larger the deployment, the more a hardware load balancer is necessary. They are more powerful, more intelligent, and more reliable.

It does add to up-front deployment cost. But it reduces TCO. Once load balancing is in place, configured, and running properly, it helps the Server Roles function at peak. Even (especially) under heavy load.

What kind of load balancing do you run in your Skype for Business topology?


How the Reverse Proxy Fits into Skype for Business

You asked for more “How It Fits” posts last year, and I’m happy to oblige. Today we’re discussing…the Reverse Proxy server!

Reverse Proxy is also part of the Skype for Business perimeter network, like Edge Server. The two act in concert, in fact, which made it an easy second choice for this series.

Now, one important thing: Reverse Proxy is NOT an official Skype for Business Server Role. You’ll need another device/appliance to serve as your Reverse Proxy. Fortunately, many good options exist; Microsoft has provided a list of reverse proxy servers to help. We’ve tried the MS Web Application Proxy and F5’s BIG-IP. Both worked very well for our purposes.

The Reverse Proxy’s Primary Role

A Reverse Proxy server facilitates external user access to some Skype4B tools. Like the Edge Server, it aids users outside the internal network: mobile users, federated users (e.g. partners, vendors), and customers.

How? It works by publishing some Skype for Business services to the public Internet, and regulating access to them from outside the perimeter network. I’ve listed which services in the next section.

Main Functions of a Reverse Proxy Server

Here’s the list of Reverse Proxy functions in a Skype for Business Server deployment. You’ll see that they all deal with external users, be they permanently remote or a standard user out of the office.

  • Connect to meetings or dial-in conferences using simple URLs (e.g., “meet.yourdomain.com”).
  • Download meeting content.
  • Expand distribution groups.
  • Get user-based certificates for client certificate based authentication. In other words, authorize some mobile clients to access the Skype for Business Server.
  • Download files from the Address Book Server, or to submit queries to the Address Book Web Query service.
  • Obtain updates to client and device software.
  • Allows mobile devices to automatically discover the Front End Servers offering mobility services (e.g., “lyncdiscover.yourdomain.com”).
  • Enables push notifications from Office 365 to mobile devices.

Some IT admins would argue that a Reverse Proxy’s final function is to frustrate them! That’s because it handles switching between ports on the same IP address, when traffic moves from the public Internet to the internal network. Here’s an example image.

Reverse Proxy Diagram

Image courtesy of Perficient Blogs.

You see the Reverse Proxy translating from TCP port 80 facing external, to TCP port 8080 facing internal. Same IP, different ports. Helps with security…but it’s a pain on a certification exam!

Other Servers Reverse Proxy Communicates With

Front End Server/Front End Pool. The Reverse Proxy communicates primarily with your Front End Server. It is publishing some of the Front End’s services out to the public Internet, and funneling in requests from external users to use those services.

Director/Director Pool. If your Skype for Business topology has a Director, the Reverse Proxy will publish its external Web services (e.g. Autodiscover) as well.

mobile user photo

Someone got locked out while outside the network!
Photo by GirlieMac

Edge Server. The Reverse Proxy also sits in the perimeter network, between the external and internal DMZs. It and the Edge Server have distinct roles, but the two must act in concert.

Without the Edge Server authenticating some external users, the Reverse Proxy could accidentally provide a Skype4B mobile service to the wrong user (or not at all!).

Load Balancer. Depending on where you use load balancing, the Reverse Proxy may need to talk to yours. Otherwise it could deprive some external users of the access they need. I’ll address this in the Load Balancers post.

Firewall. Since the Reverse Proxy uses two sets of ports matched to IP addresses, your firewall needs to play nice with it. Otherwise you’ll have some very locked-out (and upset) users outside the office!

Is One Reverse Proxy Server Enough?

In most cases, one Reverse Proxy per Skype for Business topology is enough. I checked with a co-worker regarding one hybrid deployment we did early last year. This customer has satellite offices and job site trailers…their external users easily outnumber internal users about 4 to 1. Yet they only have one Reverse Proxy, and report no bandwidth issues or delays.

That said, I can think of two situations where two or more Reverse Proxies may make sense:

  1. A high-availability global on-prem deployment.
  2. More than one perimeter network exists in your organization.

Reverse Proxy is What Makes Skype Meetings Happen Anywhere

Since the Reverse Proxy is not a Skype4B Server Role, I’m not sure what will happen to it with the Teams merger. It could continue to provide the same external publishing & regulation function as it does now. Teams would certainly need such services for guest users and remote workers. I’ll keep it in mind as we hear more about Teams.

Additional Reverse Proxy Resources:
Reverse Proxy 101 – Perficient Blogs
Edge Server System Requirements in Skype for Business Server 2015 – TechNet
Plan for Mobility for Skype for Business Server 2015 – TechNet

In the next “How it Fits” post I’ll address Load Balancers. What Skype for Business/Teams tool should I do after that? Please comment your choice!


How the Edge Server Fits into Skype for Business

“What’s the Edge Server do?”

One of our team members fielded this question while on-site the other day. He’d just finished describing the Skype for Business topology we proposed for the customer’s business (hybrid deployment, across 3 offices). One of the users piped up right afterward.

Now to his credit, my co-worker answered the question immediately, and (from his impressions) to the user’s satisfaction. He’d mentioned it to me only in passing. But, me being me, I seized on it as a good post idea.

We’re all about educating users here. In case another user at that customer site, or a future customer’s, still has questions? Let’s take a detailed look at what goes into an Edge Server.

(Please note: We will not discuss Reverse Proxies or Load Balancers in this post. If you want to hear more about these, I’m happy to dedicate a post to each. Please comment if so.)

The Edge Server’s Primary Role

The Edge Server grants Skype for Business access to users outside the internal network. These are mobile users, remote users, federated users (e.g. partners, vendors), and sometimes even customers.

Without the Edge Server, these external users can’t send or receive IM, take phone calls, or join in Online Meetings.

How does it do that? Essentially, by acting as an IP intermediary. It translates external IP addresses into internal IP addresses to facilitate the external user connections. As such, the Edge will need routable public IPs assigned to it (or non-routable private IPs, if you use NAT).

Skype for Business Servers

That’s our Edge Server right there. No, that one.

Main Components of an Edge Server

Each Edge Server runs four main services.

  1. Access Edge. This service gives users a trusted connection for inbound & outbound SIP traffic. Like a private road through the Internet.
  2. Web Conferencing Edge. This service allows an external user to join Online Meetings running on your Skype for Business Server. A virtual “ticket to the show,” as it were.
  3. A/V Edge. This service enables audio/video, application sharing, and file transfer for external users while in said Meetings. That way you’re not missing out on any parts of the conversation.
  4. XMPP Proxy. Finally, this service sends & receives XMPP messages (eXtensible Messaging and Presence Protocol) from federated partners. It makes sure external users can still talk with federated users.
    • NOTE: This is not required for all Edge Servers. You may need an XMPP gateway running on the Front End as well.

Other Servers Edge Communicates With

Front End. Obviously, the Edge Server will communicate the most with the Front End (Standard or Enterprise Edition). Otherwise external user connections would just vanish!

Office 365 Cloud. If you’re running a hybrid configuration, the Edge Server will have to communicate with Office 365 servers. Edge will treat the Office 365 tenant as a federated partner, so make sure SIP Federation is enabled.

Exchange UM Server. Edge must communicate with Unified Messaging, in order for external users to get their voicemails.

Persistent Chat Server. For topologies supporting Persistent Chat, the Edge Server will need to communicate with its server. Access Edge needs to facilitate external users joining chats.

Reverse Proxy, Firewall, Load Balancer. Together with the Edge Server, these servers/tools create the “perimeter network.” They protect your network from unauthorized access (e.g. malware), while letting authenticated users through.

Edge Server Functionality

A Microsoft diagram illustrating some of the Edge Server’s functions. It keeps busy. Image courtesy of Microsoft.com.

Is One Edge Server Enough?

For most offices, yes. One Edge Server can handle 12,000 concurrent users. But for high-availability topologies, you can collocate Edge Servers.

Reminder: Don’t Forget about Mobile User Access

When configuring an Edge Server, make sure you’ve addressed mobile users. We’ve had to reconfigure Edge Servers which were set up properly for most remote users…but mobile apps didn’t have access the moment they left the office.

Every Time You Use Skype for Business on the Road, Thank Your Edge Server

Among our customers, IM is the most-used Skype for Business tool benefiting from the Edge Server. But inviting customers or vendors into an Online Meeting is the most valued benefit.

“You mean they can actually join the meeting too? Just like each of us?” Yes, they sure can! Thanks to the Edge Server. Show it a little love.

(I’m not actually sure how you’d do that. Do servers appreciate it when you clean their fans?)

Did you have a question about what Edge Servers do, or how they do it? Please comment or email your thoughts.


How to Add DNS Suffixes to Edge Server – and Why Lync Needs Them

I had a post scheduled talking about eDiscovery. But I got an email from Larry, our senior Lync team member, describing a Lync troubleshooting project he’d just finished for a client.

Well, we just have to document that one for our readers, don’t we?

The Scenario: Everything’s Installed, But is Edge Configured Properly?

Larry was on-site with a client who had some Lync Server 2013 components already installed. However their Edge Server was not communicating with the Front End. What was the problem?

He found no issues on the Front End Server itself. (FYI: Lync Server 2013 Enterprise Edition, Enterprise Voice and Monitoring roles installed.)

So he looked at the Edge Server. It must have a configuration issue, but what kind? He logged directly into the Edge Server and looked through its properties. The Lync Server software was up & running, DNS names were in place…

Wait a second. The Edge Server had a local name only (“companydomain”). What about its suffix?

The DNS Suffix: Necessary for Lync Server Topology

A DNS suffix is required for Edge Servers to communicate with the rest of Lync Server. Topology Builder requires a FQDN (Fully Qualified Domain Name), but by default Edge Servers use short machine names.

Configure the DNS Suffix for Edge Servers – TechNet

The client’s Edge did not have a DNS suffix. This must be why the topology couldn’t communicate with it. We had to add the suffix.

Here are the steps to adding a DNS suffix on an Edge Server:

  1. On the Edge Server, click Start, right-click Computer, and select Properties.
  2. Under “Computer Name, Domain, and Workgroup” settings, click Change Settings.
  3. On the Computer Name tab, click Change.
  4. You should see the “Computer Name/Domain Changes” screen. Click the More… button.
  5. The “DNS Suffix and NetBIOS Computer Name” window will pop up. In the Primary DNS suffix of this computer field, type the name of your internal domain (for example, lync.companydomain.com).
  6. Click OK to close the windows.
  7. Restart the computer.

DNS Suffix

(Apologies for the blurring. I used a testing server to create the screenshot, so there’s little risk of hacking. But, better safe than sorry!)

*Important Note: Make sure you restart the server before going any further! Larry did not immediately restart after implementing the DNS suffix (the client asked a question). It took him a moment to realize that THAT’S why he still had communication issues.

Add DNS Records for Edge Lookups

Once the DNS suffix had been added & Edge Server restarted, Larry was able to add the Edge to the existing Lync topology. Time for configuring some DNS records.

DNS records are required for external DNS lookups, perimeter networks and internal client lookups. Some of this was already in place, but Larry had to reconfigure so Edge was fully supported in the Lync architecture.

Here are details on DNS for Edge Servers in Lync Server 2013: Configure DNS for Edge Support in Lync Server 2013 – TechNet

The steps to creating a DNS SRV record:

  1. On the DNS server, click Start, & open Control Panel.
  2. Click Administrative Tools, and then click DNS.
  3. In the console tree for your SIP domain, expand the “Forward Lookup Zones”. Right-click the domain your Lync Server 2013 uses.
  4. Click Other New Records.
  5. Under “Select a Resource Record Type”, type Service Location (SRV), and then click Create Record.
  6. Provide the necessary information to populate the DNS SRV record.

Then, to create a DNS A record:

  1. Follow Steps 1-3 above to reach the Forward Lookup Zones on your SIP domain.
  2. Click New Host (A).
  3. Provide the necessary information for the new DNS record.

Lo and behold, communication worked between Edge and Front End! The client was happy.

DNS Suffix: A Small Addition, but Critical to Edge Communications

If you have trouble with your Edge Servers not cooperating with the Front End, make sure they have FQDNs in place. Otherwise DNS won’t understand proper lookups, and your topology won’t function.

Have you encountered a DNS error with your Edge Server? If so, please comment or email your story in. Did you solve it? Was it a DNS suffix issue, or something else? I’d love to hear about it.

Speaking of hearing about it, I’m a little behind on responding to reader support questions. Not ignoring anyone, I promise. Just wanted to reassure everyone.

Join us here again next week for that discussion on eDiscovery.


Follow Along With the Lync January 2014 Update Process

Before I get into today’s post, I want to point out – we now have an email subscription option for the Lync Insider! The latest posts delivered to your inbox, every Friday. Enter your name and email in the boxes to the right.


We installed a series of Lync updates last week. The full list is here:
Updates for Lync Server 2013: January 2014

As you’ll see, the updates included patches to Core Components, Conferencing, Front End Servers, Mediation and several others. Like many other Microsoft support packages, it also includes updates previously released for completion & dependencies. Which is helpful if you haven’t already done the July or February 2013 updates.

I don’t have to tell you how important it is to keep your Lync Server up-to-date. (At least I hope not!)

So why a post on following an update process? Isn’t it pretty much self-explanatory?

While there are instructions – and we should all follow them – it’s useful to have perspective on people actually doing the process. There may be snags you encounter. Steps you don’t need to take. Alternate ways to install components.

And if nothing else, having our process laid out here can provide you, our readers, with another reference point.

So with all that in mind, here’s how we installed the January 2014 Lync Updates.

The Updating Process: Prep

Log onto your Lync Server as Administrator.
From here, go to the Update page. Download the updates manually. Microsoft offers them as separate files, so you can install the updates you need. Most are in .msp format. We grabbed all of them, just in case.

Leave the Updates page open, so you’ll have instructions & details handy.

(One point to make here: We did not always specify certain criteria. The reason was, not doing so encourages the servers to put existing values into the updates. For example, auto-detecting our SQL Server. You’ll see this later.)

At this point I need to clarify something on the Update page. There are two install processes – one for Standard Edition, one for Enterprise Edition. They are clearly marked. Use the set which corresponds to your Lync Server!

(We followed the Standard Edition instructions below.)

The Updating Process: Running Step by Step

(Important Note! Make sure this takes place during a maintenance window. The Update Installer WILL bring down Lync services while it works.)

The update process begins at Step 1, with running the LyncServerUpdateInstaller.exe file on the Front End. Run it directly, not through Management Shell. And make sure to run it as Administrator if you have UAC on. Otherwise it will error out.

The installer will examine your system for its patch status. It then shows you which updates are needed with red icons. If an update has a green check icon, it’s up-to-date and will not be messed with.

The Update Installer, when you tell it OK, will apply the necessary updates to your Front End Server. The easy part. Sit back and relax a moment.

Once the installer is done, reboot the Lync Server.

Step 2 is to apply database updates. The SQL database will drop as you do. Once the server is back up, you’ll need to update your backend database via the Management Shell.

The cmdlet to use for this in Standard Edition is:
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SE.FQDN -Verbose

Enter the SQL Server’s FQDN where you see SE.FQDN in the cmdlet above. If you don’t remember it, open up Topology Builder. (We’ll reference Topology Builder in a moment anyway.)

The backend databases updated without a hitch for us. I hope they do as well for you.

Next, the Persistent Chat databases. Run the same cmdlet again, with some different parameters:
Install-CsDatabase -DatabaseType PersistentChat -SqlServerFqdn PChatBE.fqdn -SqlInstanceName DBInstance -Verbose

Remember what I said earlier about letting servers fill in values? You can try this here. Try leaving the PChatBE.FQDN value blank and see if it works. Same with the DBInstance name.

Another thing to note: When we first ran this cmdlet, it failed. We took the SQLInstance name off, and it worked by auto-detection.
And finally for Step 2, we re-ran the cmdlet for the Monitoring store.
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SQLServer.FQDN -Verbose

Placing the Monitoring Server’s FQDN in for SQLServer.FQDN. (If you need to recall the Monitoring Store FQDN, you can check in Topology Builder.)

The Monitoring Store may already be updated by the backend database update. If so, Management Shell will say “already up to date.” It’s still OK to do this; you won’t hurt anything.

Step 3 is to apply the Central Management Service (CMS) Update. We did not do this.

Why not? Because we’d already done the February 2013 Cumulative Update. If you did too, then you can skip Step 3. If not, follow the instructions!

And now, Step 4 – enable the Mobility service again. Very simple – just run:
Enable Cs-Topology
No parameters needed.

The Update Process: Verification

Step 5 is titled, “Enable the Unified Communications Web API.” Essentially, it wants you to activate Lync Services and verify that they’re running. To do this, we run Bootstrapper.exe.

If you haven’t run the Bootstrapper before, there are two ways to access it: via Management Shell cmdlets, or via the Deployment Wizard. We opted for the Deployment Wizard here, as it’s an easy process.

(I’ll do a post on Bootstrapper.exe later on.)

In Deployment Wizard, go to “Install/Update Lync Server System”. Run the “Install Local Configuration Store” command. You should see green check icons pop up for the window’s listed commands. Bootstrapper has done its job.

Note: Bootstrapper.exe creates an HTML log file of its activity. If you experience any errors, look in the log file. If you use Bootstrapper.exe via Management Shell, you’ll see the log file’s name and location. This is not displayed within Deployment Wizard (but the log file still exists).

Repeat for Edge Servers

This update process must also be run on every Edge Server in your topology. (Sorry.)

The good news is, it’s the exact same process. Just follow the instructions as we did above. Our Edge only needed 3 of these updates, and one reboot.

When Edge Servers reboot, you’ll drop outside connections like phones. Again, do updates within a maintenance window!

The instructions do not say to, but we ran Bootstrapper.exe again on the Edge Server. It may not be needed, but we covered the base. Making sure all components are updated.

As before, we opened the Deployment Wizard, running “Retrieve Local Replica Store.” It should work fine, since it’s a live, communicating environment.

Lync Server Now Up-to-Date!

All updates are complete! Your Lync Server should be back up and purring. This update took us a little less than 1 hour to complete. Provided there are no serious snags, yours should take about the same time.

One final recommendation: Check your Services.msc on the Windows Server. Verify that all Lync Server services are Running.

Have you experienced a snag with Lync Server updates recently? If so, please comment or email me! Let’s talk about the stranger errors we find, and what we can do to solve them.

See you next week!


How Many SQL Servers Do You Need to Run Lync?

Front End, Mediation, Monitoring, Archiving, Edge, Chat…with all these servers running, Lync Server 2013 must need a lot of database storage.

But how much is required? How many SQL Servers should a Lync administrator deploy?

Some of Lync requires a SQL Server database; some does not. But you’ll need to decide how many beforehand, because each SQL Server instance must be installed and available PRIOR to setting up their databases (via Topology Builder or PowerShell).

So let’s go through, server by server, and figure it out.


Standard Edition Front End Server

We start off easy. Standard Edition Server comes with its own database – SQL Server 2012 Express. It’s even auto-configured when you install Standard Edition Server.

SQL Server Instances Required (Minimum): 0


Enterprise Edition Front End Server

Of course, Front End requires a SQL Server instance. It needs a place to store the back-end database. Next!

Mediation Server

A critical server, many admins debate whether to collocate Mediation Server on a Front End Pool, or place it standalone. However, you don’t need a separate SQL Server instance for it.

Monitoring & Archiving

Since both the Monitoring and Archiving Servers can be collocated on Front End in Lync Server 2013, they can use the same SQL Server as Front End. They will each have a database to themselves (and you should install SQL Server Reporting Services too, for Monitoring).
–Placing these databases on their own SQL server instead would provide an extra security layer, if properly configured. But for most small or mid-size deployments, it’s not necessary.


Our friend the Director, standing guard against the tide of harmful access attempts. Since it has no users homed on it, it doesn’t really need its own database.

Persistent Chat

Persistent Chat stores your chat history, configuration and user provisions in a SQL database. You can install a second database to store compliance data, if you like. Both of these databases can reside in the same SQL Server instance as the Front End Server’s.

Edge Server

Remote access, enabling mobility…Edge Server must require a separate SQL Server for itself, right? To protect all that important connection data?

Well…Yes and No. Edge Server runs SQL Express Edition for a local CMS. Another instance of SQL Server is not required.

SQL Server Instances Required (Minimum): 1

(Reference: Server Collocation in an Enterprise Edition Front End Pool Deployment – TechNet Library)

Of course you can create multi-system SQL Server pools if you like.  Or use mirroring, or clustering for higher availability. I’ll cover those later on.

Oh, one last thing! Remember that Lync Server 2013 requires you use Microsoft SQL Server 2008 R2 SP1, or Microsoft SQL Server 2012. Don’t forget!

How many SQL Server databases are you running in your Lync pools?


External Lync 2013 Users Need a 2013 Edge Server to Use Mobility Services

A Lync Insider reader emailed me the other day, asking about Mobility Services. His external users couldn’t log in using Lync Mobile, and he wasn’t sure why.

After reviewing what he said, I thought it sounded similar to a problem we encountered during the Moving to Lync Server 2013 process.

The Problem: Everything’s Working, Except Mobility Services for External Users

The reader (let’s call him Bob) runs Lync Server 2010 Standard Edition. A 2010 Front End pool and a 2010 Edge Server, in place and properly configured. Voice, video, chat, mobility services, and federation all work fine.

Bob introduces a Lync Server 2013 Front End server in a new pool, in co-existence mode. Following configuration, Bob finds that just about everything is–still working fine!

Except for one thing. A Lync 2013 user, when signing in externally with Lync Mobile, experiences an error. Can’t Connect to Server. It may be busy or unavailable.

What’s going on here? Bob checks his Edge Server. DNS and push settings are configured. Internal Lync users on both Lync 2010 and Lync 2013 have no issues. External users can use voice and video.

It’s just Mobility Services which aren’t working on the Lync 2013 server. Why not?

The Solution: A 2013 Edge Server is Needed

In Part 7 of the Moving to Lync Server 2013 series, I mentioned a change we made after implementing the 2013 Edge Server:

“Larry also pointed the 2010 topology to the 2013 Edge server. External DNS must point to new Edge only. The new Edge Server (provided DNS is updated) will work for both 2013 and 2010 users.”

Here is the solution for Bob’s problem.

You do need a 2013 Edge Server to fully use Mobility Services. The new Mobility Services in 2013 is designed to take tablets into account; Lync 2010 didn’t have that functionality native. (Cumulative Updates did allow for tablet support, but it’s better-supported in Lync Server 2013.)

We encountered a Lync Mobile error similar to Bob’s while troubleshooting the 2013 Edge. Even though most of our users still used Lync 2010 clients, we moved all users from the 2010 Edge Server to the new 2013 Edge Server.

Everyone’s Lync clients worked without a hitch, irrespective of platform, after that. Including Lync Mobile.

Bob thought he’d just missed a settings tweak. He didn’t; in fact, he’d done a very thorough job on his topology. What he was missing was an additional Edge Server. With that in place, Mobility Services for Lync 2013 works!

If you’re planning to use Co-Existence Mode to transition from Lync Server 2010 to Lync Server 2013, take note. A 2013 Edge Server is critical to begin transitioning Lync users. Not to mention mobile access.

Have you encountered a mobility error like this? Let’s discuss!


Moving to Lync Server 2013: Error on the Front End (Part 7)

For this week, I have a short post documenting a serious error we encountered while installing Lync Server 2013.

A fix is available (thankfully). But it took us hours of back-and-forth research to locate it. I hope this post will save our readers all that time!

Stuck on an Internal Certificate Error…or Are We?

When we left off at Part 6, Larry and I were waiting for a new Active Directory server to finish installing. We wanted to use the new 2012 Certificate Services to issue internal certs for Lync Server.

Once AD had finished, we made a cert request. The cert issued, and we downloaded it to a file. The cert was placed in “Trusted Root Cert Authorities” for both the user and the Lync 2013 local machine.

However, we still had no luck. Lync would not recognize the cert.

Re-issuing the cert & adding it just to the local machine had more luck; it was recognized for “Web services internal” in Certificate Wizard. Recall that we already had an external cert for external Web services.

Everything looks okay now…but Lync’s not working. We were unable to connect to the server with a test account (not even for IM).

We tried reworking the cert, restarting the servers, going back in the Lync 2013 install process…nothing.

The error was not in the Certificate Wizard though. It was somewhere else.

Error: Lync Front End Service Appears Active (But Really Isn’t)

While we investigated, Larry checked the services running in the background. The Lync Front End service did appear in the services listing. Despite this, Lync would only connect for a moment–and then drop.

However, this service was a ghost!

According to this TechNet forum thread, the Lync Front End service had not activated properly.
Lync 2013 Enterprise Pool Front-End Service doesn’t start – Lync Server 2013 TechNet Forums

This error is NOT in current Microsoft documentation.

The solution was a fix from a Microsoft engineer (posted to the above thread by RSudmeijer):

Please note this will lower security so I don’t know if this has any security impact for Server 2012 and Lync. And if this will be the fix that Microsoft will offer. But the solution works for testing until further notice.

On the Front-End server create the following registry:

Create a registry key named ClientAuthTrustMode and set value to 2.

Restart the machine after making the changes. Once the server is restarted, check if the service is started.

This error only occurs during a migration from Lync Server 2010 to Lync Server 2013.

The fix corrected the Front End server issues, AND allowed for internal certificate retrieval.

Once Larry implemented this, we were able to test Lync 2013 via IM.

Larry also pointed the 2010 topology to the 2013 Edge server. External DNS must point to new Edge only. The new Edge Server (provided DNS is updated) will work for both 2013 and 2010 users.

And that’s how we fixed the most challenging error Lync Server 2013 gave us. All that’s left was installing Mobility services, installing the Web Apps server, and testing. Look for more on those next week!


Moving to Lync Server 2013: Build Out Mediation, Monitoring, Archiving and Edge (Part 6)

First off, hello to everyone at the Lync Conference!

I really wanted to make it down, but it just didn’t happen. Makes me sad…lots of Lync announcements (and goodies) I’m missing out on!

If you want to follow the action (like me), check out these people on Twitter:

Now, back to the Lync Server 2013 install process.

Last time, I mentioned that we had to upgrade Active Directory in order to acquire Certificate Services 2012. While we waited for it to install, Larry and I proceeded with building out Lync’s additional server roles: Mediation, Monitoring, Archiving, and Edge.

Mediation: In Place Already, SIP Trunk Needed

First up, Mediation. In Part 3 we’d selected the option to collocate the Mediation Server with the Front End pool. So it was already created. However, we needed to configure a SIP trunk for it.

We had already requested an IP for the SIP trunk; it came from a hosted SIP provider. To define it, we right-clicked “PSTN Gateway” in Topology Builder and selected “New IP/PSTN Gateway…”

Trunk Configuration steps are as follows:

  • Define the PSTN Gateway FQDN (The field will accept an IP address as well)
  • Enable IPv4 or IPv6. (We chose IPv4.)
    • Sub-Option: “Use all configured IP addresses” or “Limit Service Usage to selected IP addresses”. We chose Limit Service Usage, and entered an internal IP.
  • Define Root Trunk. We entered:
    • A Trunk Name (the same gateway IP)
    • A Listening port for gateway (the default is 5067; we changed it to 5068)
    • A SIP transport protocol (default is TLS; we changed to TCP)
    • Associated Mediation Server (we used the pre-set value)
    • Associated Mediation Server port (default is 5067; it changed to 5068 when we changed the listening port).

Click Finish. Trunk configured! We tested it (later) by making phone calls to a test number.

Install Monitoring & Archiving Servers

Since Monitoring & Archiving Servers are add-ons to Front End in Lync 2013, all we needed to do was create a new SQL database for them, and configure the servers in Topology Builder.

Larry had created a new SQL database already, so we proceeded with installing the Monitoring and Archiving add-ons.

(If you need assistance setting up SQL databases for Monitoring and Archiving, refer to the first half of this post:
Step by Step Installing Lync Server 2013 Monitoring Role Collocated on Standard Edition Front End – Part 2: Matt Landis Windows PBX & UC Report )

Right-click your Standard Edition Front End Pool in Topology Builder. Click Edit Properties.

The Properties window should open displaying General properties. Scroll down until you see the “Archiving” option. Check the box.

Click the “New…” button next to “Archiving SQL Server Store”. A new window will open.

We entered the SQL database name (formatted like this: sql01.domainname.dom). We chose a Named Instance, and labeled it “Archiving”. We left the mirroring values on defaults. Click OK and you’re done.

Below this on the Properties window is the “Monitoring (CDR and QoE metrics)” option. Click “New…” next to this as well. You’ll see the same new window as Archiving. We entered the same SQL database name, but labeled this one “Monitoring” to differentiate. All other values left on defaults.

Click OK to close the box. And OK again to close Properties!

(Don’t forget to Publish the topology once these changes are made.)

Installing Edge

Certificate Services 2012 still had not finished setup. So we logged into the designated Edge Server instead.

We ran Lync Setup. After specifying an install location, the core components installed, just like the main Lync install.

Next, the Deployment Wizard pops up. Like I said in Part 2, install Administration Tools first (for Topology Builder).

After that, click “Install/Update Lync Server” like before. We selected “Import from File” when prompted, and navigated to the saved topology file in C:Support.

1 Error: Prerequisite not satisfied.
Remember a few weeks ago, when I said to make sure Windows Identity Foundation” was installed? It wasn’t on this virtualized server. We opened Server Manager, added the “Windows Identity Foundation” service…and no more error.

Resuming Lync setup, I found that it auto-starts the prerequisite install. Plus it moves straight to “Install Edge Server”. You should see Installing Server.msi (Feature_Server_Edge) in the progress window.

Time to request a cert. We tried using the same cert as before (due to the multiple SANs listed within it). In the Certificate Assignment window, we deactivated “Edge Internal” for now (we’d need the local root from the new AD/Cert Services for that).

Right now, we’d just set up the External Edge certificate. We chose to “Import Certificate” from the saved text file; no problems. Then we clicked Assign.

Error! No certs appear in the list.

We tried this a few times with no change. Then Larry looked further into the cert structure. After many frustrating re-import attempts, he found the issue.

It turns out that the private key had not exported with the cert. Even though it was from the same server, we had to repair the key and re-export it before the Edge Server could see it.

*This was NOT a Lync-related error; it came from our own networking environment. I’m posting it in case you encounter the error as well.

Thing is, Lync Server 2013 DID give us an error right after this. A serious error that stopped us in our tracks.

I’ll devote the next “Moving to Lync Server 2013” post to it.

Until then, join me in following the Lync Conference!


Moving to Lync Server 2013: Creating a Lync Server Topology (Part 3)

Last time I took you through our initial steps on preparing servers and Active Directory for Lync Server 2013. We stopped at the Topology Builder.

Anyone who’s worked with Lync Server 2010 knows Topology Builder. In 2013 not much is different; we’ll use it to determine which server roles we want to run, and the IP information necessary to run them.

I’m adding all the Topology Builder steps into one post; makes sense this way. So pour some coffee, and let’s keep moving to Lync Server 2013!

Bouncing Off Existing Environment – Good for Migration

Because we have an existing Lync Server 2010 setup running in our domain, we chose “Download Topology from existing environment” on loading. This loaded two Lync Servers: one 2010, one 2013 (empty).

We’re adding all the bells and whistles we can to this version, since our datacenter is expanded and we have a hosted PSTN Gateway from Cohere ready to go.
(NOTE: Having IP information on hand for such hosted elements is critical!)

Expand the Lync Server 2013 folder. Right-click on “Standard Edition Front End Server” and click “New Front End Pool…”.
(If you plan to use Enterprise Edition, right-click the “Enterprise Edition Front End Server” and click “New Front End Pool…” instead.)Define 2013 Front End Pool

A new window will open, asking for details to define the new Front End pool. First, enter your Fully Qualified Domain Name (FQDN). For example, mslync03.domainname.com.

Next up is the Feature Select window. Select which Lync Server features you want to run.
Select Lync Server 2013 Features

We selected all options (as seen above), EXCEPT Archiving and Monitoring. Why no Archiving or Monitoring? We didn’t have SQL databases prepared for them yet. Once those are ready, we’ll re-enter Topology Builder and add them.

(This is also a recommended step in Matt Landis’ post series on installing Lync Server 2013. You’ll find it here:
Step by Step Installing Lync Server 2013 Standard Edition Front End on Windows 2012 – Part 1: Matt Landis Windows PBX & UC Report)

Down through the Feature Options

At the next screenshot you’ll define your Mediation Server. Necessary component for voice communications. We followed Ondrej’s example and chose “Collocate Mediation Server”.
Set Collocated Mediation Server

Next, you’ll see a screen asking to associate Server Roles with this Front End pool. We selected Edge.

Define SQL Server Store: We had a SQL 2012 database prepared for this; selected “New” and entered it.
Define Lync 2013 SQL Store

Define File Store: At this point we left the Topology Builder running, & switched directly to the Windows Server we were installing on. Why? To create a folder called “LyncShare”, which will be our file store.

This folder must be accessible to ALL users on this server, so Lync has no trouble storing/using files. Be sure to right-click the folder and share it with everyone.

Then we can go back to Topology Builder, and define a new file store using our server’s FQDN and the new shared folder.
Define Lync Server File Store Folder

Next up, Specify Web Services URL. Enter an external FQDN (for example, lyncexternal.domainname.com). It can be anything really, but make sure it’s NOT the same FQDN you use for your Edge Server later. We used a brand new FQDN to avoid any association issues with our 2010 system, as well.

We skipped the option of setting up an Office Web Apps Server – again, something to add later.

Next you’ll see options for specifying an Archiving SQL Store and a Monitoring SQL Store. Since ours weren’t enabled yet, we turned these off for now.

After that, it’s time to define an Edge Server pool.
Extra information is required to set up Edge Servers: their own IP, FQDN, multiple Edge servers vs. a single server, etc. Lucky for all of us, Topology Builder gives you reminders for all of it.
Define the New Edge Pool - Reminders

So if you don’t have something, just leave it up and go find what you need.

We entered our Edge FQDN, and selected “Single computer pool”. Right now, we don’t need load balancing in place.

Edge Features Selected: Use single FQDN and IP address, Enable federation, Enable XMPP Federation. We selected all of them.

IP Options: You can define IPs by IPv4 OR IPv6! Very useful in the coming year. We stuck with IPv4 for now.
Set IPv4 or IPv6 for Lync

External FQDNs: Lync will ask for 3 FQDNs – one for Access Edge, one for Web Conferencing Edge and one for A/V Edge. We used the same FQDN for all three.

(Again, DON’T use the same FQDN as the one you input for external Web services! We had a lot of grief to deal with when we did that.)

Edge Setup will then ask for internal and external IP addresses. External IP is a private IP used for Edge services alone. We added in a new external IP for NAT, which figures into the Public IP.

Define Public IP: This is for the A/V Edge service. We used the same IP as the External IP.

Next Hop: The last step in Edge Setup. You must select a Front End or Director pool to serve as the Edge’s next hop. If you had a Director, this would give you the option of selecting it. Since we’re on Standard Edition, Next Hop is automatically filled in with the Front End pool’s FQDN. Just click Next, and Edge Setup is done!

One more step. Topology Builder should have finished its wizard. But before you publish, make sure to define an administrative URL for future work. We had one prepared – something similar to http://admin.lyncpm.com.

Right-click the new topology, and select Edit Properties. Scroll until you see the “Administrative access URL” field.
Enter your administrative URL. It must correspond with the Front End pool FQDN you set earlier.
Below this field, in the “Front End Server to install Central Management Store to” menu, select your Front End server. Click OK to save changes.

All set (for now)! Right-click the new Lync 2013 Server and click Publish Topology. Click “Next” twice to complete the publication.
Publish Topology - Warnings

Uh oh…error! Error! What’s happened?

It appears we have an Access Permissions error.
(( ACL Error: Failed Adding “Access Write” permission for “RTCHS Universal Services” on “LyncShare”. ))

The file store? Yep. Turns out this is a relatively common error that occurs with sharing of the file store folder. Engineers at FortressITX located a fix, and posted it on Quora:
How Can I fix the Microsoft Lync 2013 Installation Topology Error? – Quora

It essentially requires you to go overboard on sharing the file store with admin groups. We followed the steps and wound up with this:
Everyone Read-Write for Lync 2013 File Store Folder

And what do you know, the topology published after that!

You now have an active Lync Server 2013 topology. The next step will be to install the Lync Server software on its appropriate servers, and define roles such as Edge and Archiving.

Again, please note that a Lync Server topology is not set in stone. Today’s build establishes the functionality baseline for our Lync Server system. We’ll add to it as we go along. Just as any administrator can add to/change their Lync Server.

Check back next time for Part 4!