This diagram is important in any Lync discussion as it shows exactly the ports and protocols required for Lync Edge servers and Reverse Proxy, and the traffic flow between the DMZ and the LAN.
However, I find it a little outdated (Office Web Apps missing) and sometimes I need a little more space to draw some stuff and write down IP addresses and other stuff when meeting with customers and colleagues.
I drew an updated, more spacious one for my use, shared with your here:
the “Lync Configuration Information” option on the Lync client actually provides a lot of useful information about how the client connects to the server and can help identifying issues.
To access the Lync client’s configuration information, go to your computer’s Notification area and look for the Lync icon:
Hit Ctrl and right-click the Lync icon, then choose “Configuration information”:
A new window will open up, showing you your client’s configuration:
This Windows will provide you with all the information your client is retrieving from the server and from your settings. You can copy the contents of this windows to a text editor by clicking “Copy”, or close it by hitting “Close”. “Refresh”, however, will surprise you and do nothing. If you want to refresh the information displayed in this window you’ll have to close and reopen it…
Let’s cover this Windows’s contents line by line. Note you might not have all the information populated. This might depend on your actual implementation or connection state:
DG URL Internal
Lync Server 2013 will populate the Lync address book with all the Distribution Groups it finds in your Environment. If in the organization’s network, your client will use this URL to connect to the server and expand these groups to show theirs members. This should normally point to the address of your Front-end pool or server.
DG URL External
Same as DG URL Internal, only for external users. Your client will use this URL to connect to the server and expand these groups to show their members when you’re connected to Lync from outside of your organization’s network. This should normally point to the address of your Reverse-Proxy server, representing Lync’s External base URL.
Quality Metrics URI
This should represent the address of the Front-end server you’re connected to. The Front-end server will in turn use the MSMQ feature to send your quality metrics to the Monitoring Server. If this field is populated, it means you have monitoring enabled for the pool you’re connected to.
ABS Server Internal URL
If configured to download the Lync address book via web service, your client will use this url when connected inside the oraniztion’s network.
ABS Server External URL
Your client will use this url to download the Lync address book when connected outsidde of the oraniztion’s network.
Voice mail URI
This string shows how other clients and services are calling your voicemail.
This field represents how calls are routed to your mailbox. It would normally show a familiar dial plan’s name or just say “destination=default”. Having this fileld populated usually means you’re enabled for Voice mail.
MRAS stands for “Media Relay Authetication Service”. This service provides your credentials to the AV Edge Server. when this field is populated, it means you successfuly authenicted against the AV Edge server.
This field shows which server was used to download the address book and if it was successful.
The “Focus Factory” is where all your conferences are created. The server will use the URI listed in this field when you create a new conference or Lync Meeting.
This shows your line URI.
Line Configured From
“Line configured from” shows where the line was configured. In this case, the line was configured on the server.
This setting is actually pulled from your Exchange server, and represents the location profile of your Exchnage UM Dial plan.
Call Park Server URI
If you enabled Call Parking for this environment, your call park server URI will be displayed here.
Server Address Internal
If you configured your Lync client to use a manually entered internal address (see This post), the configuration will be displayed here. Note that even if you switched to automatic configuration but haven’t cleared the names, it will still be displayed here.
Server Address External
Same as Server Address Internal, but for external access addresses.
Server SIP URI
Denotes the SIP uri that’s signed against the server.
will say “TRUE” if you’re enabled for Exchange UM or “FALSE” if, well, you’re not.
This will display your phone’s model if you have a Tanjay-compatible device connected.
GAL or Server Based Search
Depending on your Client Policy Configuration, this will display whether you’re retrieving the adress book using the web service or the Lync Shared Folder.
PC to PC AV Encryption
Should usually say “AV Encryption Enforced” unless you changed it to “DoNotSupportEncryption” or “RequireEncryption” on your Media Configuration settings.
This will display either “Telephony Mode UC Enabled” if you’re Entreprise Voice enabled, “Telephony Mode Disabled” if you’re set to PC-to-PC only, “Telephony Mode No Audio” If you have Audio/Video disabled, “Telephony Mode RCC Enabled” if you have RCC turned on, or “Telephony Mode RCC Only” if you enabled RCC only for this user.
Line Configured From
I have only seen this one set as “Auto Line Configuration”.
“Auto Configuration” means you’re set to automatically find and connect tho the server. “Manual Configuration” means you’re using the values provided in “Server Address Internal” and “Server Address External” to connect to the server.
EWS Internal URL
This should point to the internal url of your EWS virtual directory, i.e. your internal Exchange CAS or CAS Array. If this setting is misconfigured (automatically retrived from Exchange), you might not be able to access Outlook free-busy from you Lync client and Lync phone.
EWS External URL
Points to the address of your external EWS virtual directory, based on the settings of your organizations’ Exchange Autodiscover configuration. If you’re using Office 365 Exchange Online, you will see only this field populated, pointing to https://outlook.office365.com/EWS/Exchange.asmx/WSSecurity.
SharePoint Search Center URL
points to your organization’s SharePoint Search Center URL if you configured Lync-SharePoint integration.
Skill Search URL
points to your organization’s SharePoint Skill Search URL if you configured Lync-SharePoint integration.
Connected Lync Server
Shows which server you’re connected to at the moment.
Local Log Folder
Shows the location of the Lync logging folder. This usually points to %userprofile%\AppData\Local\Microsoft\Office\15.0\Lync\Tracing.
Inside User Status
If set to “TRUE” – the user is connected directly to a Front-End server or a director. If set to “FALSE” – the user is connected to the organization via the Edge server.
Contact List Provider
Will display “Lync Server” if Lync is providing the contacts list, or “UCS” if Exchange Unified Contact Store provides it.
Will determine wehther Pairing is enabled or not, and will display the phone’s model if paired.
UCS Connectivity State
Will display “Exchange connection Down” if UCS is not your Contact List Provider or if Lync can’t make a connection to the UCS.
“MAPI OK” means Lync was able to communicate with Exchange via Outlook. “UCMAPI is connected to Outlook, but one or more folders are not updating.;MAPI unavailable” means either the Lync user and the Outlook profile don’t match, or Outlook is closed.
“EWS Status OK” means Lync was able to contact Exchange through EWS, “EWS has not fully initialized” means it’s in the process of Autodiscovering EWS, “EWS not deployed” meand Lync was not able to communicate with Exchange via EWS.
Shows if Lync is licensed and what sort of licesnse is assigned.
Hanging Notification Status
This will either appear as “Connected” or “Disconnected”, any input on this field is appreciated!
pChat Room Mgmt Int URL
Denotes the internal url for Persistent Chat Room Management
pChat Room Mgmt Ext URL
Denotes the external url for Persistent Chat Room Management
Will display all Persistent Chat URIs
pChat Default URI
Will display the defualt Persistent Chat URI
“True” means you’re Persistent Chat enabled and the above filelds shoud be populated. “False” means you were not enabled for Persistent Chat, and the above fields shoud be blank.
Published: July 7, 2014.
Updated: September 8, 2014
I’ve been looking for this functionality for quite some time, and with great help from Guy Bachar, we created the following script to help assign Lync policies to Active Directory Security Groups.
This version of the script allows assigning user-scope policies to any all Lync enabled users in a certain Active Directory Group.
The process is easy:
Run the script from a computer or a sever that has both the Lync Management Shell the Active Directory PowerShell Module installed. If they’re not there – The script will let you know.
As you run the script, it will automatically check if you have local admin privileges on this machine and will prompt you to elevate your PS session if you didn’t choose “Run As…”. Many thanks to Ben Armstrong for creating the self-elevating script. We changed it to match our needs here.
If all is ok, the script will next ask you to choose your desired AD group: Enter the group’s display name, and in return the script will show you its CN, just to make sure it’s what you’re looking for:
The script will immediately ask you to choose which type of policy or dial plan you would like to assign from the following 14 options:
A call came in last week from a customer that’s using Lync 2013 on premises and Exchange Online. “We can’t reach our voicemail anymore”. Lync to Lync calls, PSTN to Lync calls, none could be forwarded to the Office 365 UM services. Funny enough, if I wanted to leave them a voicemail (being a federated partner), I managed to do so without any problem.
That did make sense in a way, since I’m being forwarded by Office 365 to contact the UM servers directly when using Lync. Then again, this would not solve the internal issues.
First discovery I made was that the Edge server in unable to resolve any external DNS queries. Having some firewall changes lately, I blamed it on the firewall and waited for that to be tested again. Indeed, something was preventing the Edge from sending DNS queries to the internet. That’s fixed now, but still – same issue. Additionally, it was not affecting only communications with the Office 365 UM service, all external communications that required the usage of the AV service failed.
Needless to say, throughout the entire process – No errors on the Edge server. Management store replication is ok, certificates are ok, server is patched, restarted – It’s all dandy and happy in Edge kingdom.
I insisted on rechecking all the firewall rules again – all seemed to be in place. I used James Cussen‘s great tool to test Edge connectivity – All results were successful.
After examining the UCCAPI log files of the clients and tracing the Edge server’s logs – everything was still ‘working’ as far as the Edge server was concerned. We could see the SIP traffic working perfectly (plus, we had IM and presence functioning), and the sessions would only drop as soon as the other party “picked up” the call.
This is where things are getting a little interesting. Back to Networking 101, if I’m testing a TCP connection – I will only accept the session as “Successful” if the handshake is completed:
This means that if the service is not responding, I will not get the server’s ACK, and the connection will time out.
When using UDP, it’s a different story:
So “testing” a UDP service might be a little tricky…
This had me suspicious about the AV service, being the one in charge of our RTP traffic.
With no other options left, I started tracing the actual UDP sessions.
Here’s how it looks when the AV service is not cooperating:
This is where I should be getting back a TURN:Allocate Response from the application. Yet, no reply.
Tried stopping the Edge AV service – it said “Stopping” for 30 minutes but never stopped, even when using the -Force switch. Trying to kill the process and the task was unsuccessful either.
This is where I tried to remove the Lync Edge components from “Programs and Features”. This failed as well, saying there was a problem with the “Lync Server Media Relay Driver” on the Local Area Connection interface.
Immediately went to “Network Connections” and what do you know?! This is what I see:
I uninstalled it, ran Bootstrapper again, and retried the connection. The result was clear:
There are many factors in this equation, and each one has its own influence on the final result. I found out what works for most of my implementations, using the following configurations:
I use a direct SIP trunk to an ITSP – walking through firewalls and dedicated routes, but no gateways along the way. I found that converting traffic from analogue to digital to analogue is usually a guarantee to break the connection.
My ITSP is NOT Microsoft certified. I can use either TLS or TCP SIP, as long as it works.
For any analogue device you’re going to connect to Lync, you’ll need an analogue translation and port. an ATA (Analogue Telephone Adapter) is a small box that knows how to do just that. I usually use AudioCodes MP series ATAs.
If I do use a gateway to the PSTN, I’d prefer taking all fax calls and redirect them to FXS ports on the gateway before they arrive to the Lync Mediation server. This way it stays analogue all the way. . I’d strongly recommend having these ports on your gateway as there’s always a use for an extra analogue interface. Trust me.
So Basically, in an ideal Lync implementation, you’ll have the following:
So by now you probably have all of the above, just need to make sure it works. As soon as you have the ATA configured as an additional PSTN gateway, you can go ahead and add the analogue device.
First let’s start with adding the fax as an analogue device:
New-CsAnalogDevice -LineUri tel:+35315556789 -DisplayName "Your Fax Description" -RegistrarPool LyncFE.domain.local -AnalogFax $False -Gateway <Gateway IP or FQDN> -OU "OU=LyncDevices,DC=domain,dc=local"
Now you’re not wrong: It says -AnalogFax $False for a reason. I followed James Cussen’s interesting and very detailed post on connecting fax to Lync, and tested all options until I figured out which one works for me.
Next thing would be to configure your AudioCodes ATA. Assuming you’re comfortable with configuring its IP and DNS settings, I’ll only go through the settings relevant for the fax to work:
Configure Lync as your ATA’s next hop. Go to VoIP-> SIP Definitions-> Proxy &Registration and Choose “Use Default Proxy” and click the small arrow beneath it to enter your Mediation server’s details:
Then enter your Mediation server’s FQDN and choose TCP for protocol:
For fax to go through I configure all fax coding to use G.711:
Go to VoIP-> Media-> Fax/Modem/CID Settings and configure Fax Transport Mode to ByPassEnable.
I usually disable all the other settings as a precaution, but you don’t have to do that. Set your Coder type to Alaw or Ulaw, based on your location:
Next, go to VoIP-> Coders And Profiles -> Coders and set your coder to Alaw or Ulaw based on your location:
On the same pane, scroll a little down to Tel Profile Settings and configure the Fax signalling Method to G.711:
And one more on the same pane, go to IP Profile Settings and configure Fax signalling Method to G.711:
Now, configure your fax number for the ATA port you’re going to connect it to. On the following screenshot, I configured port 1 to use the number +35315556789. Remember to use the exact same number you used when ran the New-CsAnalogDevice command, as this is the exact number tat will be sent to the ATA. If the number is different – the ATA will reply with “Number can’t be found”. This is done at VoIP-> Hunt Group-> EndPoint Phone Number:
Next, to allow outgoing faxes through Lync, we’ll need to configure where analogue traffic is going to. Go to VoIP-> Routing-> Tel to IP Routing and configure the IP and port of your Mediation server:
That’s about it. Fax should be going in and out.
AudioCodes uses an INI file to save the configuration of your ATA. Alternatively, you can upload a file with most of the configurations already done for you and only change the relevant settings.
I created an INI file with all the above configurations, all you’ll have to do is change the IP addresses and names and you can upload it to your ATA to only configure the Endpoint numbers.
Open the INI file with a text editor and search for anything that start with <Change Here = >. Replace the existing values with your values and reboot the ATA.
Microsoft announced the release of the March 2014 Lync App update.
This update brings some cool new features, but I had to force the update through the Windows Store. Eventually, it showed up:
Once installed, the first thing you can see is the change in the log-in screen. Guest log-in is now below the user log-in:
Once logged in, Lync will tell you it was updated:
The first change you see is the big “Meet Now” button on the left:
As soon as you touch it – it launches a new meeting. Unfortunately, you can’t see the meeting entry info like you do with the Desktop client, but you now have the option to invite people using the people menu:
Control over participants is easier and useful:
One more nice thing is that now you have all the controls at the bottom of the screen: