Freeze one phone and one expected value
Record the phone's exact vendor, model, hardware revision, MAC address, firmware, extension, IP address, current value, expected value and the time the change was submitted. Choose one visible low-risk field such as a label or time zone. Do not start with a fleet-wide rebuild, firmware change or factory reset.
Confirm the installed Endpoint Manager and, where relevant, DPMA versions and configuration owner. If legacy Sangoma Phones Config and Endpoint Manager DPMA are both active, stop and resolve ownership under the supported migration path before interpreting a generated file.
Prove the mapping and template source
Find the device by normalized MAC address and confirm the mapped extension, account position, vendor, model and template. Check whether the intended field comes from the normal template, model setting, base-file override, extension mapping or device-local policy. A changed default template does not affect a phone mapped to another template, and a setting for one model may not exist on another.
Preserve the pre-change mapping and value. Correct one demonstrated source rather than copying an override into every template; broad base-file edits can make later GUI values appear ineffective.
Separate save, build and update evidence
Confirm that the template value was saved, then rebuild the configuration for the pilot device. Inspect the newly generated file or DPMA state for the expected value without exposing credentials. Only then send the documented update action. Sangoma describes Save, Rebuild Config(s) and Update Phones as saving database state, writing files and asking mapped phones to retrieve them; each stage can succeed or fail independently.
Record the generated artifact timestamp and the update request. A success banner or notification proves neither a device fetch nor an applied runtime value.
Find which server the phone actually uses
Record the active discovery path: manually configured URL, DHCP Option 66, zero-touch service, mDNS or DPMA. Sangoma documents that, once a configuration address is set by Endpoint Manager, supported phones can stop honoring Option 66; enabling the documented override can instead make Option 66 the only server checked. That precedence is model and configuration specific, not a universal DHCP rule.
For a server migration, prove the old server's last configuration, the DHCP or redirection value, DNS and certificate result, and the new server request. Do not enable a base-file parameter by number on an unverified model or remove the old service until the pilot fetches from the intended owner.
Correlate fetch, parse and apply
Use a short authorized server log or capture to show the phone's source address, requested path, response status and artifact timestamp. A 200 can still return an old or wrong-model file; no request points back to discovery, reachability or authentication. If the phone fetched the expected content but retained the old value, check supported syntax, local override, application timing and whether the setting needs a controlled restart.
DPMA, HTTP, HTTPS, TFTP and FTP leave different evidence. Do not open an additional protocol as a diagnostic shortcut, and remove temporary logging after the one-device trace.
Keep firmware and reset as late controlled branches
If only a firmware-dependent field is rejected, compare the exact installed build with vendor prerequisites and the Endpoint Manager slot. A selected or uploaded image is not proof that it is valid for the phone; Sangoma says custom firmware is not validated by Endpoint Manager. Pilot any change with stable power, checksum or signature evidence, backup and rollback.
Use a factory reset only after preserving local configuration, credentials, recovery access and the authoritative provisioning path. A reset can erase the evidence that identified a stale server and can strand a remote device. After the smallest correction, verify the chosen value, registration, inbound and outbound calling, media, emergency path and an unrelated phone.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma Endpoint Manager ↗
- Sangoma Endpoint Manager admin guide ↗
- Sangoma EPM and DPMA for D and P phones ↗
- Sangoma Endpoint Manager custom firmware ↗
- Sangoma Option 66 precedence after EPM provisioning ↗
- FreePBX Endpoint module password advisory ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.