RPRM 10.0.1_25, HDX 7000('s), 3.0.
We are able to dynamically provision Group Series endpoints. Both Admin and Network profiles.
Trying to provision an HDX 7000 endpoint and recieving failure notices on the HDX and RPRM. Have attempted both Machine Account on RPRM and an Active Directory room account (preferred for us). The AD account approach does seem to work somewhat. The AD account info and attributes we are using do seem to show up in RPRM (phone attribute and .164 number, etc) but the provisioning status shows 'failed'. So clearly the command from the HDX with the user/pass/domain is hitting the RPRM. Under Rooms in RPRM, after an attempt to provision the HDX is associated with the Room Account (with details coming from the AD account).
On the HDX, the endpoint logs show a failure:
2017-02-22 22:55:00 ERROR jvm: pc: UI: fcgi/0: ProvisionUpdater: There was a fatal error in parsing the profile, abandoning provisioning 2017-02-22 22:55:00 ERROR jvm: pc: UI: fcgi/0: ProvisionUpdater: Provisioning had fatal error on: enablesecureprofile
I have reset the profiles for the HDX (Group Series has their own profiles), applied just network profile or just admin profile, setup simplified profiles that don't change much (if anything at all) and the HDX still throws an error. The provisions page shows the same default error, something to the affect of checking user, pass, domain, etc.
Looking through the RPRM logs but not sure where to be looking exactly. Is there a particular log with the provisioning details?
RPRM has a self-signed cert, all the provisioning is happening behind a central firewall and manually pointing the HDX at the DMA, etc all seems to work fine.
Solved! Go to Solution.
welcome back to the Polycom Community.
The only issue internally I could find with the same error message was SSGSE-11866 and goes back to the days of the CMA.
Is your HDX some kind of JITC aka a secure installation?
The "old" issue was that the HDX did not understand the security profile of NONE as it should be Off instead. You can double check this on your profile but the old case was from back in 2011
The next step would be a Polycom service ticket via your reseller.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Polycom Global Services
Working with our reseller and Polycom on this.
I figured out something that got a bit further. The HDX takes the Provisioning information and reboots. RPRM Status for that particular endpoint is 'in progress' - which is an improvement.
This particular issue - which we have seemed to get past, but have got caught on the next conflicting setting - is related to the Security Profile and Enable Secure Mode on the RPRM network profile settings when provisioning HDX units.
RPRM 10.+ seems to be catered to Group Series, especially the Dynamic provisioning. The profile language and what gets sent to the endpoints, especially with security, is centered on the Group Series. In this case the Security profile (in my experience) needs to be set to NONE and Enable Secure Mode [unchecked].
We are not out of the woods on our particular deployment (I got 30+ HDX units and can't abandon them) but I'll document what I find here, to help someone in the future.
We plan to use (with HDX):
Dynamic Provisioning from RPRM 10
Calendaring/One Touch Dialing (OTD)
Enterprise Integration (AD OU's to set local account access, etc on each endpoint).
I'll try and come back and summarize what works and doesn't for us when we come to some conclusion.
We worked with our vendor and Polycom support to come to a couple conclusions:
For HDX units, 3.1.11 (at this point, the final update from what I understand) the Dynamic Provisioning should work. In our tests, it seems to work.
For anything under that (essentially, most owners whether on maintainence or not should be able to update to 3.0.6, we were able to take 20+ endpoints from 2.6.xx to 3.0.6), Scheduled Provisioning is required. In our tests, even under this scenario, we run into provisioning failures (reported in RPRM). However, the endpoints take the settings. Breaking up the number of changes pushed at once increases the odds of success being reported on RPRM. At this point we have 4 'sets' of changes being pushed with one sneaky problem child setting that causes the HDX to report some error to RPRM to report failure in the provisioning process. I am not sure we'll hunt down that particular problem because, as I said, the settings we are pushing do end up on the endpoint, it's that RPRM shows the error. Looking through the logs, all this stems from some XML markups that RPRM pushes that only certain HDX versions understand. When the HDX hits one it doesnt know, it stops or skips it and the RPRM sees that failure.
Settings related to calendaring, etc on the older HDX's need to be set by hand, which isn't that big of a deal. We are generating Active Directory room accounts for each endpoint. The 3.1.11 HDX units and the Group Series complete their entire setup (including AD tie-ins) automatically. For the older HDX we just take the AD account info and generate a format for HDX naming, calendars, directory, etc that ensures contiunity across all our devices.
From Polycom's side, the RPRM Op manual should just have a clear and defined note saying 'Less than 3.1.11 HDX....' with a small description. Even Polycom techs had to look it up outside of the regular material available to users and even then, they setup some bench setups to mimic ours to confirm (which was nice of them to do - shout out to Waxson).
Do you have a Polycom Ticket reference as I am unable to find a Polycom employee called Waxson
Polycom Global Services