Jabber 10.6 is bringing a wealth of new features and functionality to the desktop. However we’re getting to a point you might not want to enable all of these slick features for your entire enterprise. So I’ve recently fielded a question how to ‘group’ enable features.
Let’s get a little context with configuration files so you’ll understand when and when not to have group configuration files. If you’d like to spend time reading the deployment and installation guide you can get more details.
Global configuration files applies to all users. This file (jabber-config.xml) is downloaded by the client from your TFTP nodes. (cough.. UDS via HTTPS). Group configuration files applies to subset of users and take priority over global configuration files.
The ‘take priority’ piece is what you need to logically plan for. You may even think of the global configuration file as a baseline for the environment and have features added by a group configuration file only. This may get to be a lot of work so don’t go overboard with group configuration files. You’ll end up creating a lot of work maintaining the CSF devices.
The group configuration file is uploaded and maintained just like the global one. You can create a group naming convention that suits your needs. Some have used something similar such as ‘jabber-config-group1.xml’ or feature specific as ‘jabber-config-hunt.xml’ that takes the global config and adds in the hunt group tab.
So where do you specify this group configuration file? On the CSF, BOT, TCT, or TAB “Cisco Support Field”. Yes I know this isn’t the greatest place to maintain this and it’s already been suggested to break this out into another field but that isn’t the direction we’re going. This is really only a stop gap or you have a specific group of people you need to add a feature or turn off a feature. Executives and Contact Centers come to mind.
So scroll down to “Cisco Support Field” and put in something like this.
configurationfile=jabber-config-group1.xml
You can even get creative with TFTP directories if you already have this going on CUCM. So configurationfile=/folder/jabber-config-group1.xml
If you’re uploading the file for the first time you’ll need to restart your TFTP service. If the file already exists and you’re simply making changes you do not need to restart the TFTP service. Send me a note on Twitter if you’d like me to post an explanation of this.
Another thing to note is that the Jabber client will be notified of this change and if it determines it needs a restart it will prompt the user to log out and sign back in.
I’d recommend creating a test XML file for your deployment so you can test the enabling and disabling of features without affecting the enterprise population. Once you get the hang of policies and working with different files you’ll be able to test and roll out new features very quickly.
Thanks and happy Jabbering!
I ran through this myself just recently, however, setting the configuration file statement with the leading / for the on-box TFTP results in this failing. Of course the error is some generic error about No TFTP servers configured in list, but, that is what it ends up being.