Wednesday, 3 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!


STOP,PRGSBC51,0x000174D700000001,3955074504,GMT,10/22/2014,01:11:19.7,0,4,37,10/22/2014,01:11:40.8,3,2076,16,VoIP,IP-TO-IP,DEFAULT,,,6731234507,,0,,0,,0,,RL7,1,PRGSBC51:TG07,192.168.229.118,192.168.228.237,TG07,,192.168.229.117:1024/10.128.176.185:5062,,192.168.229.117:1026/192.168.228.237:5048,213416,1036,176476,1025,0,,,0x00800000,,,,,2,"SIP,009258DD-F957-E411-8C61-342F2AB2DB43@10.128.176.185,<sip:PhonerLite@10.128.176.185>;tag=3367902045,<sip:6731234507@192.168.229.118>;tag=gK0c816f95,0,,,,sip:6731234507@192.168.229.118,,,,sip:PhonerLite@10.128.176.185:5060,sip:6731234507@192.168.229.118:5060,,,,1,BYE,,0,0,,0,0,,,,,,,,1,0,0,0,,,,,,,,0,,",12,12,0,5,,,0x0a,6731234507,1,1,,1,0,0,0,TG07,"SIP,786432_119514912@192.168.229.118,<sip:PhonerLite@192.168.229.118:5060>;tag=gK0c0170af,<sip:+16731234507@192.168.228.237:5060;user=phone>;tag=4fbfd5e7e6e006f0,0,,,,sip:+16731234507@192.168.228.237:5060;user=phone,,,,sip:PhonerLite@192.168.229.118:5060,sip:+16731234507@192.168.228.237:5060;transport=udp,,,,,BYE,16,0,0,,0,0,,,,,,,,1,0,0,0,,,,,,,,0,,",,110,,,1,1,,,2,P:2:1,P:2:1,10,0x000C0000,,,0,,,,,,0,,,,1,,,,,,,6,,,,,,1,1,1,1,,0,,,1,7,0,2076,1,,,,,192.168.229.118,10.128.176.185,2,16,8,,,,,,,,,0,,,TANDEM,,,10,211150,1025,178192,1036,0,0,0,35,20,,,,,,,13,1,,,,,,,,,,,,,,,,,,,,,0,9,,,,,,,,,,,,,,,"3,39,0,42",0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,"01,audio,1,G711S,192.168.229.117:1024,10.128.176.185:5062,0:0:0:0,56,G711S,192.168.229.117:1026,192.168.228.237:5048,0:0:0:0,124","01,audio,1,1036,1025,213416,176476,0,0,1025,1036,211150,178192,0,0",0,,,

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:

      Protocol
      Port
      Description
      nsiiops
      261
      IIOP Name Service over TLS/SSL
      https
      443
      http protocol over TLS/SSL
      ddm-ssl
      448
      DDM-SSL
      smtps
      465
      smtp protocol over TLS/SSL
      nntps
      563
      nntp protocol over TLS/SSL
      sshell
      614
      SSLshell
      ldaps
      636
      ldap protocol over TLS/SSL
      ftps-data
      989
      ftp protocol, data, over TLS/SSL
      ftps
      990
      ftp, control, over TLS/SSL
      telnets
      992
      telnet protocol over TLS/SSL
      imaps
      993
      imap4 protocol over TLS/SSL
      ircs
      994
      irc protocol over TLS/SSL
      pop3s
      995
      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:
      EXT. TRAINING MONTAGE - THE STAIRS AT THE FRONT OF THE PHILADELPHIA MUSEUM OF ART- DAY
      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.

      MAN
      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




      Version 1.0 Features:
      • Zero installation.
      • 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.
      • 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.

      Version 2.0 Update:
      • Added output formatting options to work with Sonus LX tool and AudioCodes Syslog Viewer tool (Commonly used Skype for Business syslog tools used with SBC devices).
      • In version 2 if you create a config file named "PowerSyslogServerSettings.cfg" in the same directory as the tool it will use the config file to save all of its settings. The SyslogPort="514" setting remains a hidden setting that can still be used in the config file to change the listening port number.
      • UDP socket code has been made more robust to deal with errors when the listening port is being used by another app.
      • Changed the font to Courier New for fixed width goodness.
      • Fixed issue with rolling files in folders including "." in name and faster processing.
      2.01 Bug Fixes (9/8/2017):
      • Fixed Sonus LX output formatting to only have LF and not CRLF.
      • Increased socket buffer and tuned threading to fix dropped packet issues and double writing of some lines.
      • Added disable display checkbox to increase performance when display is not required.


      Download from Technet Gallery:





      Version 2.0 – Output formats


      Version 2.0 of Power Syslog Server now gives you the option to add additional prefix formatting to the start of each line of syslog output. From the research I have done the format of output from each syslog server varies greatly and contains items such as date/time, text based priority field interpretation (ie. The <135> value at the start of syslog messages sent on the wire) and IP Address of the server that sent the message.

      The reason that these prefixes are important is that if you want to import the file output back into a tool like Sonus LX or AudioCodes Syslog Viewer to generate call flow diagrams or other features the file needs to be in a format that these tools can interpret. So in order to achieve this, the Format dropdown box has been added in version 2. The Format setting will alter the outputs into the required format for Sonus LX or AudioCodes syslog tools. In addition to these specific tool formats, some other generic prefix formats have been added which will make the output files easier for humans to read.

      Output Formats
      Format
      Example Prefix Format
      Comment
      None
      <No Prefix>
      Output syslog in the exact format that it was sent from the device in.
      AudioCodes
      "17:50:17.588  10.20.2.170     local0.notice"
      Output syslog in AudioCodes Syslog Viewer tool format.
      SonusLX
      "10.20.1.150:53434 <==>"
      Output syslog in the same format as the Sonus LX tool.
      Level
      "Local0.Debug"
      Prefix the syslog with the Facility and Severity levels.
      DateTime
      "2011-10-11 15:00:02.123"
      Prefix the syslog with the date and time.
      DateTimeLevel
      "2011-10-11 15:00:02.123 Local0.Debug"
      Prefix the syslog with Date/Time and Facility/Severity.
      DateTimeLevelIP
      "2011-10-11 15:00:02.123 Local0.Debug    192.168.0.100"
      Prefix the syslog with Date/Time, Facility/Severity, and IP Address of the device.

      Note: Sonus LX tool cannot open AudioCodes files and AudioCodes syslog tool cannot open LX files. This is because there are special lines of output generated by each brand of SBC that the specific syslog tools use for generating call flow diagrams. So you need to select the correct format for the device and tool you are using if you want to be able to import the files at a later date.


      Config File Example


      Version 2 can use a configuration file to retain settings that will be applied when the tool boots. When settings are changed within the tool the values will be saved out to the config file. It is important to note that the config file needs to be manually created in order for the tool to start using it. This is deliberate as the config file is for advanced usage scenarios. To create the config file, simply create a text file in the same directory as the script is located and rename the file to "PowerSyslogServerSettings.cfg". Once the file exists the tool will start writing settings to the file. Below is an example of the file format:

      SyslogPort="514"
      Format="AudioCodes"
      LogFile="C:\PowerSyslogFile.cfg"
      KeepFiles="2000"
      RollFile="20"
      Note: Setting values must be surrounded in quote marks. 


      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. 

      Subsystems:

      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 acquired 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.


      AudioCodes Syslog Viewer


      AudioCodes also have a nice Syslog Viewer Tool that can be used with the AudioCodes range of SBCs. The tool has a very nice call flow viewer which gives you a ladder diagram of SIP messages per call which allows you to click on the SIP message to see its contents.


      I have found this tool to be much quicker and easier to use in comparison with the Sonus LX tool for troubleshooting SIP related call flow issues. The tool also can accept inputs from multiple devices at once and will put each syslog input into different tabs on the main screen. Using version 2 of Power Syslog Server you can output files into a format that the AudioCodes Syslog Viewer can import and display call flows and multiple device tab windows.





      Example Display/Log Filters


      Power Syslog Server includes a 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:
      192.168.0.20 <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 192.168.0.96:51823;branch=z9hG4bK96df5daa
      CONTACT: <sip:2013ENTFE003.mylynclab.com:5068;transport=Tcp;maddr=192.168.0.96>
      CONTENT-LENGTH: 0
      USER-AGENT: RTCC/5.0.0.0 MediationServer


      192.168.0.20 <135>[2014-09-16 00:57:02,718]  322 0001

      SIP/2.0 200 OK
      Allow: INVITE, ACK, CANCEL, BYE, UPDATE, NOTIFY, OPTIONS, REFER, REGISTER
      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 192.168.0.96:51823;branch=z9hG4bK96df5daa


      192.168.0.20 <135>[2014-09-16 00:57:04,827]  393 0003

      OPTIONS sip:siptrunk.aapt.com.au:5060 SIP/2.0
      Allow: INVITE, ACK, CANCEL, BYE, UPDATE, NOTIFY, OPTIONS, REFER, REGISTER
      Call-ID: call-71280200-0000-0010-1101-0@10.237.176.6
      Content-Length: 0
      CSeq: 132654 OPTIONS
      From:  <sip:Anonymous@10.237.176.6:5060>;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 10.237.176.6:5060;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:
      192.168.0.20 <134>[2014-09-16 00:51:13,126] 1160 0097 com.sonus.sbc.route INFO (callrouter.cpp:2193) - Handling route request.
      192.168.0.20 <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)).
      192.168.0.20 <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 ""
      192.168.0.20 <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)).
      192.168.0.20 <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"
      192.168.0.20 <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)).
      192.168.0.20 <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"
      192.168.0.20 <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)).
      192.168.0.20 <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"
      192.168.0.20 <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: "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 →

      Popular Posts