Amir Jabbari
در این راهنما مسیر Resync را از خود Cisco MPP تا DNS، TCP/TLS، HTTP Status Code، نام فایل و Parsing پروفایل دنبال می‌کنیم. هدف این است که قبل از Factory Reset یا تغییر تصادفی تنظیمات، دقیقاً مشخص شود دانلود در کدام مرحله متوقف شده است.
اول بدانیم Resync در Cisco MPP چه مراحلی دارد
یک Resync موفق را می‌توان به این زنجیره ساده کرد:
Resync Trigger
↓
Provision Enable
↓
Profile Rule evaluation
↓
DNS lookup
↓
TCP / TLS
↓
HTTP GET
↓
HTTP response
↓
Profile download
↓
XML / config parsing
↓
Apply parameters
↓
Successful Resyncهرجا این زنجیره متوقف شود، روش عیب‌یابی متفاوت خواهد بود.
درخت تصمیم سریع برای Cisco Resync Failed
| نشانه | اولین بررسی |
|---|---|
| با زدن Resync هیچ اتفاقی نمی‌افتد | Provision Enable و Triggerها |
| هیچ Requestی به Web Server نمی‌رسد | Profile Rule، DNS، TCP و TLS |
| HTTP 401 | Authentication |
| HTTP 403 | ACL، Permission یا Policy سرور |
| HTTP 404 | Filename، MAC Macro یا Path |
| 301/302 | Location جدید و دسترسی مقصد |
| 200 دریافت می‌شود ولی تنظیمات عوض نمی‌شوند | XML، Parsing، Profile Rule بعدی یا پارامتر اشتباه |
| بعد از خطا دوباره تلاش نمی‌کند | Resync Error Retry Delay |
| فقط هنگام تماس Resync نمی‌شود | Forced Resync Delay و Line State |
مرحله اول: Provision Enable را بررسی کنید
در رابط وب Cisco MPP وارد:
Admin Login → advanced → Voice → Provisioning
شوید و مطمئن شوید:
Provision Enable = Yesاین گزینه کنترل اصلی تمام عملیات Resync است و در مستند فعلی Cisco مقدار پیش‌فرض آن Yes است.
اگر روی No باشد، تغییر Profile Rule یا Resync Periodic کمکی نمی‌کند.
Resync On Reset را هم بررسی کنید
اگر انتظار دارید تلفن بعد از Boot فایل را دانلود کند:
Resync On Reset = Yesباشد.
مقدار پیش‌فرض فعلی Cisco نیز Yes است.
نمونه XML این دو پارامتر
<Provision_Enable ua="na">Yes</Provision_Enable>
<Resync_On_Reset ua="na">Yes</Resync_On_Reset>مرحله دوم: Profile Rule واقعی را بخوانید
Cisco MPP می‌تواند چهار Profile Rule داشته باشد:
Profile_Rule
Profile_Rule_B
Profile_Rule_C
Profile_Rule_Dدر هر Resync این Ruleها به‌ترتیب پردازش می‌شوند.
اگر Profile_Rule موفق شود اما Profile_Rule_B با خطا مواجه شود، زنجیره در همان نقطه متوقف می‌شود و Profile_Rule_C و D اجرا نمی‌شوند.
این نکته در عیب‌یابی بسیار مهم است
فرض کنید:
Profile_Rule → common.xml → 200 OK
Profile_Rule_B → 001122aabbcc.xml → 404
Profile_Rule_C → security.xml → never reachedدر این سناریو دیدن 200 برای فایل اول به معنی موفق‌بودن کل Resync نیست.
Profile Rule ساده باید چه شکلی باشد؟
https://prov.example.com/phones/$MA.xmlاگر Protocol را ننویسید، رفتار Provisioning می‌تواند بر اساس تنظیمات دیگر یا TFTP تفسیر شود. برای عیب‌یابی بهتر است URL را صریح و کامل بنویسید.
مرحله سوم: بدانید $MA دقیقاً به چه چیزی تبدیل می‌شود
یکی از رایج‌ترین علت‌های 404، نام اشتباه فایل MAC است.
فرض کنید MAC تلفن:
00:11:22:AA:BB:CCباشد.
Macro داخلی `$MA` به این مقدار تبدیل می‌شود:
001122aabbccیعنی دوازده رقم Hex، بدون Colon و با حروف کوچک.
این فایل‌ها یکسان نیستند
00:11:22:AA:BB:CC.xml
001122AABBCC.xml
001122aabbcc.xmlروی Linux نام فایل‌ها Case Sensitive است. اگر Profile Rule از `$MA.xml` استفاده می‌کند، نام سوم مطمئن‌ترین انتخاب مطابق Macro مستند Cisco است.
نام فایل واقعی را روی سرور کنترل کنید
ls -lah /var/www/cisco-provision/phones/URL نهایی را خودتان بازسازی کنید
اگر Profile Rule این است:
https://prov.example.com/phones/$MA.xmlبرای MAC بالا باید URL واقعی این باشد:
https://prov.example.com/phones/001122aabbcc.xmlمرحله چهارم: همان URL را خارج از تلفن تست کنید
روی Linux:
curl -I https://prov.example.com/phones/001122aabbcc.xmlاگر Authentication دارید:
curl -u cisco-prov:'YOUR_PASSWORD' \
-I https://prov.example.com/phones/001122aabbcc.xmlاما تست curl یک تفاوت مهم دارد
اگر curl فایل را دانلود می‌کند ولی Cisco نمی‌تواند، هنوز چند احتمال باقی است:
تلفن DNS دیگری دارد، Certificate برای Cisco معتبر نیست، TLS Version یا Cipher متفاوت است، VLAN تلفن ACL متفاوت دارد یا Authentication Profile روی Phone صحیح نیست.
پس موفق‌بودن curl فقط Server Side را تا حدی تأیید می‌کند.
مرحله پنجم: HTTP Status Code را جدی بگیرید
Cisco برای Provisioning رفتار مشخصی در برابر پاسخ HTTP دارد.
| کد | معنی | اقدام |
|---|---|---|
| 200 | فایل دریافت شده | Parsing و Apply را بررسی کنید |
| 301 | انتقال دائمی | Location جدید فوراً دنبال می‌شود |
| 302 | انتقال موقت | Location جدید فوراً دنبال می‌شود |
| سایر 3xx | Redirect متفاوت | مثل 301/302 فرض نکنید |
| 400 | درخواست نامعتبر | URL و Web Server |
| 401 | Authentication لازم است | Credential را بررسی کنید |
| 403 | Access Denied | ACL، Permission یا WAF |
| 404 | File Not Found | Filename، Path و FNF |
| 5xx | خطای Server | Nginx/Apache/Backend |
301 و 302 در Cisco MPP پشتیبانی می‌شوند
در مستند فعلی Cisco، هنگام دریافت:
HTTP/1.1 301 Moved Permanentlyیا:
HTTP/1.1 302 FoundPhone Location جدید را بلافاصله Retry می‌کند.
اما Redirect را بی‌دلیل پیچیده نکنید
اگر Provisioning URL چنین مسیری دارد:
http://prov.example.com/device.xml
↓ 301
https://prov.example.com/device.xml
↓ 302
https://cdn.example.net/device.xmlشما DNS، Certificate و Authentication سه مسیر مختلف را وارد مسئله کرده‌اید.
برای عیب‌یابی، ابتدا URL نهایی HTTPS را مستقیماً داخل Profile Rule تست کنید.
Redirect را با curl ببینید
curl -IL https://prov.example.com/phones/001122aabbcc.xmlمرحله ششم: Resync Fails On FNF را درست درک کنید
FNF یعنی File Not Found.
پارامتر Cisco:
Resync Fails On FNF = Yesبه‌طور پیش‌فرض فعال است.
یعنی اگر Profile موردنظر دریافت نشود و Server پاسخ File Not Found بدهد، Resync ناموفق تلقی می‌شود و Error Retry Logic فعال می‌شود.
اگر Resync Fails On FNF = No باشد چه؟
Phone می‌تواند File Not Found را به‌عنوان Resync موفق بپذیرد.
این رفتار فقط در معماری‌هایی منطقی است که نبودن یک Profile واقعاً مجاز باشد.
برای فایل اختصاصی MAC که باید همیشه وجود داشته باشد بهتر است 404 را پنهان نکنید.
نمونه XML
<Resync_Fails_On_FNF ua="na">Yes</Resync_Fails_On_FNF>مرحله هفتم: HTTP 401 را از TLS Failure جدا کنید
اگر Web Server پاسخ:
HTTP/1.1 401 Unauthorizedمی‌دهد، TCP و TLS عملاً تا مرحله HTTP جلو رفته‌اند.
در اینجا Certificate مشکل اصلی نیست؛ Authentication را بررسی کنید.
Credential داخل Profile Rule
نمونه:
[--uid cisco-prov --pwd YOUR_PASSWORD] https://prov.example.com/phones/$MA.xmlCisco برای Profile Rule از Basic و Digest Authentication پشتیبانی می‌کند.
Credential داخل Profile Rule نسبت به Profile Account اولویت بالاتری دارد؛ بنابراین اگر Username یا Password اشتباه داخل Rule نوشته شده باشد، واردکردن Credential صحیح در Profile Account مشکل را برطرف نمی‌کند.
مرحله هشتم: TLS را فقط وقتی بررسی کنید که HTTPS قبل از HTTP می‌شکند
اگر در Nginx هیچ Requestی نمی‌بینید و URL شما HTTPS است، احتمالاً درخواست هنوز به HTTP نرسیده است.
ابتدا Certificate را ببینید:
openssl s_client \
-connect prov.example.com:443 \
-servername prov.example.com \
-showcertsبرای HTTPS Provisioning این موارد مهم‌اند
| بررسی | نتیجه مطلوب |
|---|---|
| DNS | FQDN به IP صحیح Resolve شود |
| TCP/443 | قابل دسترس باشد |
| Certificate | معتبر و قابل اعتماد |
| SAN/CN | با FQDN سازگار |
| CA Chain | کامل |
| NTP | ساعت Phone صحیح |
| TLS Version | Phone و Server مشترک داشته باشند |
اگر Domain Resolve نمی‌شود ابتدا DNS را حل کنید
در محیط‌هایی که Cisco روی Voice VLAN قرار دارد، DNS تلفن ممکن است با DNS لپ‌تاپ متفاوت باشد.
اگر در این بخش مشکل دارید، راهنمای عیب‌یابی DNS و systemd-resolved در لینوکس نیز برای بررسی Resolver سمت Server مفید است.
مرحله نهم: Resync Random Delay را با خرابی اشتباه نگیرید
بعد از Boot ممکن است Phone فوراً Request ارسال نکند.
پارامتر:
Resync Random Delayبرای پخش‌کردن Requestها میان تعداد زیادی Phone طراحی شده است.
مقدار پیش‌فرض فعلی Cisco برابر ۲ ثانیه است.
Resync At نیز می‌تواند رفتار Periodic را تغییر دهد
اگر مقدار معتبری برای:
Resync At (HHmm)وارد شده باشد، Cisco مستند کرده است که Resync Periodic نادیده گرفته می‌شود.
پس اگر انتظار دارید هر یک ساعت فایل دانلود شود اما Resync At تنظیم شده، Timer متفاوتی دارید.
مرحله دهم: Resync Error Retry Delay را بررسی کنید
این پارامتر مشخص می‌کند بعد از Resync ناموفق Phone چه زمانی دوباره تلاش کند.
مثال ساده:
Resync Error Retry Delay = 300یعنی بعد از Fail، پنج دقیقه صبر کند.
در Firmwareهای فعلی می‌توانید چند Retry تعریف کنید
مثلاً:
600,1200,300یعنی Retry اول بعد از ۶۰۰ ثانیه، Retry دوم ۱۲۰۰ ثانیه بعد و Retry سوم بعد از ۳۰۰ ثانیه.
بازه تصادفی Retry نیز پشتیبانی می‌شود
2400+30یعنی Retry در بازه ۲۴۰۰ تا ۲۴۳۰ ثانیه انجام شود.
نکته مهم: مقدار صفر یعنی Retry خودکار انجام نشود
در مستند فعلی Cisco:
Resync Error Retry Delay = 0به این معنی است که بعد از Resync ناموفق، Retry خودکار انجام نمی‌شود.
مرحله یازدهم: Active Call می‌تواند Resync را عقب بیندازد
Cisco برای جلوگیری از مختل‌شدن تماس فعال، Resync را هنگام Busy بودن Line عقب می‌اندازد.
پارامتر:
Forced Resync Delayحداکثر Delay را کنترل می‌کند.
مقدار پیش‌فرض فعلی:
14400 secondsاست.
پس اگر روی تلفن پرتماس تست می‌کنید، Delay را با Fail اشتباه نگیرید.
مرحله دوازدهم: 200 OK الزاماً به معنی اعمال موفق Config نیست
گاهی Nginx چنین چیزی ثبت می‌کند:
GET /phones/001122aabbcc.xml HTTP/1.1" 200اما Phone تغییر نمی‌کند.
در این حالت Download انجام شده و باید مرحله Parsing را بررسی کنید.
XML خراب را قبل از انتشار پیدا کنید
روی Server:
xmllint --noout /var/www/cisco-provision/phones/001122aabbcc.xmlاگر هیچ خروجی برنگردد و Exit Code صفر باشد، ساختار XML از نظر Syntax معتبر است.
اما XML معتبر هم می‌تواند پارامتر اشتباه داشته باشد
مثلاً Tag اشتباه یا مربوط به Firmware دیگری ممکن است نادیده گرفته شود.
Config را با XML Reference همان Firmware مقایسه کنید.
Profile Rule بعدی می‌تواند مقدار قبلی را Override کند
مثلاً:
common.xml
Proxy_1 = pbx-old.example.com
device.xml
Proxy_1 = pbx-new.example.comاگر device.xml بعد از common.xml اجرا شود، مقدار دوم می‌تواند مقدار اول را جایگزین کند.
پس فقط به اولین فایل دانلودشده نگاه نکنید.
مرحله سیزدهم: Log Request، Success و Failure را فعالانه استفاده کنید
Cisco برای Resync پیام‌های داخلی Syslog دارد.
نمونه مفهومی:
Requesting https://prov.example.com/phones/001122aabbcc.xml
Successful Resync https://prov.example.com/phones/001122aabbcc.xml
Resync failed: ...این Logها بسیار مهم‌اند چون Phone URL نهایی بعد از Macro Expansion را نشان می‌دهد.
Nginx Access Log را هم‌زمان باز کنید
sudo tail -f /var/log/nginx/access.logError Log:
sudo tail -f /var/log/nginx/error.logسه حالت Log خیلی سریع تکلیف را روشن می‌کنند
| Phone | Nginx | برداشت |
|---|---|---|
| Resync شروع می‌شود | هیچ Requestی نیست | DNS/TCP/TLS/URL |
| Resync Failed | 404 | Filename یا Path |
| Resync Failed | 401 | Authentication |
| Resync Failed | 200 | Profile Parsing یا Rule بعدی |
| Successful Resync | 200 | انتقال و Parsing احتمالاً سالم |
مرحله چهاردهم: Packet Capture را فقط وقتی Log کافی نیست بگیرید
برای تلفن با IP نمونه:
ip.addr == 192.168.20.45برای HTTP ساده
httpبرای HTTPS
tlsبرای DNS
dnsالگوی سالم HTTPS Provisioning
DNS Query
DNS Response
TCP SYN
SYN, ACK
ACK
TLS ClientHello
TLS ServerHello
Certificate
TLS Finished
HTTP GET
401 Unauthorized
HTTP GET + Authorization
200 OK
Profile downloaded
Successful Resyncسناریوی ۱: Resync را می‌زنید ولی Nginx هیچ Requestی نمی‌بیند
به‌ترتیب بررسی کنید:
Provision Enable، Profile Rule، DNS، TCP Port، TLS Handshake و Firewall.
در این مرحله Filename روی Web Server هنوز مظنون اول نیست، چون Request حتی به Server نرسیده است.
سناریوی ۲: Nginx دائماً 404 ثبت می‌کند
URL واقعی Request را از Log کپی کنید.
مثلاً:
GET /phones/0023abcd1234.xml HTTP/1.1" 404بعد دقیقاً همان Path را روی Filesystem مقایسه کنید.
سناریوی ۳: فایل در سرور هست ولی 404 می‌گیرید
ممکن است Nginx Root اشتباه باشد.
مثلاً فایل اینجاست:
/var/www/cisco-provision/phones/001122aabbcc.xmlاما Nginx Root این است:
root /var/www/html;در این حالت Filename صحیح است ولی Virtual Host به مسیر دیگری نگاه می‌کند.
سناریوی ۴: 403 Forbidden می‌گیرید
Permission فایل‌ها را بررسی کنید:
namei -l /var/www/cisco-provision/phones/001122aabbcc.xmlهمچنین IP ACL، WAF، Basic Auth و Location Rule را بررسی کنید.
سناریوی ۵: 401 پشت سر هم می‌بینید
Username و Password را در Profile Rule، Profile Account و Web Server مقایسه کنید.
به یاد داشته باشید Credential داخل Profile Rule اولویت دارد.
سناریوی ۶: 301 یا 302 می‌بینید ولی فایل دانلود نمی‌شود
Location Header را استخراج کنید:
curl -I https://prov.example.com/device.xmlبعد مقصد Redirect را مستقلاً تست کنید.
ممکن است مقصد دوم DNS متفاوت، Certificate متفاوت یا Authentication دیگری داشته باشد.
سناریوی ۷: فایل 200 می‌شود ولی Resync Failed است
XML را Validate کنید، Encoding فایل را بررسی کنید و Syslog Phone را ببینید.
همچنین Profile_Rule_B/C/D را فراموش نکنید؛ ممکن است فایل اول 200 باشد ولی فایل بعدی Fail شود.
سناریوی ۸: Resync Successful است ولی مقدار جدید دیده نمی‌شود
سه احتمال مهم:
پارامتر XML اشتباه است، پارامتر توسط Profile بعدی Override شده یا تغییر برای اعمال‌شدن به Reboot نیاز دارد.
Config نهایی تلفن را با Profile ارسالی مقایسه کنید.
سناریوی ۹: بعد از اولین Fail دیگر هیچ Retry ندارید
مقدار زیر را بررسی کنید:
Resync Error Retry Delayاگر صفر باشد، در مستند فعلی Cisco Retry خودکار بعد از Failure انجام نمی‌شود.
سناریوی ۱۰: Resync فقط بعد از پایان تماس اجرا می‌شود
این رفتار می‌تواند طبیعی باشد.
Forced Resync Delay برای جلوگیری از ایجاد اختلال وسط مکالمه طراحی شده است.
سناریوی ۱۱: پس از Reboot تنظیمات برمی‌گردند
Provisioning Server احتمالاً فایل قدیمی را دوباره اعمال می‌کند.
گاهی مدیر Web UI را دستی تغییر می‌دهد و تصور می‌کند مشکل حل شده، اما Resync بعدی همان مقدار قدیمی را بازمی‌گرداند.
Source of Truth را روی Provisioning Server اصلاح کنید.
سناریوی ۱۲: فقط یکی از چند Profile دانلود نمی‌شود
URL هر چهار Rule را جداگانه با curl تست کنید و ترتیب اجرای آن‌ها را ثبت کنید.
وجود یک Profile اختیاری با 404 می‌تواند وقتی FNF روی Yes است کل Resync را Failed کند.
یک روش حرفه‌ای برای تست Resync
برای عیب‌یابی، موقتاً Profile Rule را تا حد ممکن ساده کنید.
مثلاً فقط:
https://prov.example.com/test.xmlو فایل:
<?xml version="1.0" encoding="UTF-8"?>
<device>
<flat-profile>
<Display_Name_1_ ua="na">RESYNC-TEST</Display_Name_1_>
</flat-profile>
</device>را قرار دهید.
اگر این فایل ساده کار کرد، شبکه و HTTPS سالم‌اند و مشکل را باید در Profile اصلی یا Ruleهای چندمرحله‌ای جست‌وجو کنید.
بعد از تست، تنظیم آزمایشی را Rollback کنید
قبل از تغییر Profile Rule اصلی، مقدار قبلی را ذخیره کنید.
اگر Configuration مرکزی دارید، نسخه قبلی فایل را نیز نگه دارید تا در صورت مشکل بتوانید سریع بازگردید.
چک‌لیست نهایی Cisco Resync Failed
| مورد | وضعیت مطلوب |
|---|---|
| Firmware | MPP/3PCC |
| Provision Enable | Yes |
| Resync On Reset | طبق طراحی |
| Profile Rule | URL کامل و صحیح |
| $MA | ۱۲ رقم lowercase |
| DNS | Resolve صحیح |
| TCP/TLS | اتصال سالم |
| Certificate | معتبر برای Phone |
| HTTP Status | 200 یا مسیر قابل تحلیل |
| 301/302 | Location مقصد سالم |
| 401 | Credential صحیح |
| 404 | Filename و Path اصلاح شده |
| FNF | متناسب با معماری |
| Retry Delay | بیشتر از صفر در صورت نیاز به Retry |
| XML | Syntax معتبر |
| Profile B/C/D | هیچ Rule خرابی وجود نداشته باشد |
| Syslog | Request/Success/Failure ثبت شود |
پرسش‌های متداول درباره Cisco Resync Failed
چرا Cisco MPP فایل Provisioning را دانلود نمی‌کند؟
علت می‌تواند Provision Enable غیرفعال، Profile Rule اشتباه، مشکل DNS یا TLS، خطای HTTP، فایل 404، Authentication نامعتبر، XML خراب یا Failure یکی از Profile Ruleهای بعدی باشد.
Provision Enable در Cisco چه کاری می‌کند؟
این گزینه عملیات Remote Provisioning و Resync را کنترل می‌کند. در مستند فعلی Cisco مقدار پیش‌فرض آن Yes است.
Resync Fails On FNF چیست؟
مشخص می‌کند File Not Found یک Resync Failure محسوب شود یا خیر. مقدار پیش‌فرض فعلی Yes است.
چرا فایل Cisco با وجود حضور روی Server خطای 404 می‌دهد؟
نام MAC، حروف بزرگ و کوچک، Path، Nginx Root یا Macro داخل Profile Rule را بررسی کنید. $MA به MAC دوازده‌رقمی lowercase تبدیل می‌شود.
آیا Cisco Redirect را دنبال می‌کند؟
در مستند فعلی Cisco، پاسخ‌های 301 و 302 بلافاصله با Location جدید Retry می‌شوند. سایر پاسخ‌های 3xx همان رفتار تضمین‌شده 301 و 302 را ندارند.
چرا Server پاسخ 200 می‌دهد ولی تنظیمات اعمال نمی‌شوند؟
ممکن است فایل XML قابل Parse نباشد، Tag اشتباه باشد، Profile Rule بعدی مقدار را Override کند یا آن Profile بعدی Fail شود.
Resync Error Retry Delay صفر چه معنی دارد؟
در مستند فعلی Cisco، مقدار صفر یعنی بعد از Resync ناموفق Retry خودکار انجام نشود.
چرا تلفن هنگام تماس Resync نمی‌شود؟
Cisco برای جلوگیری از قطع یا اختلال در تماس می‌تواند Resync را تا Idle شدن Line عقب بیندازد. Forced Resync Delay حداکثر این انتظار را کنترل می‌کند.
چرا بعد از Reboot تنظیم دستی من حذف می‌شود؟
اگر Resync On Reset فعال باشد، Provisioning Server دوباره Source of Truth را اعمال می‌کند و مقدار موجود در Profile می‌تواند تنظیم دستی را جایگزین کند.
چطور بفهمم مشکل قبل از HTTP است؟
اگر Phone Resync را شروع می‌کند اما هیچ Requestی در Access Log سرور دیده نمی‌شود، DNS، TCP، TLS، Firewall و خود Profile Rule را بررسی کنید.
چرا فقط Profile Rule اول دانلود می‌شود؟
Cisco Ruleها را به‌ترتیب اجرا می‌کند. اگر Rule B یا هر Rule دیگری Fail شود، زنجیره متوقف می‌شود و Ruleهای بعدی اجرا نمی‌شوند.
برای پیدا کردن علت Resync Failed مهم‌ترین Log چیست؟
Syslog خود Cisco و Access/Error Log سرور را هم‌زمان بررسی کنید. ترکیب URL واقعی، HTTP Status Code و پیام Failure معمولاً محل خرابی را سریع مشخص می‌کند.
جمع‌بندی
وقتی Cisco MPP فایل Provisioning را دانلود نمی‌کند، از Factory Reset شروع نکنید. ابتدا بررسی کنید Provision Enable فعال است و Profile Rule واقعاً به URL مورد انتظار اشاره می‌کند.
بعد URL نهایی پس از Macro Expansion را پیدا کنید. اگر از `$MA` استفاده می‌کنید، Cisco آن را به MAC دوازده‌رقمی lowercase تبدیل می‌کند. HTTP 404 معمولاً در همین مرحله با Filename، Path یا Web Root مرتبط است.
اگر Request به سرور می‌رسد، HTTP Status Code را مبنا قرار دهید. 401 به Authentication، 403 به Access Control، 404 به فایل و 5xx به Server اشاره می‌کند. Cisco پاسخ‌های 301 و 302 را دنبال می‌کند، اما Redirectهای دیگر را نباید بدون تست معادل آن‌ها دانست.
اگر Server پاسخ 200 می‌دهد اما Config اعمال نمی‌شود، بررسی را به XML Parsing و زنجیره Profile_Rule تا Profile_Rule_D منتقل کنید. یک Rule خراب می‌تواند ادامه Resync را متوقف کند و یک Rule بعدی نیز می‌تواند مقدار فایل قبلی را Override کند.
در نهایت Syslog تلفن را کنار Access Log وب‌سرور قرار دهید. اگر Phone Request می‌فرستد ولی Server آن را نمی‌بیند، شبکه یا TLS را بررسی کنید؛ اگر Server پاسخ می‌دهد، همان Status Code و URL واقعی تقریباً همیشه مشخص می‌کنند مشکل از Authentication، Redirect، Filename، FNF یا خود Profile است.
مسیر Resync را از تلفن تا Provisioning Server بررسی کنید
اگر Resync با خطای 401، 403، 404، TLS یا Retry ناموفق روبه‌رو شده است، می‌توانید درخواست بررسی کانفیگ ثبت کنید تا Profile Rule، HTTPS، فایل MAC، Web Server و Logهای Cisco به‌صورت مرحله‌ای بررسی شوند.
تماس با پشتیبانی ایرانیکاسرور
دیدگاه‌ها (۰)