Lync Snom Phone Manager

Note: Also see my Lync Snom Configuration Manager Post for more Snom related fun.

In a previous blog post I released a tool for managing Polycom VVX phones that was well received by the Lync community. So I thought that it was only fitting that I go back to the drawing board and engineer a new tool for managing Snom phones. The tool's front end works in a very similar way to the VVX manager tool with some minor tweaks and differences, however, the backend has been completely overhauled to work with Snom devices (which turned out to be a lot of work). Rightio, let's skip the chit chat and get down to the brass tacks…

Lync Snom Phone Manager

Version 1.0:

• The Lync Snom Manager has the ability to query the Lync Monitoring database (if you have one deployed) and find all the IP Addresses of Snom phones connected to your Lync server. It will then scan all the IP Addresses of Snom phones supplied by the Monitoring database using a fast multi-threaded discovery method to connect to and learn about all the Snom devices on the system.
• If you do not have a Lync Monitoring Database you can simply type an IP Range (format: "192.168.0.1-192.168.0.20" OR "192.168.0.0/24" OR add multiple with comma separation "192.168.0.0/24,192.168.1.0/24") into the listbox and press the "Discover from IP Range" button. The tool will then scan the phones using a fast multi-threaded discovery method to see if they are at each IP address in the range.
• If a Snom handset that is not logged in as a user is discovered, it will be added to the user list under the name “SnomNot@LoggedIn_<index number>”. This allows you to use the tool to access these devices even though they are not logged into Lync.
• Find out information about Snom handsets connected to a Lync system (IP Address, the Lync server that the handset is registered to, user policies, PIN status).
• Remotely reboot Snom handsets using the "Reboot" button. Reboot a selection of handsets by selecting (hold shift/ctrl) multiple users in the list, then press the ‘Reboot’ button. Or reboot all the Snom handsets on a Lync system with the “Reboot All” button.
• Remotely set a Snom phone's configuration back to factory default settings by pressing the "Reset" button. To be safe. you will be warned before this function is actually completed.
• Set the PIN for a user - either a random PIN (if the PIN field is left blank), or specify a PIN number by filling in the field. This can also be done on multiple selected users.
• Lock and unlock the PIN for a selected user with the "Lock PIN" and "Unlock PIN" buttons. This can also be done for multiple selected users.
• Easily connect to the Snom phone web interface of any user on the system by clicking the “Web Config” Button.
• Test PIN and device bootstrapping by entering a PIN number for the selected user and pressing the "Test PIN" button.
• Export your Snom phone deployment information. This outputs a CSV file that contains all the Users, IPs, Firmware Version, Serial Numbers, Lync Server, and MAC Address (if available) for all logged in phones. If you select the "More" checkbox you will also get the additional Lync settings for the phone (this is slower).
• Import previously exported phone data. This allows you to import previously exported phone data, which can save you time “Pinging” IP address ranges looking for phones. The “Rescan” option will make the Snom Phone Manager tool connect to each device in the imported list and update its information. This is to help try and avoid importing stale data with incorrect IP Addresses in it. If you trust that your phone IP Addresses have not changed from when you previously exported the data, you can untick the “Rescan” option, and all settings will be imported directly from the file (much faster but less safe).
• Variable for https connections to the Snom web interface. Change the variable $script:useHTTPS to be $true if you would like all web interface connections to use https instead of http. This will also require that you change the $script:WebPort variable to be "443" as well (or whatever port you set in the configuration file for https). These settings can also be added in a settings file if you don't want to edit the script.
• Remotely view what is showing on the screen of the phone by pressing the “Show Screen” button. This will load another window that will show you what is on the screen of the phone, and will refresh approximately every second. This feature can be useful for remotely troubleshooting issues with users' phones. Example:

Version 1.01 Update:

• Added support for common area phones. The Display Name is also shown as part of the User Information section in order to make Common Area Phone identification easier.
• Added window resizing capability.

Download Version 1.01:

System Configuration Requirements

Lync Configuration

In order to use the Snom Phone Manager, you will need to make sure that the phones have some settings configured in them. Fortunately you can use my Snom Configuration manager Tool to push these settings to the phones (rather than individually configuring each phone, or using a separate config server). The following settings need to be configured in your Lync server Client Policy PolicyEntry settings:

Web Username:

Name: snom_http_user 

Value:  snommanager

Web Password:

Name: snom_http_pass  

Value: snommanager

Authentication Type – The tool uses Basic Authentication over HTTPS

Name: snom_http_scheme

Value: off

In order to get to get to many of the configuration settings in the phone you need to set the phone to Administrator Mode. This mode has its own password setting, and if it is not changed from the default setting of “0000” there will be a message displayed on the phone screen (Admin mode password not set). This password should also be set for security reasons:

Admin Mode Password:

Name: snom_admin_mode_password

Value: snommanager

Admin Mode Password Confirm:

Name: snom_admin_mode_password_confirm

Value: snommanager

Using Lync Configuration Manger to make these settings:

Script File Variables

There are two methods for changing these variables in the script file:

Method 1: Preserve Code Signing Method

The script file has been signed so it can be used on sites that have restrictive script execution policies in Powershell. This means though that if any element of the script is edited, the signing becomes invalid and you will not be able to run the script. So to get around this issue I have made the script be able to take variable input from an external file. :)

To an external settings file, simply create a file  (or edit the file I supplied in the zip file with the tool)  named "LyncSnomPhoneManagerSettings.cfg" in the same directory as your Snom Phone Manager script is in. The file must be in the following format:

SnomHTTPUsername=snommanager

SnomHTTPPassword=snommanager

SnomAdminModePassword=snommanager

WebPort=443

useHTTPS=true

IPRanges=192.168.0.1/24,192.168.1.1/24

When the script runs it will look for the settings file and parse it into the appropriate variables.

Method 2: The "Who cares about code signing" method

In the script file you will need to set the following settings to match whatever you have configured in your Snom phones:

#Edit these settings if you would like to use a custom username and password for your Snom devices.

$script:SnomHTTPUsername = "snommanager"

$script:SnomHTTPPassword = "snommanager"

$script:SnomAdminModePassword = "snommanager"

Monitoring Database Discovery Permissions

In order to discover phones from the Monitoring database (this is not required for the IP range discovery method), the user logged into the server will need to be a Domain Admin or have “Select” privileges granted on the LscCDR database's Registration table for a security group they are a member of (eg. CSAdministrator). For more details on how to grant these privileges, please refer to the manual process in my article about Group Call Pickup permissions here. Note: the database and table being edited in this case are different than the ones documented in the article, but the process is the same.

The Wrap Up

It’s as simple as that! So now you have a solution for managing your Snom phones' configuration via Lync Client Policy as well as a tool for accessing and managing individual endpoints. What more could you ask for?? Actually, don’t answer that… I’m sure there are plenty more things you would like… I’m working on it ;) 

Read more →

Lync Snom Configuration Manager

Note: Also see my Lync Snom Phone Manager Post for more Snom related fun.

Are you tired of having to maintain a separate configuration server for your third party Lync compatible SIP phones? Well you’ve come to the right place… At Lync Conf this year Snom officially released a feature (it had actually been available for quite some time) that allows you to push configuration settings directly from a Lync Front End server to Snom Lync UC Edition phones. This saves you the effort of setting and managing a separate server containing configuration files. This is an enormous step forward as it will not only reduce your workload but it will also reduce the number points of failure in your Lync deployment.

The way Snom has made the Lync based configuration settings work is by leveraging settings in Lync Client Policy called CsClientPolicyEntries, which was originally introduced in Lync 2010 for sending special configurable settings to Lync clients. An example of this in use is for pushing the photo URL setting back to Lync 2013 clients.

If you’re interested in knowing more about how the Powershell settings work behind the scenes, Matt Landis has a post here about it. The short version of this story is that any setting in the phone that you can see in the configuration file can be pushed to a phone using Client Policy settings. All you need to do is take the name of the Snom config setting and pre-append “snom_” to the start of it and then add this setting to a Client Policy Entry within Lync.

If you’re not so interested in learning all the Powershell behind this, then try using this new tool that I have made…

Lync Snom Config Manager

Version 1.0

• Create or Delete Client Policies.
• View all PolicyEntry settings for each Client Policy within a Lync environment.
• Add, Edit, Delete, and Delete All, CsClientPolicy PolicyEntry settings.
• Click the "?" button to go directly to the Snom Wiki page for the selected setting or if no setting is selected go to the base Wiki page.
• The script is code signed! (thanks to Digicert)
• Export settings from a policy to file.
• Import settings into the Snom Config Manager tool. This is useful for copying settings between policies, or just saving copies of settings. Note: You can also import Snom configuration files, however, this is not recommended (see the "What about...?" section for more details). 
• Importing configuration files can be done by merging with current policy settings, or replacing any existing policies settings.

Download Version 1.0

Import Mode Details

When you have pressed the “Import Config” button the contents of the file that you select to import will be displayed in the list view. At this stage you are in "Import Mode", meaning that all the settings from the file have not been applied to a policy yet (to let you know you're in "Import Mode" the settings will be displayed in red). This gives you the opportunity to view the settings and Add/Delete settings before you write the settings to a Client Policy setting in Lync (at which time they will become live in the system).

Import Mode Example

Once you have edited the settings as you would like in the Client Policy, you then select the policy that you would like to apply the settings to from the import drop down box and press the “Upload Config” button. Once you have done this, the setting will be written to the policy within Lync. If you select the “Cancel Upload” button the upload will be aborted. The "Merge" radio button will give you the option to retain all the current settings in the Lync policy and add the imported settings to the existing settings (it will also replace any existing settings that have the same setting name as the one being imported). The "Replace" radio button will first remove all settings from the selected Client Policy and then import the new settings in the place of the old settings.  If the “Import Blanks” check box is unticked then any blank settings (usually if importing an actual Snom config file) in the config file will be ignored and not imported (Note: you cannot enter blank settings into a Client Policy, so you will need to give these settings values before completing the import process).

Example Configuration Settings

Below are some examples of settings that you might want to use:

Set the HTTP Server User and Password

Take back control of your Snom devices! You may have noticed that when you use PIN Auth on a Snom device it will set the Extension number as the Web Admin user name, and the PIN number as the Web Admin password. I personally find it a bit weird that the user should have access to the configuration of the phone and the Administrator doesn’t. So use the following settings to Push out your own Administrator Username and Password for the web interface:

Web Username:

Name: snom_http_user 

Value:  snommanager

Web Password:

Name: snom_http_pass  

Value: snommanager

Set the Admin Mode Password

In order to get to get to many of the configuration settings in the phone you need to set the phone to Administrator Mode. This mode has its own password setting, and if it is not changed from the default setting of “0000” there will be a message displayed on the phone screen (Admin mode password not set). This password should also be set for security reasons:

Admin Mode Password:

Name: snom_admin_mode_password

Value: snommanager

Admin Mode Password Confirm:

Name: snom_admin_mode_password_confirm

Value: snommanager

Turn off the Security Warning

If you really want to leave this setting as the default “0000” you can suppress the phone displaying the error with the following setting:

Name: snom_ignore_security_warning

Value: on

Change Language Settings

If you have users within your organisation with different language requirements, you can create separate Client Policies and push them different language settings:

Name: snom_language

Value: English

Note: Be careful with language settings as some use special characters, eg. “Español”. See the settings WIKI here.

Snom Hotline

Do you have a snom phone that you want to automatically call a specific person when it’s taken off hook? Well, try this setting:

Name: snom_action_offhook_url

Value: https://127.0.0.1/command.htm?number=john.woods@mylynclab.com

Turn off keyboard lock

Keyboard lock can be a blessing and a curse. Security is good, but too much can be annoying. If there are some phones that you don’t want Lync settings to control the keyboard lock for, then switch them off with this setting:

Name: snom_server_enforced_kb_lock  

Value: off

Timezone

If you have your Snom phones deployed in different timezones you can push them the correct timezone for their location with this setting:

Name: snom_timezone

Value: AUS+10

These are just a handful of examples of settings that you can push to the phones. If you want know more, read the Wiki and try out the settings in the lab until you get your required blend of settings for your deployment.

Important Considerations for Policy Deployment

When you are deploying Client Policy settings for Snom phones you must ensure that any policy entry that you add also gets included in all other Client Policies in the system (I call this symmetrical policy deployment). The reason for this is that when a policy entry setting is pushed to a phone, the phone will retain the client policy settings in its memory even when it is moved to another policy, or has had another user sign into it!

Symmetrical Policy Deployment Example

To highlight the issue, this is an example of a non-symmetrical policy deployment. In this deployment there is an off hook action that has been in deployed in the “Snom Hot Line Policy” policy that has not been deployed in the “Snom Basic Policy” policy:

A Bad Policy Deployment:

Lync Policy: "Snom Hot Line Policy"

snom_action_offhook_url!: https://127.0.0.1/command.htm?number=john.woods@mylynclab.com

snom_admin_mode_password!: snommanager

snom_admin_mode_password_confirm!: snommanager

snom_http_pass!: snommanager

snom_http_user!: snommanager

Lync Policy: "Snom Basic Policy”

snom_admin_mode_password!: snommanager

snom_admin_mode_password_confirm!: snommanager

snom_http_pass!: snommanager

snom_http_user!: snommanager

If we have a user that starts off being deployed in the “Snom Hot Line Policy” policy that then gets moved to the "Snom Basic Policy”, the off hook action will be retained. This is not at all what you would want in a real world deployment, however, there are ways around this. One way is to reset the phone’s configuration before moving it to the new policy, which can be quite a bit of hassle. The other way is to ensure that all of your policies contain an off hook action setting that will return the setting back to its original state. Below is an example of this:

A Good Policy Deployment:

Policy: "Snom Hot Line Policy"

action_offhook_url!: https://127.0.0.1/command.htm?number=john.woods@mylynclab.com

admin_mode_password!: snommanager

admin_mode_password_confirm!: snommanager

http_pass!: snommanager

http_user!: snommanager

Policy: "Snom Basic Policy”

action_offhook_url!: <SPACE CHARACTER>   //Reset to default - Simulating a blank setting

admin_mode_password!: snommanager

admin_mode_password_confirm!: snommanager

http_pass!: snommanager

http_user!: snommanager

Note: For settings that have a String type you can use a <SPACE CHARACTER> to set the setting back to blank. This works because the phone appears to trim all white spaces from the setting before applying it to memory. This does not work for Boolean (True/False) type settings, as the phone will set anything that it not explicitly “yes” (including space characters) as being “no”. So be sure that for Boolean settings you explicitly either set “yes” or “no” for the setting (if you need to know the default value for a setting look it up on the Snom Wiki).

What about…?

Below are some Snom Client Policy Questions that I wanted to know the answers to, and as a result I tested. These might also be of use to you:

1. What are all of these configuration settings?

Snom has a wiki that contains a list of all the settings. Clicking on the "?" button will take you to the wiki page for the selected setting.

2. Are settings case sensitive?

No. For example, “Deutsch” or “deutsch” can be used.

3. Are settings special character sensitive?

Yes. For example Espanol  and Español are not the same, the phone will not parse an regular “n” to be a “ñ”.

4. Should I just export the whole config out of a Snom phone and import it into Lync?

No. Whilst the Lync Snom Configuration Manager tool will allow you to import a whole configuration file that you have exported from the phone, you should only import the settings that you specifically want to control. There are two main reasons for this: Snom config files are full of blank settings (which cannot be imported and will lead to non-symmetrical settings between policies), and you don't want to import settings that might be used for PIN login.

5. How do you make specific settings in the phone go back to default value?

Client Policy Entry settings within Lync can’t be blank (Lync will give you an error if you try to use an empty value for Client Policy Entries). This poses an issue, because Snom phones use blank config settings to indicate that a setting should set to the default value.

Settings for values that are strings, like a URL for example, can be removed by replacing them with a <SPACE Character>. When you set a space character in Client Policy, the phone will trim the leading and trailing blank space characters and apply it to the configuration. This will result in a space character being turned into a blank setting.  However, if the setting is a Boolean (ie. yes/no) value and you set it to a <SPACE Character>, it will not set the setting to the default value. It instead interprets anything that is not the word “on” as being “not on” (ie. off).

Example: If you set snom_show_clock which has a default value of ON to <space character> it will make the setting OFF and the clock will not be displayed.

The result of this is that you need to be explicit when making settings using Lync Client Policy Entry settings. If you want a setting to be the default setting, you will need to look at the snom web site, determine what the default setting is, and then explicitly set that in Lync (ie. don’t try and enter blank settings).

Note: I have raised this with Snom and they are working on a solution for blank settings, hopefully we’ll see it soon.

6. What happens if you move a user from one policy to another?

The expectation here might be that the phone would default all of its values and apply the new policy to a fresh configuration. However, this is not reality… What actually happens is that the phone will retain all of its settings from the previous policy and then apply the new policy settings over the top of the old ones.

Example: If you had a phone in a Policy that had a hotline configured in it, and then moved it to a policy that had nothing set for the hotline setting, the phone would continue to function like a hotline phone.

Where this might also catch you out is when you have users with different Client Policies hot desking on the same phone hardware. When the settings get written to the phone they will be retained for the next user that logs into the phone as well!! So look out for this…

In practice this means that all of your policies need to contain settings for every other setting that you have in another policy. So if you have a hotline configured in one policy, you need to have the hotline setting configured to “nothing” (<SPACE Character>) in all other policies. This is kind of annoying… however, something you need to be prepared for!

The only other option here is to reset the configuration in the phone before moving it to the new policy. This can be done using the Lync Snom Phone Manager tool (coming soon!) and pressing the “Reset” button. This option is very open to human error though, because you may move a user to a new policy and forget to reset their configuration. I don’t recommend this as a practical deployment option though.

7. How long does it take for a setting to push to the phone?

The answer to this is that it’s variable. It appears to depend on where the phone is in its registration cycle. A registration period can be quite long, so it can take many hours for the settings to be pushed to the phone. It is recommended to reboot the phone to know that the settings have applied.

8. Will settings be applied without rebooting the phone?

The answer to this seems to be that it depends on what the setting is. For example if you move a user from a policy set for English to one set for Spanish, the setting does not take effect on the phone interface until you reboot. However, if the policy you are moving to has an offhook policy (for example) this does get implemented by the phone. So to guarantee that the settings have taken effect it is best to reboot the phone. (You can also get the phone to re-register by pressing  Menu key, 3, 2, 1. Or use my Lync Phone Manager Tool to remotely reboot phones)

The Wrap Up

Now, kick back, relax, and feel your blood pressure lowering whilst you manage your Snom configuration in style from the comfort of your slightly smelly office cubicle. If you have any issues with the tool, let me know.  Next post will be another tool for remotely managing Snom phones… J

Read more →

Microsoft Lync / Skype for Business Wireshark Plugin

In this post I have the pleasure of talking about a project that I’ve been working on for a while, as well as one of my all-time favourite networking tools - Wireshark! For those that don’t know, Wireshark (originally named Ethereal) is a packet sniffer program that decodes hundreds of networking protocols for your viewing pleasure. I’ve been using Wireshark for about 10 years now, and am extremely appreciative of all of the people that have worked to build and maintain the product over the years. The other amazing thing about Wireshark is that it’s free software and works across all the major OS platforms. So if you haven’t used it before, I suggest you use this as an opportunity to download it and give it a try.

As an IT professional working on Lync / Skype for Business, what can Wireshark do for you? Well, it can do quite a few things: I personally use it all the time for troubleshooting connection issues, networking problems, certificate negotiation, and other protocol issues. When I started using Wireshark with Lync / Skype for Business I found that some protocols are not decoded properly by Wireshark, which made me sad. For example, STUN (Simple Traversal Utilities for NAT) is a protocol used extensively with Lync / Skype for Business is only partially decoded by Wireshark. 

Example:

So why can’t Wireshark decode these STUN messages properly? The answer to this is that Microsoft has made additions to the base IETF standards which are not recognised by Wireshark. The good news is that Microsoft documented these extensions and released them to the world. Some examples of these documents can be found here:

Microsoft Protocol Documentation:      

• Microsoft Turn Bandwidth Management Extensions [MS-TURNBWM]
• Microsoft TURN Extensions [MS-TURN]
• Real Time Protocol Extensions [MS-RTP]
• RTP for Application Sharing Format Extensions [MS-RTASPF]
• RTP DTMF Extensions [MS-RTPDT]
• Interactive Connectivity Establishment (ICE) 2.0 BandwidthManagement Extensions [MS-ICE2BWM]

These documents that are provided by Microsoft extend the base level standards that were originally written by the Internet Engineering Task Force (IETF). Here are some examples of these specifications:

IETF Protocol Documentation:

• ICE RFC5245
• STUN RFC5389
• TURN RFC5766
• ICE-19
• RTP / RTCP RFC3550

Lync / Skype for Business Wireshark Plugin

Armed with the information available in the Microsoft’s Office Protocol documents, RFCs, and a healthy dose of reverse engineering, I was able to put together a plugin for Wireshark that made packet captures taken on an Edge server readable. Below is an example of a packet capture taken on an Edge server:

So without further ado, I give you The Lync / Skype for Business Wireshark Plugin:

1.00 Initial Release:

• This Wireshark plugin is designed to dissect Lync AV Edge and Internal Edge AV traffic. Captures can be taken on the Edge server (Capturing AV Edge External traffic, and Internal Interface traffic), or it can also be used on the client side for decoding STUN and RTP/RTCP traffic.
• This Wireshark plugin dissects STUN/TURN traffic on Microsoft Lync Edge port 3478 (STUN, RTCP, RTP)
• This Wireshark plugin dissects traffic on Microsoft Lync Edge port 443 (STUN, RTCP, RTP)
• This Wireshark plugin dissects dynamically assigned RTP and RTCP traffic by using ports allocated in STUN requests.
• Dissector can be turned on/off within Wireshark Preferences. (Edit->Preferences->Protocols->LYNC_SKYPE_PLUGIN)
• Port numbers can be changed within Wireshark Preferences. (Edit->Preferences->Protocols->LYNC_SKYPE_PLUGIN)
• If you enter “lync_skype_plugin” in the Filter bar, only the traffic that is being decoded by the Lync Plugin will be displayed.

2.00 Wireshark 2.0 update:

• Some updates to work with Wireshark 2.0+
• Changed the naming of the plugin to LYNC_SKYPE_PLUGIN.
• Big updates to RTP and STUN classification to fix detection issues.
• Added TLS pass-through to the Wireshark default SSL dissector for Hello, Handshaking, and Application data. So now you can have the plugin running all the time and still troubleshoot TLS handshaking issues on port 443. This also makes the plugin better for client side testing.
• Corrected some issues with decoding 0x0013 Data Attribute encapsulated data.
• The decoding of port 443 can have false positive matches for different packet types. The amount of false positive in this version of the plugin has been greatly decreased.
• Widened the scope of RTP port classification from 1024-59999 (which was limited for Edge use) to 1024-65535. This makes the plugin work better when testing client side connections.
• And much more!

Available on the TechNet Gallery:

DOWNLOAD HERE

Note: The Lync Wireshark Plugin by default will take over the dissection of UDP port 3478 and TCP port 443. You can turn these off in the plugin settings found under Edit->Preferences…->Protocols->LYNC_SKYPE_PLUGIN.

Feedback

It’s a complex balancing act decoding multiple protocols that are multiplexed on the same port numbers. So there may be cases where you run into something I haven’t seen before that may cause an error in the decode. If you have an issue with the Plugin not decoding something correctly, or LUA errors with your captures, please email me (mylynclab <at> gmail <dot> com) an example of the capture (ie. a Wireshark pcap file) and tell me the packet number where you had the error. I will endeavour to maintain the plugin and correct issues that people might find. 

Known Issues / Limitations:

• The plugin currently doesn't decode X-Address data for IPv6 packets. I don't have a capture of this to test on at the moment. If someone would like to supply one I can add the functionality. 
• Plugin does not (yet) include full decoding of data encapsulated in 0x0013 data attributes.

Installation of Plugin

Installing the plugin could not be simpler. You simply take the plugin file (Lync-Skype4B-Plugin2.00.lua) and put it in the following directory:

"C:\Program Files\Wireshark\plugins\<wireshark version number>\"

After this, whenever you open Wireshark, this plugin will also be used to decode protocols.

Example:

Plugin Settings

The plugin has some variables that can be set to change what is getting decoded. The settings are accessed through Edit->Preferences…->Protocols->LYNC_SKYPE_PLUGIN. By default all decoding is enabled (ie. UDP port 3578, TCP port 443, and dynamically assigned RTP ports).

Plugin Settings:

Setting	Purpose
Decode UDP Port (Default 3478)	Port 3478 is the standard port used for STUN protocol on the Lync Edge and Lync Front End servers.
Decode TCP Internal Port (Default 443)	Port 443 is the standard port used by Internal Edge services. The Access Edge port gets sent STUN messaging on this port. Use this setting to enable or disable the plugin from decoding traffic on this port.
Decode TCP External Port (Default 443)	Port 443 is the standard port used by Internal Edge services. This will always be 443, however, it’s a variable for if something changes in the future. Use this setting to enable or disable the plugin from decoding traffic on this port.
Decode 1024-65535 Dynamic Ports	The 1024-65535 dynamic ports are the ports used by Servers and Clients for RTP connections. By turning this setting on, the Plugin will look in STUN messages for RTP ports that are being negotiated during session establishment and add these ports to the decode.
UDP Port (Default 3478)	This port in theory should always be 3478. However, if you would like to change this port number you can.
TCP Internal Port (Default 443)	The TCP decode ports have been broken into separate Internal and External settings. This is for when you are capturing on an Edge server that has a different port than 443 configured for the External AV edge. By default internal and external AV (TCP STUN, RTP, RTCP) traffic will be on port 443.
TCP External AV Port (Default 443)
Show original Wireshark Dissection Tree (Default False)	When you are running the Lync Wireshark Plugin it will override the original Wireshark decode for the ports that have been selected above. If you would like to also see how Wireshark would decode the packets, you can tick this box and the original default Wireshark decode will be displayed in the tree item above the plugin decode.

Decode As...

The plugin by default will listen on port TCP 443 and UDP 3478 for traffic, this will capture traffic that is sent to Edge (and other) servers. However, if you make peer-to-peer calls between clients or phones the ports used may fall into the media port ranges which are not captured by default. If you have captured traffic on different ports that you would like to decode using the plugin, simply right click on the packet in Wireshark window and select "Decode As..." then set the Current protocol to LYNC_SKYPE_PLUGIN and it will decode the traffic with the plugin. Here is an example:

 

More Details on How Lync Edge protocols Work

There was a great blog post written back in the 2010 about OCS that talks in some depth about how the STUN and TURN protocols are used by Lync. So if you would like more of an overview of the protocols have a read of this post.

Alternative Software

Microsoft also has their version of Wireshark that they call Network Monitor. They also have a Parser pack for Lync that will decode STUN and RTP messages. Here is where you can get Network Monitor and the Lync parser pack:

http://www.microsoft.com/en-au/download/details.aspx?id=4865

http://www.microsoft.com/en-au/download/details.aspx?id=22440

Note: Network Monitor does not decode TCP (443) STUN/RTP messages and limited STUN attributes.

The Wrap Up

In this post we have travelled to tech town via the Metro (which recently had it’s name changed to something that I can never seem to remember). The outlook from the windows of the train carriage were amazing, with vistas as far as the eye could see. When we passed through the gates of the city we were given the bill by the conductor which, as it turns out, was free for onedrive only. The word around town was that there was a publisher that excelled at Lync projects. We tried to gain access to him and see if he would sharepoint his wisdom with us. After much looking, we finally found him and he cryptically told us that the infoPath to enlightenment was perhaps closer than we knew, and that we already had the powerpoint to realise this if we looked deep enough within ourselves. The trip allowed us to plug back in to our natural surroundings and be at onenote with nature. I hope you had as much fun as I did... Oh dear, it seems I have “Jumped the Wireshark” with the puns on this wrap up… J

Read more →

SEFAUTIL and Lync 2013 Call Pickup Group Tool Permissions

I have had some enquiries from people about issues that they have been having with SEFAUtil  (ie. the Call Forwarding and Group Call Pickup tool from the Lync ResKit). Many of these questions have been about getting no response from SEFAUTIL after running a command. This can be for a few reasons, some of which may have to do with permissions, others to do with configuration. So in this post we’re going to go through the requirements and permissions needed for SEFAUtil as well as the permissions needed for running the Lync 2013 Call Pickup Group Manager. Before we go any further, some background; SEFAUTIL was designed to be run on a server that has Lync server components installed on it. As Jens Trier’s blog post on the tool points out, even if you want to run SEFAUTIL on a separate machine, it still needs to have Lync server base components installed. So it makes sense to choose to run the SEFAUtil on an Front End Server.

How can we run SEFAUtil and the Call Pickup Manger on a server and only give a user accessing it minimum permissions? Well, as we all (may or may not) know, the Lync RBAC role permissions (ie. the Active Directory security groups starting with the prefix “Cs”, example “CsAdministrator”) do not apply to someone that is logged directly into a Lync server. These roles only restrict access to users that are either connecting via Lync Control Panel, or via remote Powershell connection via the “OcsPowershell” webservice that runs on the Front End. When you’re logged into the Lync server directly there are some Active Directory permissions that will affect your ability to access the backend SQL database which will stop you from running some commands. These SQL permissions are tied back to the Active Directory security groups that start with the “RTC” prefix. So, in short, these permissions can still affect a user's ability to access some commands/functions when logged directly into a Lync server.

The SEFAUtil tool documentation doesn't contain any details about what rights are required to use it. However, from testing in the lab I have concluded that you need to be logged in as a user with a minimum of “RTCUniversalReadOnlyAdmins” rights for it to work. Example:

In case you were also wondering which other permissions work for SEFAUTIL, here’s a list:

Permission	SEFAUTIL Works?
RTCUniversalReadOnlyAdmins	Yes
RTCUniversalUserAdmins	Yes
RTCHSUniversalServices	Yes
RTCUniversalSBATechnicians	Yes
RTCSBAUniversalServices	Yes
RTCUniversalServerAdmins	No
RTCUniversalServerReadOnlyGroup	No
RTCUniversalGlobalReadOnlyGroup	No
RTCUniversalUserReadOnlyGroup	No
RTCComponentUniversalServices	No
RTCProxyUniversalServices	No
RTCUniversalConfigReplicator	No
RTCUniversalGlobalWriteGroup	No

Note: These results are from lab testing. If you see any different results in the field, let me know.

Lync 2013 Call Pickup Manager Permissions

As I mentioned earlier, the Call Pickup Manager Tool also needs to query SQL in order to get information about users in the database (this allows for quick retrieval of current user settings). It does this by making direct SQL SELECT calls to the RTCLOCAL databases on each Front End server. When you run the tool you may find that you receive an error that looks like this:

Error running SQL on 2013ENTFE004.domain.com : The SELECT permission was denied on the object 'Resource', database 'rtc', schema 'dbo'.

This error is caused by the user not having sufficient rights to make direct SQL SELECT calls on the database. If you were logged in with Domain Admin rights you would not receive this error, as you would have sufficient permissions on the database (however, not everyone can be given Domain Admin permissions!).

To get around this issue we will need to allow permissions for specific users to be able to make SELECT (read only) calls on the “rtc” database. The simplest way to do this is to Grant “select” permissions to the “RTC Local Read Only Administrators” user within SQL for the “rtc” database. The “RTC Local Read Only Administrators” local machine user maps back to the “RTCUniversalReadOnlyAdmins” security group within Active Directory. So any user that you add to the “RTCUniversalReadOnlyAdmins” will have permission to run SQL SELECT commands on the database. This also works well, as SEFAUtil also requires a minimum of “RTCUniversalReadOnlyAdmins” group permissions to work, so it is a good choice for allowing permissions on the database as well.

Granting SQL Permissions on Tables Example

To be as restrictive as possible, we can grant “Select” permissions only on the tables that the Call Pickup Manager tool needs to read in order to work. The two databases that the Call Pickup Manager Tool needs access to are the dbo.Resources and dbo.PublishedStaticInstance tables. The steps below walk you through applying these permissions:

STEP1: Open SQL Management Studio (you will need to have installed this on a machine to access the database).

STEP 2: From the Object explorer, open the “Databases”->”rtc”->”Tables” tree.

STEP 3:  Right Click on the PublicStaticInstance table, and select Properties

STEP 4: On the Permissions page, click on the Search button:

STEP 5: Click on the Browse Button. Then select the “RTC Local Read Only Administrators” user:

STEP 6: Click OK. You should see the User in the object list:

STEP 7: Now the "RTC Local Read Only Administrators" user will appear in the Users and Roles list. Click on it and Grant it “select” permissions:

STEP 8: Do the same process to give select permission on the “resources” table (STEP 1 - STEP 7):

If you would prefer not to do this manually I’ve also prepared a Powershell script that you could use to speed up the process:

Download SQL PermissionsScript:

1.00 Initial Release:

• This script will give RTCUniversalReadOnlyAdmins SELECT permissions on all the Lync Front End Servers RTC PublishedStaticInstance and Resource database tables.
• Run the script from a Lync server with a user account that has sufficient permissions to make changes to the "rtc" SQL database.
• This script is designed to give the minimum required permissions to the database for a user to use the Call Pickup Group Manager tool.
• Ensure that you have opened the Firewall ports for the RTCLOCAL database using the "OpenSQLPortsForCallPickupManager1.00.ps1" script before trying to running this permissions script. If you haven't opened the firewall you will get connection errors when you try and run this script.

SEFAUtil Error Debugging

By default, SEFAUtil does not give you any feedback as to why the tool is not working: when it hits an exception it will stop executing with no error message. However, after doing a bit of detective work, I discovered that SEFAUtil actually has an undocumented “verbose” flag that can be used to help debug why SEFAUtil is not working (this is now baked into the Call Pickup Group ManagerTool version 1.02). Below are two examples of common issues that you might see with SEFAUtil not working: 

User Running SEFAUtil Does Not Have Correct Permissions: 

If the user logged into the Lync Server does not have the correct permissions (ie. one of the “RTC” group permissions I talked about earlier) they will get an error reported in the shell window like this one:

PS C:\Program Files\Microsoft Lync Server 2013\ResKit> .\sefautil.exe /server:melbfepool.domain.com holly.hunt@domain.com /verbose

Starting CollabPlatform...

Microsoft.Rtc.Collaboration.ProvisioningFailureException:One or more values in the configured settings are invalid or unusable. Check inner exception and logs for more details. ---> Microsoft.Rtc.Internal.ServerConfiguration.SettingsInitializationException: The settings wrapper failed to initialize.

Unable to find  the Sqld database: Cannot open database "xds" requested by the login. The login failed.

Login failed for user '2013ENT\testadmin'.

   at Microsoft.Rtc.Internal.ServerConfiguration.UCSettings.InitConsumerWithRole

(RoleName role)

   at Microsoft.Rtc.Internal.ServerConfiguration.UCSettings..ctor(String applicationId, SettingsWrapperOptions options)

   at Microsoft.Rtc.Internal.ServerConfiguration.UCSettings.Get(String applicationId, SettingsWrapperOptions options)

   at Microsoft.Rtc.Collaboration.ProvisioningSourceImpl.GetInitialPlatformData()

--- End of inner exception stack trace ---

   at Microsoft.Rtc.Signaling.SipAsyncResult`1.ThrowIfFailed()

   at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult result)

   at SEFAUtil.SefaTool.Execute()

Detected at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)

   at System.Environment.get_StackTrace()

   at Microsoft.Rtc.Collaboration.ProvisioningFailureException..ctor(String message, Exception innerException, ProvisioningFailureReason failureReason)

   at Microsoft.Rtc.Collaboration.ProvisioningSourceImpl.GetInitialPlatformData()

   at Microsoft.Rtc.Collaboration.ProvisioningSourceGetInitialPlatformDataAsyncResult.ProcessCoreHelper()

   at Microsoft.Rtc.Collaboration.SipCollaborationAsyncResult.ProcessCore()

   at Microsoft.Rtc.Signaling.AsyncWorkitemQueue.ProcessItems()

   at Microsoft.Rtc.Signaling.SerializationQueue`1.ResumeProcessing()

   at Microsoft.Rtc.Signaling.SerializationQueue`1.ResumeProcessingCallback(Object state)

   at Microsoft.Rtc.Signaling.QueueWorkItemState.ExecuteWrappedMethod(WaitCallback method, Object state)

   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

FailureReason = 2

SEFAUtil Trusted Application Not Configured Properly:

If the Trusted Application has not been configured correctly in Lync you will get an error like the one below:

PS C:\Program Files\Microsoft Lync Server 2013\ResKit> .\sefautil.exe /server:melbfepool.domain.com holly.hunt@domain.com /verbose

Starting CollabPlatform...

Microsoft.Rtc.Collaboration.ProvisioningFailureException:One or more values in the configured settings are invalid or unusable. Check inner exception and logs for more details. ---> Microsoft.Rtc.Internal.ServerConfiguration.SettingsInitializationException: The settings wrapper failed to initialize.

The ExternalServer service is not installed on the machine.

   at Microsoft.Rtc.Internal.ServerConfiguration.UCSettings.InitConsumerWithRole

(RoleName role)

   at Microsoft.Rtc.Internal.ServerConfiguration.UCSettings..ctor(String applicationId, SettingsWrapperOptions options)

   at Microsoft.Rtc.Internal.ServerConfiguration.UCSettings.Get(String applicationId, SettingsWrapperOptions options)

   at Microsoft.Rtc.Collaboration.ProvisioningSourceImpl.GetInitialPlatformData()

--- End of inner exception stack trace ---

   at Microsoft.Rtc.Signaling.SipAsyncResult`1.ThrowIfFailed()

   at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult result)

   at SEFAUtil.SefaTool.Execute()

Detected at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)

   at System.Environment.get_StackTrace()

   at Microsoft.Rtc.Collaboration.ProvisioningFailureException..ctor(String message, Exception innerException, ProvisioningFailureReason failureReason)

   at Microsoft.Rtc.Collaboration.ProvisioningSourceImpl.GetInitialPlatformData()

   at Microsoft.Rtc.Collaboration.ProvisioningSourceGetInitialPlatformDataAsyncResult.ProcessCoreHelper()

   at Microsoft.Rtc.Collaboration.SipCollaborationAsyncResult.ProcessCore()

   at Microsoft.Rtc.Signaling.AsyncWorkitemQueue.ProcessItems()

   at Microsoft.Rtc.Signaling.SerializationQueue`1.ResumeProcessing()

   at Microsoft.Rtc.Signaling.SerializationQueue`1.ResumeProcessingCallback(Object state)

   at Microsoft.Rtc.Signaling.QueueWorkItemState.ExecuteWrappedMethod(WaitCallba

ck method, Object state)

   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

FailureReason = 2

The Wrap Up

“Permissions, Permissions everywhere, nor any lock to Lync.” - Samuel Taylor Lyncridge 

So anyway, that may have been slightly long winded, however, hopefully it was edu-taining for you all. In a nutshell you just need to put the user in the “RTCUniversalReadOnlyAdmins” security group, and add the SELECT permissions on the database. After that, you should be about to access SEFAUtil and the Lync Call Pickup Group Manager. 

Read more →