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