المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

المشاكل

استكشاف الأخطاء وإصلاحها

تم تأجيل المزامنة بين CUC و Exchange أو لا يوجد مزامنة

المزامنة المتأخرة من Exchange Server إلى CUC

المقدمة

يوفر هذا المستند معلومات حول مشاكل المزامنة التي تمت رؤيتها بين عمليات النشر المحلية ل Cisco Unity Connection (CUC) و Microsoft Exchange.

المتطلبات الأساسية

المتطلبات

cisco يوصي أن يتلقى أنت معرفة من CUC.

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.

المشاكل

توجد ثلاثة أنواع من مشكلات المزامنة:

- لا توجد مزامنة

- مزامنة متأخرة من كلا الجانبين (CUC إلى Exchange Server والعكس صحيح)

- مزامنة متأخرة من Exchange Server إلى CUC

استكشاف الأخطاء وإصلاحها

يوفر هذا القسم معلومات حول كيفية أستكشاف المشكلات الثلاث وإصلاحها. وتجمع المسألتان الأولان في فرع واحد لأن النهج المتبع لاستكشاف المشاكل وإصلاحها هو نفسه.

تم تأجيل المزامنة بين CUC و Exchange أو لا يوجد مزامنة

قد تكون هناك أسباب مختلفة لا يوجد لها تزامن أو تأخر في التزامن بين CUC و Exchange. في هذا السيناريو، تحقق من حالات فشل الاتصال بين CUC و Exchange Server إما من خلال واجهة سطر الأوامر (CLI) أو من خلال مجموعة السجلات عبر أداة مراقبة الوقت الفعلي (RTMT).

RTMT

أختر تتبع وتسجيل مركزي > تجميع الملفات. أختر سجلات مزامنة علبة بريد الاتصال وقم بالمتابعة.

جذر

في CUC (/var/log/active/cuc) من خلال CLI (واجهة سطر الأوامر):

لعرض الملف، أدخل cat <filename> أو vi <filename>، حيث <filename> هو diag_cuMbxSync_xxxxxx.uc.

واجهة سطر الأوامر (CLI) للمسؤول

كما يمكن عرض السجلات عبر واجهة سطر الأوامر (CLI) للمسؤول، ولكنها صعبة للغاية.

دخلت in order to عددت المبرد، مبرد قائمة مبرد نشط /cuc/diag_cuMbxSync* تفصيل عكسي.

لعرض ملف، أدخل طريقة عرض الملف عمليا /cuc/diag_CuMbxSync_xxxxxxxx.uc حيث يكون xxxxxx هو رقم الملف.

لنقل الملفات إلى خادم FTP آمن (SFTP)، أدخل الملف get activelog /cuc/diag_cuMbxSync*.

تحقق من أحدث سجلات CuMbxSync لأي حالات فشل أو تحذيرات HTTP. بما أن الأخطاء أو التحذيرات تتم كتابتها بشكل افتراضي في التتبع، فلا حاجة لتمكين التتبع في هذه النقطة.

يمكن أن توقف حالات فشل HTTP (بشكل متقطع أو كامل) مزامنة عملية المراسلة من CUC إلى خادم Exchange والعكس. إذا تم عرض حالات فشل HTTP في السجلات، فستكون الخطوة التالية هي أستكشاف أخطاء هذه المشاكل وإصلاحها.

يوفر مستند TechNote أحادي علبة الوارد الخاص باتصال Unity Connection بعض المعلومات حول الأخطاء المختلفة التي تم رؤيتها في سجلات CuMbxSync.

في حالة عدم وجود أخطاء / حالات فشل في سجل CuMbxSync، قم بتمكين عمليات التتبع الدقيقة ل CsEws و CuMbxSync - جميع المستويات. أختر Cisco Unity Connection ServiceAbility > Trace > Micro Trace. انقر فوق خيار إعادة التعيين في صفحة حساب تطبيق المراسلة الموحدة للمستخدم وقم بتجميع السجلات مرة أخرى. اتصل بمركز المساعدة التقنية (TAC) من Cisco للحصول على مزيد من المساعدة.

المزامنة المتأخرة من Exchange Server إلى CUC

يتصل Exchange بخادم CUC على المنفذ 7080. يزود هذا قسم steps in order to تحريت الإصدار.

1. تأكد من أن المنفذ 7080 مفتوح وأن CUC يستمع إلى هذا المنفذ.
واجهة سطر الأوامر (CLI) للمسؤول

جذر

2. قم بتجميع التقاط شبكة في كل من خادم Exchange وخادم CUC لتأكيد أن خادم Exchange يرسل إعلامات tty و CUC يتلقى إعلامات tty هذه.
في واجهة سطر الأوامر (CLI) الخاصة بوحدة التحكم في الوصول إلى الشبكة، أدخل عدد مرات تسجيل الدخول إلى شبكة 100000 حجم ALL.

في Exchange، قم بتنزيل Wireshark  وتشغيله.

في التقاط CUC، يجب أن ترى هذا ربط نمط على ميناء 7080 (ميناء يستعمل لتلقي إخطارات):

تأكد (بمساعدة عنوان IP الذي تم تمييزه في التقاط الشاشة) أنه تم إرسال الإعلام من خادم Exchange إلى CUC وليس إلى خادم وكيل. إذا لم يظهر لديك النمط نفسه في المنفذ 7080 (أو لا ترى أي حركة مرور على المنفذ 7080)، فتحقق مع فريق خادم Exchange. يمكن أن تكون الإخطارات من Exchange إلى CUC من نوعين:

- إخطارات البقاء على قيد الحياة

- إعلام عملية الرسالة

يتم إرسال رسائل Keep-Live من Exchange إلى CUC. فيما يلي نموذج لرسالة إعلام بالاحتفاظ بقيد الحياة:

يرسل خادم Exchange هذا الإعلام كل خمس دقائق (بشكل افتراضي) لكل مستخدم مشترك. يتم إرسال هذا الإعلام بواسطة Exchange إلى عميل خدمات ويب ل Exchange (EWS) (CUC في هذه الحالة) لإبقاء الاشتراكات حية في CUC.

يتم تلقي الإعلامات من خادم Exchange على خادم CUC بواسطة Tty، والذي يقوم بتحليل الإخطارات وتحديث البيانات في جدول tbl_ExSubscription.

نموذج إدخالات في tbl_ExSubscription:

يمكن عرض المعلومات نفسها عبر واجهة سطر الأوامر (CLI) للمسؤول. أدخل الأمر run cuc dbquery unitydyndb select first 10 * من tbl_exsubscription.

يقوم tbl_ExSubscription بتخزين معلومات حول كل اشتراك في علبة البريد تم تسجيله مع Exchange عبر EWS. يعد Timestamputc (تم تمييزه في لقطة الشاشة السابقة) أحد الأعمدة في هذا الجدول. يحتوي على وقت التاريخ في وقت UTC الذي يشير إلى الوقت الذي تم فيه آخر تلقي لإشعار لهذا الاشتراك من قبل CUC من خادم Exchange.

تحتوي عملية CuMbxSync على مؤشر ترابط يراقب الاشتراكات القديمة كل دقيقتين ويقوم بإعادة الاشتراك لأي إدخالات قديمة. في سجل النموذج، يعتبر مؤشر الترابط مجموعة من إدخالات الاشتراك على أنها قديمة. وهذه ليست حالة مثالية (إذا كان كل شيء على ما يرام وقام Exchange بإرسال إعلامات مستمرة في الوقت المناسب). يتم إستخدام هذا الحقل لاكتشاف الاشتراكات القديمة بواسطة عملية CuMbxSync. الشرط المستخدم لتصفية الاشتراكات القديمة هو timestamputc < (CurrentTime - 15 دقيقة).

حتى في حالة عدم وجود أي تغيير في علبة بريد المشترك على جانب Exchange، يظل خادم Exchange يرسل إعلامات لكل مشترك (مشترك على خادم Exchange) في فترة زمنية مدتها خمس دقائق.

يمكن مشاهدة الإعلامات الخاصة بالإبقاء على قيد الحياة التي تأتي من Exchange في سجلات "خط الاتصال". يمكن تجميع هذه السجلات من RTMT (أختر Trace & Log Central > Collection Files > Connection Tty وتتابع) أو من خلال Root Access (/usr/local/tty/log).

يظهر هذا السجل الاستجابة التي تم إرسالها بواسطة CUC المقابلة للإعلامات الخاصة بالإبقاء على قيد الحياة التي تم إرسالها بواسطة Exchange Server. إذا لم تصل إعلامات "الاحتفاظ" إلى CUC من Exchange، فسيتم إعادة الاشتراك في الاشتراك بعد كل 16 دقيقة (تقريبا) وعندها فقط تحدث مزامنة علبة البريد.

وقد تكون الأسباب المحتملة لمثل هذا السلوك أحد هذه الأسباب:

- تكوين الوكيل في Exchange Server

- تكوين ترجمة عنوان الشبكة (NAT) في CUC

- تكوين جدار الحماية بين CUC و Exchange Server، وهكذا

قم بإشراك فريق الشبكة وفريق Exchange للحصول على السبب الفعلي لهذا السلوك.

إذا تلقى CUC الإعلام من خادم Exchange في الوقت المحدد ولم يتم انعكاس التحديث في علبة بريد CUC، فاتصل ب TAC للمساعدة في أستكشاف المشكلة وإصلاحها.