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

Fri Oct 6 18:34:11 EDT 2017

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 <nicksbarnett at gmail.com> 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 <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/20171006/8ce28f1e/attachment.html>