I have a fresh install of 10.5 but when attempting self provision im getting error 'This Device Cannot Be Associated to your account, contact your systems administrator'
Been using doco, could be missing something in my config.
I have done the following:
Looking at the documentation it states the user needs a primary extension, the only way I have been able to do that is to create a EM profile and associate it. Once i do this the IVR does state that the device will restart with new settings but then get the original error message straight after
Solved! Go to Solution.
If the "Apply mask to synced telephone numbers to create a new line for inserted users" is checked and the appropriate Mask entered that matches the "telephonenumber" LDAP attribute in AD, then when the Directory sync occurs CUCM will create a new DN, and assign that DN to the Primary extension field of the end user.
one thing that might also cause problems is, if the DN already exists in the partition used for the templates.
I also using Extension Mobility to assign a primary extension in enduser. But, the ULT does not populate the lines (just UDT is updated). Anybody has more ideas for this feature?
I've found that if you don't specify a mask in the LDAP directory settings, the DN from AD is not imported. You can specify a mask of Xs to match the string length in the AD attribute you are syncing from.
If you don't do this, you have to build a DN and then associate it with the user in User management>User/Phone Add>Quick User/Phone Add.
I can see some scenarios where you don't want the telephone # to be synced from AD. If you have a high turn over rate i.e. high turn over rate. It would be better to assign a pre-existing DN then create a duplicate. I'm also guessing that maybe the script cant create a new DN for the user if one exists already. The Quick User/Phone Add shows whether a DN is available or not (assigned to a device). this may be an easier way to manage DNs.
The way I was able to get this going was to create a jabber desktop profile for the user so they could get the primary extension then once the primary extension is assigned the self provisioning IVR ID is automatically populated.
Which aligns with the documentation having to have a primary extension but would be great if users could self provision with out this. I will continue to work on this if there are any further options.
As a FYI it works with+E.164 as well and populates the user provisioning ID without the +
Yeahh, got the same problem.
I kind of figured it was the primary extension that was missing that was causing the problem - but creating Jabber CSF will consume licenses since the customer I was planning to use this feature only has UCL Enhanced and plans to use desk phones.
Perhaps I will just create UDP profiles for all the users, let them register and delete them afterwards(if that works) but it's really silly that the primary extension is a requirement for this self provisioning, it should be the telephone number field.
But I'm hoping that I'm missing something, or else this feature is not really useful I guess since I've been deploying systems through the years with extension mobility and might just continue with that strategy.
I'm having the same problem. It works fine when I am using the default templates from the install, but the new one I created does not work. If I go back in and look at the settings of the one I created it tells me there is an error. The Device Security Profile field is blank and I cannot populate it. I don't need a Jabber profile when I am using the system created template.
You should be able to set the primary user extension on the user properties.
I deleted the templates I created and added a new one with only the required items, the new one worked. I then started adding items back in waiting to see which one was breaking the template. As I came to realize I do not have the same functionality I have using BAT and TAPS, I gave up on self provisioning. Disappointing since I had high hopes for the service.
One of my main complaints of the new auto-registration is that it creates an individual phone button template for EVERY phone. What what could possibly be the purpose for 480 individual templates that are all identical. Please go back to using the default template for the phone type.
May be you have found the solution/workaround for this problem but just to give out for those who haven't figured it out.
Wasn't able to create a BAT file to update users with Primary Extension because they have to control a phone before Primary Extension is available. As a quick workaround I created a CTI port tied to their directory number, and ran a BAT file to update the user.
A shame that Self Provisioning isn't easier to get going - with all of the prep work that needs to be done it'd really just be easier to use TAPS or BAT.
Would love to hear any alternate suggestions.
I concur completely!
I had some 'quiet time' and thought I would try out the auto-registration self provisioning in my own lab environment as I wouldn't want to inflict experimentation when deploying in a 'live environment'. Yes, over the years I have learned to become skeptical about Cisco's 'auto' anything, particularly when they try to take complex stuff and 'simplify' it. True to my expectations, after about 6-8 hours of annoyance and frustration, I have found this self-provisioning to be a waste of time. It's quicker to do it the way I have honed over the years and shared with my customers.
No doubt it will be 'adoptable' come version 15.x of CUCM? But for now, I have had enough.
You really want to drive yourself to distraction? Try playing around with Prime Collaboration Provisioning - omg.
I went back to this 2 months on, made a fresh pot of tea, took a deep breath and....
Stuck on: "This device could not be associated to your account. Please contact the System administrator to complete provisioning"
And finally got it to work in my lab CUCM10.5 environment!
This url helped me some-what: https://ciscocollab.wordpress.com/2014/01/12/cucm-10-0-phone-self-provisioning-with-plar/
And the CUCM Admin Guide is pretty hopeless if not downright incorrect at times, but the after thinking about it and reading various posts, the issue came down to 'defining the Extension for the user'.
Confusingly this was referred to as the Primary Extension (which it is for that user) but that refers to a specific field in the End User parameters, which of course is defiantly set to <None> by default (cos there are no devices associated with that user!) - yet.
Apart from ensuring that the CUCM hostname is resolvable (if you have DNS, if not rename your CUCM to an IP address) and doing all the other things documented in terms of defining templates both for auto-registration and the various Devices/Sites for Device and Line templates, etc and of course have a self-service userID defined, you need to go to: User Management>User/Phone Add>Quick User/Phone Add and click Find.
A list of users displays.
Select the user you want to 'provision' a phone for and scroll down to 'Extensions' section.
At this point you need to click on '+' under Action and then click New to enter a new extension. Enter the extension and relevant line template for that user and their phone.
Now try either self-provisioning using the auto IDLE on the phone or using the IVR, hopefully the phone will self-provision for you!
Phew. Really, this could have been so elegant, but in reality is horribly painful to go through and figure out.