چطور Cisco 7800 و 8800 MPP را با HTTPS به‌صورت خودکار تنظیم کنیم؟

اما Provisioning فقط زمانی واقعاً مفید است که امن طراحی شود. قرار دادن فایل XML حاوی SIP Password روی یک Web Server عمومی، فعال‌کردن Directory Listing یا استفاده دائمی از HTTP ساده می‌تواند اطلاعات حساس تلفن‌ها را در معرض دسترسی قرار دهد.

در این آموزش برای Cisco 7800 و 8800 با Multiplatform Firmware یک ساختار مرکزی مبتنی بر HTTPS می‌سازیم، Profile Rule را تنظیم می‌کنیم، برای هر تلفن فایل مخصوص MAC ایجاد می‌کنیم، Authentication را اضافه می‌کنیم و Retry Logic را طوری می‌چینیم که در صورت قطع سرور صدها تلفن هم‌زمان به آن هجوم نیاورند.

این آموزش برای Cisco MPP است، نه Enterprise Firmware

قبل از شروع مطمئن شوید تلفن از Multiplatform Firmware یا همان MPP/3PCC استفاده می‌کند.

مدل‌هایی مانند این‌ها نمونه روشن هستند:

CP-8841-3PCC
CP-8851-3PCC

اگر دستگاه Enterprise Firmware دارد و برای CUCM طراحی شده است، ساختار این مقاله را مستقیماً روی آن اعمال نکنید.

معماری امنی که می‌سازیم

سناریوی نهایی چنین است:

Cisco MPP
    |
    | HTTPS
    v
prov.example.com
    |
    +-- Authentication
    |
    +-- common.xml
    |
    +-- phones/
         |
         +-- 001122aabbcc.xml
         +-- aabbccddeeff.xml
         +-- 10f311223344.xml

فایل مشترک تنظیمات عمومی سازمان را نگه می‌دارد و فایل هر MAC فقط پارامترهای اختصاصی همان تلفن را شامل می‌شود.

چرا HTTPS برای Cisco Provisioning مهم است؟

فایل Provisioning ممکن است شامل اطلاعات بسیار حساسی باشد؛ برای مثال SIP Username، Password، Proxy، تنظیمات TLS یا دسترسی‌های مدیریتی.

در HTTP معمولی محتوا در مسیر شبکه رمزگذاری نمی‌شود. HTTPS ارتباط Phone و Provisioning Server را رمزگذاری می‌کند و به تلفن اجازه می‌دهد هویت Server را از طریق Certificate بررسی کند.

Cisco برای Secure HTTPS Resync علاوه بر HTTPS ساده، حالت Client Certificate Authentication و Client Filtering را نیز مستند کرده است.

HTTPS به‌تنهایی فایل را خصوصی نمی‌کند

فرض کنید این URL وجود دارد:

https://prov.example.com/phones/001122aabbcc.xml

اگر هر کسی که URL را می‌داند بتواند فایل را دانلود کند، ارتباط رمزگذاری شده است اما دسترسی به فایل محدود نشده است.

برای همین حداقل باید Authentication سمت Web Server نیز داشته باشیم.

مرحله اول: Provisioning Server را آماده کنید

برای نمونه از Ubuntu و Nginx استفاده می‌کنیم.

نصب Nginx:

sudo apt update
sudo apt install nginx apache2-utils -y

دایرکتوری Provisioning بسازید

sudo mkdir -p /var/www/cisco-provision/phones
sudo chown -R www-data:www-data /var/www/cisco-provision
sudo chmod -R 750 /var/www/cisco-provision

ساختار فایل‌ها را مرتب نگه دارید

/var/www/cisco-provision/
├── common.xml
└── phones/
    ├── 001122aabbcc.xml
    ├── 00aabbccddee.xml
    └── 10f311223344.xml

مرحله دوم: Certificate HTTPS را نصب کنید

Certificate باید توسط Firmware تلفن مورد اعتماد باشد و Hostname آن با FQDN Provisioning Server سازگار باشد.

فرض می‌کنیم Provisioning Server این نام را دارد:

prov.example.com

Certificate نیز باید همین نام یا SAN مناسب را داشته باشد.

در Cisco MPPهای قدیمی و جدید Trust Store و مسیرهای پشتیبانی Certificate می‌تواند متفاوت باشد؛ قبل از Rollout گسترده حتماً Certificate واقعی را روی همان مدل و Firmware آزمایش کنید.

Certificate Server را قبل از اتصال تلفن بررسی کنید

openssl s_client \
-connect prov.example.com:443 \
-servername prov.example.com \
-showcerts

Chain، تاریخ اعتبار و Hostname را بررسی کنید.

مرحله سوم: Basic Authentication بسازید

یک Username اختصاصی برای Provisioning ایجاد کنید:

sudo htpasswd -c /etc/nginx/cisco-provision.htpasswd cisco-prov

یک Password طولانی و اختصاصی وارد کنید.

Nginx را طوری تنظیم کنید که Directory Listing خاموش باشد

نمونه Virtual Host:

server {
    listen 443 ssl http2;
    server_name prov.example.com;

    ssl_certificate     /etc/ssl/prov/fullchain.pem;
    ssl_certificate_key /etc/ssl/prov/privkey.pem;

    root /var/www/cisco-provision;

    autoindex off;

    location / {
        auth_basic "Cisco Provisioning";
        auth_basic_user_file /etc/nginx/cisco-provision.htpasswd;

        try_files $uri =404;
    }
}

مسیر Certificateها را مطابق سرور واقعی خودتان تغییر دهید.

Configuration را بررسی کنید

sudo nginx -t
sudo systemctl reload nginx

مرحله چهارم: فایل مشترک Cisco بسازید

فایل:

/var/www/cisco-provision/common.xml

را ایجاد کنید.

نمونه:

<?xml version="1.0" encoding="UTF-8"?>
<device>
  <flat-profile>

    <Provision_Enable ua="na">Yes</Provision_Enable>
    <Resync_On_Reset ua="na">Yes</Resync_On_Reset>

    <Primary_NTP_Server ua="rw">ntp1.example.com</Primary_NTP_Server>
    <Secondary_NTP_Server ua="rw">ntp2.example.com</Secondary_NTP_Server>

    <Resync_Periodic ua="na">86400</Resync_Periodic>

  </flat-profile>
</device>

این فایل تنظیمات عمومی را نگه می‌دارد و اطلاعات SIP اختصاصی کاربر داخل آن قرار نمی‌گیرد.

مرحله پنجم: فایل مخصوص هر MAC ایجاد کنید

فرض کنید MAC تلفن:

00:11:22:AA:BB:CC

است.

Macro داخلی Cisco یعنی `$MA` آن را به MAC دوازده‌رقمی با حروف Hex کوچک تبدیل می‌کند:

001122aabbcc

بنابراین فایل را با همین نام بسازید:

/var/www/cisco-provision/phones/001122aabbcc.xml

نمونه فایل اختصاصی داخلی 201

<?xml version="1.0" encoding="UTF-8"?>
<device>
  <flat-profile>

    <Display_Name_1_ ua="na">Office 201</Display_Name_1_>
    <User_ID_1_ ua="na">201</User_ID_1_>
    <Auth_ID_1_ ua="na">201</Auth_ID_1_>
    <Password_1_ ua="na">REPLACE_WITH_SIP_SECRET</Password_1_>

    <Proxy_1_ ua="na">pbx.example.com</Proxy_1_>
    <Register_1_ ua="na">Yes</Register_1_>

  </flat-profile>
</device>

در Production فایل حاوی SIP Password را داخل Git عمومی، Backup بدون رمز یا مسیر قابل فهرست‌شدن Web Server قرار ندهید.

مرحله ششم: Profile Rule را طراحی کنید

Cisco MPP چهار Profile Rule دارد:

Profile_Rule
Profile_Rule_B
Profile_Rule_C
Profile_Rule_D

در هر Resync این Ruleها به‌ترتیب اجرا می‌شوند.

Profile Rule برای فایل مشترک

https://prov.example.com/common.xml

Profile Rule B برای فایل MAC

https://prov.example.com/phones/$MA.xml

برای تلفن با MAC بالا، این Rule به‌صورت خودکار تبدیل می‌شود به:

https://prov.example.com/phones/001122aabbcc.xml

چرا فایل مشترک و MAC را جدا می‌کنیم؟

فرض کنید NTP Server، Codec Policy یا تنظیم امنیتی تمام ۱۰۰ تلفن تغییر کرده است.

اگر همه چیز داخل فایل اختصاصی هر دستگاه باشد باید ۱۰۰ فایل را تغییر دهید.

با ساختار دو لایه، فقط:

common.xml

را اصلاح می‌کنید.

اما ترتیب Profile Rule مهم است

Cisco Ruleها را به‌ترتیب اجرا می‌کند.

اگر یکی از Ruleها Fail شود، Resync Sequence متوقف می‌شود و طبق Resync Error Retry Delay از ابتدا دوباره تلاش خواهد شد.

پس یک فایل غیرضروری خراب در Profile_Rule_B می‌تواند مانع اجرای Profile_Rule_C نیز شود.

مرحله هفتم: Authentication را داخل Profile Rule فعال کنید

Cisco در Profile Rule از:

--uid
--pwd

برای پاسخ به HTTP Basic یا Digest Authentication پشتیبانی می‌کند.

نمونه مستقیم

[--uid cisco-prov --pwd REPLACE_WITH_LONG_PASSWORD] https://prov.example.com/phones/$MA.xml

اما قرار دادن Password خام در چند جای Configuration مدیریت Secret را سخت‌تر می‌کند.

روش بهتر: GPP برای Credential

Cisco پارامترهای عمومی GPP را برای Macro Expansion ارائه می‌کند.

مثلاً:

GPP_SA = cisco-prov
GPP_SB = REPLACE_WITH_LONG_PASSWORD

و Profile Rule:

[--uid $SA --pwd $SB] https://prov.example.com/phones/$MA.xml

Profile Rule کامل دو لایه

برای مثال:

Profile_Rule:
[--uid $SA --pwd $SB] https://prov.example.com/common.xml

Profile_Rule_B:
[--uid $SA --pwd $SB] https://prov.example.com/phones/$MA.xml

Profile Authentication Type در Firmwareهای جدید

Cisco MPPهای فعلی گزینه‌ای به نام Profile Authentication Type نیز دارند.

یکی از گزینه‌ها:

Basic HTTP Authentication

است.

اگر Credential داخل Profile Rule وجود داشته باشد، Cisco آن را نسبت به Profile Account دارای اولویت بالاتر در نظر می‌گیرد.

مرحله هشتم: Resync On Reset را فعال کنید

در:

Admin Login → advanced → Voice → Provisioning

بررسی کنید:

Provision Enable = Yes
Resync On Reset = Yes

نمونه XML

<Provision_Enable ua="na">Yes</Provision_Enable>
<Resync_On_Reset ua="na">Yes</Resync_On_Reset>

چرا Random Delay ضروری است؟

فرض کنید برق یک ساختمان قطع شده و ۳۰۰ Cisco هم‌زمان روشن می‌شوند.

اگر همه بلافاصله این URL را درخواست کنند:

https://prov.example.com/...

بار ناگهانی روی Nginx، Authentication Backend و Storage ایجاد می‌شود.

Resync Random Delay درخواست‌ها را در یک بازه پخش می‌کند.

مرحله نهم: Resync Periodic را منطقی انتخاب کنید

برای Production لازم نیست Phone هر ۳۰ ثانیه Configuration را دانلود کند.

مستند فعلی Cisco مقدار پیشنهادی 86400 ثانیه را نیز برای Resync Periodic ذکر می‌کند.

یعنی:

Resync Periodic = 86400

معادل یک بار در روز است.

برای تست موقت می‌توانید زمان را کوتاه کنید، اما بعد از پایان تست مقدار Production را برگردانید.

مرحله دهم: Retry Logic را حرفه‌ای تنظیم کنید

اگر Provisioning Server از دسترس خارج شود، نباید صدها Phone هر چند ثانیه یک بار Retry کنند.

نسخه‌های فعلی MPP از یک لیست زمان‌های Retry پشتیبانی می‌کنند.

نمونه‌ای که در مستند فعلی Cisco برای مقدار پیش‌فرض دیده می‌شود:

60,120,240,480,960,1920,3840,7680,15360,30720,61440,86400

یعنی Retryها به‌تدریج فاصله بیشتری می‌گیرند.

نمونه XML Retry

<Resync_Error_Retry_Delay ua="na">60,120,240,480,960,1920,3840,7680,15360,30720,61440,86400</Resync_Error_Retry_Delay>

چرا Backoff بهتر از Retry ثابت است؟

اگر Server ۲۰ دقیقه Down باشد و ۵۰۰ Phone داشته باشید، Retry هر ۳۰ ثانیه هزاران Request بی‌فایده تولید می‌کند.

Backoff باعث می‌شود در ابتدا بازیابی سریع باشد اما اگر خرابی ادامه پیدا کرد، فشار روی Server کاهش یابد.

Retry را روی صفر نگذارید مگر عمداً

طبق مستند فعلی Cisco اگر:

Resync Error Retry Delay = 0

باشد، Phone بعد از Resync ناموفق Retry خودکار انجام نمی‌دهد.

Resync در زمان تماس چه می‌شود؟

Cisco معمولاً Resync را تا زمانی که Lineها Idle شوند عقب می‌اندازد تا مکالمه کاربر مختل نشود.

پارامتر:

Forced Resync Delay

حداکثر زمانی را مشخص می‌کند که Device برای انجام Resync منتظر می‌ماند.

در مستند فعلی مقدار پیش‌فرض:

14400 seconds

ذکر شده است.

Resync From SIP چیست؟

MPP می‌تواند با SIP NOTIFY نیز درخواست Resync دریافت کند.

اگر:

Resync From SIP = Yes

باشد، Proxy می‌تواند با Event مربوط به Resync تلفن را مجبور به Sync کند.

این روش برای Push کردن تغییر فوری مفید است، اما Proxy و مسیر SIP باید مورد اعتماد باشند.

Resync بعد از Firmware Upgrade

گزینه:

Resync After Upgrade Attempt = Yes

باعث می‌شود بعد از تلاش Firmware Upgrade، Configuration دوباره Sync شود.

این رفتار برای بازگرداندن Policyها بعد از ارتقا مفید است.

مرحله یازدهم: فایل 404 را Fail در نظر بگیرید

اگر فایل مخصوص MAC وجود نداشته باشد، Web Server پاسخ:

HTTP 404 Not Found

می‌دهد.

برای معماری‌ای که هر Phone باید حتماً فایل مخصوص خودش را داشته باشد، بهتر است 404 یک Resync Failure واقعی محسوب شود.

در Cisco گزینه:

Resync Fails On FNF = Yes

برای همین رفتار وجود دارد.

مرحله دوازدهم: Authentication را قبل از اتصال Cisco تست کنید

با curl:

curl -u cisco-prov:'YOUR_PASSWORD' \
https://prov.example.com/common.xml

سپس فایل MAC:

curl -u cisco-prov:'YOUR_PASSWORD' \
https://prov.example.com/phones/001122aabbcc.xml

بدون Username باید 401 بگیرید

curl -I https://prov.example.com/common.xml

رفتار مطلوب:

HTTP/1.1 401 Unauthorized

مرحله سیزدهم: یک تلفن Pilot انتخاب کنید

قبل از اعمال Rule روی تمام سازمان، فقط یک تلفن آزمایشی را انتخاب کنید.

روی آن:

Admin Login → advanced → Voice → Provisioning

را باز کنید.

Profile Ruleها و Authentication را وارد کنید و Submit All Changes را بزنید.

اولین Rollout را روی همه Phoneها انجام ندهید

Provisioning اشتباه می‌تواند صدها تلفن را هم‌زمان با Configuration خراب مواجه کند.

ترتیب مناسب Rollout:

بعد از Resync چه چیزی را تست کنیم؟

فقط Registered شدن کافی نیست.

Logهای Nginx را حتماً ببینید

Access Log:

sudo tail -f /var/log/nginx/access.log

Error Log:

sudo tail -f /var/log/nginx/error.log

HTTP Status Code خیلی سریع محل مشکل را مشخص می‌کند

اگر هیچ Requestی در Nginx نمی‌بینید

در این حالت مشکل هنوز قبل از Web Server است.

بررسی کنید:

Profile Rule واقعاً ذخیره شده، DNS صحیح است، TCP/443 باز است، Certificate Handshake آغاز می‌شود و Provision Enable فعال است.

Packet Capture برای HTTPS Provisioning

در Wireshark ابتدا IP Phone را فیلتر کنید:

ip.addr == 192.168.20.45

و سپس TLS:

tls

در HTTPS نباید XML و Passwordهای فایل Provisioning به‌صورت Plain Text روی Wire دیده شوند.

Advanced Security: Client Certificate Authentication

Cisco برای Provisioning پیشرفته امکان HTTPS با Client Certificate Authentication را نیز مستند می‌کند.

در این طراحی Server فقط HTTPS Connection را نمی‌پذیرد؛ بلکه Certificate خود Phone را نیز بررسی می‌کند.

این مدل برای Providerها و استقرارهای بزرگ امنیت بسیار بالاتری ایجاد می‌کند.

اما Root CA و Client Certificate Model در نسل‌ها و Firmwareهای مختلف Cisco باید دقیقاً با مستند همان Device پیاده‌سازی شود. mTLS را با یک CA تصادفی روی Nginx فعال نکنید و انتظار نداشته باشید همه Ciscoهای MPP خودکار با آن کار کنند.

Basic Auth یا Client Certificate؟

Cisco از فایل Provisioning رمزگذاری‌شده هم پشتیبانی می‌کند

در Provisioning فعلی Cisco، فایل‌ها می‌توانند علاوه بر HTTPS به‌صورت رمزگذاری‌شده نیز تحویل داده شوند.

برای AES-256-CBC از Argument زیر در Profile Rule استفاده می‌شود:

[--key YOUR_ENCRYPTION_KEY]

Cisco همچنین در مستند فعلی RFC 8188 با AES-128-GCM را برای برخی روش‌های Encryption مستند کرده است.

اما مدیریت Encryption Key خودش باید امن باشد؛ قرار دادن Key در فایل عمومی مزیت Encryption را از بین می‌برد.

Rollback را از ابتدا طراحی کنید

قبل از تغییر یک Parameter حساس، نسخه قبلی فایل را نگه دارید.

مثلاً:

common.xml
common.xml.prev

یا Configها را در یک Git Repository خصوصی نگه دارید؛ البته Secretهای واقعی SIP را بهتر است خارج از Repository یا با Secret Management مناسب مدیریت کنید.

قبل از انتشار Config جدید Syntax را کنترل کنید

برای XML:

xmllint --noout common.xml

و برای فایل اختصاصی:

xmllint --noout phones/001122aabbcc.xml

اشتباه رایج: فایل MAC را با Colon نام‌گذاری می‌کنیم

`$MA` در Cisco به MAC دوازده‌رقمی با Hex کوچک تبدیل می‌شود.

در نتیجه این:

00:11:22:AA:BB:CC.xml

با این:

001122aabbcc.xml

یکسان نیست.

اشتباه رایج: همه Secretها را داخل common.xml قرار می‌دهیم

فایل مشترک نباید Password تمام Extensionها را در خود نگه دارد.

اطلاعات اختصاصی هر Device را در فایل MAC همان Device نگه دارید.

اشتباه رایج: Directory Listing روشن است

اگر بازکردن این آدرس:

https://prov.example.com/phones/

فهرست MACها را نمایش می‌دهد، Web Server را اصلاح کنید.

اشتباه رایج: Retry هر چند ثانیه یک بار

در محیط Lab قابل قبول است، اما در Production با صدها Device می‌تواند Provisioning Server را هنگام خرابی به‌شدت تحت فشار قرار دهد.

از Backoff استفاده کنید.

اشتباه رایج: تغییر مستقیم ۲۰۰ تلفن

هر تغییر ابتدا باید روی Pilot اجرا شود.

Config اشتباه Proxy یا Password می‌تواند همه Deviceها را هم‌زمان از سرویس خارج کند.

اشتباه رایج: HTTPS را داریم، پس همه چیز امن است

HTTPS محتوای انتقال را رمزگذاری می‌کند؛ اما Server باید Access Control نیز داشته باشد.

Authentication، محدودکردن Directory، کنترل Permission، Log Monitoring و در استقرارهای پیشرفته Client Certificate Authentication را نیز در نظر بگیرید.

اشتباه رایج: Certificate را فقط در مرورگر تست می‌کنیم

Trust Store مرورگر و Cisco یکسان نیست.

همیشه یک Phone واقعی با Firmware هدف را قبل از Rollout گسترده تست کنید.

چک‌لیست نهایی Cisco MPP Provisioning

پرسش‌های متداول درباره Cisco MPP Provisioning

Auto Provisioning در Cisco MPP چیست؟

روشی است که تلفن به‌صورت خودکار Configuration را از یک Server مرکزی دریافت می‌کند تا تنظیمات Deviceها بدون ورود دستی روی هر تلفن مدیریت شوند.

Profile Rule در Cisco چه کاری انجام می‌دهد؟

Profile Rule آدرس منبع Configuration را مشخص می‌کند. Cisco می‌تواند Profile_Rule تا Profile_Rule_D را در هر Resync به‌ترتیب اجرا کند.

$MA در Cisco Provisioning چیست؟

$MA به MAC Address دوازده‌رقمی تلفن با حروف Hex کوچک تبدیل می‌شود و برای ساخت URL اختصاصی هر Device بسیار مناسب است.

آیا Cisco 7800 و 8800 را می‌توان با HTTPS Provision کرد؟

بله، مدل‌های MPP از HTTPS Provisioning پشتیبانی می‌کنند و Cisco برای Secure HTTPS Resync و Client Certificate Authentication نیز روش رسمی مستند کرده است.

چطور روی Provisioning Server رمز بگذاریم؟

می‌توان HTTP Basic یا Digest Authentication را فعال کرد و در Profile Rule از گزینه‌های –uid و –pwd استفاده کرد.

آیا Basic Authentication بدون HTTPS امن است؟

خیر. Credential نباید روی HTTP ساده منتقل شود. Authentication را همراه HTTPS استفاده کنید.

Resync Periodic چه کاری می‌کند؟

فاصله زمانی دریافت دوباره Configuration از Server را تعیین می‌کند. برای Production مقدار بسیار کوتاه معمولاً لازم نیست.

Resync Error Retry Delay چیست؟

زمان یا توالی زمان‌هایی است که Cisco بعد از Provisioning ناموفق برای Retry استفاده می‌کند. در Firmwareهای فعلی می‌توان Backoff چندمرحله‌ای تعریف کرد.

اگر Resync Error Retry Delay صفر باشد چه می‌شود؟

طبق مستند فعلی Cisco، Device بعد از Resync ناموفق Retry خودکار انجام نمی‌دهد.

چرا فایل MAC من 404 می‌شود؟

نام فایل را با خروجی واقعی $MA مقایسه کنید. MAC باید بدون Colon و به‌صورت دوازده رقم Hex کوچک باشد.

آیا می‌توان Configuration مشترک و اختصاصی را جدا کرد؟

بله. یکی از بهترین طراحی‌ها استفاده از Profile_Rule برای فایل مشترک و Profile_Rule_B برای فایل مخصوص MAC است.

آیا HTTPS به‌تنهایی Provisioning را کاملاً امن می‌کند؟

خیر. HTTPS ارتباط را رمزگذاری می‌کند اما Authentication، Permission، عدم نمایش Directory و در محیط‌های حساس Client Certificate Authentication نیز مهم هستند.

چرا نباید همه تلفن‌ها را هم‌زمان Provision کنیم؟

یک Configuration اشتباه می‌تواند تعداد زیادی تلفن را هم‌زمان از سرویس خارج کند. بهتر است ابتدا Lab و Pilot انجام شود و سپس Rollout مرحله‌ای صورت گیرد.

جمع‌بندی

برای مدیریت چند Cisco 7800 یا 8800 MPP، Auto Provisioning بسیار قابل‌اعتمادتر از تنظیم دستی تک‌تک تلفن‌هاست؛ اما Server باید از ابتدا با امنیت و Rollback طراحی شود.

ساختار مناسب این است که تنظیمات عمومی را داخل یک Profile مشترک نگه دارید و اطلاعات اختصاصی هر Device را با `$MA` از فایل مخصوص همان MAC دریافت کنید. Cisco چهار Profile Rule را به‌ترتیب اجرا می‌کند و می‌توان تنظیمات را به چند لایه تقسیم کرد.

برای انتقال Profile از HTTPS استفاده کنید، Certificate را روی Firmware هدف تست کنید و Authentication را روی Web Server فعال نگه دارید. Cisco برای Profile Rule از `–uid` و `–pwd` پشتیبانی می‌کند و Credentialها می‌توانند با GPP Macroها مدیریت شوند.

Retry Logic نیز بخش مهم طراحی است. اگر Server از دسترس خارج شود، Backoff چندمرحله‌ای مانع می‌شود صدها Phone به‌صورت هم‌زمان Provisioning Server را زیر بار Request قرار دهند. Resync Random Delay و Periodic Resync نیز باید با اندازه Deployment هماهنگ شوند.

در نهایت هر تغییر را ابتدا روی یک Pilot اجرا کنید. Nginx Access Log، Syslog تلفن، HTTP Status Code و Packet Capture دقیقاً نشان می‌دهند مشکل در DNS، TLS، Authentication، فایل MAC یا خود XML قرار دارد.