أقرت شركة مايكروسوفت بأن العطل الواسع الذي أصاب خدمات Microsoft 365 ابتداءً من الخميس 12 نوفمبر 2026 نشأ من مشكلة أُدخلت خلال ترقية سابقة لسعة الشبكة، ثم ظهرت آثارها بعد تغيير شبكي أحدث. وتكشف تفاصيل التحقيقات التشغيلية أن ما بدا في البداية ارتفاعًا في أحمال الخوادم كان، في جانب أساسي منه، نتيجة لفقدان عدد كبير من الخوادم قدرتها على معالجة الطلبات، وما تبع ذلك من اختلال في توزيع الاتصالات.
وامتد تأثير الحادث من Exchange Online وOutlook إلى وظائف مترابطة داخل Teams وCopilot وSharePoint وأدوات الإدارة والأمن والواجهات البرمجية. وفي أحدث تحديث تفصيلي راجعته «البوابة التقنية»، الصادر مساء الجمعة 13 نوفمبر عند الساعة 22:00 بالتوقيت العالمي، أي الثانية صباح السبت بتوقيت الإمارات، قالت مايكروسوفت إن التعافي أصبح مستقرًا على نطاق واسع، لكنها أبقت الحادث مفتوحًا للمراقبة ومتابعة معالجة البريد الإلكتروني المتراكم.
يعيد هذا التقرير بناء ما جرى داخل البنية التحتية للشركة اعتمادًا على التحديثات التي أصدرتها مايكروسوفت للحادثتين EX1550543 وMO1550821، والمنقولة من لوحة صحة الخدمة المؤسسية عبر سجل جامعة بنسلفانيا، مع الفصل الصريح بين الوقائع التي كشفتها الشركة، والتفسير الهندسي المرجح، والأسئلة التي لم يُجب عنها التحقيق المنشور بعد.
السبب الذي أكدته مايكروسوفت: خلل قديم كشفه تغيير شبكي أحدث
في تحديث الساعة 17:57 بالتوقيت العالمي يوم 13 نوفمبر، أي 21:57 بتوقيت الإمارات، أعلنت مايكروسوفت أن «مشكلة أثناء ترقية سابقة لسعة الشبكة» هي منشأ الحادث، وأنها ظهرت عقب تغيير أحدث في الشبكة. وأكدت أنها عالجت المشكلة الأساسية وتواصل استعادة ما تبقى من الخدمات والمناطق بصورة تدريجية، مع التعهد بإصدار تقرير شامل بعد الحادث.
وتختلف هذه النتيجة عن الانطباع الأولي الذي عزَا الاضطراب إلى أحمال مرتفعة. فقد أوضحت الشركة مبكرًا أن إجمالي حركة المستخدمين لم يرتفع على نحو يفسر الأزمة؛ بل أصبحت خوادم كثيرة غير متاحة، وانتقلت الطلبات التي كانت تخدمها إلى الخوادم المتبقية، فتزايد الضغط على السعة التي لم تتعطل.
من الناحية التقنية، يتوافق هذا السيناريو مع وجود خلل كامن (Latent Fault): خطأ يُدخل إلى بيئة التشغيل أثناء تغيير سابق من دون أن يظهر فورًا، ثم تفعّله ظروف جديدة. لكن هذا توصيف تحليلي لشكل الحادث وليس تسمية أعلنتها مايكروسوفت لمكوّن برمجي محدد. ولم تحدد الشركة حتى الآن الإعداد أو الشيفرة أو جهاز الشبكة المسؤول بدقة، ولا توقيت إدخال الخلل الأصلي، ولا سبب عدم اكتشافه في الاختبارات السابقة.
كما لا توجد أدلة منشورة تكفي لنسب الحادث بصورة قاطعة إلى بروتوكول BGP أو نظام DNS أو شبكة Azure VNet أو بوابة شبكية بعينها. وأي تسمية جازمة لأحد هذه المكونات في غياب الإفصاح الهندسي النهائي ستكون استنتاجًا غير مثبت.
كيف تحول الخلل إلى توقف واسع للخدمات؟
1. اضطراب الاتصالات في طبقة استقبال الطلبات
تعمل خدمات Microsoft 365 عبر منظومة متعددة الطبقات تستقبل الاتصالات، وتؤمّنها، وتتحقق من صلاحية الوصول، ثم توجه الطلبات إلى الخوادم الخلفية المناسبة. وقد رصدت مايكروسوفت في الساعات الأولى أخطاء اتصال في جزء من البنية التحتية الذي يستقبل ويعالج طلبات الوصول إلى صناديق بريد Exchange Online، وجمعت سجلات الشبكة لتحديد منشئها.
وفي تحديث لاحق، حددت الشركة مظهرًا تقنيًا أكثر دقة: عملية برمجية مسؤولة عن إنشاء الاتصالات الآمنة على الخوادم المتأثرة أصبحت تتعرض لعبء يفوق قدرتها، مما جعل تلك الخوادم تتوقف عن معالجة الطلبات. وكانت فرقها تتحقق من تعديل في الإعدادات لمعالجة هذا السلوك وتطبقه أولًا على مجموعة محدودة من الخوادم.
هذا التفصيل مهم لأن الإخفاق لم يقتصر على تطبيق البريد أو تخزين الرسائل، بل أصاب مرحلة تسبق إنجاز كثير من الطلبات. فإذا تعثرت العملية المسؤولة عن إقامة الاتصال، فقد يفشل الطلب قبل وصوله إلى المكوّن الخلفي الذي ينفذ الخدمة المطلوبة.
لكن الشركة لم تكشف اسم العملية أو المكتبة البرمجية، ولم تقل إن المشكلة تقع تحديدًا في مصافحة TLS أو داخل خوارزمية تشفير معينة. كما لم توضح ما إذا كان الاختناق سببه استهلاك المعالج أو قيود الذاكرة أو التزامن البرمجي أو إدارة مقابس الشبكة؛ وهذه كلها احتمالات هندسية لا ترقى إلى حقائق مثبتة.
2. فشل الفحوص الآلية لسلامة الخوادم
أعلنت مايكروسوفت أن خوادم متأثرة كانت تفشل في فحوص سلامة الخدمة (Health Checks)، وهو ما أدى إلى استبعادها من القدرة المتاحة لتلقي الطلبات. وتُستخدم هذه الفحوص في البنى الموزعة لمعرفة ما إذا كان الخادم قادرًا على أداء وظيفته، ومن ثم الحد من إرسال الطلبات إلى خادم لا يستجيب على نحو سليم.
هذه الآلية مفيدة عادة، لكنها تخلق تحديًا إذا تعطل عدد كبير من الخوادم في وقت متقارب. فحين تختفي سعة تشغيلية كبيرة، يعاد توزيع طلباتها على موارد أقل، وقد يؤدي ارتفاع العبء إلى زيادة زمن الاستجابة أو انقطاع خوادم أخرى. وهذا ما يفسر وصف الشركة للضغط بأنه ناتج عن اختلال في السعة المتاحة لا عن طفرة مستقلة في الطلب.
يتوافق المشهد مع نمط الإخفاق المتسلسل (Cascading Failure) في الأنظمة الموزعة؛ أي أن آثار تعطل جزء من المنظومة تزيد الضغط على بقية أجزائها. لكن لا يوجد إفصاح يسمح بالجزم بأن فحوص السلامة نفسها كانت خاطئة؛ فقد تكون رصدت عجزًا فعليًا في الخوادم. ولم تنشر مايكروسوفت عدد الخوادم المستبعدة أو نسبة السعة التي فُقدت.
3. لماذا كانت الخوادم تتعطل بعد إعادة تشغيلها؟
واجهت مايكروسوفت مشكلة غير اعتيادية خلال الاستعادة: كانت بعض الخوادم تعود للعمل بعد إعادة تشغيلها، وتبدو مستقرة في البداية، ثم تصبح غير مستجيبة مجددًا عند إعادة إدخال حركة الاتصالات إليها. ودفعت هذه النتيجة الشركة إلى اختبار التعافي على مجموعات صغيرة من الخوادم مع فرض قيود مؤقتة على أنواع الاتصالات التي تصل إليها.
تقنيًا، يشير هذا السلوك إلى أن إعادة التشغيل قد تزيل الحالة التشغيلية غير السليمة مؤقتًا، لكنها لا تزيل الشرط الذي يعيد إنتاج المشكلة عند استقبال الطلبات. ولذلك لم يكن ممكنًا إعادة تشغيل الخوادم كلها وإعادة توجيه الحمل إليها دفعة واحدة؛ كان يلزم اختبار كل مرحلة والتحقق من تحمل الخوادم للاتصالات الحقيقية قبل زيادة الحمل.
وجربت الشركة طريقة بديلة لفحص السلامة أتاحت عودة بعض الخوادم، وتوسعت في استخدام عمليات إعادة التشغيل والكشف الآلي عن الأجهزة غير المستجيبة، كما درست إعادة بناء مجموعات محددة باستخدام إعدادات برمجية أقدم. ولا يثبت ذلك أن التهيئة القديمة وحدها كانت كافية لإزالة السبب الجذري.
4. اضطراب توجيه الاستدعاءات إلى الخوادم الخلفية
في تحديث آخر صباح الجمعة، قالت مايكروسوفت إنها رصدت قفزة في حجم الاستدعاءات الصادرة من خدمات التوجيه إلى الخوادم الخلفية. ووصفت حالة لا تستطيع فيها إحدى الخدمات توجيه الاتصالات كما ينبغي إلى الأجهزة الخلفية، بينما أسهمت عمليات إعادة توزيع الحركة التي نُفذت أثناء المعالجة في ارتفاع حجم تلك الاستدعاءات.
وفي الوقت نفسه، حاولت الشركة إجبار أجهزة متأثرة على مزامنة إعدادات التغيير الشبكي الأخير، لكنها وجدت بعض الأجهزة عالقة في حالة تشغيلية غير سليمة، بما منع وصول التعديلات إليها أو تطبيقها كما كان متوقعًا. ولهذا تداخل اضطراب معالجة الطلبات مع صعوبات التحكم في البنية التحتية أثناء إصلاحها.
ولا توضح الإفصاحات المتاحة ما إذا كان عدم مزامنة الإعدادات جزءًا من السبب الأصلي أم نتيجة ثانوية للخلل؛ كما لا تثبت أن هذه المشكلة وحدها مسؤولة عن طول الانقطاع. لكنها تفسر جانبًا من تعقيد الاستعادة: كانت بعض الأجهزة تحتاج إلى إصلاح، وفي الوقت نفسه لم تكن قادرة على استقبال بعض تغييرات الإصلاح بالطريقة المعتادة.
المسار التقني للإخفاق: ما المؤكد وما المستنتج؟
يمكن تلخيص المسار الأقرب إلى المعطيات المعلنة على النحو الآتي: مشكلة أُدخلت في ترقية سابقة لسعة الشبكة، ثم تغيير أحدث كشفها؛ تلا ذلك اضطراب في إنشاء الاتصالات الآمنة والتوجيه، وتوقف خوادم عن معالجة الطلبات وفشلها في اجتياز فحوص السلامة، ثم انتقال الأحمال إلى الخوادم المتبقية وتفاقم فقدان السعة. وأدت هذه الاضطرابات إلى تعذر الوصول إلى Exchange Online، قبل أن تظهر آثارها على وظائف في خدمات تعتمد عليه.
هذا تلخيص تحليلي متسق مع تحديثات الشركة، وليس رسمًا رسميًا لسلسلة الاستدعاءات الداخلية. وما زالت العلاقات الدقيقة بين العيب في ترقية الشبكة، واختناق عملية الاتصال الآمن، وفشل فحوص السلامة، ومشكلات المزامنة بحاجة إلى توثيق هندسي تفصيلي من مايكروسوفت.
لماذا تأثرت Teams وCopilot وSharePoint وخدمات الحماية؟
لم يكن العطل دليلًا على أن جميع المنتجات التابعة لمايكروسوفت انهارت بصورة مستقلة. أوضحت الشركة أن وظائف كثيرة في Microsoft 365 تتفاعل مع Exchange Online أو خدمات البريد والتقويم، وأن المكونات التي لا تحتاج إلى هذا التفاعل استطاعت مواصلة العمل في حالات عديدة. وفيما يأتي أبرز أشكال التأثير التي سجلتها تحديثات الشركة:
| الخدمة | الأثر التقني المعلن |
|---|---|
| Exchange Online وOutlook | تعذر الوصول إلى صناديق البريد عبر Outlook على الويب وMAPI وExchange ActiveSync وواجهات REST، مع تأخر تسليم الرسائل واحتمال تأثر تدفق البريد بين البيئات المحلية والسحابة. |
| Microsoft Teams | تعطل بعض وظائف التقويم والدعوات وتعديل الاجتماعات وجهات الاتصال وبعض تكاملات Copilot؛ بينما ظلت غالبية الاجتماعات والمكالمات والمحادثات والقنوات القياسية تعمل. |
| Microsoft 365 Copilot | صعوبة تحميل المحادثات أو الحصول على ردود والوصول إلى بيانات العمل المرتبطة بالبريد والتقويم والملفات. |
| Microsoft Graph | انتهاء مهلة بعض استدعاءات API الخاصة بالبريد والتقويم وجهات الاتصال، مع امتداد آثار إلى عمليات إدارية في Teams والتطبيقات. |
| SharePoint Online | تأثر وظائف مرتبطة بـExchange وبعض سيناريوهات المشاركة الخارجية؛ مع استمرار الوصول المباشر إلى الملفات المخزنة في SharePoint في كثير من الحالات. |
| Microsoft Defender وPurview | تعطل بعض صفحات الإدارة ووظائف Safe Links وسياسات تصنيف البيانات ومنع تسربها وعمليات البحث والتدقيق الإلكتروني، وفق السيناريوهات المذكورة في سجل الحادث. |
| Intune وWindows 365 | اضطرابات محتملة في تسجيل الأجهزة وفحوص امتثالها، وصعوبات وصول في إعدادات محددة للحواسيب السحابية المرتبطة بخدمة Customer Key. |
| Planner وTo Do وPower BI وFabric | اضطرابات في عمليات المهام أو تحميل التطبيقات، وبعض سيناريوهات تصدير التقارير المحمية بتصنيفات الحساسية. |
وتبرز هذه التفاصيل طبيعة الاعتماد المتبادل بين الخدمات السحابية: قد يستمر Teams في تشغيل اجتماع، لكنه يفشل في عرض التقويم إذا تعذرت قراءة بيانات Exchange؛ وقد يظل ملف SharePoint متاحًا مع تعطل ميزة تحتاج إلى خدمة أخرى. ولذلك لا يصح اعتبار إدراج منتج في قائمة التأثيرات دليلًا على توقفه بالكامل عند جميع المستخدمين.
وقد تناولت «البوابة التقنية» في تغطية مستقلة امتداد الاضطراب إلى تكاملات خدمات خارجية؛ أما هذا التقرير فيركز على سلسلة الإخفاق داخل بنية مايكروسوفت نفسها.
كيف تعاملت مايكروسوفت مع العطل؟
تصحيح مكوّن المصادقة والتوجيه
من أبرز خطوات العلاج تطبيق تصحيح لمكوّن تهيئة في مسار المصادقة والتوجيه العلوي (Upstream Authentication/Routing Configuration Component). وقالت الشركة إنها رصدت نتائج إيجابية لاستقرار الخوادم بعد اختباره على جزء من البنية التحتية، ثم بدأت توسيع تطبيقه تدريجيًا، مع إعطاء الأولوية للمناطق التي تشهد ساعات عمل نشطة أو توشك على دخولها.
ولا يتبين من السجل المنشور على وجه الدقة ما إذا كان هذا التصحيح يعدل العيب الأصلي في ترقية الشبكة أم يعالج إحدى نتائجه في مسار إنشاء الاتصالات. والتفريق بين الأمرين يتطلب تفاصيل تقرير ما بعد الحادث.
تقليل الحمل وإعادة توجيه الاتصالات
اتبعت الشركة كذلك نهجًا متدرجًا تضمن عزل أجزاء من البنية المتضررة، وإيقاف تغييرات وعمليات نشر مؤقتًا، وإعادة توجيه الاتصالات إلى مسارات بديلة، وتعديل بعض بروتوكولات الحركة وتقييد أنواع محددة من الطلبات في مواقع بعينها. وكانت الغاية منع الخوادم المستعادة من التوقف مجددًا فور استقبال كامل الحمل.
استعادة الخوادم وإضافة قدرة افتراضية
أعادت الفرق الهندسية تشغيل الخوادم غير المستجيبة واختبرت سلامتها قبل إعادتها إلى توزيع الأحمال، كما وسعت استخدام الآلات الافتراضية لزيادة السعة وتقليل الضغط. وفي أجزاء من البيئة حاولت فرض مزامنة الإعدادات أو الرجوع إلى تهيئات سابقة، ولم تنجح كل التدابير الأولية بالسرعة المتوقعة، وهو ما يفسر امتداد الاستعادة لساعات طويلة.
حماية رسائل البريد المتأخرة
مع استعادة الوصول إلى صناديق البريد، بقيت منظومة التسليم بحاجة إلى معالجة الرسائل المتراكمة في الطوابير. ومددت مايكروسوفت مهلة تسليم البريد إلى 48 ساعة للمساعدة في حماية الرسائل المتأخرة أثناء التعافي. وهذه المهلة ليست إعلانًا بأن كامل الخدمة سيعود خلال 48 ساعة، بل إجراء تشغيلي للحد من احتمال فقد الرسائل التي تأخر تسليمها.
ومن هنا يجب التفريق بين تعافي واجهة Outlook أو نجاح تسجيل الدخول، وبين عودة تدفق البريد ومعالجة الرسائل إلى المستوى الطبيعي. وفي تحديث الساعة 02:00 صباح السبت بتوقيت الإمارات، قالت الشركة إن معظم سيناريوهات التأثير عولجت وإنها تواصل مراقبة الطوابير والاستقرار لفترة ممتدة قبل اعتبار الحادث مغلقًا.
التسلسل الزمني للحادث بتوقيت الإمارات
يستند التسلسل الآتي إلى الأوقات المسجلة في تحديثات مايكروسوفت، بعد تحويلها من التوقيت العالمي المنسق إلى توقيت دولة الإمارات (+4). وهي أوقات بدء التأثير والتحديثات التشغيلية، ولا تمثل بالضرورة لحظة إدخال الخلل الأصلي:
| التاريخ والتوقيت | التطور المعلن |
|---|---|
| الخميس 12 نوفمبر، 20:17 | بداية تأثير Exchange Online المسجل في الحادثة EX1550543. |
| الخميس، 22:26 | بدء الحادثة MO1550821 الخاصة بخدمات Microsoft 365 المتعددة. |
| الخميس، 23:18 إلى 23:30 | توضيح أن الضغط ناتج عن خروج خوادم من الخدمة وانتقال أحمالها، وليس عن زيادة إجمالية في الطلب. |
| الخميس، 23:43 | الكشف عن إخفاق خوادم في فحوص السلامة الآلية. |
| الجمعة 13 نوفمبر، 00:56 تقريبًا | التحقق من نجاح أسلوب بديل لفحص السلامة على مجموعة من الخوادم. |
| الجمعة، 05:06 | تحديد اختناق عملية إنشاء الاتصالات الآمنة والبدء في التراجع عن تغيير شبكي حديث. |
| الجمعة، 08:59 | رصد زيادة استدعاءات التوجيه وصعوبات مزامنة الإعدادات على أجهزة عالقة بحالة غير سليمة. |
| الجمعة، 11:25 | ظهور نتائج إيجابية لتصحيح مكوّن المصادقة والتوجيه وبدء توسيع تطبيقه. |
| الجمعة، 21:57 | إعلان أن العطل نشأ في ترقية سابقة لسعة الشبكة، وظهر بعد تغيير أحدث، مع تأكيد معالجة المشكلة الأساسية. |
| السبت 14 نوفمبر، 02:00 | الإبلاغ عن تعافٍ مستدام واسع ومراقبة آثار الحادث ورسائل البريد المتراكمة. |
ما الذي يكشفه الحادث عن هندسة الخدمات السحابية؟
أولًا، لم يمنع الفصل الوظيفي بين المنتجات امتداد الأثر عبر المكونات المشتركة. فتبادل الاعتماد بين البريد والتقويم وواجهات البرمجة وأدوات الهوية والتوجيه يجعل إخفاق طبقة واحدة ظاهرًا في تطبيقات تبدو مستقلة. وهذه ملاحظة هندسية مستندة إلى نطاق التأثير، وليست دليلًا على انهيار كل منطقة استضافة أو كل آليات العزل لدى مايكروسوفت.
ثانيًا، قد يؤدي استبعاد الخوادم غير السليمة إلى مشكلة سعة إذا أصبح الاستبعاد واسع النطاق. فاختبارات الصحة وتوزيع الحمل صُممت لحماية المستخدمين من الخوادم المعطلة، لكن فعاليتها تتوقف على وجود سعة بديلة كافية. ولم تكشف مايكروسوفت بعد إن كانت معايير الاستبعاد أو سياسات توزيع الحمل بحاجة إلى تعديل.
ثالثًا، تعقّد التعافي عندما لا تستطيع بعض الأجهزة استقبال تغييرات الإصلاح. فقد أظهرت مشكلة المزامنة أهمية وجود مسارات مستقلة وآمنة للتراجع عن الإعدادات واستعادة الأجهزة غير المستجيبة. غير أن ذلك لا يكفي للجزم بوجود خلل تصميمي محدد في منظومة التحكم قبل نشر التحقيق النهائي.
رابعًا، لا تكفي عودة الخدمات المرئية لإثبات انتهاء الأثر. فالطلبات المؤجلة وطوابير البريد والعمليات الإدارية المتأثرة قد تحتاج إلى وقت إضافي حتى بعد استقرار الخوادم الرئيسية، وهو ما يفسر استمرار المراقبة بعد التحسن الواسع.
هل كان العطل هجومًا سيبرانيًا؟ وهل يشبه حادث CrowdStrike؟
أكدت مايكروسوفت أن الحادث تقني وليس مرتبطًا بنشاط سيبراني خبيث أو بأنظمة الذكاء الاصطناعي ووكلائها. ولا تدعم البيانات المنشورة فرضية أن هجوم حجب خدمة أو اختراقًا معروفًا كان وراء الإخفاق؛ بل توجه نتائج التحقيق إلى تغيير شبكي كشف خطأ كامنًا وفقدان السعة وما تبعه من مشكلات توجيه واتصال.
ويختلف هذا العطل تقنيًا عن حادث CrowdStrike في يوليو 2024، الذي ارتبط بتحديث معيب لبرنامج أمني أدى إلى انهيار أجهزة ويندوز. أما حادث نوفمبر 2026 فتمحور حول خدمات سحابية وعمليات الاتصال والتوجيه والتعافي في البنية التحتية للخدمة. ولا يوجد دليل على ارتباط مباشر بين الحادثين.
كذلك يجب عدم دمج عطل Microsoft 365 مع الحادثة المستقلة OO1550244 التي أصابت Word للويب بسبب تغيير في تجربة تحميل المحرر أوجد مشكلة توافق مع المتصفحات. فسجل الخدمة يصف لها سببًا مختلفًا، ولم تعلن مايكروسوفت أنها جزء من السبب نفسه.
الأسئلة التي تنتظر تقرير ما بعد الحادث
رغم وضوح المصدر العام للخلل، لم تنشر الشركة حتى وقت إعداد هذا التقرير تفسيرًا هندسيًا نهائيًا يجيب عن أسئلة أساسية: ما التغيير المحدد الذي أُدخل أثناء ترقية سعة الشبكة؟ ومتى نُفذت تلك الترقية؟ ولماذا لم تظهر المشكلة إلا بعد تغيير لاحق؟ وما اسم العملية المسؤولة عن إنشاء الاتصالات الآمنة، وما سبب اختناقها؟ وكيف ارتبطت بها فحوص السلامة ومشكلات التوجيه ومزامنة الإعدادات؟ وكم خادمًا أو مقدارًا من السعة فُقد بالفعل؟ وما الذي سمح بوصول الخلل الكامن إلى الإنتاج دون اكتشافه؟
ولم تتوافر كذلك حصيلة موثقة شاملة لعدد المستخدمين والمؤسسات المتضررة أو خسائرهم المباشرة، ولا دليل كافٍ يسمح بالقول إن رسائل البريد فُقدت بصورة دائمة. ولا يمكن استخدام حجم بلاغات مواقع رصد الأعطال بوصفه قياسًا لعدد الأشخاص المتأثرين فعليًا.
تُظهر المعطيات المؤكدة أن الخلل الأصلي وقع في ترقية سابقة لسعة الشبكة، ثم تفعّل إثر تغيير شبكي أحدث؛ وأن استعادة الخدمة تعقدت باختناق الاتصالات الآمنة، وخروج خوادم من الخدمة، وانتقال الضغط إلى البقية، وصعوبة تطبيق بعض تغييرات الإصلاح. أما السبب البرمجي الدقيق والتسلسل السببي الكامل فلا يزالان رهن التقرير الذي تعهدت مايكروسوفت بإصداره بعد انتهاء مراجعتها.
تحديث تحريري: يستند وصف حالة الخدمات إلى آخر تحديث مفصل في سجل الحادثتين عند الساعة 22:00 UTC من الجمعة 13 نوفمبر 2026، الموافق 02:00 صباح السبت 14 نوفمبر بتوقيت الإمارات. ويمكن متابعة المستجدات عبر لوحة حالة خدمات مايكروسوفت الرسمية.