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.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://<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.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> 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 <nicksbarn...@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@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