Sunday, June 30, 2013

ebook: Microosft Lync 2013 Unified Communications: From Telephony to Real-time Communication in the Digital Age

today I like to recommend a "non technical" book, written by my friend Daniel Valik.
Lync 2013 is not all about technical knowledge, in Unified Communication we also need to come more closer to the business approach. We need knowledge about business process and financial consultancy ahead of any Lync deployment.
With Daniels book it is possible to understand this areas and gain knowledge about this new areas we should be aware of ...

Please have a look and drop us any feedback.


Lync Client: Certificate Authentication Problem

Very often I'm ask about this problem:

Lync cannot verify that the server is trusted for your sign-in address. Connect anyway?

Lync kann nicht überprüfen, ob der Server für Ihre Anmeldeadresse vertrauenswürdich ist. Trotzdem verbinden?

Lync Client 2013 has an additional safety check implemented.
This verify the users SIP Domain with the FQDN of Lync server where the user tries to connect with.
In the most customer environments, the SIP domain is different from the Active Directory domain. It usual and normal. Possible the SIP domain will match the SMTP domain, so user can easily experience Unified Communication, and the communication addresses are the identically.

If you are in an lager enterprise, it's quiet a hassle if all users would have to click the acknowledgement. We need a solution!

How to solve this problem, there are two methods
A manual way and a GPO based solution.

If you are adjusting the Lync Client manually, you have to navigate to:

here you need to modify or add the "new String Value" TrustModelData
in this key, you need to add the server listed in the warning.
e.g. lyncpool.domain.sip

the second method by using the group policy:
add the registry settings in, e.g. the default domain policy or a dedicated client policy.
(possible: you implement the Office 2013 Administrative Template)

TechNet German:
TechNet English:
Office  2013 ADMX:

Wednesday, June 12, 2013

Configure and Identify Lync Server 2013 Services and Ports (Communication via SIP TCP Port 5060)

We in larger environments or under special circumstances, we need to identity or redefine Lync Server Services. Either we need a list of running service and their configuration about assigned servers, or we might need a special configuration.
For example, in some Video Conferencing environments, the VC system can only communicate over TCP Port 5060 with the SIP Registrar, rather than over TLS Port 5061.

If this is the case, you need to reconfigure the Lync Server 2013 defined Default Settings.
In Lync 2013, the following Ports are defined by default:

SipPort: 5061
WebPort: 444
LyssWcfMtlsPort: 5077
XmppGatewaySipPort: 5058
WinFabClientConnectionPort: 5092
WinFabLeaseAgentPort: 5091
WinFabFederationPort: 5090
WinFacIPCPort: 5093
WinFabReplicationPort: 5094

Other Ports are not defined:
SipHealthPort, SipServerTcpPort, SipClientTlsPort

We can figure-out the configuration with the following command only:
Get-CsService -Registrar

If you have a look into TechNet under Lync CmdLets, you will find several service listed, e.g. Registrar, ManagementServer and more. It is a must that you define the service which are going to configure.
If we assume a Lync Pool named: pool01.domain.local, you will have to modify the command too:

Set-CsRegistrar "registrar:pool01.domain.local" -SipServerTcpPort 5060

The tricky part here is how to figure out which cmdlet is responsible for writing the parameter. That's why I wrote: make use of the Get-CsService cmdlet or the TechNet.
It will also provide you with the correct syntax you have to use during your configuration.
Therefor if in our example, we see the Identity as "Registrar:cie-ly01.acp.cie". This is similar for all CsServices. You will be able to associate the proper cmdlet.
e.g. "Registrar:xx" - Set-CsRegistrar
e.g. "ManagementServer:xx" - Set-CsManagementServer
e.g. "EdgeServer:xx" - Set-CsEdgeServer

You still have to care about one irregular cmdlet assignment.
lets talk about the Registrar configuration. If you run a command like Get-CsRegistrarConfiguration instead of Get-CsService -Registrar, you will not be able to receive the same config information.
The Set-CsRegistrarConfiguration configures the behavior of the Global or Site based SIP Registrar.

So please do not get confused between SERVICES and CONFIGRATIONS.

We as Consultants and System Engineers have understood the need of PowerShell and are happy if we find cool settings only possible to adjust via PS ;)

(c)  2013

Monday, June 10, 2013

Lync Certificate Planning and Assignments

Lync Certificate Planning and Assignments
(Edge, Reverse Proxy, Director, Frontend, Mediation, WAC)

Download the article as PDF: SlideShare Link (here)

The following article is optimized for Lync 2013, but in general valid for Lync 2010 or OCS 2007

First I need to highlight; Lync Server and Client make use of Certificates, therefor the technical principals of certificate deployments are necessary to understand. If on your Clients or Servers an Internet Explorer Setting with a Proxy Server is activated, make sure you have the correct design. The CRL (Certificate Revocation List) check is mostly HTTP based (in AD Environments also possible via FILE or LDAP), if you have setup an internal Proxy, which cannot redirect the request into your LAN, you will run into major issues!

I wrote another article in 2012 which maybe from interest for you too:


Lync Certificate Planning must be separated into three different areas:

1. INTERNAL Deployment
(all internally deployed Lync Servers, e.g. Frontend, Directors, Mediation,..)

Including the internal NIC of the EDGE Server

2. EXTERNAL Deployment
2.1 Edge Server
2.2 Reverse Proxy

Indirectly there is a fourth area, this is if you have Pool Server configuration, due the Virtual Service configured on the Load Balancer. But I will explain this in detail within another blog later.
All Lync Server have one requirement in common, this is the way how they accept authentication based on TLS. Accepting the trust, Lync Server need a matching between the certificates common name and it FQDN. The server or client, initiating the communication with the certificate holder use DNS lookup to refer to this server FQDN. If this reference does not match the common name of the certificate, the authentication will fail.
The common name, notated as CN in X.500 terminology, is what is referenced and must match the DNS record for the server’s FQDN. For details about the specific format
This explains why a dedicated wildcard certificate would not work in Lync Server, because the common name must match exactly to the FQDN of the A record defined for the referenced server or pool. The DNS A record and the certificate subject name/common name (SN/CN) is also referenced to the trusted server list in Active Directory service Global or Configuration settings.

Reference: Microsoft Technet Certificate Guide
Important: You cannot use a wildcard CN/SN (for example, * when you configure certificates for Office Communications Server 2007 R2 and Office Communications Server 2007 (now Lync). If you do so, they will not operate as expected and the problem is very difficult to diagnose. You can use wildcard entries in the subject alternative name, but the common name is specific. Specific issues include the inability to start services because the trusted services in Active Directory Domain Services (AD DS) and the SN and CN do not match, mutual authentication fails, and so on. 

Note at last:
And, as mentioned earlier, public CAs and your internal CA can create wildcard SN/CN certificates, but they are neither reliable nor supported. It is recommended that you do this right the first time and avoid the potential for serious issues in the future by not trying to use a certificate that uses a wildcard SN/CN, such as *, to define the three Edge Server services.


Server Components
(Certificates are requited)

2.1 INTERNAL Deployment:

  • Standard Edition Front End Pool Server
    This server is the consolidated “all-in-one” Server and requires an internal certificate.

  •  Enterprise Edition Front End Pools
    This server is the High-Available Lync Core Component. Beside the local servers themselves, they also provide the consolidated access names and are attached with a Load Balancer. The certificate must contain the Pool and Server name. In certain circumstance it makes sense haven a generic certificate, which contains all Pool Server Names and the Pool Name (SAN certificate).
  • Director Pools
    This server is the “Authentication and Redirection” server. In lager deployment, with multiple site, you need the Director to offload authentication traffic and redirect the user to the homed pool.
  • Mediation Pools
    This server is responsible for Media Conversion
  • Persistent Chat Pools
    This server handles the “Group Chats”

  • Trusted Application Server
    All Server, which need to be trusted by Lync have to be publish that Lync is aware of them. If A certificate is required if the trusted server will us TLS.

  • PSTN Gateway
    The PSTN Gateway object, might be a Lync Gateway, Gateway card or an SIP Trunk. With the PSTN Gateway, this depends on how the setup must or can be done. If you make use of a TLS connection, e.g. to an ISDN card, you will need a certificate stored on the PSTN gateway.

  • Office Web Apps Server
    The WAC/ OWA server requires a certificate, this is OAuth ready.

As described in the section for Front End Pool Server, generally it has to be part of the planning how certificates are requested if a Load Balancer is involved. A Load Balancer can be setup in different way (in-band or out-band), this will discussed in a separate blog. But you need to remember, the Load Balancer is the central point for the IP connection, therefor it needs the FQDN of the POOL in its certificate presenting to the connecting client. Depending on how the Load Balancer is established, you will than understand why the Pool Member Server needs beside the Pool FQDN also its local FQDN in its local certificate!

2.2 EXTERNAL Deployment:


  • Edge Pools
    The Edge Server is the main component used to communicate from and with outside of the organization. (Responsible for PIC, XMPP, Federation, remote access and Web Conferencing)
Edge Pools have one specialty, for best practice and security reason, they make us of 2 NICs, an internal and external.

Edge Server need to have 2x NIC with different subnet, need the primary internal DNS Suffix set, must not be a domain member and will need to certificate, and internal CA issued certificate for the internal directed interface and an official, public certificate (where I will take more later about). Additionally, remember to set the default gateway on the external facing NIC and all internal subnet must be assigned a static route based on the internal facing NIC. 

·         Reverse Proxy
This optional component only needs an external certificate and it’s responsible for Web-Based Services, e.g. Address Book or Dailin Conferencing page.


3 Topologies

Topology represents your entire corporate Lync Server deployment and all involved Lync Systems, with one exception, the Reverse Proxy. Since we want to define the necessary certificates, it is necessary to fully understand the topology and server function which then represents the service making use of. 

3.1 Internet facing Systems

Before we actually start with the topologies, we need a clarification what the external facing system will do, what they are responsible for and what not.

Else which kind of usability scenarios do we have?

  • Remote Users
  • Federated User
  • Public Instant Messaging Connectivity Users
  • Mobile Users

And the type of communication:

  • IM
  • Presence
  • Audio/ Video/ App Sharing
  • Web Conferencing
  • A/V Conferencing


3.1.1 Edge Server:

The Edge Server, the Internet facing system responsible for enabling users to communicate with external partners, connect remotely and establish connectivity with Public IM Services, like Live or Skype.
Also the Audio/ Video and App Sharing runs through the Edge server if a Meeting is in place.
One newer component, called XMPP (Extensible Messaging and Presence Protocol), is established in Edge Server since Lync 2013, it is used for partner federation e.g. Google Talk.
Edge Server is not responsible for any other service as the described services in this section.

3.1.2 Reverse Proxy:

Reverse Proxy as an optional, not Lync Server Topology component, becomes responsible for several areas and will publish internal resources.
It can be separated into two areas, the remote user connectivity and generally spoke “meeting’s”.

Remote User:
Remote user need to connect to Lync server internal service, called “Web Service”, they are responsible for Address Book Synchronization, Distribution List Expansion, Device Updates, Mobility Services.

Access to Meetings, Conference Join Locations (PSTN Dial-In Numbers), Access to personal Dial-In and PIN information, Download Meeting Content.

3.2 Topology and certificate assignment

In sum we will have one primary and two secondary SIP Domains in our example topologies defined.
The third deployment would be a very complex scenario, where we have multiple geographically deployed Edge Server/ Reverse Proxy scenario.
I’m not having a look into Enterprise Voice, it is not required since we want to understand the certificate design. 

Our deployed domains are:
Active Directory Domain:             INTERNAL.AD
SIP Secondary Domain:                 DOMAIN-A.COM and DOMAIN-B.COM


In general, what we have to remember for Lync Topology designs and the related certificates is:

  1. On Edge Server, Wildcard Certificates are not allowed
  2. On Edge Server we need matching CN and 1st SAN entry of access FQDN, e.g. SIP.DOMAIN.COM
  3. On Edge Server we need SAN entries for AV and WebConferencing
  4. On Reverse Proxy, we need a matching CN with the associated Director Pool external Web Service FQDN
  5. On Reverse Proxy, all external Web Service FQDN must be in SAN
  6. On Reverse Proxy all other FQDN can be consolidated in a Wildcard entry


The “SIMPLE TOPOLOGY” is the most common deployment for smaller customers. High availability is mostly not required by Lync due to virtualization. For those customers, VM Host availability and snapshots are sufficient enough.
The simple deployment includes the full feature set of Lync in direction to the internet. This includes login possibility for all Lync Clients, incl. App Store and Mobile clients. Federation is also handled.



The “COMPLEX TOPOLOGY” is the most common deployment for lager, multi pool customers. High availability is required for Lync and due to multi pool deployments, login traffic must be handled by Director Servers.
This deployment includes the full feature set of Lync in direction to the internet. This includes login possibility for all Lync Clients, incl. App Store and Mobile clients. Federation is also handled.



The “GEOGRPHICALLY COMPLEX TOPOLOGY” is the most complex deployment for international customers. High availability is required for Lync this is also extended into a multi-region Edge Access scenario.
This deployment includes the fully feature set of Lync in direction to the internet. This includes login possibility for all Lync Clients, incl. App Store and Mobile clients. Federation is also handled.
The main component for geographically distributed deployments is the GEO-Load Balancer. It handles the Internet based distribution for Edge Access.
Since I’m talking about Certificates, it is important to understand the Certificates distribution.


4 Certificate Template Table

Making it easier for you, I prefilled in the Template with this configuration example:
We have 3 SIP domains in our deployment 1x Enterprise Pool, plus 1x Standard Edition Server in a branch. I also have 1x Director installed. 

4.1 Edge Server

Common Name
Primary SIP domain
First SAN entry must repeat the primary SIP domain
Web Conferencing only for the named primary SIP domain needed
XMPP Federation (if installed) of primary SIP domain
Second SIP domain
Third SIP domain

Table 1 Edge Server external Certificate

4.2 Reverse Proxy Server

Common Name
Just a Common Name
External URL of Director Server. Must be primary SIP domain
External URL of Enterprise Pool Server. Must be primary SIP domain
External URL of Standard Server. Must be primary SIP domain

Table 2 Reverse Proxy Server external Certificate 

4.3 Hybrid Certificate (Summary)

Common Name
Primary SIP domain
This is the Wildcard part for Revers Proxy of
This is the Wildcard part for Revers Proxy of

Table 3 Consolidated, public Certificate


5 Certificate Request Generation

How do I request the Wildcard+SAN certificate?
The following demonstration explains hybrid certificate request in Lync. This has to be done on the Edge Server itself. You have to login to the Edge Server and start the Bootstripper, than you chose the “Request, Install and Assign Certificates”.


In this example, I’m using three domains:
SECONDARY SIP Domains: and

Since this will be our Hybrid Certificate, there is still one point we haven’t spoken about. How do we request this certificate? If you for example initiate the request with DigiCert, you need to buy three (3) wildcard certificates first, than you process with DigiCert manually via email.
So remember you might take one/ two days longer in placing the order.

We need to prepare a CSR file for external, manual requests:

The friendly name can is only for better identification of the certificate in the store:

The first defined SN'S are provided by Lync automatically:

Next, you need to include the addressed SIP domains configured in Lync Topology builder:

As discussed, here we come to the point, where we need to add additional SAN entries as explained and defined the table earlier:

Verify the correct CN and SAN entries:

Finally you defined the Certificate Request. This is your CSR file. Provide this information to your Certificate supplier.
Remember, the Certificate File you will receive will NOT contain the PRIVATE KEY. The Private Key will be generate once you apply this certificate on the Edge Server where you generated the statement !
Only after its process is fully done, you have the Private Key and the Certificate is ready to be exported and imported on the other servers, e.g. Edge and Reverse Proxy

6 Best Practice

Beside the certificate design and planning process, there are some more point to remember.
I have listed all important areas you must consider during your design and planning process.

  • Network Interface Cards:
You have to use two NIC, one for internal and one for external communication. The default gateway has to be set on the external facing NIC, while you must use “persistent static routes” to all you internal networks. The DNS should be pointing to the internal DNS Server, if you are choosing an external DNS or a DNS in a DMZ, make you can resolve the internal Lync Server, if you can’t, you need to provide a hosts file.

  • Edge Server and Reverse Proxy combination
As stated earlier, the full feature set in Lync is only available if you make user of Edge Server, Reverse Proxy and all required external DNS entries (incl SRV Records). If the RevProxy is not deployed, you will miss the following features, e.g. address book download, location information, device update, Lync Web App and NON-DOMAIN Client login)
The non-domain client login requires an authenticated access the Certificate Provisioning Service.!
Also the App Store and Mobile Clients can’t login without the publish autodiscovery services.
This is the same with access to Exchange Web Services (EWS).

  • Director Server Service
The Director Server is an optional component, responsible for offload user authentication and pool redirection. IT also provide an additional layer of protection for external client connections.

  • Revers Proxy Listener
Keep the Web Listener as limited as possible. Us only one (1) Listener per internal destination server each. Make sure the Listener can work with the Hybrid Certificate to minimize costs.



(c)  2013