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