Mailing List Archive

B would be the way to go yes if you mean provision people for Jabber service for telephony but they do not have a hardware phone. If they don't need phone service at all and just IM then there are other ways.

C is what we do here. I have line templates for campus/local/national/international for each of our gateway locations, and a couple for internal contact centers or similar that we grind through enough that it is worth putting them in here. Anything more complicated does not follow our SOP and gets pushed to someone with more hours on the system to work through. This is combined with User Profile, which by default it setup for a 1 line 5 button 8800 series device and is rarely changed. I built those for 1 and 2 line 8800 and 7900 series (largely just common phone profile and button template between them) which can be used when building something new or when moving devices. In practice it doesn't usually get used as most devices are either bog standard 1 line, or some mess of buttons and need intervention.

Adam





> -----Original Message-----
> From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Lelio
> Fulgenzi
> Sent: Wednesday, July 1, 2020 2:06 PM
> To: cisco-voip voyp list <cisco-voip@puck.nether.net>
> Subject: [cisco-voip] Creating Jabber for non-existent phones
>
>
> Hello all. Looking for feedback and opinions and caveats.
>
> Right now, we’re deploying Jabber only to those with phones/DNs. But, we need
> to start deploying Jabber for those individuals without phones/DNs.
>
> Our SOPs include using Quick Add feature. (Thanks a million time Brian Meade
> for the pointer).
>
> My choices so far, to address Jabber for new those without phones:
>
> (a) Create a fake hardware phone first. This has many benefits, namely, all
> SOPs remain the same. Hardware phone would be deleted afterwards.
>
> (b) Use Directory Number admin page to create/update a DN first, then use
> Quick Add page to assign DN to user accordingly and then click manage devices
> and follow remaining SOP steps.
>
> (c) create line templates and use those when creating new extensions under
> quick add. The issue with this is we have so many combinations, I’d need a lot
> of templates.
>
> I’m leaning towards (b), since it gives me the best of both worlds.
>
> Thoughts?
>
> Lelio
>
> Sent from my iPhone
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Thanks!

I believe the actual number of “Jabber only” telephony users will be quite small.

What we will likely see are those requests that ask to remove the hardware phone they have in lieu of Jabber. In that case, we’d add Jabber before removing the phone.

If the frequency of Jabber only requests increase, I may consider option C. But B still looks good.

Sent from my iPhone

> On Jul 1, 2020, at 2:57 PM, Pawlowski, Adam <ajp26@buffalo.edu> wrote:
>
> ?CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca
>
>
> B would be the way to go yes if you mean provision people for Jabber service for telephony but they do not have a hardware phone. If they don't need phone service at all and just IM then there are other ways.
>
> C is what we do here. I have line templates for campus/local/national/international for each of our gateway locations, and a couple for internal contact centers or similar that we grind through enough that it is worth putting them in here. Anything more complicated does not follow our SOP and gets pushed to someone with more hours on the system to work through. This is combined with User Profile, which by default it setup for a 1 line 5 button 8800 series device and is rarely changed. I built those for 1 and 2 line 8800 and 7900 series (largely just common phone profile and button template between them) which can be used when building something new or when moving devices. In practice it doesn't usually get used as most devices are either bog standard 1 line, or some mess of buttons and need intervention.
>
> Adam
>
>
>
>
>
>> -----Original Message-----
>> From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Lelio
>> Fulgenzi
>> Sent: Wednesday, July 1, 2020 2:06 PM
>> To: cisco-voip voyp list <cisco-voip@puck.nether.net>
>> Subject: [cisco-voip] Creating Jabber for non-existent phones
>>
>>
>> Hello all. Looking for feedback and opinions and caveats.
>>
>> Right now, we’re deploying Jabber only to those with phones/DNs. But, we need
>> to start deploying Jabber for those individuals without phones/DNs.
>>
>> Our SOPs include using Quick Add feature. (Thanks a million time Brian Meade
>> for the pointer).
>>
>> My choices so far, to address Jabber for new those without phones:
>>
>> (a) Create a fake hardware phone first. This has many benefits, namely, all
>> SOPs remain the same. Hardware phone would be deleted afterwards.
>>
>> (b) Use Directory Number admin page to create/update a DN first, then use
>> Quick Add page to assign DN to user accordingly and then click manage devices
>> and follow remaining SOP steps.
>>
>> (c) create line templates and use those when creating new extensions under
>> quick add. The issue with this is we have so many combinations, I’d need a lot
>> of templates.
>>
>> I’m leaning towards (b), since it gives me the best of both worlds.
>>
>> Thoughts?
>>
>> Lelio
>>
>> Sent from my iPhone
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Forgive my ignorance here, since I do not do day 2 ops work often (thus
quick add's set backs are not top of mind), I mostly focus on new
deployments, which typically involve BAT, so what is the trouble/uniqueness
in Jabber CSF devices versus a physical phone? Also, how come Option A
doesn't mention the Jabber piece? Is that implied that you would come back
around and add Jabber afterwards, like you would do in option B, post DN
add?

On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:

>
> Hello all. Looking for feedback and opinions and caveats.
>
> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
> need to start deploying Jabber for those individuals without phones/DNs.
>
> Our SOPs include using Quick Add feature. (Thanks a million time Brian
> Meade for the pointer).
>
> My choices so far, to address Jabber for new those without phones:
>
> (a) Create a fake hardware phone first. This has many benefits, namely,
> all SOPs remain the same. Hardware phone would be deleted afterwards.
>
> (b) Use Directory Number admin page to create/update a DN first, then use
> Quick Add page to assign DN to user accordingly and then click manage
> devices and follow remaining SOP steps.
>
> (c) create line templates and use those when creating new extensions under
> quick add. The issue with this is we have so many combinations, I’d need a
> lot of templates.
>
> I’m leaning towards (b), since it gives me the best of both worlds.
>
> Thoughts?
>
> Lelio
>
> Sent from my iPhone
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

I would add, why not just bulk add jabber for everyone who is licensed for it and then include in your normal onboarding? Does someone care if it’s configured and not used?


Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: MLoraditch@heliontechnologies.com
From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Anthony Holloway
Sent: Wednesday, July 1, 2020 4:00 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca>
Cc: cisco-voip voyp list <cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Creating Jabber for non-existent phones

[EXTERNAL]

Forgive my ignorance here, since I do not do day 2 ops work often (thus quick add's set backs are not top of mind), I mostly focus on new deployments, which typically involve BAT, so what is the trouble/uniqueness in Jabber CSF devices versus a physical phone? Also, how come Option A doesn't mention the Jabber piece? Is that implied that you would come back around and add Jabber afterwards, like you would do in option B, post DN add?

On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

Hello all. Looking for feedback and opinions and caveats.

Right now, we’re deploying Jabber only to those with phones/DNs. But, we need to start deploying Jabber for those individuals without phones/DNs.

Our SOPs include using Quick Add feature. (Thanks a million time Brian Meade for the pointer).

My choices so far, to address Jabber for new those without phones:

(a) Create a fake hardware phone first. This has many benefits, namely, all SOPs remain the same. Hardware phone would be deleted afterwards.

(b) Use Directory Number admin page to create/update a DN first, then use Quick Add page to assign DN to user accordingly and then click manage devices and follow remaining SOP steps.

(c) create line templates and use those when creating new extensions under quick add. The issue with this is we have so many combinations, I’d need a lot of templates.

I’m leaning towards (b), since it gives me the best of both worlds.

Thoughts?

Lelio

Sent from my iPhone
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

Sorry. With (a) we would use existing SOPs to add Jabber after the dummy hardware phone was added.

The quick add assumes a DN has been assigned to the user and in the user screens a primary extension has been selected. Our SOP takes care of this.

My Hope is to use As much of the existing sop as possible.

But, as you suggest, I could have option (d) create a CSF for the user and follow the SOP using quick add for the remaining three Jabber devices.

Disadvantage would be the manual creation of the CSF and configuring of many parameters. I could do a super copy.

But an option nonetheless.



Sent from my iPhone

On Jul 1, 2020, at 3:59 PM, Anthony Holloway <avholloway+cisco-voip@gmail.com> wrote:

?

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca


Forgive my ignorance here, since I do not do day 2 ops work often (thus quick add's set backs are not top of mind), I mostly focus on new deployments, which typically involve BAT, so what is the trouble/uniqueness in Jabber CSF devices versus a physical phone? Also, how come Option A doesn't mention the Jabber piece? Is that implied that you would come back around and add Jabber afterwards, like you would do in option B, post DN add?

On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

Hello all. Looking for feedback and opinions and caveats.

Right now, we’re deploying Jabber only to those with phones/DNs. But, we need to start deploying Jabber for those individuals without phones/DNs.

Our SOPs include using Quick Add feature. (Thanks a million time Brian Meade for the pointer).

My choices so far, to address Jabber for new those without phones:

(a) Create a fake hardware phone first. This has many benefits, namely, all SOPs remain the same. Hardware phone would be deleted afterwards.

(b) Use Directory Number admin page to create/update a DN first, then use Quick Add page to assign DN to user accordingly and then click manage devices and follow remaining SOP steps.

(c) create line templates and use those when creating new extensions under quick add. The issue with this is we have so many combinations, I’d need a lot of templates.

I’m leaning towards (b), since it gives me the best of both worlds.

Thoughts?

Lelio

Sent from my iPhone
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

We may consider adding Jabber for any new phone requested. Not sure. There are disadvantages to adding a feature that someone hasn’t asked for.

As far as bulk load assignment, it would require significant reconciling and fixing of existing configurations. Not all our devices are associated with a user. Not all voicemails are. Not all phones match directory entries. Not all phones are unique 1:1 primary extensions.


Sent from my iPhone

On Jul 1, 2020, at 4:11 PM, Matthew Loraditch <MLoraditch@heliontechnologies.com> wrote:

?

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca

I would add, why not just bulk add jabber for everyone who is licensed for it and then include in your normal onboarding? Does someone care if it’s configured and not used?


Matthew Loraditch?
Sr. Network Engineer
p: 443.541.1518<tel:443.541.1518>
w: www.heliontechnologies.com<http://www.heliontechnologies.com/> | e: MLoraditch@heliontechnologies.com<mailto:MLoraditch@heliontechnologies.com>
<http://www.heliontechnologies.com/>
<image370352.png>
<https://facebook.com/heliontech>
<image284035.png>
<https://twitter.com/heliontech>
<image020357.png>
<https://www.linkedin.com/company/helion-technologies>
<image574419.png>
From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Anthony Holloway
Sent: Wednesday, July 1, 2020 4:00 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca>
Cc: cisco-voip voyp list <cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Creating Jabber for non-existent phones

[EXTERNAL]

Forgive my ignorance here, since I do not do day 2 ops work often (thus quick add's set backs are not top of mind), I mostly focus on new deployments, which typically involve BAT, so what is the trouble/uniqueness in Jabber CSF devices versus a physical phone? Also, how come Option A doesn't mention the Jabber piece? Is that implied that you would come back around and add Jabber afterwards, like you would do in option B, post DN add?

On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

Hello all. Looking for feedback and opinions and caveats.

Right now, we’re deploying Jabber only to those with phones/DNs. But, we need to start deploying Jabber for those individuals without phones/DNs.

Our SOPs include using Quick Add feature. (Thanks a million time Brian Meade for the pointer).

My choices so far, to address Jabber for new those without phones:

(a) Create a fake hardware phone first. This has many benefits, namely, all SOPs remain the same. Hardware phone would be deleted afterwards.

(b) Use Directory Number admin page to create/update a DN first, then use Quick Add page to assign DN to user accordingly and then click manage devices and follow remaining SOP steps.

(c) create line templates and use those when creating new extensions under quick add. The issue with this is we have so many combinations, I’d need a lot of templates.

I’m leaning towards (b), since it gives me the best of both worlds.

Thoughts?

Lelio

Sent from my iPhone
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

Yeah, I have done a bulk assignment on 2,000 users once, and it was a data
collection/juggling nightmare for me. BATing in CSF is a cakewalk if you
start with good data. However, getting that good data on a brownfield
that's 10 years old with a lot garbage in it is painful to say the least.

On Wed, Jul 1, 2020 at 3:38 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:

>
> We may consider adding Jabber for any new phone requested. Not sure. There
> are disadvantages to adding a feature that someone hasn’t asked for.
>
> As far as bulk load assignment, it would require significant reconciling
> and fixing of existing configurations. Not all our devices are associated
> with a user. Not all voicemails are. Not all phones match directory
> entries. Not all phones are unique 1:1 primary extensions.
>
>
> Sent from my iPhone
>
> On Jul 1, 2020, at 4:11 PM, Matthew Loraditch <
> MLoraditch@heliontechnologies.com> wrote:
>
> ?
>
> CAUTION: This email originated from outside of the University of Guelph.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe. If in doubt, forward suspicious emails to
> IThelp@uoguelph.ca
>
> I would add, why not just bulk add jabber for everyone who is licensed for
> it and then include in your normal onboarding? Does someone care if it’s
> configured and not used?
>
>
>
> Matthew Loraditch?
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/> |
> e: *MLoraditch@heliontechnologies.com* <MLoraditch@heliontechnologies.com>
>
> <image370352.png>
> <http://www.heliontechnologies.com/>
>
> <image284035.png>
> <https://facebook.com/heliontech>
>
> <image020357.png>
> <https://twitter.com/heliontech>
>
> <image574419.png>
> <https://www.linkedin.com/company/helion-technologies>
>
> *From:* cisco-voip <cisco-voip-bounces@puck.nether.net> *On Behalf Of *Anthony
> Holloway
> *Sent:* Wednesday, July 1, 2020 4:00 PM
> *To:* Lelio Fulgenzi <lelio@uoguelph.ca>
> *Cc:* cisco-voip voyp list <cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Creating Jabber for non-existent phones
>
>
>
> [EXTERNAL]
>
>
>
> Forgive my ignorance here, since I do not do day 2 ops work often (thus
> quick add's set backs are not top of mind), I mostly focus on new
> deployments, which typically involve BAT, so what is the trouble/uniqueness
> in Jabber CSF devices versus a physical phone? Also, how come Option A
> doesn't mention the Jabber piece? Is that implied that you would come back
> around and add Jabber afterwards, like you would do in option B, post DN
> add?
>
>
>
> On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>
>
> Hello all. Looking for feedback and opinions and caveats.
>
> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
> need to start deploying Jabber for those individuals without phones/DNs.
>
> Our SOPs include using Quick Add feature. (Thanks a million time Brian
> Meade for the pointer).
>
> My choices so far, to address Jabber for new those without phones:
>
> (a) Create a fake hardware phone first. This has many benefits, namely,
> all SOPs remain the same. Hardware phone would be deleted afterwards.
>
> (b) Use Directory Number admin page to create/update a DN first, then use
> Quick Add page to assign DN to user accordingly and then click manage
> devices and follow remaining SOP steps.
>
> (c) create line templates and use those when creating new extensions under
> quick add. The issue with this is we have so many combinations, I’d need a
> lot of templates.
>
> I’m leaning towards (b), since it gives me the best of both worlds.
>
> Thoughts?
>
> Lelio
>
> Sent from my iPhone
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

Not deploying Jabber yet (that will be next), however going through this exercise to create RMA/SNR config for MS Teams.

Using AXL to gather the data and fix any major issues/see what the current config is. Then AXL again to set the desired config. Thus far it works great. That said there was a significant invest of time to script this. Though it’s far less than what would have been required to do this another way.

Plan to build upon the same code to build CSFs for anyone that has a soft phone and migraine UCCE agent lines.

> On Jul 1, 2020, at 17:12, Anthony Holloway <avholloway+cisco-voip@gmail.com> wrote:
>
> ?
> Yeah, I have done a bulk assignment on 2,000 users once, and it was a data collection/juggling nightmare for me. BATing in CSF is a cakewalk if you start with good data. However, getting that good data on a brownfield that's 10 years old with a lot garbage in it is painful to say the least.
>
>> On Wed, Jul 1, 2020 at 3:38 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>>
>> We may consider adding Jabber for any new phone requested. Not sure. There are disadvantages to adding a feature that someone hasn’t asked for.
>>
>> As far as bulk load assignment, it would require significant reconciling and fixing of existing configurations. Not all our devices are associated with a user. Not all voicemails are. Not all phones match directory entries. Not all phones are unique 1:1 primary extensions.
>>
>>
>> Sent from my iPhone
>>
>>> On Jul 1, 2020, at 4:11 PM, Matthew Loraditch <MLoraditch@heliontechnologies.com> wrote:
>>>
>>> ?
>>> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca
>>>
>>> I would add, why not just bulk add jabber for everyone who is licensed for it and then include in your normal onboarding? Does someone care if it’s configured and not used?
>>>
>>>
>>>
>>>
>>> Matthew Loraditch?
>>> Sr. Network Engineer
>>> p: 443.541.1518
>>> w: www.heliontechnologies.com | e: MLoraditch@heliontechnologies.com
>>> <image370352.png>
>>> <image284035.png>
>>> <image020357.png>
>>> <image574419.png>
>>> From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Anthony Holloway
>>> Sent: Wednesday, July 1, 2020 4:00 PM
>>> To: Lelio Fulgenzi <lelio@uoguelph.ca>
>>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net>
>>> Subject: Re: [cisco-voip] Creating Jabber for non-existent phones
>>>
>>>
>>>
>>> [EXTERNAL]
>>>
>>>
>>>
>>> Forgive my ignorance here, since I do not do day 2 ops work often (thus quick add's set backs are not top of mind), I mostly focus on new deployments, which typically involve BAT, so what is the trouble/uniqueness in Jabber CSF devices versus a physical phone? Also, how come Option A doesn't mention the Jabber piece? Is that implied that you would come back around and add Jabber afterwards, like you would do in option B, post DN add?
>>>
>>>
>>>
>>> On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>>>
>>>
>>> Hello all. Looking for feedback and opinions and caveats.
>>>
>>> Right now, we’re deploying Jabber only to those with phones/DNs. But, we need to start deploying Jabber for those individuals without phones/DNs.
>>>
>>> Our SOPs include using Quick Add feature. (Thanks a million time Brian Meade for the pointer).
>>>
>>> My choices so far, to address Jabber for new those without phones:
>>>
>>> (a) Create a fake hardware phone first. This has many benefits, namely, all SOPs remain the same. Hardware phone would be deleted afterwards.
>>>
>>> (b) Use Directory Number admin page to create/update a DN first, then use Quick Add page to assign DN to user accordingly and then click manage devices and follow remaining SOP steps.
>>>
>>> (c) create line templates and use those when creating new extensions under quick add. The issue with this is we have so many combinations, I’d need a lot of templates.
>>>
>>> I’m leaning towards (b), since it gives me the best of both worlds.
>>>
>>> Thoughts?
>>>
>>> Lelio
>>>
>>> Sent from my iPhone
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

Yeah. More like 15-20 years worth of custom solutions, orphaned phones, unlinked phones and voicemail, different device CSS, various line CSS for long distance restrictions, and so on and so on.

I’d honestly have to end up making two dozen templates and then worry about the myriad of exceptions.

It would be horrible.

Sent from my iPhone

On Jul 1, 2020, at 6:09 PM, Anthony Holloway <avholloway+cisco-voip@gmail.com> wrote:

?

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca


Yeah, I have done a bulk assignment on 2,000 users once, and it was a data collection/juggling nightmare for me. BATing in CSF is a cakewalk if you start with good data. However, getting that good data on a brownfield that's 10 years old with a lot garbage in it is painful to say the least.

On Wed, Jul 1, 2020 at 3:38 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

We may consider adding Jabber for any new phone requested. Not sure. There are disadvantages to adding a feature that someone hasn’t asked for.

As far as bulk load assignment, it would require significant reconciling and fixing of existing configurations. Not all our devices are associated with a user. Not all voicemails are. Not all phones match directory entries. Not all phones are unique 1:1 primary extensions.


Sent from my iPhone

On Jul 1, 2020, at 4:11 PM, Matthew Loraditch <MLoraditch@heliontechnologies.com<mailto:MLoraditch@heliontechnologies.com>> wrote:

?

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca<mailto:IThelp@uoguelph.ca>

I would add, why not just bulk add jabber for everyone who is licensed for it and then include in your normal onboarding? Does someone care if it’s configured and not used?


Matthew Loraditch?
Sr. Network Engineer
p: 443.541.1518<tel:443.541.1518>
w: www.heliontechnologies.com<http://www.heliontechnologies.com/> | e: MLoraditch@heliontechnologies.com<mailto:MLoraditch@heliontechnologies.com>
<http://www.heliontechnologies.com/>
<image370352.png>
<https://facebook.com/heliontech>
<image284035.png>
<https://twitter.com/heliontech>
<image020357.png>
<https://www.linkedin.com/company/helion-technologies>
<image574419.png>
From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Anthony Holloway
Sent: Wednesday, July 1, 2020 4:00 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>>
Cc: cisco-voip voyp list <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Creating Jabber for non-existent phones

[EXTERNAL]

Forgive my ignorance here, since I do not do day 2 ops work often (thus quick add's set backs are not top of mind), I mostly focus on new deployments, which typically involve BAT, so what is the trouble/uniqueness in Jabber CSF devices versus a physical phone? Also, how come Option A doesn't mention the Jabber piece? Is that implied that you would come back around and add Jabber afterwards, like you would do in option B, post DN add?

On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

Hello all. Looking for feedback and opinions and caveats.

Right now, we’re deploying Jabber only to those with phones/DNs. But, we need to start deploying Jabber for those individuals without phones/DNs.

Our SOPs include using Quick Add feature. (Thanks a million time Brian Meade for the pointer).

My choices so far, to address Jabber for new those without phones:

(a) Create a fake hardware phone first. This has many benefits, namely, all SOPs remain the same. Hardware phone would be deleted afterwards.

(b) Use Directory Number admin page to create/update a DN first, then use Quick Add page to assign DN to user accordingly and then click manage devices and follow remaining SOP steps.

(c) create line templates and use those when creating new extensions under quick add. The issue with this is we have so many combinations, I’d need a lot of templates.

I’m leaning towards (b), since it gives me the best of both worlds.

Thoughts?

Lelio

Sent from my iPhone
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

Lelio,

I'm actually starting to work on creating some Python scripts to allow bulk
using the Quick User/Phone Add feature such as using it to add Jabber
devices for all users very quickly. I'm also going to use this for bulk
deploying Remote Destination Profiles/Device Profiles.

I'm not sure if I'll share the full code or keep that internal to ePlus but
I'll share some of my findings around how these internal/non-documented
API's seem to be working behind the scenes.

Create a DN with a specific line template:

POST https://<CUCM>/ucmadmin/directorynumber/addDn/ HTTP/1.1

Body:

{"dnorpattern":"8888888888","universallinetemplate":"3a63b9c6-e867-4a37-82ca-9f5ad55d515c"}

200 OK response will contain the PKID of the new Directory Number.

Set Primary Extension. Replace PKID after /enduser/ with PKID of the end
user, fknumplan/sortorder is the important part.
This one may be easier to set via AXL API instead.

PUT https://<CUCM>/ucmadmin/enduser/98735c00-12d6-6e16-f985-7778d05806b1
HTTP/1.1

Body:

{"externData":{"groupAssociations":[],"extensions":[{"pkid":"","fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","sortorder":1,"lineDirectoryURI":{"fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","directoryuri":"","fkroutepartition":"","isprimary":false}}]},"credentialInfo":{"useDefaultCredential":false,"password":null,"passwordConfirm":null,"pin":null,"pinConfirm":null},"pkid":"98735c00-12d6-6e16-f985-7778d05806b1","firstname":"Brian","middlename":"","displayname":"","lastname":"Meade","userid":"bmeade-test","fkdirectorypluginconfig":null,"fkfeaturegrouptemplate":"41128559-bd7b-93cc-1166-01acf5b5bd4d","fkucuserprofile":"b2d3d9d0-a6bd-0136-d54f-bfee73f3ed74","userRank":"1","directoryuri":"","telephonenumber":"","mailid":"","manager":"","department":""}



Find a phone to move to a user. Replace PKID in POST URI with PKID of end
user. Device list shows PKID of device you want to move:

POST https://<CUCM>/ucmadmin/enduser/movePhones/98735c00-12d6-6e16-f985-7778d05806b1
HTTP/1.1

Body:

{"devicelist":[{"pkid":"3784d3e8-62c9-4b26-bfaa-1e7c741511bd"}]}



Add a new phone for a user. Replace PKID in POST with PKID of end user.
Replace device template PKID with the device template you want to use.
tkproduct is the model number from the typeproduct table. isProfile is
used to say it's a device profile for extension mobility:

POST https://<CUCM>/ucmadmin/enduser/addPhone/98735c00-12d6-6e16-f985-7778d05806b1
HTTP/1.1

Body:

{"tkproduct":"30041","tkdeviceprotocol":"0","name":"SEPBMEADE","fkcommondevicetemplate":"580497c1-15e1-4e27-91ef-6f1e00f2e417","isprofile":"f","moduleCount":0}



On Wed, Jul 1, 2020 at 2:06 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:

>
> Hello all. Looking for feedback and opinions and caveats.
>
> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
> need to start deploying Jabber for those individuals without phones/DNs.
>
> Our SOPs include using Quick Add feature. (Thanks a million time Brian
> Meade for the pointer).
>
> My choices so far, to address Jabber for new those without phones:
>
> (a) Create a fake hardware phone first. This has many benefits, namely,
> all SOPs remain the same. Hardware phone would be deleted afterwards.
>
> (b) Use Directory Number admin page to create/update a DN first, then use
> Quick Add page to assign DN to user accordingly and then click manage
> devices and follow remaining SOP steps.
>
> (c) create line templates and use those when creating new extensions under
> quick add. The issue with this is we have so many combinations, I’d need a
> lot of templates.
>
> I’m leaning towards (b), since it gives me the best of both worlds.
>
> Thoughts?
>
> Lelio
>
> Sent from my iPhone
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

> However, getting that good data on a brownfield that's 10 years old with a lot garbage in it is painful to say the least.

This is what I’ve been doing for the last several years and I’m still not done. It’s much better than it was, but there is still some “just get it out there” mentality. We know how easy it is to take things away or change them once they’re set. This is where tooling and proficiency really help, I’ve been able to use various data sources and APIs to clean things up, where I can now make presumptions for things, like changing button layouts or provisioning. The payoff was well worth the pain. If/when we end up shifting off of premise UCM to some other solution or vendor, not having the ducks in a row would be brutal.

You tease!

Just kidding, thanks for sharing this. Did you just get this from the logs
then? Or some other dark magic?

On Wed, Jul 1, 2020 at 11:02 PM Brian Meade <bmeade90@vt.edu> wrote:

> Lelio,
>
> I'm actually starting to work on creating some Python scripts to allow
> bulk using the Quick User/Phone Add feature such as using it to add Jabber
> devices for all users very quickly. I'm also going to use this for bulk
> deploying Remote Destination Profiles/Device Profiles.
>
> I'm not sure if I'll share the full code or keep that internal to ePlus
> but I'll share some of my findings around how these internal/non-documented
> API's seem to be working behind the scenes.
>
> Create a DN with a specific line template:
>
> POST https://<CUCM>/ucmadmin/directorynumber/addDn/ HTTP/1.1
>
> Body:
>
>
> {"dnorpattern":"8888888888","universallinetemplate":"3a63b9c6-e867-4a37-82ca-9f5ad55d515c"}
>
> 200 OK response will contain the PKID of the new Directory Number.
>
> Set Primary Extension. Replace PKID after /enduser/ with PKID of the end
> user, fknumplan/sortorder is the important part.
> This one may be easier to set via AXL API instead.
>
> PUT https://<CUCM>/ucmadmin/enduser/98735c00-12d6-6e16-f985-7778d05806b1
> HTTP/1.1
>
> Body:
>
>
> {"externData":{"groupAssociations":[],"extensions":[{"pkid":"","fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","sortorder":1,"lineDirectoryURI":{"fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","directoryuri":"","fkroutepartition":"","isprimary":false}}]},"credentialInfo":{"useDefaultCredential":false,"password":null,"passwordConfirm":null,"pin":null,"pinConfirm":null},"pkid":"98735c00-12d6-6e16-f985-7778d05806b1","firstname":"Brian","middlename":"","displayname":"","lastname":"Meade","userid":"bmeade-test","fkdirectorypluginconfig":null,"fkfeaturegrouptemplate":"41128559-bd7b-93cc-1166-01acf5b5bd4d","fkucuserprofile":"b2d3d9d0-a6bd-0136-d54f-bfee73f3ed74","userRank":"1","directoryuri":"","telephonenumber":"","mailid":"","manager":"","department":""}
>
>
>
> Find a phone to move to a user. Replace PKID in POST URI with PKID of end
> user. Device list shows PKID of device you want to move:
>
> POST https://<CUCM>/ucmadmin/enduser/movePhones/98735c00-12d6-6e16-f985-7778d05806b1
> HTTP/1.1
>
> Body:
>
> {"devicelist":[{"pkid":"3784d3e8-62c9-4b26-bfaa-1e7c741511bd"}]}
>
>
>
> Add a new phone for a user. Replace PKID in POST with PKID of end user.
> Replace device template PKID with the device template you want to use.
> tkproduct is the model number from the typeproduct table. isProfile is
> used to say it's a device profile for extension mobility:
>
> POST https://<CUCM>/ucmadmin/enduser/addPhone/98735c00-12d6-6e16-f985-7778d05806b1
> HTTP/1.1
>
> Body:
>
>
> {"tkproduct":"30041","tkdeviceprotocol":"0","name":"SEPBMEADE","fkcommondevicetemplate":"580497c1-15e1-4e27-91ef-6f1e00f2e417","isprofile":"f","moduleCount":0}
>
>
>
> On Wed, Jul 1, 2020 at 2:06 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>
>>
>> Hello all. Looking for feedback and opinions and caveats.
>>
>> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
>> need to start deploying Jabber for those individuals without phones/DNs.
>>
>> Our SOPs include using Quick Add feature. (Thanks a million time Brian
>> Meade for the pointer).
>>
>> My choices so far, to address Jabber for new those without phones:
>>
>> (a) Create a fake hardware phone first. This has many benefits, namely,
>> all SOPs remain the same. Hardware phone would be deleted afterwards.
>>
>> (b) Use Directory Number admin page to create/update a DN first, then use
>> Quick Add page to assign DN to user accordingly and then click manage
>> devices and follow remaining SOP steps.
>>
>> (c) create line templates and use those when creating new extensions
>> under quick add. The issue with this is we have so many combinations, I’d
>> need a lot of templates.
>>
>> I’m leaning towards (b), since it gives me the best of both worlds.
>>
>> Thoughts?
>>
>> Lelio
>>
>> Sent from my iPhone
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

Fiddler has been helping me out a lot lately for these! I had to do the
same to figure out how the Webex Device Connector actually works under the
hood.

On Thu, Jul 2, 2020 at 12:58 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> You tease!
>
> Just kidding, thanks for sharing this. Did you just get this from the
> logs then? Or some other dark magic?
>
> On Wed, Jul 1, 2020 at 11:02 PM Brian Meade <bmeade90@vt.edu> wrote:
>
>> Lelio,
>>
>> I'm actually starting to work on creating some Python scripts to allow
>> bulk using the Quick User/Phone Add feature such as using it to add Jabber
>> devices for all users very quickly. I'm also going to use this for bulk
>> deploying Remote Destination Profiles/Device Profiles.
>>
>> I'm not sure if I'll share the full code or keep that internal to ePlus
>> but I'll share some of my findings around how these internal/non-documented
>> API's seem to be working behind the scenes.
>>
>> Create a DN with a specific line template:
>>
>> POST https://<CUCM>/ucmadmin/directorynumber/addDn/ HTTP/1.1
>>
>> Body:
>>
>>
>> {"dnorpattern":"8888888888","universallinetemplate":"3a63b9c6-e867-4a37-82ca-9f5ad55d515c"}
>>
>> 200 OK response will contain the PKID of the new Directory Number.
>>
>> Set Primary Extension. Replace PKID after /enduser/ with PKID of the end
>> user, fknumplan/sortorder is the important part.
>> This one may be easier to set via AXL API instead.
>>
>> PUT https://<CUCM>/ucmadmin/enduser/98735c00-12d6-6e16-f985-7778d05806b1
>> HTTP/1.1
>>
>> Body:
>>
>>
>> {"externData":{"groupAssociations":[],"extensions":[{"pkid":"","fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","sortorder":1,"lineDirectoryURI":{"fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","directoryuri":"","fkroutepartition":"","isprimary":false}}]},"credentialInfo":{"useDefaultCredential":false,"password":null,"passwordConfirm":null,"pin":null,"pinConfirm":null},"pkid":"98735c00-12d6-6e16-f985-7778d05806b1","firstname":"Brian","middlename":"","displayname":"","lastname":"Meade","userid":"bmeade-test","fkdirectorypluginconfig":null,"fkfeaturegrouptemplate":"41128559-bd7b-93cc-1166-01acf5b5bd4d","fkucuserprofile":"b2d3d9d0-a6bd-0136-d54f-bfee73f3ed74","userRank":"1","directoryuri":"","telephonenumber":"","mailid":"","manager":"","department":""}
>>
>>
>>
>> Find a phone to move to a user. Replace PKID in POST URI with PKID of
>> end user. Device list shows PKID of device you want to move:
>>
>> POST https://<CUCM>/ucmadmin/enduser/movePhones/98735c00-12d6-6e16-f985-7778d05806b1
>> HTTP/1.1
>>
>> Body:
>>
>> {"devicelist":[{"pkid":"3784d3e8-62c9-4b26-bfaa-1e7c741511bd"}]}
>>
>>
>>
>> Add a new phone for a user. Replace PKID in POST with PKID of end user.
>> Replace device template PKID with the device template you want to use.
>> tkproduct is the model number from the typeproduct table. isProfile is
>> used to say it's a device profile for extension mobility:
>>
>> POST https://<CUCM>/ucmadmin/enduser/addPhone/98735c00-12d6-6e16-f985-7778d05806b1
>> HTTP/1.1
>>
>> Body:
>>
>>
>> {"tkproduct":"30041","tkdeviceprotocol":"0","name":"SEPBMEADE","fkcommondevicetemplate":"580497c1-15e1-4e27-91ef-6f1e00f2e417","isprofile":"f","moduleCount":0}
>>
>>
>>
>> On Wed, Jul 1, 2020 at 2:06 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>>
>>>
>>> Hello all. Looking for feedback and opinions and caveats.
>>>
>>> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
>>> need to start deploying Jabber for those individuals without phones/DNs.
>>>
>>> Our SOPs include using Quick Add feature. (Thanks a million time Brian
>>> Meade for the pointer).
>>>
>>> My choices so far, to address Jabber for new those without phones:
>>>
>>> (a) Create a fake hardware phone first. This has many benefits, namely,
>>> all SOPs remain the same. Hardware phone would be deleted afterwards.
>>>
>>> (b) Use Directory Number admin page to create/update a DN first, then
>>> use Quick Add page to assign DN to user accordingly and then click manage
>>> devices and follow remaining SOP steps.
>>>
>>> (c) create line templates and use those when creating new extensions
>>> under quick add. The issue with this is we have so many combinations, I’d
>>> need a lot of templates.
>>>
>>> I’m leaning towards (b), since it gives me the best of both worlds.
>>>
>>> Thoughts?
>>>
>>> Lelio
>>>
>>> Sent from my iPhone
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>