03-09-2005 08:47 AM - edited 03-18-2019 04:19 PM
Hi,
I have a idea I would like the developers to consider for functionality of the CUBI tool.
The import tool references the users telephoneNumber attribute in Active Directory (AD) to derive the users extension number. It then synchronises back to a new attribute called ciscoEcsbuDtmfId, which is a direct reference to the users Unity extension. This is one of the many new attributes added by the Unity Schema Extensions.
This creates an issue if the Telephone Number does not represent the users actual extension number. Even if it does, it also creates an issue if the Telephone Number attribute contains non-DTMF characters, such as +, ( or ).
An added issue is that this Telephone Number is often referenced in a Global Address List, and cannot simply be changed to match the users x digit extension number.
So what this means is that we first have to temporarily modify every users Telephone Number in AD, then import them into Unity, then change their AD phone numbers back to the standard corporate format. This has the potential to create a lot of extra work.
Since Unity synchronises with the ciscoEcsbuDtmfId attribute, it will never actually overwrite the telephoneNumber attribute.
In another post I was told that the CUBI tool can filter the first x number of digits to leave you with the extension number. I don't see this functionality and I am using version 4.0(4).
Another issue here is that it expects that the Telephone Number field contains only DTMF valid characters. As it usually contains the +() type symbols, the import tool bypasses these user accounts and an error is written to the log file.
Therefore I would like to put in a change request for Cisco to look into providing an option in the wizard that asks which field you want to reference the extension number from, such as IP Phone, etc.
The Customer can then ensure that this field is correct before we attempt to run an import. If the last x digits of their Telephone Number does indeed match their extension number, a simple ADSI script can be written to copy the required value into the newly referenced attribute, such as IP Phone.
Hopefully Cisco can provide a solution in the not too distant future.
I believe this change request will make the tool far more flexible than it currently is.
Cheers,
Jeremy.
03-09-2005 10:38 AM
Most of what you asked for here is already in CUBI, however it didn't end up making the 4.0(4) ship date so it's in 4.0(5) (I just checked to be sure). Unfortunately this tool isn't something that can be bundled up and posted seperately (i.e. it'll have problems running on 4.0(4) due to back end changes along the way they've had to accomodate). So it'll have to wait for the 4.0(5) release for this.
It doesn't, however, let you select which field you use for the phone number field - which would be nice, but it is smart enough to only strip digits out of the field and grab the rightmost X digits if you want...
03-09-2005 01:50 PM
That would be okay if it didn't error on non-DTMF characters. Because the record is skipped if a +, ( or ) is in the field, the filter you are talking about is useless.
Cheers,
Jeremy.
03-10-2005 09:26 AM
I'm told by the developer that did the work that this is the case in 4.0(5) - it only pulls digits out of the field, it ignores all non digit characters - so you should be OK.
03-10-2005 12:58 PM
Thanks for following up on that Jeff.
Please also consider adding functionality to be able to select which Active Directory attribute is used to derrive the extension number from.
Cheers,
Jeremy.
03-10-2005 01:17 PM
As always with feature changes like this, ask your account team to open a PERs for this - I don't handle the CUBI tool so I don't have personal control over it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide