List all users and devices – Lync 2013

I recently published a post with a short script that creates an automated Excel file that lists all your Lync users. This file can be used in documentations and to find all your assigned phone numbers.

Getting some feedback from users and colleagues, I updated the script and it can now show all the users, common area phones, analog devices and Response Groups workflows in youe environment.

The Excel file is created with a separate tab for users, common are phones, analog devices and RGS workflows.

A built-in filter into every column will help you find the information you need based on registrar, analog gateway, username, etc.

Lync users

The file lists the following for each tab:

Lync users:

Display Name SIP Address Registrar Pool Enterprise Voice Line URI

Analog Devices:

Display Name SIP Address Registrar Pool Gateway Line URI

Common Are Phones:

Display Name SIP Address Registrar Pool Description Line URI

RGS Workflows:

Display Name SIP Address Line URI

Run the script from your client machine (NOT Your Lync servers), where you have Excel (At Least 2010) and PowerShell version 3.0 and above.

The script will ask you for your Lync Admin credentials and one of your Lync pools’ FQDN:

Remote PowerShell

It will then connect remotely to you server and start Excel. The script is designed to ignore certificate certificates warnings as you might be running this from a none domain-joined machine.

Download the script here.

Lync 2013 E.164 CLI and carriers (It’s that Plus sign!)

If you’re using Lync properly, you must have all your numbers in accordance with the E.164 format, as recommended by Microsoft and as often preached by Ken Lasko.

There are many benefits for using E.164, but – like any good thing – it comes with some flaws. One of these flaws when using Lync 2013 is that Lync will cease normalizing numbers that are prefixed with +.
The moment you add the ‘+’ sign to your number, Lync will consider it already normalized and will not process any more rules.

This can cause issues with some providers that require us to remove the leading ‘+’ sign from the number.
The work around for dialled numbers (Or as Lync describes it “Called Numbers”) is to use the Set-CsTrunkConfiguration command to remove ‘+’ sign at the trunk level by adding the parameter -RemovePlusFromUri $true.

This is all good for numbers Called – but what about numbers Calling? How can we manipulate the “Source” number?
If we look at a trace from Lync we can see that the destination number is stripped from it’s leading ‘+’, but the source number still has that annoying sign, although I have a rule that says it’s removing it:

With plus

The SIP invite shows the issue:
INVITE sip:3531891170170@MediaGateway.y0av.local;user=phone SIP/2.0
FROM: <sip:+35314396804;;user=phone>;epid=3DFA3756A7;tag=1e448bc93
TO: <sip:3531891170170@MediaGateway.y0av.local;user=phone>

As you can see in the image above, the ‘+’ sign is removed from the destination number, but it’s still there on my source number.
This might result on certain carriers dropping the call since they’re expecting the CLI with no ‘+’.

The workaround:

If you’re working with a gateway or a SBC, you’ll usually be able to work around this issue by stripping the ‘+’ there, simple as this.

If you’re working with Lync only and using a direct SIP trunk to your provider – it’s easy too!
The numbers are not normalized due to Lync’s lack of ability to ignore the rest of the data in the FROM line; when we’re creating normalization rules within Lync, we will usually be looking at numbers and specific characters, not the entire weird string.
The workaround then, is to treat the entire string as… a string.
I add the following rule for my “Calling Numbers” manipulation in the trunk:


This rule says that whenever a number starts with a plus and has at least 8 characters (ANY character) following it, we should ignore the ‘+’ and send only the characters:
Pattern to match: ^\+(.{8,})
Translation rule: $1
Of course, you can change that to look for more numbers if you have other rules there.

Once the rule has been placed and committed, traces look like this now:

Without Plus

The SIP Invite shows the difference:
INVITE sip:3531891170170@MediaGateway.y0av.local;user=phone SIP/2.0
FROM: “Yoav Barzilay”<sip:35315267877;;user=phone>;epid=3DFA3756A7;tag=c9b24cf3b
TO: <sip:3531891170170@MediaGateway.y0av.local;user=phone>


Lync 2013 November 2014 update

As part of the full Office 2013 update dated November 11, 2014 (See here for full details), Lync 2013 clients gets an update as well, KB2899507.

The update fixes the following issues:

  • Video freezes consistently for two second-intervals when you make a video call in Lync 2013
  • Incorrect format of string in a trace statement when application sharing session viewers stop viewing in a conference
  • Memory leak occurs when you start a peer-to-peer application sharing session in Lync 2013
  • Lync 2013 crashes when you join a meeting that is hosted on Lync Server 2010 as an anonymous user
  • Lync 2013 freezes when a toast notification of a call appears

32bit update
64bit update

More information here.

Understanding: Lync client Configuration Information

We use many tools to troubleshoot Lync.

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:

Notification AreaHit Ctrl and right-click the Lync icon, then choose “Configuration information”:

Lync Configuration InformationA new window will open up, showing you your client’s configuration:

Configuration Window

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.
Exum URL 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 Server 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.
GAL Status This field shows which server was used to download the address book and if it was successful.
Focus Factory 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.
Line 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.
Location Profile 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.
Exum Enabled will say “TRUE” if you’re enabled for Exchange UM or “FALSE” if, well, you’re not.
Controlled Phones 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.
Telephony Mode 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”.
Configuration Mode “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
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.
Pairing State 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 Information “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 Information “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.
License State 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
pChat URIs Will display all Persistent Chat URIs
pChat Default URI Will display the defualt Persistent Chat URI
pChat Enabled? “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.


Assign Lync Policies to Lync users based on Active Directory Group membership

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.

Verifying permissions

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:

1     Voice Policy
2     Client Policy
3     External Access Policy
4     Mobility Policy
5     Archiving Policy
6     Hosted Voicemail Policy
7     Client Version Policy
8     Conferencing Policy
9     Voice Routing Policy
10     Location Policy
11     PIN Policy
12     Presence Policy
13     Persistent Chat Policy
14     Dial Plan

When you choose the type of policy you wish to apply, the script will display the User-scope policies that can be assigned:

2_chosen2After choosing the policy you wish to apply you’ll be prompted to confirm the operation:

Confirm applying policy2

If confirmed, the script will run through all the users in this group and assign the policy.


  • Use at your own risk – We tested it, but make sure it works for you too.
  • We’re working on the next version in which you’ll be able to reset a certain groups’ policy to “Global” (-PolicyName $null)
  •  We’re working on some reporting for the next version.

Please use and share and give us your feedback!

September 8, 2014, Vesion 2.4.2:
– Fail sae warnings and indications.
– Error messages cleared.
– Anility to default a group to the Global policy.

Download the script here.



My adventures with the Lync Edge AV service

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:

TCP Handshake

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:

lync.exe TURN TURN:TURN:Allocate Request {UDP:59, IPv4:58}
lync.exe TCP TCP:Flags=......S., SrcPort=10963, DstPort=HTTPS(443),
lync.exe TCP TCP:Flags=...A.R.., SrcPort=HTTPS(443), DstPort=10963,
lync.exe TCP TCP:Flags=......S., SrcPort=10851, DstPort=HTTPS(443),
lync.exe TCP TCP:Flags=...A.R.., SrcPort=HTTPS(443), DstPort=10851,
lync.exe TURN TURN:TURN:Allocate Request {UDP:59, IPv4:58}
lync.exe TURN TURN:TURN:Allocate Request {UDP:59, IPv4:58}
lync.exe TCP TCP:Flags=......S., SrcPort=10963, DstPort=HTTPS(443),
lync.exe TCP TCP:Flags=...A.R.., SrcPort=HTTPS(443), DstPort=10963,

Digging a little dipper into the TURN Allocate Request, we can see all the right details:

Frame: Number = 194, Captured Frame Length = 232, MediaType = WiFi
+ WiFi: [Unencrypted Data] .T....., (I)
+ LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
+ Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
+ Ipv4: Src =, Dest =, Next Protocol = UDP, Packet ID = 22808, Total IP Length = 168
+ Udp: SrcPort = 8588, DstPort = 3478, Length = 148
+ TURN: TURN:Allocate Request

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:

Media Relay Driver

I uninstalled it, ran Bootstrapper again, and retried the connection. The result was clear:

lync.exe TURN TURN:TURN:Allocate Request {UDP:40, IPv4:39}
lync.exe TURN TURN:TURN:Allocate Request {UDP:45, IPv4:39}
lync.exe TLS TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:47, SSLVersionSelector:46, TCP:44, IPv4:39}
lync.exe TURN TURN:Control message, TURN:Allocate Error Response {TCP:41, IPv4:39}
lync.exe TURN TURN:TURN:Allocate Error Response {UDP:45, IPv4:39}
lync.exe TURN TURN:TURN:Allocate Response {UDP:40, IPv4:39}
lync.exe TLS TLS:TLS Rec Layer-1 HandShake: Server Hello. Server Hello Done. {TLS:47, SSLVersionSelector:46, TCP:44, IPv4:39}

Almost Immediatley you can see that the application is responding and we can get both the TURN:Allocate Response and the TLS sessions complete.

Remember this next time you’re having issues with the Lync Edge AV service.

Windows Phone Lync 2013 App update – April 2014

Woke up this morning with an update to the Windows Phone Lync app 🙂

This update brings the app to version 5.4.1087.0.


First thing you can see is the GUI change. There’s no more a screen for your profile, instead, the user’s photo is on the right side of the screen, and touching will activate the user menu:


You also have the option to see your favourites in a different screen:


I must admit the app seems a little faster, but maybe it’s just wishful thinking.

Most sharing features work, such as PowerPoint, Program sharing and desktop sharing:

Polls, Whiteboard and Q&A cannot be viewed on this app.


Download the app here.

Compare Lync users’ policies script

Had the privilege to help a friend and a colleague, Guy Bachar, owner of the Just a Lync Guy blog, writing the following script.

This script helps admins compare the policies of two Lync users and see the differences between them:

Policy comparison

The output is pretty clear and displayed on the screen. We’re working on an exportable version as well… 🙂

Comments and suggestions are welcome!

Download the script here.