About Me

TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015) - before that, a Lync Server MVP (2010-2014).
My day job is titled "Principal Consulting Engineer" - I work with an awesome group of people at CDW, LLC.
I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times.
FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA.
One of these days, I intend to start teaching.
The opinions expressed on this blog are mine and mine alone.

2010/11/05

I just did a deployment where the PSTN was a Nortel and we used an AudioCodes 1000 gateway. Everything worked out well until we noticed that outside calls coming through the Nortel got dead air until the Lync user either answered the call or Lync sent the call to voice mail.

Seeing as how Lync to Lync calls behaved properly, and tracing showed the proper SIP 180 responses, the obvious culprit was either the gateway or the Nortel. Turns out that in an AudioCodes gateway there is a setting for allowing ringback to leave the system and head for the PSTN!

Now, I am not a gateway guru, but don’t you think that would be a desired thing to have? Well, it is off by default. Flip it over a bit and voila! Ringback to PSTN.

2010/11/02

There are actually two ways do get this all done in one swoop. Using the GUI is good, but wouldn't you rather just do some cut n paste? Note that there subtle differences here in the syntax although the individual feature add statements are the same.

For Server 2008 SP1 or SP2:

Open a command line (runas administrator). Then do the following (command will have wrapped):

2010/11/01

Now that we have the prerequisites installed, the CMS in place, the schema extended, and the topology built, here in part three we will continue through the SE install and take a first look at the Lync Control Panel.

To get started, return to the deployment wizard and select the “Install or Update Lync Server System.”

Notice that the first selection is to install the local configuration store. This is an important difference from OCS and the reason we needed to have the CMS installed and why we did the topology builder work. After that, the install proceeds very much like OCS, so I will not go into details. One note of importance: If you configured an element in topology builder, changes to the environment that involve that element will get changed in topology builder and re-published.

Note that at the end, the wizard shows you the powershell commands. Those who are seriously interested could reverse engineer these strings and do some serious learning. Moving on.

Now we are going to do the PKI for the SE. Remember the questions that were asked in the topology builder? Did you document your answers? Thankfully, if the answer is “no” you can simply open your topology builder and look. I am going to use a single name cert, and when the Reverse Proxy comes into being, I will redirect from public DNS name to internal fqdn. The Lync cert wizard is different from the OCS cert wizard, but nothing too weird.

Notice how the wizard wants a cert for each function. After clicking no NEXT no less than five times I get to actually define my cert. I use the KISS method.

After that some basic cert info like who what where etc. Then we get this gem straight from the topology builder! Nice! However, if you are not planning on doing the RP redirect thing, you better know which name there corresponds to which. Remember that we left those boxes checked? Lync is going to look at the topology build in the CMS, as replicated to the local configuration store, and assign the certificate as needed. We have one cert, so there will be no issues. But if you use three different certs you may need to track things a bit closer.

On this next screen, read and understand. For my purposes all my answers are no, AND I already have sip.tsoorad.net defined on my topology so that name was already included. For those who use those expensive public certs, adding yet another domain name might just bump you to a more expensive cert. For those who are doing internal certs, but have multiple sip domains that meet the listed items, you better be prepared to hit the necessary check boxes.

A few more default “next” clicks and the certreq gets pushed to my internal EntCA.

We have a cert. Leave the “assign this certificate…” box checked and the wizard will assign the certificate as needed. In our case, the FE, and both web sites (internal and external).

After a few more obligatory “next” clicks we are finished with the cert request and assignment.

Almost done! Start the services.

Now, let’s take a quick tour of the Lync Control Panel. This is a Silverlight app. It is really pretty nice. We won’t go into great levels of detail here. Remember that we added a user to the CSAdministrator group in a previous section? You will need that user or another user of that group to operate the LCP and expect to be able to change things.

How pretty. One stop shopping. Sorta. Remember that many of the functions that were previously included in the R2 MMC are now configured in the Topology Builder and you will not find those items here. Take a review of the categories on the left hand side.

Users – self explanatory

Topology – no IP, certificates or anything like that. But you can start/stop, view replication, view settings, etc. This is where you go to drain a server.

IM and Presence – URL and File filter.

Voice Routing – Dial Plan, Voice Policy, Routes, PSTN Usage, Trunks, and a rudimentary Voice Route helper. You can export and import configurations from here. But only for voice elements, not the entire system.