CUCM Self-Provisioning

Self-Provisioning is a new feature introduced in the 10.x release of Cisco’s Unified Communications Manager (CUCM). It provides a “plug and play” type of functionality that simplifies the phone deployment process. Using auto-registration, some template and profile configurations, along with a new IVR service, CUCM administrators now have the ability to deploy phones with minimal upfront configuration. This isn’t a new concept because it’s similar in function to the old Tool for Auto-Registered Phones (TAPS) method. The key difference with Self-Provisioning is that the IVR service runs on CUCM so you don’t need UCCX as you do with TAPS.

Self-Provisioning also adds value to the LDAP sync feature that is commonly used in CUCM deployments. In addition to importing user data from Active Directory, you can now configure the synchronization agreement to automatically create a directory number based on a mask applied to the phone number attribute. Likewise, if a user doesn’t have a phone number then a directory number can be assigned from a specified pool of numbers.

Now let’s walk through the configuration process and components. I’ll point out some things along the way and then conclude with some points for you to consider if/when you evaluate Self-Provisioning for use within your business environment.

First, we need a Universal Device Template (UDT). In CUCM, go to User Management > User Phone/Add > Universal Device Template. UDTs are applied to devices so they mostly correlate to typical device configuration settings. However, if you go through them a bit more then you’ll see there are also a number of key directory number (or line-level) configurations controlled here as well. You’ll also notice that you can use tags (i.e. variables) to automatically populate specific fields (e.g. Device Description). Some of the key configurations for UDTs include:

• Description
• Device Pool
• Device CSS
• Some line-level settings, which are embedded under the Phone Buttons Configuration, including Line Label, Caller ID, and External Phone Number Mask

Now we need a Universal Line Template (ULT). For that, go to User Management > User Phone/Add > Universal Line Template. ULTs are similar in function to UDTs except they control all of the line-level configurations (except those few set in UDT). Key configurations for ULTs include:

• Description
• Partition
• VM Profile
• Line CSS
• Alerting Name
• Call forwarding settings such as CFA and CFB/CFNA destination and CSS

Now that we have a UDT and ULT configured, we can configure a User Profile and enable Self-Provisioning for end users. To do that, go to User Management > User Settings > User Profile. User Profiles are where you set UDTs, a ULT, and enable the Self-Provisioning capability for end users. User Profiles are pretty simple actually but notice that I said UDTs (as in potentially more than one). That’s because, as previously noted, they are applied to “devices”. In today’s world, “devices” doesn’t just equate to an IP phone(s). “Devices” can also mean Jabber client(s) and/or single number reach configurations. In the Service Profile, you can set different UDT(s) for three different device types: desk phones, mobile and desktop clients, and mobility-related devices (e.g. remote destination, RDP).

Now it’s time to create a Feature Group Template. It’s also part of the User Management options, so go to User Management > User Phone/Add > Feature Group Template. The Feature Group Template is used to assign features and/or set parameters for end users such as enabling IM&P and mobility among other things. A Feature Group Template can then be associated with an LDAP synchronization agreement so that users are imported into CUCM with a common set of features enabled. The key configurations within the Feature Group Template include:

• Ability to set the CUCM/IM&P cluster as the end user’s home cluster
• Ability to enable IM&P and also include meeting information for Presence state
• Set a Services Profile for Jabber
• Set the User Profile, which associates UDTs, a ULT, and enables the Self-Provisioning capability
• Allow CTI control
• Enable single number reach (i.e. mobility) and/or MVA
• Set the BLF Presence Group and SUBSCRIBE CSS

Like many of my customers, my CUCM is integrated with AD for directory synchronization and authentication. I mentioned that Self-Provisioning brings some value-add here so let’s take a look at that. Go to System > LDAP > LDAP Directory and configure a Synchronization Agreement. You’ll see that the LDAP Directory configuration has a Group Information section. In my lab, I am going to do the following:

• Add the Standard CCM End Users and Standard CTI Enabled Access Control Groups
• Specify a Feature Group Template
• Select “Apply mask to synced telephone numbers to create a new line for inserted users” and specify a mask of +1703555XXXX

When the synchronization completes, my end users are imported as usual but a couple of other things happen as well. In my synchronization agreement, I map Phone Number to ipPhone and that attribute is populated in AD as a 4-digit abbreviated extension. However, I want Directory Numbers in CUCM to be configured as E.164. With the configuration I set, CUCM also automatically creates a DN for each imported user. Eddie Vedder’s user info syncs over with an ipPhone attribute set as 2001 but a full E.164 DN is created by applying the mask set in the LDAP synchronization agreement. Each DN is created based on the ULT set within the User Profile assigned to the Feature Group Template specified within the LDAP synchronization agreement.

There’s something else that happens behind the scenes here as well. When I go to the CUCM end user database and take a look at Ed’s user configuration, he now has a Self-Service User ID (e.g. 17035552001). Once the Self-Provisioning IVR is online, this is the ID that users will enter to provision their phone.

Now it’s time to get the IVR up and running. First, I should note that there is an associated CTI Service (i.e. Self Provisioning IVR) that needs to be activated. Once that’s done, we need a CTI Route Point for the Self-Provisioning IVR. This isn’t really any different than any other CTI route point so no need to elaborate much further. Just remember that you’re going to be using auto-registration so assign a DN to the service that’s in a partition accessible from the CSS applied to auto-registered phones in your environment.

Next we need to create an Application User for the Self-Provisioning IVR and this is also straightforward. Most of the settings here are arbitrary but you do need to add the CTI route point as a controlled device and then add the user to the Standard CTI Enabled Access Control Group.

Last but not least, we need to configure the Self-Provisioning Application. Go to User Management > Self-Provisioning and you’ll find this last configuration is lightweight as well. You can set the application to either Require Authentication or not. I recommend the use of authentication and if you go that route, you have two options. You can allow authentication for users only using a password or PIN (we’ll talk about that in a minute) OR you can allow authentication for users (again via password or PIN) as well as administrators (using a specified authentication code). From there you set the language preference for the IVR and associate the CTI Route Point and application user.

Now that we’ve finished up the configurations, we can talk a bit about the actual end user experience with Self-Provisioning. To reiterate, this feature relies on auto-registration in addition to the various components outlined above. I’m not going to walk through how to configure auto-registration here as I assume most of you are familiar with that. However, it is worth noting that some of the same components (specifically UDT and ULT) can now also be customized and applied to auto-registered phones.

A user has a couple of options for how to use Self-Provisioning. The first is to dial the extension assigned to the Self-Provisioning IVR. If you have enabled authentication for the application, then the user will enter their Self-Service User ID and their PIN. The second is to use the phone interface, which is “advertised” via an Idle URL configuration. From the phone, the user will still enter their Self-Service User ID and their password. So, that’s where the “via password or PIN” option comes into play. In either case, the IVR application will authenticate the user based on their credentials, associate the user to the DN auto-created for them, and re-assign the auto-registered as well. When the phone re-registers, it will use the UDT and ULT settings specified in the User Profile associated with the end user account via the Feature Group Template assigned to the synchronization agreement.

There you have it, folks. We’ve walked through the configurations and tied them together along the way. Now, I’ll leave you with a few things that you might want to consider further as you consider if/how to implement Self-Provisioning in your environment.

First, I’d like to point out a little something about the Idle URL component of the Self-Provisioning feature. Along with my UC team colleagues at NetCraftsmen, I’ve been working with a number of both new and existing customers to rollout Jabber with Mobile and Remote Access via the Collaboration Edge architecture. As a result, I’ve grown accustomed to referencing servers via FQDN. So, if you’re doing the same then you’ll want to also adjust the Idle URL within the Service Configuration Settings in the UDT used for Auto-registered devices.

Second, there is an end user communications facet here to consider. IMO, there isn’t that much information to convey to the end users. They need to know their Self-Care User ID, PIN, IVR extension, and basic instructions on what to do. However, if your company takes the “have the end user do as little as possible” approach, then you can simplify the process a bit further by doing one (or both) of the following:

• Do you think that two IVR access options is one too many? Ok, you can remove the Idle URL component.
• Do you not even want to tell the end users what extension to call? Use a ring-down configuration. You can easily apply a standard PLAR setup to the auto-registered phones. The user only needs to go off-hook to enter the IVR.
• Hey, you could even do both. That’s as simple as it gets. One option, which automatically enters the IVR. Suddenly my end user communication goes something like this: “Mr. Vedder, you have a phone. Plug it in. Pick up the handset. Enter your Self-Care User ID, which is 17035552001 followed by your PIN, which is 12345.”

As a NetCraftsmen, I believe in the power of integrity. I could give you the whirlwind tour and be on my merry way but most anyone can do that. With that said, I also want to share some potentially limiting factors that I took notice of early on in the configuration process. All you have to do is look back at the very first component that we configured (i.e. the UDT) to get a sense of the scope.

In a fairly homogenous environment with only one or a just a few locations, Self-Provisioning may be quite simplistic and work very well but the mileage may vary in a larger multi-tenant environment. This is particularly true if you want to use the feature in conjunction with LDAP synchronization. In a multi-tenant environment, you’re typically going to have a number of tenant-specific configurations such as Device Pools, CSS, and so on. In order to fully realize the benefit of Self-Provisioning in this type of environment, you’ll need to plan a multi-tenant approach for this feature as well. There will be multiple UDTs, User Profiles, and even Feature Group Templates.

In the end, you will also need a multi-tenant approach to LDAP synchronization because you can only assign one Feature Group Template to each LDAP Directory configuration. In other words, you will need multiple synchronization agreements and/or a method to filter out tenant-specific groups of users. The upper limit will be either 10 or 20 (i.e. the total number of synchronization agreements is limited to 10 if there are more than 80K users and 20 is the max when there are less than 80K users). If you think about it, 20 synchronization agreements is a lot (10 is pretty healthy too) but there is also a dependency on LDAP organizational structure as well in terms of scalability here. I’m not sharing this as a means to discourage the use of Self-Provisioning. In fact, that’s not what I’m saying at all. Instead, my point is that it will take more planning in some environments than others and even then there may be some limitations based on your specific requirements.