تغيّر Microsoft عنوان عميل Teams على الويب. خلال سبتمبر 2026، قد يُعاد توجيه المستخدمين الذين يفتحون teams.microsoft.com إلى teams.cloud.microsoft. وتصف Microsoft ذلك بأنه تغيير في النطاق، لا ترحيل للميزات: من المتوقع أن تستمر الروابط والإشارات المرجعية الحالية في العمل، ولا يحتاج المستخدمون النهائيون إلى تثبيت عميل جديد.

رسم توضيحي تحريري لإعادة توجيه المتصفح عبر فحوصات جدار الحماية وDNS والوكيل والتطبيقات المضمنة في المؤسسة.

يبدو الأمر اعتياديًا إلى أن يمر الطلب عبر وكيل مؤسسي أو بوابة ويب آمنة أو سياسة DNS أو قائمة سماح للمتصفح أو سياسة لأمن المحتوى أو بيان تطبيق أو نظام تحكم في الوصول عن بُعد. في هذه البيئات، لا تكون إعادة التوجيه آمنة تلقائيًا. يجب أن يتمكن المتصفح من حل العنوان الجديد والوصول إليه، ويجب أن تسمح به طبقة الحماية، كما ينبغي لتطبيقات Teams المضمّنة أن تتعرف إلى الأصل الجديد.

النصيحة الفورية واضحة: تعامل مع teams.cloud.microsoft بوصفه نقطة نهاية إنتاجية، وراجع بيانات نقاط نهاية Microsoft 365 التي تستخدمها مؤسستك، واختبر تجربة الويب كاملة قبل أن يكتشف المستخدمون التغيير عبر فشل تسجيل الدخول أو ظهور تبويب فارغ. والدرس المفيد يتجاوز Teams؛ فعناوين خدمات البرمجيات السحابية تنتمي إلى إدارة نقاط النهاية وإجراءات ضبط التغيير، حتى عندما يقول المورّد إن وظائف المنتج لم تتغير.

ما الذي تغيّره Microsoft؟

يفيد إشعار مركز الرسائل لدى Microsoft، MC1465764، بأن مستخدمي Teams على الويب سيُعاد توجيههم من teams.microsoft.com إلى teams.cloud.microsoft بحلول سبتمبر 2026. ويصنّف الإشعار التغيير على أنه تغيير رئيسي له أثر على المسؤولين. وتستخدم الوجهة عائلة نطاق cloud.microsoft الأوسع، التي قدّمتها Microsoft لتجارب Microsoft 365 المصادق عليها والموجهة إلى المستخدمين.

لا يُقدَّم الترحيل على أنه عميل Teams جديد أو نظام حسابات جديد. يفترض أن يصل الشخص الذي يستخدم المتصفح إلى الخدمة نفسها، بالمحادثات والاجتماعات والملفات وسياق المؤسسة نفسه. أما الفرق الظاهر فهو العنوان المعروض في المتصفح، إلى جانب سلوك الشبكة وتطبيقات الويب الناتج عن هذا العنوان.

تقول Microsoft إن العنوان القديم سيعيد التوجيه وإن الروابط الحالية ستواصل العمل. وهذا يقلل الاضطراب لدى المستخدم العادي، لكنه لا يلغي الحاجة إلى الاختبار الإداري. فالإشارة المرجعية تستطيع اتباع إعادة توجيه HTTP، بينما قد يقيّم وكيل مُدار بإحكام اسمي المضيف الأول والثاني كلًّا على حدة. وقد يحمّل المتصفح الصفحة، في حين يفشل تبويب مضمّن لأن سياسة frame-ancestors الخاصة به لم تُحدَّث. وقد يسمح جدار ناري بـ teams.microsoft.com لكنه يرفض *.cloud.microsoft.

ويذكر إشعار مركز الرسائل كذلك أن هناك عنصر تحكم إداريًا مؤقتًا يمكنه تعطيل إعادة التوجيه، لكن هذا التحكم ينتهي في 31 ديسمبر 2026. ولذلك فهو أداة مساعدة للترحيل وليس نموذج تشغيل دائمًا. على المؤسسات التي تستخدمه أن تسجل الاستثناء، وتعيّن له مالكًا، وتخطط لإزالته.

وتدرج وثائق نقاط النهاية العامة لدى Microsoft بالفعل كلاً من *.teams.microsoft.com و*.teams.cloud.microsoft لخدمة Teams، إلى جانب teams.microsoft.com وteams.cloud.microsoft. كما تسرد الوثائق نفسها *.cloud.microsoft بوصفه نقطة النهاية الموحدة المطلوبة لتجارب Microsoft 365 المصادق عليها. والنتيجة العملية مهمة: ينبغي للمؤسسة تحديث عملية مصدر الحقيقة الخاصة بنقاط النهاية، لا إضافة اسم مضيف واحد إلى قاعدة جدار ناري واحدة فحسب.

لماذا يمكن أن تتحول إعادة التوجيه إلى انقطاع؟

تعبر إعادة التوجيه عدة نقاط تحكم. وقد تنشئ كل نقطة منها عرضًا مختلفًا، بينما يظهر العرض للمستخدمين في صورة عامة هي أن Teams متوقف، حتى لو كانت خدمة Microsoft سليمة.

الجدران النارية وبوابات الويب الآمنة

تحتوي قوائم السماح التقليدية غالبًا على أسماء مضيفين محددة. فإذا سمحت السياسة بـ teams.microsoft.com ولم تسمح بـ teams.cloud.microsoft، فقد ينجح الطلب الأول ثم يُحظر الطلب الذي نتجت عنه إعادة التوجيه. وبحسب البوابة، قد يرى المستخدمون صفحة رفض وصول أو مهلة انتظار أو حلقة مصادقة أو هيكلًا غير مكتمل للتطبيق.

تستخدم بعض المؤسسات تصفية قائمة على الفئات أو فحص TLS أو توجيهًا صريحًا عبر الوكيل. وقد تعتمد هذه الضوابط على أسماء الشهادات أو فئات عناوين URL أو قواعد كُتبت حول النطاق القديم. يجب تقييم المضيف الجديد ضمن السياسة المقصودة نفسها. إن إضافة حرف بدل واسع من دون مراجعة طريقة تعامل البوابة معه قد تنشئ تعرضًا غير ضروري؛ ورفض الحرف البدل من دون فهم إرشادات Microsoft الخاصة بنقاط النهاية قد يؤدي إلى تشغيل هش. القرار الصحيح يتوقف على نموذج الضبط في المؤسسة، لكنه يجب أن يكون مقصودًا وموثقًا.

DNS وسلوك الشبكات المنقسمة

يدخل اسم المضيف الجديد أيضًا في مسارات DNS. فقد تفرض أدوات الحل الداخلية وخدمات التصفية ومنتجات DNS الآمن وعملاء الوصول عن بُعد سياسة مختلفة على نطاق ظهر حديثًا. اختبر من شبكات المكتب، والأجهزة المتصلة بشبكة VPN، وسيناريوهات العمل من المنزل، وأي بيئة سطح مكتب افتراضية مُدارة. فالاختبار الناجح من حاسوب مسؤول لا يثبت أن كل مسار خروج سيتصرف بالطريقة نفسها.

لا تثبّت عنوان IP لهذه التغييرات. فإرشادات نقاط النهاية لدى Microsoft مصاغة من حيث نطاقات الخدمة وبيانات العناوين المنشورة، كما أن الخدمات السحابية قد تغيّر بنيتها التحتية الأساسية. وقد يفشل الحل المعتمد على IP أثناء تغيير خدمة عادي، أو يتجاوز الغرض من الضوابط المعتمدة على اسم المضيف.

ثقة المتصفح وسياسات ملفات تعريف الارتباط

يعتمد الوصول إلى Teams عبر الويب على سلوك المتصفح بقدر اعتماده على إمكانية الوصول إلى الشبكة. وتحدد إرشادات استكشاف أخطاء Teams وإصلاحها لدى Microsoft أن *.cloud.microsoft من النطاقات التي قد تحتاج إلى وضعها ضمن النطاقات الموثوقة عندما تقيّد ضوابط المتصفح ملفات تعريف الارتباط أو المواقع الموثوقة. وعلى المؤسسات التي تحظر ملفات تعريف الارتباط التابعة لجهات خارجية، أو تفرض قوائم مواقع للمتصفح، أو تنشر سياسات عبر Group Policy، اختبار تسجيل الدخول وبدء الاجتماعات والتنقل بعد إعادة التوجيه.

يجب حصر استثناء النطاق في خدمات Microsoft المطلوبة وإدارته عبر عملية المراجعة نفسها المعتمدة لاستثناءات المصادقة الأخرى. لا تعطل ضابط خصوصية في المتصفح على مستوى المؤسسة كلها لمجرد إنجاح اختبار واحد. حدّد أولًا ما إذا كانت المشكلة في نطاق ملف تعريف الارتباط، أو سياسة الموقع الموثوق، أو فحص TLS، أو قاعدة الوكيل، أو نقطة نهاية محظورة.

تطبيقات Teams المضمّنة والتبويبات

Teams ليس مجرد عميل؛ فهو يستضيف التطبيقات أيضًا. وقد يُحمّل تبويب مخصص أو أداة أعمال داخلية أو تطبيق شريك داخل عميل Teams على الويب بدل فتحه كصفحة رئيسية مستقلة. في هذه الحالة، يغيّر المضيف الجديد أصل المتصفح، وقد يكشف افتراضات لم تكن ظاهرة تحت العنوان القديم.

تذكر إرشادات تطوير Teams لدى Microsoft أن على مالكي التطبيقات تحديث مكتبة JavaScript الخاصة بـ Teams إلى الإصدار 2.19.0 أو أحدث، وتهيئة التطبيق للمضيف الجديد. كما تنص على أن التطبيقات التي تستخدم ترويسات سياسة أمن المحتوى يجب أن تدرج *.cloud.microsoft في توجيه frame-ancestors، مع الإبقاء على القيم الحالية للتوافق العكسي أثناء الترحيل.

لا يعني هذا تغيير كل ترويسات الأمان بلا تمييز. بل يعني مراجعة الترويسة مقابل قائمة المضيفين المدعومين فعليًا، واختبار التطبيق داخل عميل Teams على الويب، والتحقق من أن أي تحقق من الأصل، أو إدخالات validDomains، أو إعدادات ملفات تعريف الارتباط، أو معالجة postMessage ما زالت تطابق مسار التطبيق المقصود.

من أنماط الفشل الشائعة النجاح الجزئي: يُحمّل هيكل Teams، لكن يعرض أحد التبويبات إطارًا فارغًا؛ أو يفتح التبويب، لكن يفشل اختيار ملف؛ أو تعود المصادقة إلى التطبيق من دون جلسة قابلة للاستخدام. سجّل المضيف الظاهر في المتصفح والمضيف الذي يظهر في آثار الشبكة قبل تعديل كود التطبيق.

من المتأثر؟

الفئة المتأثرة أساسًا هي المؤسسات التي تستخدم Teams في المتصفح وتتحكم في الوصول الصادر عبر الجدران النارية أو الوكلاء أو بوابات الويب الآمنة أو مرشحات DNS أو سياسات المتصفحات المُدارة. ويكون التغيير أقل ظهورًا لمن يستخدمون عميل سطح المكتب أو الهاتف فقط، مع أن الروابط ومراحل تسليم المصادقة والتجارب المضمّنة قد تظل تستعين بمكونات المتصفح.

مالكو تطبيقات Teams فئة ثانية. ويشمل ذلك المطورين الداخليين، وموردي البرمجيات، وفرق الإنترانت، والأقسام التي تدير تبويبات أو امتدادات رسائل أو مواقع مضمّنة داخل Teams أو تكاملات تتحقق من أصل Teams. ولا يقتصر خطرهم على إعادة التوجيه الأولى. فقد يؤثر المضيف الجديد في سياسات الإطارات، وفحوص الأصل، وافتراضات عناوين إعادة التوجيه، وسمات ملفات تعريف الارتباط، ومرشحات القياس، ووثائق الدعم.

كما ينبغي إشراك فريقي الشبكات والهوية. فكثيرًا ما يملك كل منهما قطعة مختلفة من المسار: يدير فريق الشبكات الخروج، وفريق نقاط النهاية سياسة المتصفح، وفريق الهوية ضوابط تسجيل الدخول، بينما يدير فريق التطبيقات المحتوى المضمّن. وقد يقع التغيير الذي يعبر المالكين الأربعة بين قوائم الانتظار ما لم يتعامل معه أحد باعتباره تغييرًا واحدًا في الخدمة.

ولا تُعفى المؤسسات الصغيرة تلقائيًا. فقد لا تملك الشركة الصغيرة وكيلًا معقدًا، لكنها قد تعتمد على جدار ناري مُدار أو مزود خدمات تقنية خارجي أو سياسة متصفح موروثة من مؤسسة أم. على البيئات الأبسط أن تختبر بسرعة بدل افتراض أن البساطة تضمن التوافق.

تفاصيل نقاط النهاية التي تهم

تقول وثائق عناوين URL ونطاقات IP في Microsoft 365 إن نقاط النهاية المطلوبة يجب أن تكون قابلة للوصول، وتحدد *.cloud.microsoft وجهة موحدة مطلوبة عبر TCP 443 وUDP 443. وفي قسم Teams، تسرد الوثائق *.teams.cloud.microsoft و*.teams.microsoft.com وteams.cloud.microsoft وteams.microsoft.com، مع TCP 443 و80 وUDP 443.

وتكون هذه الإدخالات أنفع من نسخ قائمة من منشور في منتدى، لأن Microsoft تحدّث بيانات نقاط النهاية عندما تتغير خدمتها. وتوضح الوثائق أن بيانات نقاط النهاية تُنشر عادةً مسبقًا، لكن التحديثات قد تحدث أيضًا خلال الشهر لمعالجة تصعيدات الدعم أو حوادث أمنية أو متطلبات تشغيلية عاجلة أخرى. وهذا سبب قوي لأتمتة تغذية نقاط النهاية في المؤسسة عندما تدعم أدوات الأمان ذلك.

وهو تذكير كذلك بأن فئات نقاط النهاية مهمة. تميز Microsoft بين الوجهات المطلوبة والاختيارية والافتراضية، وتوضح أن ميزة واحدة قد تعتمد على نقاط نهاية عبر مجموعات أحمال عمل متعددة. وقد يفوّت الفريق الذي يبحث عن كلمة Teams في قائمة ثابتة نقطة نهاية شائعة للمصادقة أو المحتوى مطلوبة للتجربة الكاملة.

التسلسل التشغيلي الآمن هو مقارنة بيانات نقاط النهاية الحالية لدى Microsoft بطبقات التحكم الفعلية في المؤسسة، ثم اختبار النتيجة. لا تفترض أن قائمة سماح واحدة في جدار الحماية المحيطي تمثل السياسة كلها. فقد يظل وسيط أمان الوصول إلى السحابة أو عميل نقطة النهاية أو إعداد المتصفح أو منطقة DNS خاصة أو قاعدة نفق VPN المنقسم يحظر المضيف الجديد.

خطة تحقق عملية

1. حدّد المستخدمين والمسارات الفعلية

ابدأ بجرد، لا بتغيير قاعدة. حدّد مجموعات المستخدمين التي تفتح Teams في المتصفح، والمجموعات التي تستخدم أسطح المكتب الافتراضية، والمستخدمين الذين يتصلون عبر VPN، وما إذا كان المتعاقدون أو مزودو الخدمات المُدارون يستخدمون مسارات خروج منفصلة. أدرج محطات العمل المشتركة والأجهزة ذات النمط المقيد وأنظمة غرف الاجتماعات إذا كانت تطلق روابط Teams المعتمدة على المتصفح.

سجّل الضوابط المطبقة على كل مسار: تصفية DNS، والوكيل، وفحص TLS، والجدار الناري، وبوابة الويب الآمنة، وسياسة المتصفح، وأمن نقطة النهاية، وسياسة الوصول المشروط للهوية. تساعد هذه الخريطة على التمييز لاحقًا بين مشكلة في الخدمة ومشكلة في سياسة محلية.

2. راجع مصدر نقاط النهاية في المؤسسة

استخدم وثائق نقاط النهاية الحالية لـ Microsoft 365، وحيثما أمكن بياناتها القابلة للتنزيل أو خدمتها على الويب، بدل الاعتماد على جدول بيانات محلي تتم صيانته يدويًا. تأكد من تمثيل إدخالات النطاق الموحد المطلوبة وإدخالات Teams في الأنظمة التي تفرض الوصول فعليًا.

إذا كانت المؤسسة تسمح عمدًا بأسماء FQDN محددة فقط، فقرّر ما إذا كان teams.cloud.microsoft كافيًا لإعادة توجيه Teams الحالية على الويب، أو ما إذا كان الحرف البدل الموثق مطلوبًا لاستخدام Microsoft 365 الأوسع في المؤسسة. اتخذ القرار مع مسؤول الأمان. قد يسهّل الحرف البدل الصيانة، بينما تمنح أسماء المضيفين المفردة نطاقًا أضيق لكنها تحتاج إلى صيانة أكثر تكرارًا.

3. اختبر إعادة التوجيه نفسها

من كل مسار شبكة تمثيلي، افتح عنوان Teams القديم وراقب السلسلة كاملة. تأكد من وصول الطلب إلى teams.cloud.microsoft، وقبول الشهادة، واكتمال المصادقة، وانتهاء تحميل التطبيق. اختبر حساب مستخدم عاديًا إلى جانب حساب مسؤول؛ فقد تكون للحسابات ذات الامتيازات سياسة وحالة مخزنة مؤقتًا مختلفتان.

استخدم أدوات المطور في المتصفح أو سجلات البوابة لتسجيل الطلبات المحظورة، ورموز الحالة، وقرارات السياسة. ليس الهدف جمع تفريغ ضخم للحزم، بل الإجابة عن أربعة أسئلة محددة: هل حُلّ DNS؟ هل مر الاتصال؟ هل اكتملت إعادة التوجيه؟ وهل حمّل التطبيق كل الموارد المطلوبة؟

امسح بيانات الموقع المخزنة مؤقتًا فقط بعد تسجيل النتيجة الأولى. فقد يخفي المسح مشكلة ترحيل قابلة لإعادة الإنتاج، أو ينشئ فشلًا زائفًا لا يواجهه المستخدمون العاديون. نفّذ اختبارًا واحدًا على الأقل بملف تعريف نظيف، وآخر بملف تعريف الإنتاج المُدار.

4. اختبر إجراءات المستخدم لا صفحة الوصول فقط

لا تكفي شاشة تسجيل دخول ناجحة. تحقّق من الإجراءات التي تهم المؤسسة: فتح محادثة، والانضمام إلى اجتماع، وبدء مكالمة إذا كانت مفعلة، وفتح ملف مشترك، والتبديل بين المستأجرين عند انطباق ذلك، وتحميل تبويب مخصص، واستخدام أي تكامل معتمد لـ Teams. اختبر إشارة مرجعية مباشرة ورابطًا وصل عبر رسالة بريد إلكتروني أو دعوة تقويم.

بالنسبة إلى الاجتماعات، اختبر المسار من رابط التقويم، لأن المتصفح قد يمر عبر خطوات إضافية لإعادة التوجيه والمصادقة. وبالنسبة إلى الملفات، اختبر فتح مستند تمثيلي وتحريره إذا كان ذلك المسار مهمًا. أما التطبيقات المخصصة، فاختبر كل تبويب حرج للأعمال ومسار عودة تسجيل الدخول.

5. افحص سياسات التطبيقات المضمّنة

على مالكي التطبيقات البحث في الكود المصدر والإعدادات عن المراجع الثابتة إلى teams.microsoft.com، ومقارنات الأصل الصريحة، وقيم frame-ancestors في CSP، وقوائم النطاقات الموثوقة، وعناوين إعادة التوجيه، وافتراضات نطاق ملفات تعريف الارتباط، ومرشحات القياس. وينبغي أن يشمل البحث إعدادات النشر والوثائق، لا كود التطبيق وحده.

اتبع إرشادات تطبيقات Teams لدى Microsoft بشأن إصدار TeamsJS وسلوك التهيئة. احتفظ بقيم المضيف القديم عندما يكون التوافق العكسي مطلوبًا، وأضف المضيف الجديد وفق نموذج أمان التطبيق. لا تستبدل القيم القديمة عشوائيًا إذا كان المستخدمون ما زالوا قادرين على الوصول عبر العنوان القديم، أو إذا بقيت مضيفات Microsoft 365 أخرى مدعومة.

بعد تغيير الترويسات أو البيانات الوصفية، اختبر في كل سياق مضيف مدعوم. فقد تعمل CSP في تبويب متصفح رئيسي، لكنها ترفض إطارًا مضمّنًا. وعلى العكس، قد تخفي ترويسة اختبار متساهلة أن استجابة الإنتاج تُنشأ عبر وكيل عكسي أو شبكة توصيل محتوى مختلفة.

6. حدّث المواد التشغيلية

ابحث في مقالات مكتب المساعدة، وأدلة تهيئة المستخدمين، ونماذج طلبات الجدار الناري، وسياسات الوكيل، وسياسات المتصفح، وفحوص المراقبة، وكتب تشغيل الحوادث عن اسم مضيف Teams القديم. احتفظ بالعنوان القديم في الملاحظات التاريخية عند الحاجة، لكن صفه بأنه مصدر لإعادة التوجيه لا عنوان الخدمة الوحيد.

يجب تحديث المراقبة أيضًا. فقد يبدأ فحص اصطناعي يفترض اسم المضيف النهائي بالفشل، رغم أن الخدمة سليمة، إذا كُتب للفحص العنوان القديم. ويكون الفحص الذي يتبع إعادة التوجيه ويتحقق من الصفحة النهائية أكثر تمثيلًا، شرط أن ينبه أيضًا عند تغير سلسلة إعادة التوجيه على نحو غير متوقع.

ما الذي ينبغي عدم فعله

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

لا تعطل إعادة التوجيه نهائيًا لمجرد أن فريق التطبيقات لم يختبر تبويبه. فعنصر التحكم الإداري المؤقت له تاريخ انتهاء، وتأجيل العمل يحوّل تغييرًا يمكن ضبطه إلى حادثة مرتبطة بموعد نهائي. استخدم التحكم فقط عندما يكون ضروريًا لحماية استمرارية الخدمة بينما تُجدول معالجة محددة.

لا تستبدل قواعد أسماء المضيفين بعناوين IP ثابتة. فالبنية السحابية لدى Microsoft مصممة للتطور، وقد يصبح الحل المعتمد على IP قديمًا أو يوجّه الحركة بشكل غير صحيح.

لا تسمح بكل وجهات *.microsoft من دون مراجعة. تحدد وثائق Microsoft ذات الصلة عائلات نطاقات وفئات نقاط نهاية بعينها؛ وتوسيع الوصول إلى ما يتجاوز متطلبات العمل يضعف قيمة الضبط.

لا تعتبر استجابة HTTP 200 من الصفحة الأولى دليلًا على أن Teams يعمل. فقد يحدث الفشل بعد المصادقة، أو أثناء استدعاء واجهة برمجة تطبيقات، أو عند تحميل تبويب، أو عند فتح ملف.

كيفية التعامل مع الاستثناء المؤقت

يفيد إشعار Microsoft بأن عنصر التحكم الإداري لتعطيل إعادة توجيه Teams ينتهي في 31 ديسمبر 2026. وإذا استخدمته مؤسسة، فينبغي أن يكون للاستثناء سبب واضح ومالك محدد. ويتضمن السجل المفيد المستأجر أو مجموعة المستخدمين المتأثرة، والاعتمادية المحظورة، وفريق التطبيق أو الشبكة المسؤول، وتاريخ الاختبار المستهدف، وتاريخ إزالة الاستثناء.

لا ينبغي أن يصبح الاستثناء بديلًا عن صيانة نقاط النهاية. إذا كانت المشكلة قاعدة وكيل، فأصلح قاعدة الوكيل. وإذا كانت المشكلة CSP في تبويب مخصص، فأصلح استجابة التطبيق. وإذا كان الخلل في تكامل تابع لجهة خارجية، فاطلب من مالكه مسار ترحيل مدعومًا ووثّق الإجابة.

عندما يتعذر التحقق من تطبيق حرج للأعمال في الوقت المناسب، افصل المخاطر. أبقِ الاستثناء ضيقًا بقدر ما تسمح به أداة التحكم المتاحة، وراقب مسار العمل المتأثر، وأبلغ مالك الخدمة بتاريخ الانتهاء. الهدف هو الحفاظ على الاستمرارية مع إبقاء الترحيل ظاهرًا وقابلًا للمتابعة.

لماذا يُعد هذا تغييرًا في البنية التحتية؟

يمكن لمزود خدمة سحابية أن يغيّر اسم مضيف من دون تغيير الميزة التي يراها المستخدم. لكن اسم المضيف، بالنسبة إلى العميل، جزء من عقد الخدمة الذي تفرضه الشبكات والمتصفحات والتطبيقات. فالعنوان يحدد السياسة المطابقة، والشهادة التي يجري فحصها، وملفات تعريف الارتباط التي تُرسل، والأصل الموثوق، والسجلات التي تحدد هوية الحركة.

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

يوضح التغيير أيضًا تحولًا في تشغيل السحابة. فلم تعد نقاط نهاية الخدمة ملحقًا ثابتًا يُحدّث مرة واحدة أثناء النشر. تقول Microsoft إن بيانات نقاط النهاية تتغير مع تطور الخدمات، ويمكن تحديثها خارج الوتيرة المعتادة عندما تفرض الظروف التشغيلية ذلك. وقد تقلل المؤسسات التي تستهلك بيانات نقاط النهاية آليًا التأخير اليدوي، لكن الأتمتة تظل بحاجة إلى مراجعة: فقد تحدّث التغذية جدار الحماية، بينما تبقى CSP الخاصة بالتطبيق وكتاب التشغيل من دون تغيير.

قائمة تحقق مختصرة لشهر سبتمبر

  • تأكد من استخدام Teams عبر المتصفح داخل المؤسسة.
  • راجع MC1465764 في مركز إدارة Microsoft 365 وحدد حالة الطرح لدى المستأجر.
  • تأكد من السماح بـ teams.cloud.microsoft وبنقاط نهاية *.cloud.microsoft ذات الصلة ضمن سياسة الشبكة الموثقة.
  • اختبر من مسارات المكتب وVPN والعمل عن بُعد وسطح المكتب الافتراضي والمتصفح المُدار.
  • اتبع إعادة التوجيه وتحقق من تسجيل الدخول والاجتماعات والملفات وتبويبات Teams الحرجة.
  • راجع تصفية DNS وقواعد الوكيل وفحص TLS وسياسات الثقة أو ملفات تعريف الارتباط في المتصفح.
  • اطلب من مالكي التطبيقات فحص TeamsJS وCSP frame-ancestors والتحقق من الأصل والبيانات الوصفية وعناوين إعادة التوجيه.
  • حدّث المراقبة الاصطناعية والوثائق وإرشادات مكتب المساعدة.
  • سجّل أي استثناء مؤقت لإعادة التوجيه مع مالك وتاريخ إزالة قبل 31 ديسمبر 2026.

المصادر

الخلاصة العملية

تكون عملية ترحيل Teams على الويب سهلة في متصفح غير مُدار، وقد تكون مؤثرة في مؤسسة مُدارة. والاستجابة المناسبة ليست تغييرًا طارئًا واسعًا في الجدار الناري، بل تحقق قصير قائم على الأدلة من نقطة النهاية الجديدة عبر المسارات الفعلية التي يسلكها المستخدمون والتطبيقات. بعد اكتمال هذا العمل، يفترض أن تصبح إعادة التوجيه ما تقصده Microsoft: تغييرًا في العنوان، لا تغييرًا في الإتاحة.