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

Sun Oct 1 14:35:57 EDT 2017

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 <nathan.a.reeves at 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://<connection-server>/vmrest/users/ will dump the users
> on the Connection Server.
> - For each user you'll find an objectId listed. A GET to https://<connection-server>/vmrest/users/<user-objectid>/externalserviceaccounts
> will dump any attached external services account for the user.
> - You'll want to then grab the '<URI>' value in the returned data (looking
> like '/vmrest/users/<user-objectid>/externalserviceaccounts/<ObjectId>' and
> execute a DELETE against that URI (obv adding 'https://<connection-server>/'
> to the URI).
> - Note that you need to use basic auth to login as an appadmin for the
> request.
> - CURL wise: curl --basic --user <app admin>:<password> -k -X DELETE
> https://
> <connection-server>/vmrest/users/<user-objectid>/externalserviceaccounts/<object-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.
>
> <ExternalServiceAccount>
>      <ExternalServiceObjectId>*%umservice-objectid%*</ExternalServiceObjectId>
>      <SubscriberObjectId>*%user-objectid%*</SubscriberObjectId>
>      <UserURI>/vmrest/users/*%user-objectid%*</UserURI>
>      <EnableCalendarCapability>true</EnableCalendarCapability>
>      <EnableMeetingCapability>false</EnableMeetingCapability>
>      <EnableTtsOfEmailCapability>true</EnableTtsOfEmailCapability>
>      <IsPrimaryMeetingService>false</IsPrimaryMeetingService>
>      <LoginType>0</LoginType>
>      <UserPassword/>
>      <EnableMailboxSynchCapability>true</EnableMailboxSynchCapability>
>      <EmailAddressUseCorp>true</EmailAddressUseCorp>
> </ExternalServiceAccount>
>
> You'll need to then POST this XML to url: 'https://<connection-server>/vmrest/users/<user-objectid>/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.reeves at 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-voip at 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://
>>> <connection-server>/vmrest/users/<user-objectid>/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 <nicksbarnett at gmail.com>
>>> 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 at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20171001/f3cb88cb/attachment.html>