Tuesday, 2 December 2014

Sonus SBC 5k/SWe CDR Decoder

I was on a training course recently learning about the SBC5000/SWe series SBCs from Sonus as these are now supported with Microsoft Lync 2013! This range of SBCs are completely different from the SBC1000/2000 range that you may be used to in your previous Lync deployments. The reason for this difference is that the SBC1000/2000 range were originally designed around a completely different code base by the NET company which was later acquired by Sonus. 

The SBC5000 was  originally designed for large carrier deployments, however, a newer virtualised version of the SBC5000 called the SWe (Software Edition) starts to make these systems much more affordable and interesting for enterprise sized customers. During the training course we were introduced to an online tool that Sonus has for parsing individual Call Detail Records (CDR) to show you what each field in the record represents. This may not sound like much until you see the size of a SBC5000’s CDR record… Behold!


From this mess you might see how finding field 134 might take some time… So Sonus’ online tool is a very handy thing. The CDR records also contain a great deal of useful information about a call (kind of like Lync Monitoring Database records) such as Codecs Used, if transcoding took place, SBC routes used, reason for disconnection, etc. These records can be extremely useful when troubleshooting issues with the system.

Sonus Online CDR Decoder

I was thinking, though, that you don’t always have access to the internet when you’re working on a customer site, and often you might want to look through a whole file worth of records (instead of cutting and pasting individual records into the online tool). So I decided that it was time once again to get cracking on a Powershell tool for browsing SBC5000 CDR files … and after eleven thousand lines of parsing code I bring you:

Sonus SBC 5k/SWe CDR Decoder

Version 1.0:
  • Import SBC5000 or SWe CDR files (ACT files).
  • Left hand list view will display all of the records that are in the file.
  • Right hand list view displays all of the fields in the selected records.
  • Subfields (ie. fields that contain multiple pieces of information in them) are individually broken out and displayed in grey colour.
  • Fields are decoded where possible with the decoded value of the field shown in brackets next to the field entry.

Version 1.01 (5/12/2014):
  • Added some more enumerations.
  • Fixed a few small parser bugs.
  • Added a show as text button.

Download Version 1.01:

How to access SBC5000/SWe CDR files

CDR files are also called account files, and they can be easily downloaded from the system via Platform Manager. Simply access Platform Manager (ie. management interface IP on port 444) and go to the Logs -> Event Logs section and select ACT as the log type you wish to access. Then download the file with the Download button:

Then open the Sonus SBC 5k/SWe CDR Decoder tool in Powershell and select the “Browse…“ button, select the ACT file, and click the “Load” button to import the contents of the file. Now you’ll be able to browse the records in the left hand listview and each record you open will be displayed in the right hand listview.

The Wrap Up

At this stage there may not be many deployments of the Sonus SBC5000 or SWe in Lync deployments around the world. However, I can see the SWe being a highly flexible and tenantable virtualised SIP Trunk SBC in the future. So even if this tool doesn’t seem immediately useful it may someday become handy for troubleshooting your future SWe deployments!

Read more →

Friday, 24 October 2014

When Poodles Attack - Poodle Checker Tool

It’s not too often you get to be excited about a security threat. However, the POODLE security threat seems to put a smile on my face every time I see it written somewhere… Poodles are just so innocent and ridiculous looking to take seriously as a major threat. So in a bid to take this security issue more seriously, I have built a Powershell tool for remotely checking servers for having either SSL 2.0 or SSL 3.0 enabled on them.

More Detail on the POODLE threat

Here are some links that explain the POODLE threat in a little more detail:

POODLE Checker Tool

  • The tool will try and connect using SSL 2.0 and SSL 3.0 to any server FQDN/IP and port (multiple ports can be entered with a comma separating them) you enter.
  • Press the Test button and it will check all the ports in the ports text box. The tool will report in the Powershell window which ports have SSL 2.0 and SSL 3.0 running on them.
  • The tool will also visually display the results…
  • Script is signed.

Update 1.01
  • Added additional checking of TLS (1.0, 1.1, 1.2) protocols so you can better understand all the TLS connection options available on the server before deciding to disable SSL. 
Update 1.02 (16/2/2015)
  • Added the ability to handle multiple comma separated IP Addresses/DNS Names.
  • Added Cancel button to stop testing.
  • Disabled text boxes during testing phase.
  • Textboxes now stretch when resized.

      Download Version 1.02:

      Standard SSL Port Numbers

      SSL can technically run on any port that you configure and application to use. However, the well-known port numbers for applications that use SSL (as defined by IANA, and IETF) are listed below:

      IIOP Name Service over TLS/SSL
      http protocol over TLS/SSL
      smtp protocol over TLS/SSL
      nntp protocol over TLS/SSL
      ldap protocol over TLS/SSL
      ftp protocol, data, over TLS/SSL
      ftp, control, over TLS/SSL
      telnet protocol over TLS/SSL
      imap4 protocol over TLS/SSL
      irc protocol over TLS/SSL
      pop3 protocol over TLS/SSL

      Note: A listing of all IANA port assignments can currently be found at: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

      I have made the tool load all of these ports into the port text field by default.

      Note: The documented attack vector for POODLE is described for HTTPS connections, and not necessarily for these other protocols. The tool checks all of these protocols to check if your server is still accepting SSL2/3 connections in order to determine if it's globally enabled (in Windows the registry key effects SSL across most applications). Also, additional attack vectors may be found for other protocols, so if your applications can support newer versions of TLS it is probably wise to turn these older versions of SSL anyway.

      The Wrap Up

      There you have it, short and sweet! I hope the tool is useful to you and helps you take security issues more seriously J

      Let me know if you find any bugs or have any issues.

      Read more →

      Tuesday, 30 September 2014

      Power Syslog Server

      “My Kingdom for a free and simple syslog server!” – Anonymous System Administrator

      So I don’t know about you, but I can’t remember how many times I have got to the point of having to troubleshoot an issue with a Sonus gateway and suddenly remembering I need a Syslog server to get logging out of the box. At this point I usually go and ask Google politely “Google, can you please point me in the direction of a free, and simple, syslog server that I can run without installing a bunch of malware and other rubbish on this nice customer’s server?” At this point Google usually responds “No, I cannot. However, here is a syslog server that requires you install SQL, IIS, and fifteen other dependent services as well as being crippled unless you pay $14.99 per month to a Russian guy name Vlad via this popup window that displays in the middle of the screen every 5 minutes. Also, here’s a Yahoo browser search bar for your trouble.”

      This is not an ideal situation… So as usual, I just decided to build it myself. In doing this I sat down and thought about the things I wanted in a simple syslog server, and came up with this list:
      • It needs to have no installation process, and leave no trace once removed from a server, as it will be run on customers' servers in a lot of cases.
      • It needs to have a display where I can see the messages coming in in real time.
      • The messages being displayed must be able to be paused and reviewed, so I can check if a specific event has happened yet.
      • The messages window must be able to be cleared so that I can start fresh when trying to troubleshoot a fault.
      • The syslog server needs to be able to log to file. Ideally the files should be able to be opened in Sonus LX tool so that further message debugging can be done easily.
      • The syslog server needs to be able to roll the log files once they get to a specific size (so they can be emailed, etc).
      • The syslog server should only keep a specific number of these log files so that the server’s hard disk does not get filled with log files.
      • Both the display and log files should be able to be filtered to display only information that I want to see. For example, only show lines with a specific phone number in them, or only show me SIP messages. These filters should be independent so that you can view the filtered information on screen whilst more detailed information is getting logged to file for further review and troubleshooting later.

      Based on these requirements I figured it would be very cool to write the server in Powershell, as this allows for absolutely no installation and can be run on any Windows machine you are likely to run into. How hard could it be?

      <Insert training montage>

      SMASH CUT:
      A man in a sweaty hoody runs to the top of a large set of stairs carrying a tablet based productivity device that he is furiously typing on. A large group of the town’s population is also running after him in a large pack for no apparent reason. Upon reaching the top of the steps he punches the air and launches the tablet into the sky. The tablet hits the concrete and smashes into a million pieces. He falls to the ground and screams towards the sky.

      Nooooooo! I should have backed up to the cloud, the cloud I tells ya.

      Okay okay, let’s cut to the chase. I did it, and now you too can syslog with me into the sunset.

      Power Syslog Server

      • Zero installation.
      • Signed Powershell Script.
      • Real time log display (Approximately 1000 lines).
      • Copy the displayed text with the Copy Text button. This is useful for more in depth analysis in your favourite notepad software.
      • Rolling log files based on file size and number of files to keep.
      • Clear display and Pause display functions.
      • Filter real-time display logging with regular expression.
      • Filter logging to file with regular expression.
      • Log files can be opened in Sonus LX tool for further debugging.
      • Open firewall for Syslog Server port with the click of a button. If you are not seeing any syslog output in the Power Syslog Server display log then try pressing the Open Firewall button.
      • Server listening port can be changed by creating a config file (PowerSyslogServerSettings.cfg) in the same directory as the script. The config file needs to have text in it in the following format "SysLogPort=514". This allows you to maintain the integrity of the code signing by not directly editing the script file.

      Download 1.0

      How to configure a Sonus Gateway for Syslog Output

      Sonus makes some of the most popular Lync Gateways on the market, so I have chosen to use them as an example of how to set up a device to output syslog. Power Syslog Server will work with any other UDP based syslog client as well though, so feel free to use it with other devices too.

      Remote Log Servers:

      Setup your device to output syslog to the server you are running Power Syslog Server on.  

      Global Log Level: If your subsystems are set to “Default” logging level then this setting will be applied to them. This is also the level it will log for all services that are not specified in Subsystems. You will usually set this to a low value like “Error” or “Warning” to avoid log flooding.
      Log Destination: The server with the Power Syslog Server running on it.
      Port: 514                 
      Protocol: UDP
      Log Facility: local0
      Enabled: Yes

      Important Note: When you're finished debugging remember to Disable the syslog output. Otherwise the device will continue to output syslog data over the network, which can be a significant amount of unnecessary overhead for your device, network and server. 


      Then enable the Subsystems as required:

      Subsystem: Set the specific Subsystem that you would like to have logged to the syslog output. For troubleshooting call flows and SIP messaging the “SIP Stack Service”, “Common Call Control” (for ISDN translation tables), “Call Routing Service” (for SIP translation tables), and "ISDN Protocol" (for E1 integrations) are useful subsystems to configure here.
      Log Level: Set the required Log Level.
      Log Destination:The Remote Log Server we created in the first step.

      Debugging Log Files in LX Tool

      Once you have captured your syslog files using the Power Syslog Server on the server on site you may want to do further call flow debugging using the Sonus LX tool (which can offer you decoded call flows for both SIP and ISDN calls providing your syslog contrains "ISDN Protocol" DEBUG and "SIP Stack Service" DEBUG logging).

      To import the file into the LX tool, simply take one of the log files that the Power Syslog Server created and drag it into the LX tool window (or use File->Open). When you do this the LX tool will break the syslog file down into the individual call flows that were captured in the log. Here is an example:

      Sonus LX Tool

      By double clicking on a call in the "Calls" tab at the bottom of the screen you can get further details on each call flow (including ISDN decoding!):

      Sonus LX Tool - Call Flow

      Note: The LX Tool is a tool orginally created by NET (which was subsequently aquired by Sonus). To get a copy of the software go to the Sonus Salesforce portal and select "Software Downloads" then select "LX" from the Products list. If you don't have access to the Portal, speak to your Sonus representative to get a copy of the software.

      Example Display/Log Filters

      Power Syslog Server includes a cool feature that allows you to filter (using regular expressions) what lines of syslog get displayed on the screen and logged to file. The reason for allowing for having a separate Display Filter and Log Filter is to help you when troubleshooting in real time. By this I mean that you can configure a very specific Display Filter to allow you to see only the messages you want to see for a specific issue and a more general Log File Filter so you can capture more detailed logs to review later in order to pinpoint the exact cause of the issue. Below are some examples of how you can use these filters when troubleshooting issues:

      Show Only SIP Messaging

      When you are running SIP Stack Service logging at a DEBUG level the Sonus gateway will output all of the SIP messaging that is traversing it. This can be very useful when you need to know what error messages are being sent by the Carrier SIP network or Lync when a call fails.

      Example Filter (without quote marks): “sip:”

      Example Output: <135>[2014-09-16 00:57:02,709]  287 0002

      OPTIONS sip:ux1000lab.mylynclab.com SIP/2.0
      FROM: <sip:2013ENTFE003.mylynclab.com:5068;transport=Tcp;ms-opaque=152721d992435f69>;epid=B3F80C5FC7;tag=fb568a1fab
      TO: <sip:ux1000lab.mylynclab.com>
      CSEQ: 9993 OPTIONS
      CALL-ID: 87a0bbd93e7f4e33a2c87ff8bbccd3d7
      MAX-FORWARDS: 70
      VIA: SIP/2.0/TCP;branch=z9hG4bK96df5daa
      CONTACT: <sip:2013ENTFE003.mylynclab.com:5068;transport=Tcp;maddr=>
      USER-AGENT: RTCC/ MediationServer <135>[2014-09-16 00:57:02,718]  322 0001

      SIP/2.0 200 OK
      Call-ID: 87a0bbd93e7f4e33a2c87ff8bbccd3d7
      Content-Length: 0
      CSeq: 9993 OPTIONS
      From:  <sip:2013ENTFE003.mylynclab.com:5068;transport=Tcp;ms-opaque=152721d992435f69>;epid=B3F80C5FC7;tag=fb568a1fab
      Server: SONUS SBC1000 3.0.2v270 Sonus SBC
      Supported: replaces,update,100rel
      To:  <sip:ux1000lab.mylynclab.com>;tag=aedb006-3ef64
      Via: SIP/2.0/TCP;branch=z9hG4bK96df5daa <135>[2014-09-16 00:57:04,827]  393 0003

      OPTIONS sip:siptrunk.aapt.com.au:5060 SIP/2.0
      Call-ID: call-71280200-0000-0010-1101-0@
      Content-Length: 0
      CSeq: 132654 OPTIONS
      From:  <sip:Anonymous@>;tag=aedb006-1
      Max-Forwards: 70
      Supported: replaces,update,100rel
      To:  <sip:Anonymous@siptrunk.aapt.com.au:5060>
      User-Agent: SONUS SBC1000 3.0.2v270 Sonus SBC
      Via: SIP/2.0/UDP;branch=z9hG4bK-UX-0aed-b006-40c88

      Show Output Relating to Transformation and Route Rules

      This can be extremely useful for troubleshooting what transformation rules a call is using and what routing rule it has chosen.

      Example Filter (without quote marks): “regex match|transformation|route request”

      Note: You need to be logging at DEBUG level for “Common Call Control” (for ISDN translation tables) and the “Call Routing Service” (for SIP translation tables) for this to work.

      Example Output: <134>[2014-09-16 00:51:13,126] 1160 0097 com.sonus.sbc.route INFO (callrouter.cpp:2193) - Handling route request. <135>[2014-09-16 00:51:13,127] 1163 0094 com.sonus.sbc.route DEBUG (translation.cpp:1332) - Performing OPTIONAL transformation using entry Testing Calling Party Rule (13.1(4)). <135>[2014-09-16 00:51:13,127] 1164 0093 com.sonus.sbc.route DEBUG (translation.cpp:649) - Failed regex match of "tfCallingSubNumber" field for "^(9999113\d{2})$" (updated "^(9999113\d{2})$") with input of "" <135>[2014-09-16 00:51:13,127] 1165 0092 com.sonus.sbc.route DEBUG (translation.cpp:1332) - Performing OPTIONAL transformation using entry 4 digit to E.164 (13.2(1)). <135>[2014-09-16 00:51:13,127] 1166 0091 com.sonus.sbc.route DEBUG (translation.cpp:653) - Successful regex match of "tfCalledNumber" field for "^(45\d{2})$" (updated "^(45\d{2})$") with input of "4501" <135>[2014-09-16 00:51:13,127] 1168 008f com.sonus.sbc.route DEBUG (translation.cpp:1332) - Performing OPTIONAL transformation using entry Full National to Lync (13.3(2)). <135>[2014-09-16 00:51:13,127] 1169 008e com.sonus.sbc.route DEBUG (translation.cpp:649) - Failed regex match of "tfCalledNumber" field for "^0(3958245\d{2})$" (updated "^0(3958245\d{2})$") with input of "+61395824501" <135>[2014-09-16 00:51:13,127] 1170 008d com.sonus.sbc.route DEBUG (translation.cpp:1332) - Performing OPTIONAL transformation using entry Local to Lync (13.4(3)). <135>[2014-09-16 00:51:13,127] 1171 008c com.sonus.sbc.route DEBUG (translation.cpp:649) - Failed regex match of "tfCalledNumber" field for "^(958245\d{2})$" (updated "^(958245\d{2})$") with input of "+61395824501" <134>[2014-09-16 00:51:13,127] 1172 008b com.sonus.sbc.route INFO (callrouter.cpp:2396) - Successful route request with entry Analog to Lync (5.1(3))

      Show Only Syslog Lines Related to a Specific Phone Number

      This can be useful if you know a users telephone number and you only want to see messages that relate to them.

      Example Filter (without quote marks): “+61399995555”

      The Wrap Up

      So there you have it, another tool for the kit bag. I hope you like it and find it useful, I know it’s already got me out of a few close calls. If you find any bugs or have any feature requests feel free to drop me a line.

      Read more →

      Thursday, 28 August 2014

      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: "" OR "" OR add multiple with comma separation ",") 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

      Admin Mode Password Confirm:
      Name: snom_admin_mode_password_confirm

      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:


      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 →

      Monday, 21 July 2014

      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

      Admin Mode Password Confirm:
      Name: snom_admin_mode_password_confirm

      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

      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

      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_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"
      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 →

      Popular Posts