Heads up for anyone running self-hosted 3CX on Azure with Azure Site Recovery (A2A) configured for disaster recovery:
After a 3CX update in May 2026 that bumped the underlying Debian 12 kernel to 6.1.0-44-amd64, our Azure Site Recovery replication silently went to "Critical" with:
Error ID 153013: "Replication is blocked as the data change tracking module of the mobility service is not loaded on the VM."
Root cause: Microsoft's ASR Mobility Service ships a kernel driver that must exactly match the running kernel build. Checking Microsoft's own kernel certification tracker (github.com/Azure/Azure-SiteRecovery), Debian 12 kernels 6.1.0-40/41/42/43 and 6.1.0-47/48/49 are certified - but 6.1.0-44/45/46 are not, even in the most recent builds. Our VM landed exactly in that gap.
This isn't obvious from the portal - "Agent status" shows "Healthy" the whole time (that only reflects the extension process, not the actual driver-load state). In our case it went unnoticed for ~70 days before we caught it via RPO/replication health.
If you run 3CX on Azure with ASR for DR: after any 3CX/Debian update, actively check Recovery Services Vault > Replicated Items > RPO and Errors panel - don't rely on "Agent status: Healthy" alone.
Curious if anyone else has hit this.
After a 3CX update in May 2026 that bumped the underlying Debian 12 kernel to 6.1.0-44-amd64, our Azure Site Recovery replication silently went to "Critical" with:
Error ID 153013: "Replication is blocked as the data change tracking module of the mobility service is not loaded on the VM."
Root cause: Microsoft's ASR Mobility Service ships a kernel driver that must exactly match the running kernel build. Checking Microsoft's own kernel certification tracker (github.com/Azure/Azure-SiteRecovery), Debian 12 kernels 6.1.0-40/41/42/43 and 6.1.0-47/48/49 are certified - but 6.1.0-44/45/46 are not, even in the most recent builds. Our VM landed exactly in that gap.
This isn't obvious from the portal - "Agent status" shows "Healthy" the whole time (that only reflects the extension process, not the actual driver-load state). In our case it went unnoticed for ~70 days before we caught it via RPO/replication health.
If you run 3CX on Azure with ASR for DR: after any 3CX/Debian update, actively check Recovery Services Vault > Replicated Items > RPO and Errors panel - don't rely on "Agent status: Healthy" alone.
Curious if anyone else has hit this.
