Re: [cisco-voip] Changing CUC UM Account with API?

[Anthony Holloway]

If you want to feel crushed again, you can challenge yourself to the UCCX
Admin API.  That documentation is worse than the CUC documentation.  ;)

On Fri, Oct 6, 2017 at 2:33 PM Nick Barnett  wrote:

> I just wanted to send a quick update and another THANK YOU, this worked
> perfectly for adding office 365 accounts! Thanks so much. I only ran into
> one real issue, which I'll know more about next time... apparently, one of
> my POST requests actually worked and then added the UM account to the CUC
> user. I didn't know this happened because I guess I wasn't paying close
> enough attention. From that point on, I kept getting a "400 Bad Request."
>  We spun our wheels for an hour or so trying to figure out what was wrong
> with the web request. Turns out, there was nothing wrong and CUC responds
> with a 400 when you try to add a SECOND UM account. Derp. We deleted the
> one that was added during testing and were able to successfully put it back
> on.
>
> FWIW, we used iwr from powershell, and not postman. Going through this
> exercise has really been eye opening on how this works. I just didn't "get
> it" before... one step closer to world domination :)
>
> Thanks,
> Nick
>
> On Sun, Oct 1, 2017 at 12:25 AM, Nathan Reeves 
> wrote:
>
>> Taken a quick look and yeah, Anthony is correct in regards to the use of
>> DELETE.
>>
>> *To Delete the existing UM Service account:*
>> - A GET to https:///vmrest/users/ will dump the users
>> on the Connection Server.
>> - For each user you'll find an objectId listed. A GET to 
>> https:///vmrest/users//externalserviceaccounts
>> will dump any attached external services account for the user.
>> - You'll want to then grab the '' value in the returned data
>> (looking like
>> '/vmrest/users//externalserviceaccounts/' and
>> execute a DELETE against that URI (obv adding 'https:///'
>> to the URI).
>> - Note that you need to use basic auth to login as an appadmin for the
>> request.
>> - CURL wise: curl --basic --user : -k -X DELETE
>> https://
>> /vmrest/users//externalserviceaccounts/
>>
>> *To add the new UM Service to the user account:*
>> - Update the XML below with:
>>- %umservice-objectid% - The guid of the um service (easiest way is to
>> grab the guid from the CUC Admin pages for the UM service listed under
>> Unified Messaging > Unified Messaging Services).
>>- %user-objectid% - As per the id you found prev when you did the
>> delete.
>>
>> 
>>  
>> *%umservice-objectid%*
>>  *%user-objectid%*
>>  /vmrest/users/*%user-objectid%*
>>  true
>>  false
>>  true
>>  false
>>  0
>>  
>>  true
>>  true
>> 
>>
>> You'll need to then POST this XML to url: 
>> 'https:///vmrest/users//externalserviceaccounts'.
>> Note that again you need to provide basic auth.
>>
>> Note that the XML Above worked for me when adding a UM Service configured
>> to point to Exchange, so ~in theory~ this should work for O365 as well.
>> Not got a tenancy I can test against at the moment in O365 to confirm.
>>
>> If you use Postman to run this stuff, make sure you use the desktop
>> version (not the chrome extension version), and make sure you add the
>> 'Origin' header.  The value should be the url of the CUC Server (eg '
>> http://172.20.2.25').  This should stop you receiving the 'domain not
>> allowed' error message'
>>
>> Hope this assists.
>>
>> Nathan
>>
>>
>> On Fri, Sep 29, 2017 at 7:56 AM, Nathan Reeves > > wrote:
>>
>>> While people are possibly playing around with the CUC Provisioning API,
>>> let me know if you ever get the import of CUCM Local users to CUC working
>>> correctly.  The last rollout I did I was trying to pull in local users but
>>> the api just didn't work.  Had to use LDAP imports instead.  Never looked
>>> too much deeper as I just needed to get on with things.
>>>
>>> But yeah, the API for CUC is really hit and miss.  lol, and the API for
>>> UCCX can be a bit the same.
>>>
>>> Nathan
>>>
>>> On Fri, Sep 29, 2017 at 5:07 AM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 Wow, the documentation for the CUC API has gone to shit.  There's
 literally a link on the developer.cisco.com site that sends you to a
 wiki site, which itself then sends you to developer.cisco.com.  Nice.

 Anyway, I tried to look into this quick for you, but I got stuck with
 the documentation on POSTing a new UM account for end users.  It literally
 just says:

 "To create an a new external service account, POST an XML document 
 (formatted
 similar to the one above) to the following URL:
 POST https://
 /vmrest/users//externalserviceaccounts"
 Source:
 http://docwiki.cisco.com/wiki/Cisco_Unity_Connection_Provisioning_Interface_(CUPI)_API_--_User_Unified_Messaging_Account

 The key part being "similar to."  It's beyond my comprehension that
 anyone would think that this is 

Re: [cisco-voip] Changing CUC UM Account with API?

[Lelio Fulgenzi]

Thanks to the group for this thread. I’m likely going to have to go down a 
similar path soon and will be using this as a reference.

My biggest fear is that we haven’t had a real userID to phone to voicemail 
mapping over the years. It’s gonna be interesting going forward.

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Nick 
Barnett
Sent: Friday, October 06, 2017 3:33 PM
To: Nathan Reeves
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Changing CUC UM Account with API?

I just wanted to send a quick update and another THANK YOU, this worked 
perfectly for adding office 365 accounts! Thanks so much. I only ran into one 
real issue, which I'll know more about next time... apparently, one of my POST 
requests actually worked and then added the UM account to the CUC user. I 
didn't know this happened because I guess I wasn't paying close enough 
attention. From that point on, I kept getting a "400 Bad Request."  We spun our 
wheels for an hour or so trying to figure out what was wrong with the web 
request. Turns out, there was nothing wrong and CUC responds with a 400 when 
you try to add a SECOND UM account. Derp. We deleted the one that was added 
during testing and were able to successfully put it back on.

FWIW, we used iwr from powershell, and not postman. Going through this exercise 
has really been eye opening on how this works. I just didn't "get it" before... 
one step closer to world domination :)

Thanks,
Nick

On Sun, Oct 1, 2017 at 12:25 AM, Nathan Reeves 
<nathan.a.ree...@gmail.com<mailto:nathan.a.ree...@gmail.com>> wrote:
Taken a quick look and yeah, Anthony is correct in regards to the use of DELETE.

To Delete the existing UM Service account:
- A GET to 
https:///vmrest/users/<https://%3cconnection-server%3e/vmrest/users/>
 will dump the users on the Connection Server.
- For each user you'll find an objectId listed. A GET to 
https:///vmrest/users//externalserviceaccounts<https://%3cconnection-server%3e/vmrest/users/%3cuser-objectid%3e/externalserviceaccounts>
 will dump any attached external services account for the user.
- You'll want to then grab the '' value in the returned data (looking like 
'/vmrest/users//externalserviceaccounts/' and execute 
a DELETE against that URI (obv adding 'https:///' to the 
URI).
- Note that you need to use basic auth to login as an appadmin for the request.
- CURL wise: curl --basic --user : -k -X DELETE 
https:///vmrest/users//externalserviceaccounts/<object-id<https://%3cconnection-server%3e/vmrest/users/%3cuser-objectid%3e/externalserviceaccounts/%3cobject-id>>

To add the new UM Service to the user account:
- Update the XML below with:
   - %umservice-objectid% - The guid of the um service (easiest way is to grab 
the guid from the CUC Admin pages for the UM service listed under Unified 
Messaging > Unified Messaging Services).
   - %user-objectid% - As per the id you found prev when you did the delete.



 %umservice-objectid%

 %user-objectid%

 /vmrest/users/%user-objectid%

 true

 false

 true

 false

 0

 

 true

 true


You'll need to then POST this XML to url: 
'https:///vmrest/users//externalserviceaccounts'.
  Note that again you need to provide basic auth.

Note that the XML Above worked for me when adding a UM Service configured to 
point to Exchange, so ~in theory~ this should work for O365 as well.  Not got a 
tenancy I can test against at the moment in O365 to confirm.

If you use Postman to run this stuff, make sure you use the desktop version 
(not the chrome extension version), and make sure you add the 'Origin' header.  
The value should be the url of the CUC Server (eg 'http://172.20.2.25').  This 
should stop you receiving the 'domain not allowed' error message'

Hope this assists.

Nathan


On Fri, Sep 29, 2017 at 7:56 AM, Nathan Reeves 
<nathan.a.ree...@gmail.com<mailto:nathan.a.ree...@gmail.com>> wrote:
While people are possibly playing around with the CUC Provisioning API, let me 
know if you ever get the import of CUCM Local users to CUC working correctly.  
The last rollout I did I was trying to pull in local users but the api just 
didn't work.  Had to use LDAP imports instead.  Never looked too much deeper as 
I just needed to get on with things.

But yeah, the API for CUC is really hit and miss.  lol, and the API for UCCX 
can be a bit the same.

Nathan

On Fri, Sep 29, 2017 at 5:07 AM, Anthony Holloway 
<avholloway+cisco-v...@gmail.com<mailto:avholloway+cisco-v...@gmail.com>> wrote:
Wow, the documentation for the CUC API has gone to shit.  There's literally a 
link on the developer.cisco.com<http:/

Re: [cisco-voip] Changing CUC UM Account with API?

[Nick Barnett]

Anthony, that's what I experienced too, just an endless loop of not being
able to find what I was looking for.
Nathan, you have WAY more patience than I do right now. Thank you!

On Sun, Oct 1, 2017 at 1:35 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Oh man, you just solved my major problem with Postman desktop app.  I was
> getting the domain not allowed error, and just quit after that. I have not
> experienced that before, but now I know.  Thanks!
>
> On Sun, Oct 1, 2017 at 12:25 AM Nathan Reeves 
> wrote:
>
>> Taken a quick look and yeah, Anthony is correct in regards to the use of
>> DELETE.
>>
>> *To Delete the existing UM Service account:*
>> - A GET to https:///vmrest/users/ will dump the users
>> on the Connection Server.
>> - For each user you'll find an objectId listed. A GET to https://
>> /vmrest/users//externalserviceaccounts
>> will dump any attached external services account for the user.
>> - You'll want to then grab the '' value in the returned data
>> (looking like 
>> '/vmrest/users//externalserviceaccounts/'
>> and execute a DELETE against that URI (obv adding 
>> 'https:///'
>> to the URI).
>> - Note that you need to use basic auth to login as an appadmin for the
>> request.
>> - CURL wise: curl --basic --user : -k -X DELETE
>> https:///vmrest/users//
>> externalserviceaccounts/
>>
>> *To add the new UM Service to the user account:*
>> - Update the XML below with:
>>- %umservice-objectid% - The guid of the um service (easiest way is to
>> grab the guid from the CUC Admin pages for the UM service listed under
>> Unified Messaging > Unified Messaging Services).
>>- %user-objectid% - As per the id you found prev when you did the
>> delete.
>>
>> 
>>  
>> *%umservice-objectid%*
>>  *%user-objectid%*
>>  /vmrest/users/*%user-objectid%*
>>  true
>>  false
>>  true
>>  false
>>  0
>>  
>>  true
>>  true
>> 
>>
>> You'll need to then POST this XML to url: 'https:///
>> vmrest/users//externalserviceaccounts'.  Note that again
>> you need to provide basic auth.
>>
>> Note that the XML Above worked for me when adding a UM Service configured
>> to point to Exchange, so ~in theory~ this should work for O365 as well.
>> Not got a tenancy I can test against at the moment in O365 to confirm.
>>
>> If you use Postman to run this stuff, make sure you use the desktop
>> version (not the chrome extension version), and make sure you add the
>> 'Origin' header.  The value should be the url of the CUC Server (eg '
>> http://172.20.2.25').  This should stop you receiving the 'domain not
>> allowed' error message'
>>
>> Hope this assists.
>>
>> Nathan
>>
>>
>> On Fri, Sep 29, 2017 at 7:56 AM, Nathan Reeves > > wrote:
>>
>>> While people are possibly playing around with the CUC Provisioning API,
>>> let me know if you ever get the import of CUCM Local users to CUC working
>>> correctly.  The last rollout I did I was trying to pull in local users but
>>> the api just didn't work.  Had to use LDAP imports instead.  Never looked
>>> too much deeper as I just needed to get on with things.
>>>
>>> But yeah, the API for CUC is really hit and miss.  lol, and the API for
>>> UCCX can be a bit the same.
>>>
>>> Nathan
>>>
>>> On Fri, Sep 29, 2017 at 5:07 AM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 Wow, the documentation for the CUC API has gone to shit.  There's
 literally a link on the developer.cisco.com site that sends you to a
 wiki site, which itself then sends you to developer.cisco.com.  Nice.

 Anyway, I tried to look into this quick for you, but I got stuck with
 the documentation on POSTing a new UM account for end users.  It literally
 just says:

 "To create an a new external service account, POST an XML document 
 (formatted
 similar to the one above) to the following URL:
 POST https:///vmrest/users//
 externalserviceaccounts"
 Source: http://docwiki.cisco.com/wiki/Cisco_Unity_
 Connection_Provisioning_Interface_(CUPI)_API_--_User_
 Unified_Messaging_Account

 The key part being "similar to."  It's beyond my comprehension that
 anyone would think that this is sufficient documentation to make an API
 request work.  Suffice it to say, it didn't work for me, and now I'm done
 troubleshooting it.

 Since any good REST API should use CRUD, it would then make sense that
 you issue an HTTP DELETE to the user object + um account object URI to
 remove the old one, after you successfully run the POST above to Create the
 new association.

 Good luck.  If I have more time in the next few days, I'll try again.

 On Wed, Sep 27, 2017 at 10:25 AM Nick Barnett 
 wrote:

> I can handle most things in CUCM with SOAP, but I always get confused
> when trying to use VMREST in CUC. I cannot find a way to add and 

Re: [cisco-voip] Changing CUC UM Account with API?

[Anthony Holloway]

Oh man, you just solved my major problem with Postman desktop app.  I was
getting the domain not allowed error, and just quit after that. I have not
experienced that before, but now I know.  Thanks!

On Sun, Oct 1, 2017 at 12:25 AM Nathan Reeves 
wrote:

> Taken a quick look and yeah, Anthony is correct in regards to the use of
> DELETE.
>
> *To Delete the existing UM Service account:*
> - A GET to https:///vmrest/users/ will dump the users
> on the Connection Server.
> - For each user you'll find an objectId listed. A GET to 
> https:///vmrest/users//externalserviceaccounts
> will dump any attached external services account for the user.
> - You'll want to then grab the '' value in the returned data (looking
> like '/vmrest/users//externalserviceaccounts/' and
> execute a DELETE against that URI (obv adding 'https:///'
> to the URI).
> - Note that you need to use basic auth to login as an appadmin for the
> request.
> - CURL wise: curl --basic --user : -k -X DELETE
> https://
> /vmrest/users//externalserviceaccounts/
>
> *To add the new UM Service to the user account:*
> - Update the XML below with:
>- %umservice-objectid% - The guid of the um service (easiest way is to
> grab the guid from the CUC Admin pages for the UM service listed under
> Unified Messaging > Unified Messaging Services).
>- %user-objectid% - As per the id you found prev when you did the
> delete.
>
> 
>  *%umservice-objectid%*
>  *%user-objectid%*
>  /vmrest/users/*%user-objectid%*
>  true
>  false
>  true
>  false
>  0
>  
>  true
>  true
> 
>
> You'll need to then POST this XML to url: 
> 'https:///vmrest/users//externalserviceaccounts'.
> Note that again you need to provide basic auth.
>
> Note that the XML Above worked for me when adding a UM Service configured
> to point to Exchange, so ~in theory~ this should work for O365 as well.
> Not got a tenancy I can test against at the moment in O365 to confirm.
>
> If you use Postman to run this stuff, make sure you use the desktop
> version (not the chrome extension version), and make sure you add the
> 'Origin' header.  The value should be the url of the CUC Server (eg '
> http://172.20.2.25').  This should stop you receiving the 'domain not
> allowed' error message'
>
> Hope this assists.
>
> Nathan
>
>
> On Fri, Sep 29, 2017 at 7:56 AM, Nathan Reeves 
> wrote:
>
>> While people are possibly playing around with the CUC Provisioning API,
>> let me know if you ever get the import of CUCM Local users to CUC working
>> correctly.  The last rollout I did I was trying to pull in local users but
>> the api just didn't work.  Had to use LDAP imports instead.  Never looked
>> too much deeper as I just needed to get on with things.
>>
>> But yeah, the API for CUC is really hit and miss.  lol, and the API for
>> UCCX can be a bit the same.
>>
>> Nathan
>>
>> On Fri, Sep 29, 2017 at 5:07 AM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Wow, the documentation for the CUC API has gone to shit.  There's
>>> literally a link on the developer.cisco.com site that sends you to a
>>> wiki site, which itself then sends you to developer.cisco.com.  Nice.
>>>
>>> Anyway, I tried to look into this quick for you, but I got stuck with
>>> the documentation on POSTing a new UM account for end users.  It literally
>>> just says:
>>>
>>> "To create an a new external service account, POST an XML document 
>>> (formatted
>>> similar to the one above) to the following URL:
>>> POST https://
>>> /vmrest/users//externalserviceaccounts"
>>> Source:
>>> http://docwiki.cisco.com/wiki/Cisco_Unity_Connection_Provisioning_Interface_(CUPI)_API_--_User_Unified_Messaging_Account
>>>
>>> The key part being "similar to."  It's beyond my comprehension that
>>> anyone would think that this is sufficient documentation to make an API
>>> request work.  Suffice it to say, it didn't work for me, and now I'm done
>>> troubleshooting it.
>>>
>>> Since any good REST API should use CRUD, it would then make sense that
>>> you issue an HTTP DELETE to the user object + um account object URI to
>>> remove the old one, after you successfully run the POST above to Create the
>>> new association.
>>>
>>> Good luck.  If I have more time in the next few days, I'll try again.
>>>
>>> On Wed, Sep 27, 2017 at 10:25 AM Nick Barnett 
>>> wrote:
>>>
 I can handle most things in CUCM with SOAP, but I always get confused
 when trying to use VMREST in CUC. I cannot find a way to add and remove a
 UM account via automation. We're stuck using a CSV and it's really putting
 a cramp in our migration to Exchange Online.

 The particular change I'm needing is here: Users->EditMenu->Unified
 messaging accounts
 1) Need to add an additional one that connects to Exchange Online (this
 already exists in CUC)
 2) Need to delete the old one that connects to on prem Exchange. 

Re: [cisco-voip] Changing CUC UM Account with API?

[Nathan Reeves]

Taken a quick look and yeah, Anthony is correct in regards to the use of
DELETE.

*To Delete the existing UM Service account:*
- A GET to https:///vmrest/users/ will dump the users on
the Connection Server.
- For each user you'll find an objectId listed. A GET to
https:///vmrest/users//externalserviceaccounts
will dump any attached external services account for the user.
- You'll want to then grab the '' value in the returned data (looking
like '/vmrest/users//externalserviceaccounts/' and
execute a DELETE against that URI (obv adding 'https:///'
to the URI).
- Note that you need to use basic auth to login as an appadmin for the
request.
- CURL wise: curl --basic --user : -k -X DELETE
https://
/vmrest/users//externalserviceaccounts/

*To add the new UM Service to the user account:*
- Update the XML below with:
   - %umservice-objectid% - The guid of the um service (easiest way is to
grab the guid from the CUC Admin pages for the UM service listed under
Unified Messaging > Unified Messaging Services).
   - %user-objectid% - As per the id you found prev when you did the delete.


 *%umservice-objectid%*
 *%user-objectid%*
 /vmrest/users/*%user-objectid%*
 true
 false
 true
 false
 0
 
 true
 true


You'll need to then POST this XML to url:
'https:///vmrest/users//externalserviceaccounts'.
Note that again you need to provide basic auth.

Note that the XML Above worked for me when adding a UM Service configured
to point to Exchange, so ~in theory~ this should work for O365 as well.
Not got a tenancy I can test against at the moment in O365 to confirm.

If you use Postman to run this stuff, make sure you use the desktop version
(not the chrome extension version), and make sure you add the 'Origin'
header.  The value should be the url of the CUC Server (eg '
http://172.20.2.25').  This should stop you receiving the 'domain not
allowed' error message'

Hope this assists.

Nathan


On Fri, Sep 29, 2017 at 7:56 AM, Nathan Reeves 
wrote:

> While people are possibly playing around with the CUC Provisioning API,
> let me know if you ever get the import of CUCM Local users to CUC working
> correctly.  The last rollout I did I was trying to pull in local users but
> the api just didn't work.  Had to use LDAP imports instead.  Never looked
> too much deeper as I just needed to get on with things.
>
> But yeah, the API for CUC is really hit and miss.  lol, and the API for
> UCCX can be a bit the same.
>
> Nathan
>
> On Fri, Sep 29, 2017 at 5:07 AM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Wow, the documentation for the CUC API has gone to shit.  There's
>> literally a link on the developer.cisco.com site that sends you to a
>> wiki site, which itself then sends you to developer.cisco.com.  Nice.
>>
>> Anyway, I tried to look into this quick for you, but I got stuck with the
>> documentation on POSTing a new UM account for end users.  It literally just
>> says:
>>
>> "To create an a new external service account, POST an XML document (formatted
>> similar to the one above) to the following URL:
>> POST https:///vmrest/users//ext
>> ernalserviceaccounts"
>> Source: http://docwiki.cisco.com/wiki/Cisco_Unity_Connection
>> _Provisioning_Interface_(CUPI)_API_--_User_Unified_Messaging_Account
>>
>> The key part being "similar to."  It's beyond my comprehension that
>> anyone would think that this is sufficient documentation to make an API
>> request work.  Suffice it to say, it didn't work for me, and now I'm done
>> troubleshooting it.
>>
>> Since any good REST API should use CRUD, it would then make sense that
>> you issue an HTTP DELETE to the user object + um account object URI to
>> remove the old one, after you successfully run the POST above to Create the
>> new association.
>>
>> Good luck.  If I have more time in the next few days, I'll try again.
>>
>> On Wed, Sep 27, 2017 at 10:25 AM Nick Barnett 
>> wrote:
>>
>>> I can handle most things in CUCM with SOAP, but I always get confused
>>> when trying to use VMREST in CUC. I cannot find a way to add and remove a
>>> UM account via automation. We're stuck using a CSV and it's really putting
>>> a cramp in our migration to Exchange Online.
>>>
>>> The particular change I'm needing is here: Users->EditMenu->Unified
>>> messaging accounts
>>> 1) Need to add an additional one that connects to Exchange Online (this
>>> already exists in CUC)
>>> 2) Need to delete the old one that connects to on prem Exchange. (Not
>>> delete the whole UM connector service, but just the account association to
>>> a particular user)
>>>
>>> Does anyone have any pointers on this? We have batches of people
>>> migrating every week, sometimes multiple times per week... so I can't just
>>> make some global change.
>>>
>>> We're on CUC 10.5
>>>
>>> Thanks!
>>> Nick
>>>
>>> P.S.  I hate that MSFT and CSCO both have a product called "Unified
>>> Messaging" :)
>>> 

Re: [cisco-voip] Changing CUC UM Account with API?

[Nathan Reeves]

While people are possibly playing around with the CUC Provisioning API, let
me know if you ever get the import of CUCM Local users to CUC working
correctly.  The last rollout I did I was trying to pull in local users but
the api just didn't work.  Had to use LDAP imports instead.  Never looked
too much deeper as I just needed to get on with things.

But yeah, the API for CUC is really hit and miss.  lol, and the API for
UCCX can be a bit the same.

Nathan

On Fri, Sep 29, 2017 at 5:07 AM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Wow, the documentation for the CUC API has gone to shit.  There's
> literally a link on the developer.cisco.com site that sends you to a wiki
> site, which itself then sends you to developer.cisco.com.  Nice.
>
> Anyway, I tried to look into this quick for you, but I got stuck with the
> documentation on POSTing a new UM account for end users.  It literally just
> says:
>
> "To create an a new external service account, POST an XML document (formatted
> similar to the one above) to the following URL:
> POST https:///vmrest/users//
> externalserviceaccounts"
> Source: http://docwiki.cisco.com/wiki/Cisco_Unity_Connection_Provisioning_
> Interface_(CUPI)_API_--_User_Unified_Messaging_Account
>
> The key part being "similar to."  It's beyond my comprehension that anyone
> would think that this is sufficient documentation to make an API request
> work.  Suffice it to say, it didn't work for me, and now I'm done
> troubleshooting it.
>
> Since any good REST API should use CRUD, it would then make sense that you
> issue an HTTP DELETE to the user object + um account object URI to remove
> the old one, after you successfully run the POST above to Create the new
> association.
>
> Good luck.  If I have more time in the next few days, I'll try again.
>
> On Wed, Sep 27, 2017 at 10:25 AM Nick Barnett 
> wrote:
>
>> I can handle most things in CUCM with SOAP, but I always get confused
>> when trying to use VMREST in CUC. I cannot find a way to add and remove a
>> UM account via automation. We're stuck using a CSV and it's really putting
>> a cramp in our migration to Exchange Online.
>>
>> The particular change I'm needing is here: Users->EditMenu->Unified
>> messaging accounts
>> 1) Need to add an additional one that connects to Exchange Online (this
>> already exists in CUC)
>> 2) Need to delete the old one that connects to on prem Exchange. (Not
>> delete the whole UM connector service, but just the account association to
>> a particular user)
>>
>> Does anyone have any pointers on this? We have batches of people
>> migrating every week, sometimes multiple times per week... so I can't just
>> make some global change.
>>
>> We're on CUC 10.5
>>
>> Thanks!
>> Nick
>>
>> P.S.  I hate that MSFT and CSCO both have a product called "Unified
>> Messaging" :)
>> ___
>> 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
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Changing CUC UM Account with API?

[Anthony Holloway]

Wow, the documentation for the CUC API has gone to shit.  There's literally
a link on the developer.cisco.com site that sends you to a wiki site, which
itself then sends you to developer.cisco.com.  Nice.

Anyway, I tried to look into this quick for you, but I got stuck with the
documentation on POSTing a new UM account for end users.  It literally just
says:

"To create an a new external service account, POST an XML document (formatted
similar to the one above) to the following URL:
POST https://
/vmrest/users//externalserviceaccounts"
Source:
http://docwiki.cisco.com/wiki/Cisco_Unity_Connection_Provisioning_Interface_(CUPI)_API_--_User_Unified_Messaging_Account

The key part being "similar to."  It's beyond my comprehension that anyone
would think that this is sufficient documentation to make an API request
work.  Suffice it to say, it didn't work for me, and now I'm done
troubleshooting it.

Since any good REST API should use CRUD, it would then make sense that you
issue an HTTP DELETE to the user object + um account object URI to remove
the old one, after you successfully run the POST above to Create the new
association.

Good luck.  If I have more time in the next few days, I'll try again.

On Wed, Sep 27, 2017 at 10:25 AM Nick Barnett 
wrote:

> I can handle most things in CUCM with SOAP, but I always get confused when
> trying to use VMREST in CUC. I cannot find a way to add and remove a UM
> account via automation. We're stuck using a CSV and it's really putting a
> cramp in our migration to Exchange Online.
>
> The particular change I'm needing is here: Users->EditMenu->Unified
> messaging accounts
> 1) Need to add an additional one that connects to Exchange Online (this
> already exists in CUC)
> 2) Need to delete the old one that connects to on prem Exchange. (Not
> delete the whole UM connector service, but just the account association to
> a particular user)
>
> Does anyone have any pointers on this? We have batches of people migrating
> every week, sometimes multiple times per week... so I can't just make some
> global change.
>
> We're on CUC 10.5
>
> Thanks!
> Nick
>
> P.S.  I hate that MSFT and CSCO both have a product called "Unified
> Messaging" :)
> ___
> 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

[cisco-voip] Changing CUC UM Account with API?

[Nick Barnett]

I can handle most things in CUCM with SOAP, but I always get confused when
trying to use VMREST in CUC. I cannot find a way to add and remove a UM
account via automation. We're stuck using a CSV and it's really putting a
cramp in our migration to Exchange Online.

The particular change I'm needing is here: Users->EditMenu->Unified
messaging accounts
1) Need to add an additional one that connects to Exchange Online (this
already exists in CUC)
2) Need to delete the old one that connects to on prem Exchange. (Not
delete the whole UM connector service, but just the account association to
a particular user)

Does anyone have any pointers on this? We have batches of people migrating
every week, sometimes multiple times per week... so I can't just make some
global change.

We're on CUC 10.5

Thanks!
Nick

P.S.  I hate that MSFT and CSCO both have a product called "Unified
Messaging" :)
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip