Lync 2010 Deployment Guide (even more DNS)

Let’s now check the meeting functionality. I can indeed start a meeting from “Meet Now” menu…

 

But when we reveal the Meeting Join Information, our URL points to meet.drago.ws and not drago.local and… internal users cannot connect to a meeting. 

Quick look in our certificate shows that because of our entries in Topology Builder, meet.drago.ws and dialin.drago.ws is included in the list or SAN (Subject Alternative Name)

...and so, all we need is to create the appropriate A-records in our drago.ws internal zone.

 Once again – rejoice! Internal users now join the meeting as expected.

 

Lync 2010 Deployment Guide (More DNS)

So, all looks good thus far…

 …and yet we cannot sign-in. Let’s see – the Lync server is accessible, all services up and running, _sipinternaltls._tcp.drago.local DNS record is present… way a second! Our SIP domain is drago.ws and the SIP-URI we decided to use is @drago.ws. In this case, the users will sign-in as user@drago.ws and Lync client will look for _sipinternaltls._tcp.drago.ws DNS SRV record. But… we don’t have drago.ws zone in our DNS…

Here comes the Split DNS mystery.

Our domain is drago.local and by default, we have Active Directory Integrated Zone for .local domain. Shall internal users make a DNS query for, let say, www.drago.ws, the request would be forwarded to the Public internet where the zone drago.ws will be discovered and an answer will be returned. With this in mind, we could, indeed, create _sipinternaltls._tcp.drago.ws SRV record pointing to fe.drago.local, but publishing internal resources on Public DNS is absolutely un-acceptable.
The solution is to create a zone for drago.ws domain in our internal DNS. Then, the queries for .ws domain will be served locally. In this scenario we have “Split-brain DNS”. Split, because internal DNS queries will be served internally, while public internet users will be served from the Public DNS (in our case hosted by GoDaddy.)

Maintaining two zones is a “Double the fun” indeed and must be carefully planned and cared for. Many times we could end up chasing ghosts if the zone was misconfigured. Also, in some cases we could send traffic (internal requests) to public server interfaces thus creating bottleneck.

For example, in our college, the “home page” is the college web site. Had we had split-brain DNS and mishandled the A record entries, all 1,500 internal computers would hit the Public IP interface in addition to the thousand hits from outside. Instead, we have “internal” and “external” website, essentially “splitting” traffic because internal resources gets the website bind to an interface with Local IP address (internal DNS returns LAN IP), while external requests go to the NIC with Public IP.

Another example that apply to our lab: Let’s assume that we have web server with two NIC. We run two web sites – one public – http://www.drago.ws  and another – http://resources.drago.ws where we publish internal reports and sensitive information. “resources” web site is bind to internal IP address only thus not accessible from Internet. In this case we would create one A record in the Public DNS (for www.drago.ws with the public IP address) but two A records in the internal DNS – one for www and one for resources.

Having said all that, let’s create the additional zone in our .local DNS.

Now we have to create our Lync SRV records in the new zone.

…and try to sign-in again.

Finally, if we look Lync Configuration Information, our Server SIP URI is listed correctly (fe.drago.local)

Lync 2010 Deployment Guide (Enable Users)

It time now to sign in with Lync client for first time.

I have two Windows 7 SP1 virtual machines and created two user accounts – Lync User 1 and Lync User 2. While the accounts are on my drago.local domain, the email address is @drago.ws and so will be the sip-uri.

First, of course, we have to enable the users for Lync.

And now our first user is enabled for Lync.

Let’s do the same for the second user. This time we will use Lync Server Management Shell.

Ouch, I hate that!

CP (Control Panel) shows all services are up and running and yet I cannot sign-in. What could be wrong?

Let’s discuss this in the next post.

Lync 2010 Deployment Guide (Installing Lync Roles)

To install Lync roles, certificates and activate services we will user Deployment Wizard.

We will begin by installing “Local Configuration Store”

Next step – “Setup or Remove Lync Server Components”

Time to “Request, Install and Assign Certificates”

I will use my internal Certificate Authority and so, will send the request immediately

I am logged with Domain Admin credentials and don’t have to specify alternative credentials.

I will give friendly name “Home_Office_Pool_Internal” for easy identification later and also mark the private key as exportable – might come handy later for tracing… you never know.

On the last screen, just before the request is send, we see the SN and SAN’s if the future certificate. Something is missing here, isn’t it?

…and here we go.

Our Certificate Request was completed successfully...

…and must be now assigned.

What left now is – to start the services.

Beautiful, isn’t it?

Let see what we have done so far…

I LOVE THIS JOB!