Using the Analog Device Creation Script

Last week I launched a new script on the script center to bulk create analog devices in Lync.  This script uses a source CSV file (reference file included in the download) to create a large (or small) number of analog devices.  The zip also includes a “readme” detailing how to run the script, but in case it wasn’t clear, I wanted to cover a few of the fields in this article.

The first field I want to cover is the “LineURI” field.  This field is used to establish the phone number of the analog device.  Once the analog device object has a number listed here, Lync will use that number to route to it (via the analog gateway or ATA).  It is important to include the “tel:+” in this field, followed by the full number, without any spaces, dashes or periods. For example, the number 513-555-1212 would be entered as shown below:

Next, we have the “Gateway” field. This one can either be the name or IP address of the analog gateway that the analog device is plugged into, not your PSTN gateway. For example, if my analog gateway was 192.168.1.5, I would enter it as show below:

Finally, I want to cover the “OU” field.  This field defines which OU in your domain the analog device object will be created in.  For example, lets say I have an OU named “LyncAnalogDevices” in my AD domain, “contoso.local”:

I would populate the “OU” field entry with “ou=LyncAnalogDevices,dc=contoso,dc=local”.

Other than those items I think the readme covers everything but if you have questions feel free to post them here.

Script Center

Hi All,

I’ve added a script center (link in the bar above) to the site and will be adding a number of new scripts shortly.  All scripts will have a transcript feature and will be digitally signed so hopefully they run without issue for you.  If you have suggestions for new scripts or find a bug, please post in the comments section below.

 

Enoy!

-kp

Troubleshooting CMS Replication

Like most of my other articles, this one comes from a real world scenario I had to solve.  While working with a client, we ran into two front end servers and an edge server
that wouldn’t replicate.  The CMS was hosted in another country with plenty of firewalls in between, which definitely complicated the issue.  However, the root cause wasn’t a network issue or firewall.

We started by tackling the front end servers, two out of four front end servers in a pool were showing out of date in the topology.  From the server hosting the CMS I verified I could ping each front end server by name and to my surprise I could also telnet to them on port 445.

Depending on your level of familiarity with CMS, at this point you may be wondering why port 445?  The server hosting the CMS will push the data to all replicas in the topology (other than edge) using SMB[4].  For more information on CMS, please have a look at Jens’ blog here, it goes into great detail.

Since we knew the path used to connect was valid and the server was listening for the connection, the next thing on my list was a packet capture to see what was happening.  I started a packet capture using NetMon, and ran the invoke-csmanagementstorereplication
CMDlet to kick off replication.

After capturing data for 30 seconds I stopped the capture and applied a Display Filter so I could look at the SMB traffic first.

It didn’t take long to figure out what was going on from here; there was “Access Denied” all over the logs.  I tried to view the properties of the RTCReplicaRoot folder (by default this folder is on the root of the drive Lync is installed on), but didn’t have permission.  Although this would seem like an error, it is actually expected behavior and it is best not to try to modify permissions to this directory.  At this point, we discussed the build process with the client and determined a security script meant to tighten NTFS permissions had inadvertently broken CMS replication for those two servers.  Instead of trying to fix the
NTFS issue and risking other problems down the road, we removed the boxes from the topology, re-installed the OS, and added them back as Lync servers after a clean rebuild without the security script.

Now that all the front ends were replicating, it was time to find out what was going on with that edge server.  The customer had rebuilt this server as well, assuming the script had caused the same issue on it, but we soon found out that wasn’t the case.  To start troubleshooting I ran a network capture and this time I filtered for traffic on port 4443 since the edge server receives its updates via this port over https, not 445/SMB like the front ends.  After verifying traffic was coming in on the appropriate port, I couldn’t do much more with network captures since the traffic was encrypted.  My next step was to begin logging on the server hosting the CMS, grabbing logs for all three of the CMS related
services.  One thing of note here- when you are trying to troubleshoot CMS issues, you won’t see CMS listed in Lync Server Logging Tool.  However, you will see XDS- that’s the guy you want to log.

I started logging of all three XDS options with all flags, all levels, as shown below:

Next I ran the invoke-csmanagementstorereplication CMDlet with the –ReplicaFQDN parameter to limit the replication to just that one machine.  I let the log run for about 30
seconds and then stopped it.  I started by analyzing the FTA (File Transfer Agent) logs.  As a quick hint, these logs are in trace format which is a bit harder to read than the messages format but you do have yellow and red highlights to indicate warnings and errors.  Also, the search comes in quite handy.  I ran a search for the edge servers name and while viewing the results I found a yellow bar (warning).  I clicked on the yellow bar and saw my problem almost immediately:

In the log we see the error “Failed to copy files from Replica” and “Invalid certificate presented by remote source”.  In this case, the “remote source” is actually our server hosting the CMS (seems a bit backwards).  This means our edge server doesn’t trust the certificate the CMS is using.  In a more simplistic install, that may not be a huge issue but in this case there were a number of intermediate CA’s and tracking down all the certificates one by one and reviewing everything wasn’t going to be much fun.

That’s when my good friend Paolo from Microsoft, whom I just happen to be IM’ing about the issue, let me in on a cool little trick.  We exported the certificate from the server hosting the CMS (without the private key) and copied the file to the edge server (C:\tmp\CMSCert.cer).  From acommand prompt I ran the following command:

Certutil -verify -urlfetch “C:\tmp\CMSCert.cer” > c:\CRL.TXT

This command runs a check on the certificate (including accessing the CRLs) and dumps the results to a text file, it may take a few minutes to complete.  After reading through the text file we found the information we needed:

This told us exactly what certificate was missing and we were able to get it installed and the edge server started replicating.

To wrap this all up, I’d recommend running through the following when CMS replication isn’t working:

1. Ping from the server hosting the CMS to the host that isn’t replicating
2. Telnet from the server hosting the CMS server to the host that isn’t replicating (port 445 for all servers except edge, which is 4443)
3.  Network Capture to see if the traffic is making it and to look for possible SMB errors
4. XDS logging on the server hosting the CMS, review with Snooper
5. CertUtil – using the commands above will test the CA chain all the way through to verify trusts.

Hope this helps!

Southwestern Ohio UC Users Group

Hi All,

A non-technical post for today.  Adam Curry, Travis Swank and I are working to start a UC Users Group based out of Cincinnati.  We have scheduled the first meeting and have a website live at www.ucusersgroup.com.

The first nights content will start with an Office 365 overview and move into technical content focusing on the edge roles.  Food and drinks will be provided.  Please join us for an evening of networking and learning new things about Lync.

-Kevin

Group Policy Configuration May Break Presence in Lync

Today, I feel like Bill Murray in the movie Groundhog Day.  While working with a customer on a Lync pilot, I ran into an issue where Users on the Lync Pool could not see Presence for Users on any other Pool.  The user would see “Presence Unknown” for all Contacts on Pools other than their own as shown below:

This was a little bit different than the last time I saw the issue. This time the Users couldn’t see Presence for existing Contacts.  This only impacted Users on other Pools though, not Users who were homed on the same Pool.

After a quick email exchange the customer removed the policy “Configure SIP compression mode” that had been set to “Based on ping round-trip time” as shown below:

After the policy was removed users could see presence for all contacts again:

I have reported this issue to Microsoft and hopefully the KB published last time will be updated to include Lync.

Logging on a Lync Enterprise Pool

Building a Lync Enterprise Pool allows you to protect your users and services in the event of hardware or software failure on one (or more) servers in your pool.  While this is great for redundancy, it can make troubleshooting a particular user error a little more complicated.  For example, if you have eight servers in your pool, logging on to each one can create a lot of additional work just to troubleshoot a problem; especially if it is just for
one user.

As an example, at a recent customer deployment, Federation wasn’t working for users on a new Lync Pool. This was a large and rather complex environment that was still in co-existence mode with OCS R2 and I didn’t want to have to dig through a bunch of logs.  But have no fear, PowerShell came to the rescue!

The following command will tell me to which server(s) my Lync client will connect, and in which order (the command should be all on one line)

Get-CsUserPoolInfo –Identity “user” | Select-Object –ExpandProperty PrimaryPoolMachinesInPreferredOrder

Here is a sample output from my lab:

In the example above, the user will first connect to “1:1-2” which is EE2.contoso.local.  If for any reason that server is unavailable, the next server tried will be ee1.contoso.local.  If the user’s home server is up and running, their Lync client will connect to it.  This allows the administrator to run Logger just on that server for troubleshooting purposes.  This will make your job a little bit easier.

To put this to test, we’ll go through the process.  My lab has a DNS load-balanced Enterprise Edition Pool with servers EE1.contoso.local and EE2.contoso.local.  The SIP Domain is contoso.com and I have 2 DNS A records for my pool as indicated below:

For my first sign-in I have manually configured my client to
use “eepool.contoso.com” as its logon server.

I’ve also enabled logging so we can examine the results in Snooper.  By default the logs can be found in %userprofile%\tracing and will be named “Communicator-uccapi-0.uccapilog”.  This file can be opened with Snooper.  Snooper is available from the Lync Resource Kit available here.

Now let’s break down the SIP traffic.  First we see our initial Register.  Notice that
the client attempts to talk to 10.255.106.152 (EE1)

After the initial Register you will see three “401 Unauthorized” messages.  This is normal
as the client has not authenticated yet.  After the three “401 Unauthorized” messages, you will see a new Register attempt.  This time with an authentication type set.

After the Lync clients has authenticated to EE1, we immediately see a “301 Redirect Request to Home Server”.  This tells our client that it should connect to EE2.contoso.local (the preferred server) since it is online and servicing clients.  We can tell EE2 is our
preferred server by the “q=0.7” section at the end of the first “Contact” line.

In the screen shot above we also see a second “Contact” entry with “q=0.3”.  This tells our
client its Backup Registrar is “se.contoso.local”.  The Backup Registrar can be a Lync Standard Pool or an Enterprise Pool in a backup datacenter.

Now that our client knows which server it should talk to, we attempt to register to the new server. As in the previous case, the client will receive three “401 Unauthorized” errors before it successfully registers using TLS authentication.

If for any reason our preferred server is not available, we will attempt to connect to all other entries listed in the order shown in the first screen capture above.  If our pool
is down, our client will connect to the backup pool after the failover interval has elapsed.

Now that we are sure which server we are connecting to, we can log in and run the logging tool to troubleshoot any issues:

I’ve chosen to log the SIP Stack as you can see in the screen shot below:

After I’ve started and stopped logging, I can click the “Analyze Log Files” button and as long as snooper is installed, I’ll be able to jump right into troubleshooting from the server.

Some great reference material is available on what I’ve covered in the following links. I highly recommend these articles:

Another Reason to Include a Director in Your Lync Server 2010 Deployment

Haiku #120 – Lync Powershell

DNS Load Balancing in Lync Server 2010

Get-CsUserPoolInfo – Technet

Introducing the OCSGuy_QuickUI

This is a utility I wrote to provide a GUI for common power shell tasks.  This is a version 1 utility and I do expect to update it semi-frequently.  The entire utility is included in a single .ps1 file and does not require an install; it should be run from a Lync server, though.   Please feel free to download the utility, unzip it, take a quick look at the very short readme and give it a try.  If you’d like to see a new feature or find a bug, please feel free to comment below.  Please be patient as I will be adding features and fixing bugs in my spare time.

The current features include:

Install Lync 2010 Pre-requisites for Server 2008 R2

Export Topology File for Edge Installation

Upload Phone Firmware

Create a Reverse Proxy Certificate Request (Web Services Certificate)

Enable Meeting Join from Legacy Client

Enable Attendee Download Link on the Meeting Entry Page

Enable Lync Federation with Office 365

Enable 720P Video with MSN/Live – (Global Policy Only)

Increase the Number of Distribution Lists Allowed in Contact List – (Global Policy Only)

Download Here

Thanks to a few folks are in order for assisting me with writing this.

Adam Curry

Pat Richard

Nick Nelson

A Few Words on Federation

Recently, while creating some documentation for an install it struck me that federation may be a bit confusing if you aren’t working with Lync on a daily basis.  With that in mind I’m writing this article in hopes of clearing up some common questions I hear around federation during deployments or see on the forums.

First of all, if you’re not sure what all of this federation stuff is about, there is a good overview here, but basically federation is the process by which we connect our Lync/OCS/LCS environments to other Lync/OCS/LCS environments, such as our partner companies.  This connection allows users to easily communicate with users in other companies utilizing all the same modalities they have with users in their own environment (IM, Audio, Video, Desktop Share, etc….).

In Lync 2010 there are 3 types of federation: Dynamic, Enhanced and Direct.  Picking which one is right for your partner companies is where it starts to get a little tricky.  I won’t go into great detail about how to configure your edge server for federation in this article, but you can reference this article if you’d like more information there.  Instead, I’d like to focus on choosing one of the 3 types of federation and the benefits of each.

We’ll start with dynamic federation.

Dynamic federation is a method where a partner company’s edge server is discovered by looking up an SRV record (_sipfederationtls._tcp.domain.com).  Dynamic federation is perfect for an environment where users may need to add contacts from other companies quickly and without administrative intervention.  The firewall will have to allow inbound connections to the access edge server on port 5061 from any potential partners, but for most companies who use open federation, they allow traffic from everywhere on this port to prevent needing administrative assistance.

There are a couple of limitations on Dynamic federation, first when a partner is discovered via dynamic federation; limitations are put on how many SIP messages (20) can be received per second by that partner.  Also, there is a limit of 1000 contacts per federated contact.  Last, but not least, if you discover a partner via dynamic federation, the A record and certificate for their federated access edge must match the sip domain of the user.   It is very common to see 14607 warnings in the event viewer of your edge server if you are discovering partners via dynamic federation.  This is expected behavior but can be modified by using one of the 2 other types of federation.  Here is a look at that error:

If you would like to cross the 20 SIP messages per second mark, the 1000 user per partner mark, or be a little pickier about whom you federate with you can use Enhanced Federation.

Enhanced Federation requires that you add your partners SIP domain to the “Federated Domains” list in the Lync control panel.  However, you do not need to add the FQDN of their access edge server.  Enhanced federation is not limited like dynamic federation so you will no longer have a cap on the number of messages or users.  However, if you configure a partner via enhanced federation, the A record and certificate for their federated access edge still must match the sip domain of the user.  Here’s a screen shot of how to configure enhanced federation

Last but not least we come to Direct Federation.

Direct Federation just like enhanced federation, has no limit on the number of messages or users, but there is one big difference.  If your partner company has an access edge server with an FQDN that doesn’t match the SIP domain, you can still federate.  You will just need to put the FQDN of the access edge server and the domain name in like in the screen shot below.

The nice thing about Lync, is you can still utilize all 3 options, for example at my company we have enabled dynamic federation, but still utilize enhanced and direct federation for partners once we start seeing the 14607 errors start showing up.

That covers how you configure the different types of federation in a Lync environment; I did not however, cover federation with the Office 365 cloud.  Federation with the Office 365 cloud is done via the Hosting Provider tab and works much like direct federation.   For more information on that have a look at Tommy’s article here.  There may also be additional consideration around firewall rules based on your company’s decision on which way to configure federated partners.

Hope this helps!

Lync Client Conversation Translator

Today we have a guest post by one of my colleges in the Unified Communications practice at PCMS, Adam Curry.  Hope you enjoy!

Here is a really intriguing and interesting extension of the Lync 2010 client found in the Lync SDK called the “Conversation Translator.”  By using Silverlight and Bing’s translator feature, you can have a real-time conversation with someone in a completely different language.

The Good Stuff

• It’s free!
• You are able to have conversations with anyone in literally any language.
• It’s great for international companies.
• It can easily be pushed out to all client machines by using MS System Center.

The Bad Stuff

• It’s still a translator.  The translations may not always be 100% correct due to regional slang from certain countries.
• You have to have the “Conversation Translator” open prior to receiving the foreign text.

Thankfully, you don’t need to grab the Lync SDK and compile the Conversation Translator as the heavy lifting has already been done.

How to Install

Create the registry key by opening a new Text file and copying the following:

***(code block the reg)

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Communicator\ContextPackages\{54C2C31A-A291-4DFA-825A-18994EBE9877}]

“Name”=”Conversation Translator”

“ExtensibilityApplicationType”=dword:00000000

“ExtensibilityWindowSize”=dword:00000001

“DefaultContextPackage”=dword:00000000

“InternalURL”=”http://input.microsoft.com/translator/OCTranslatorTestPage.html”

“ExternalURL”=”http://input.microsoft.com/translator/OCTranslatorTestPage.html”

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoft.com\input]

“http”=dword:00000002

Save the Text file and change the extension to .reg file.  If you currently have the Lync 2010 client open, close it.  Once closed, double click on the .reg file to import the keys into the registry. Now, you  go ahead and start the Lync 2010 client and you’re ready to use the extension.

How to Use

The basic premise of the extension is to automatically translate incoming IMs and preview and send outgoing translations to the recipient.  Think of the extension as “injecting” itself into the conversation, saving you the necessary steps of copying and pasting from a translation website.

Start the Lync Client.  If you go over to the side menu, you will see a “Conversation Translator.”

Select “Conversation Translator” to open the extended IM window.

Now you have an extended IM window that will inject itself into the IM conversation.  Note, it will not translate any IMs prior to opening the “Conversation Translator.”  Another important step is setting your language and the recipient’s language.  Below, shows some of the different languages that you can select.

Example Time

The following is a pretend conversation with a person located in Germany.  Kevin is having a problem with his mailbox that’s located in Munich.  He wants to get a hold of I.T. that’s located in the U.S. Instead of using a translator within the office, he communicates his problems through Lync 2010 to Adam (that’s me!).

We get Kevin’s initial response that he is having a mailbox issue.  I have already turned on the Conversation Translator, so I was able to translate his first IM.  As we can see, we can read the original German on the left and the translated English on the right.

As I type, we can hit the button Translate to complete the translation into the other language.

After translating the language hit the Send button to send the IM to Kevin.

The extension leaves the pre-translated English into the right pane, but only sends the German translation to Kevin.  After some more back and forth with Kevin, we were able to resolve the issue.

For Kevin, this is how his Lync 2010 client looks like after our IM communication:

To Wrap Up

This is such an extremely useful extension that it’s odd to me why it would not be built-in to the Lync 2010 client.  Albeit, the translations are sometimes not 100% correct, the efficiency to communicate with people who speak a foreign language is remarkable.  Many thanks to Kevin for the guest post.

Source: http://msdn.microsoft.com/en-us/library/gg436843.aspx

Lync CU1 Released

I haven’t seen these all in one place yet so I figured I’d post them.  Happy patching!

Product	KB
Lync 2010 (64bit)	2467763
Lync 2010 (32bit)	2467763
Lync Server 2010	2493736
Lync 2010 Phone Edition (Tanjay)	2493722
Lync 2010 Phone Edition (Aries-Aastra)	2493724
Lync 2010 Phone Edition (Aries-Polycom)	2493723
Lync 2010 Attendee (Admin Install)	2467762
Lync 2010 Attendee (User mode install)	2467761
Lync 2010 Attendant (32 & 64 bit are a combined patch)	2467760
Lync 2010 Group Chat Client	2467765
Lync 2010 Group Chat Admin	2467764