Using the ipPhone field is an option. However, it’s a bit of a chicken and egg thing. They don’t have an extension until we assign it. And we can’t import them until they have the number in that field.
So we’d have to assign them an extension, modify the attribute, then sync manually, then import, etc. There are some other scenarios which still wouldn’t help though. It’s a drag. ☹ But I’m still not defeated! From: Hunter Fuller <hf0...@uah.edu> Sent: Thursday, January 30, 2020 6:26 PM To: Lelio Fulgenzi <le...@uoguelph.ca> Cc: Charles Goldsmith <w...@woka.us>; voyp list, cisco-voip (cisco-voip@puck.nether.net) <cisco-voip@puck.nether.net> Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ? On Thu, Jan 30, 2020 at 4:51 PM Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote: We can’t filter on anything telephone number based. Sounds silly, but the information in the directory doesn’t always jive with what someone wants, extension wise. This was true for us. Our solution was to populate the ipPhone field with their real phone number and populate telephoneNumber with what they wanted to appear in the directory (e.g., their admin assistant, or for some people in IT it's the help desk, etc. etc.). Then UCM/Unity use the ipPhone attribute for provisioning and all is well in the world.
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
