Polycom Configuration File Generator Tool
Tanja Freeze
Zero-touch provisioning (ZTP) is a method of setting up devices that automatically configures the device using a switch feature. ZTP helps IT teams quickly deploy network devices in a large-scale environment, eliminating most of the manual labor involved with adding them to a network.
ZTP can be found in devices and tools such as network switches, routers, wireless access points and firewalls. The goal is to enable IT personnel and network operators to install networking devices without manual intervention. Manual configuration takes time and is prone to human error -- especially if many devices must be configured at scale. ZTP is faster in this case, reduces the chance of error and ensures configuration consistency.
When a ZTP-enabled device is powered on, it runs a boot file that sets up the device's configuration parameters. Then a network switch sends out a request through DHCP or TFTP to get the location of its centrally stored image and configuration, which it downloads and runs. The port configuration and IP address are automatically provisioned based on the location requirements. The protocol used -- DHCP, for example -- provides the gateway address, the domain name and the server location.
ZTP carries out the basic configuration, after which the switch can be deployed in an environment where custom configuration changes are made. ZTP can use a user-provided script to connect to a configuration management platform, such as Puppet, CFEngine, Chef or a custom tool.
Zero-touch provisioning automates steps like updating operating systems, deploying patches or bug fixes, and implementing added features prior to connection. Automation is most useful in large environments with a lot of devices to update or configure. For example, it is more efficient to use ZTP to configure hundreds of routers than to manually configure every single device. Likewise, if each of those routers needs updating, then ZTP would be the more efficient option.
ZTP is also useful in situations where an organization must scale up its devices and IT resources. Adding many devices at once requires that each device be configured. ZTP makes that task easier, saving time and money, by automatically provisioning devices.
Network switches that are individually configured take more time and effort to connect. This means IT staff must spend more time in a command-line interface, configuring each system or switch. Most data centers will have tens or hundreds of switches to provision and configure, taking a significant amount of time.
OTP is often used in situations where ZTP would need additional configuration. For example, if there is a virtual LAN configuration required, Point-to-Point Protocol over Ethernet credentials must be entered or static addressing needs to be done.
The process documented in this article can be used in any Lync 2010 or 2013 environment to setup a centralized provisioning server for managing Polycom SIP phones running Polycom Unified Communications Software (UCS).
This article is not intended to replace or accompany any official Polycom documentation. Instead this process alone can be used to deploy a basic provisioning server in a lab or testing environment when evaluating Polycom SIP phones, and much of the guidance contained reflects a non-production scenario. Also note that some of this guidance differs from instructions found in the official Polycom provisioning guides, most importantly the guidance to use a large number of parameters which no longer need to be defined for Lync interoperability as of the introduction of the Lync Base Profile.
Traditionally Lync Optimized devices (e.g. CX600) receive all of their provisioning information and software update packages directly from a Lync server. Although Qualified devices (e.g. VVX400) do also receive a lot of information in-band from the Lync Server, UCS devices contain a variety of configurable parameters available outside of what the Lync Server can provide itself. When looking to provision any of these out-of-band features, like Paging, or when dealing with device firmware updates then it is required to deploy a centralized server to provide this today.
The provisioning server is not a specific product or solution, it is basically just a centrally-accessible file store which contains certain files that the devices are programmed to look for. The phones will look for specific firmware files to perform an upgrade/downgrade and will download and upload configuration data in XML files.
Polycom UCS devices can utilize a variety of different file server platforms to store and manage both firmware packages and configuration files, no additional third-party software is required. In this article a basic FTP server will be used but the phones also support the TFTP, HTTP, and HTTPS protocols.
When a factory-reset device is first powered on it will check for specific DHCP Options that may be defined on the network which would provide a path to the provisioning server. If this information is found then it will connect to that file service, authenticate with a pre-configured username and password, and then look for one of two specific filenames stored in the root directory. First the device will look for a configuration filename matching its MAC address (e.g. 0004f28062d6.cfg) but if that does not exist then it will revert to loading the default master configuration file provided in the UCS distributable package (e.g. 000000000000.cfg). Regardless of which file is downloaded it will contain a defined parameter which tells the device where to locate firmware packages and what (if any) additional configuration files to look for. By default the firmware packages are stored at the root of the directory and each individual phone model is programmed to look for a specific filename unique to each model (e.g. 3111-46157-001.sip.ld). Additionally the device can also upload files to the directory to store device-side settings (e.g. ringtone) as well as diagnostic and call logs.
Specifically Microsoft FTP services in Internet Information Server are used in this example, running on Windows Server 2012 on a dedicated host. Any standard FTP service (e.g. FileZilla, WarFTP) can be used. It is not recommended to use an existing Lync Server also as the FTP server, thus the guidance that a separate Windows host be utilized.
Before setting up the file server it is important to understand that the UCS firmware is pre-programmed with a default username and password which is used during authentication to the provisioning server. The default credentials use the same string for both the username and password and are stored in as case-sensitive so if the FTP server uses case-sensitive username and/or password make sure the uppercase and lowercase characters are used correctly. (Traditionally username are not case-sensitive while passwords are, but this may depend on the actual file server product used.)
If using a custom set of user credentials is desired then they can be changed manually on each phone prior to provisioning by accessing the Settings > Advanced > Administration Settings > Network Configuration > Provisioning Server menu.
For this lab environment the Windows Active Directory password policy was customized to disable strong password complexity requirements as the default password does not meet the complexity of the default Windows AD password policy. In a production environment it would not be advisable to alter the password complexity policy simply for this reason, but a different file server platform which is not AD-integrated could be used which may not have this same limitation.
Now that the FTP service has been prepared the root directory needs to be populated. This is a simple process given that every UCS package released by Polycom always includes the entire set of base files needed, so any version of UCS can be used to first populate the directory.
The desired software package can be downloaded from the Polycom Support site, either directly from the support page for a specific phone model, or from the Software Release Matrix page. Depending on the number of different device models which need to be supported multiple packages may be required, but the first package selected is sufficient to instantiate the directory.
The package contains a number of directories and files but most of these can be ignored when dealing with Lync integration, including the directories which store sample configuration and localization files as well as the image and audio files. The important files are highlighted in the table below.
An additional recommendation is to create dedicated directories to store call and diagnostic logs for each phone. By default they would all be written to the root directory which in larger deployments can lead to a lot of files being stored there, making it more difficult to weed through and manage files configuration files.
For proper operation of the phones it is required to provide information about the location of critical network resources automatically to the phones via DHCP. In this example Microsoft DHCP Services are currently configured to hand out IP addresses to any network hosts. These options can be defined at either the server or scope level.
When receiving a dynamic IP address on the network the phone will by default look for the location of a provisioning server by first checking for the existence of DHCP Option 160. In the event that option 160 is not configured then it will fall back to looking for Option 66.
The preferred option 160 is specific to Polycom UCS devices while the secondary option 66 value is commonly shared with other SIP phones as well. Either option can be used with the UCS phones, thus the configuration of the existing network will typically drive the choice of which to utilize. In a lab or green-field environment where no other hosts are leveraging option 66 then this can be used and is commonly pre-defined as an available option on most DHCP servers. If some other devices are already leveraging option 66 then it may be best to utilize option 160 for these phones.
7fc3f7cf58