يوم جيد ،٪ username٪!
في أي شركة كبيرة (وليس فقط في شركة كبيرة) ، يرغب الأشخاص في الوصول إلى معلومات الشركة (بريد العمل والتقويم والموارد الداخلية) في أي وقت وببساطة قدر الإمكان. تم إنشاء حلول منفصلة تسمى إدارة الأجهزة المحمولة لتوفير وإدارة عمليات الوصول هذه.
تاريخياً ، استخدمنا حلولاً مختلفة لإدارة الأجهزة المحمولة في شركتنا. في البداية كان حلًا مخصصًا لمصنع معين ، ثم انتقلنا إلى منتج آخر سمح لنا بدعم كل من أجهزة iOS و Android. في وقت لاحق ، تقرر التحول إلى حل من Microsoft.
مايكروسوفت intune
في وقت تحليل وظيفة الحل ، قدمت النسخة السحابية قائمة صغيرة إلى حد ما من الميزات ، لذلك تقرر استخدام Intune Hybrid.
ما هو Intune Hybrid؟
هذا هو مدير تكوين مركز النظام القديم الجيد ، والمتكامل مع Microsoft Intune. هذا الحل له خصائصه الخاصة:
- تتم إدارة جميع الأجهزة المحمولة من خلال SCCM.
- يتم إنشاء جميع سياسات وتكوينات الأمان وإدارتها من خلال SCCM.
بشكل عام ، أصبحت إدارة الأجهزة المحمولة لا تختلف عن إدارة محطات العمل. يتم استخدام الجزء السحابي فقط للاتصال بين الأجهزة و SCCM.
جنبا إلى جنب مع قرار التحول إلى MS Intune ، أصبح من الضروري نقل جميع المستخدمين إلى النظام الأساسي الجديد. للأسف ، لم يكن لدينا سوى 5 أشهر للترحيل و 28000 مستخدم حول العالم.
بالنسبة للمبتدئين ، تم استخدام أقل طريقة تدميرية للترحيل ونصح المستخدمون بإعادة تكوين الأجهزة للعمل مع الخدمة الجديدة.
توقف هذا النهج عن العمل في لحظة معينة ، وبدأ المستخدمون يضطرون إلى قطع الاتصال بالخدمة السابقة مع حظر متوازي للقدرة على تكوين الجهاز. هذا خلق صعوبات معينة وتحميل إضافي على خدمة سطح المكتب. يوضح الرسم البياني للحوادث المفتوحة على خدمة الأجهزة المحمولة بوضوح فترة الترحيل الأكثر نشاطًا.
لحسن الحظ ، كان الانتقال ناجحًا - في الوقت المحدد وبدون مشاكل غير متوقعة.
كيف هي الحياة على كوكب المريخ مع Microsoft Intune؟
أثناء الترحيل ، كان من الصعب جدًا على جميع فرق الدعم التكيف ، حيث كانت وظيفة إدارة الأجهزة المحمولة أوسع وأكثر ملاءمة من SCCM. ولكن بعد التضحية بقدر من الوظائف ، حصلنا على استقرار أكبر بكثير للخدمة وعدد أقل من الحوادث بشكل عام. للمقارنة ، مع الحل السابق لـ 28000 مستخدم ، كان لدينا حوالي 700 حادثة في الشهر ، ولكن الآن يتم الحفاظ على المستوى عند ± 350 حادثة.
مع إصدارات SCCM الجديدة ، تضيف Microsoft وظائف جديدة ، وآمل أن تستمر في الاستثمار في حل مختلط.
ما الجديد؟كما وفر الانتقال إلى المنتج الجديد ميزات جديدة للتحكم في الوصول ، حيث إن Intune ليست سوى جزء من خدمة Enterprise Mobility + Security. أهم الميزات وأكثرها إثارة للاهتمام بالنسبة لنا هي
الوصول المشروط وإدارة تطبيقات الهاتف المحمول .
الوصول المشروط هو سياسة التحكم في الوصول إلى الخدمة. لنفترض أن مستخدمًا واحدًا يريد الاتصال من هاتف شخصي ببرنامج Exchange Online. تتطلب سياسة الوصول أن جهازك يجب أن يقوم بتشغيل Microsoft Intune من أجل الوصول إلى EXO. إذا حاول هذا المستخدم تكوين صندوق البريد من خلال تطبيق البريد القياسي على نظام iOS ، فسوف يرى رسالة واحدة فقط: "يطلب المسؤول التحكم في الجهاز من خلال Microsoft Intune". وبالمثل ، يمكنك التحكم في الوصول إلى أي تطبيق مسجل في Azure AD.
إدارة تطبيقات الهاتف المحمول هي إدارة بيانات الشركة داخل التطبيق. هذا الإعداد هو الذي يحدد ما إذا كان من الممكن حفظ مستندات العمل في ذاكرة الهاتف ، ونسخها إلى تطبيقات الطرف الثالث ، وما إلى ذلك.
تتيح كلتا هاتين الوظيفتين تكوين مستخدم مرن وغير مؤلم لإعدادات الأمان.
الهجرة إلى Intune Standalone
بعد أن أصبحنا مهتمين بالحلول الجديدة من Microsoft ، وخاصة الإدارة المشتركة والطيار الآلي ، أدركنا أنه من الضروري التحول إلى حل قائم على السحابة بالكامل (ما يسمى Intune Standalone).
في وقت اتخاذ القرار ، كانت Microsoft قد نشرت بالفعل تعليمات خطوة بخطوة حول ترحيل المستخدمين من SCCM إلى Intune Standalone:
- تصدير التكوينات من SCCM واستيرادها إلى Intune.
- ترحيل مستخدمي الاختبار.
- هجرة جميع المستخدمين.
- تبديل سلطة MDM من SCCM إلى Intune.
في مرحلة التصدير / الاستيراد ،
تم استخدام حل من Microsoft نفسها . لسوء الحظ ، لم يتم الاستيراد بشكل جيد للغاية ، ولم يتم ترحيل تطبيقات محددة فقط من SCCM ، ولكن جميع أنواع النشر ، مما أدى إلى إنشاء تطبيقات منفصلة في Intune.
بدا شيء من هذا القبيل:
علاوة على ذلك ، لسبب ما ، لم يتم استيراد إصدار التطبيق بشكل صحيح ولهذا السبب ، كان من الضروري نشر جميع التطبيقات يدويًا. مع هذا التكوين والسياسات تم ترحيلها دون أي مشاكل.
اختبار ترحيل المجموعةفي البداية ، تألفت مجموعة الاختبار من زملائي وأنا. كنا نخشى أن يلاحظ المستخدمون أنهم يهاجرون. هذا يمكن أن يثير موجة من المكالمات لخدمة سطح المكتب. لكن الاختبار أظهر أنه في حالة عدم وجود اختلاف في التكوينات والتطبيقات المنشورة ، لا يلاحظ المستخدمون أي شيء.
ما هي آلية الهجرة؟ تمت إزالة المستخدم المطلوب من مجموعة SCCM ، التي تم استخدامها في إعدادات اشتراك Intune. تم ذلك من خلال مجموعة حصرية تم ربطها بدورها بمجموعة في Active Directory. وفقًا لذلك ، من أجل ترحيل المستخدم ، ما عليك سوى إضافته إلى المجموعة الإعلانية الضرورية.
ولكن بشكل غير متوقع ، كانت هناك مشاكل في توفير الوصول إلى مكتب الخدمة لإدارة الأجهزة التي تم ترحيلها. لقد أنشأت دورًا خاصًا لم يكن لديه سوى الحقوق اللازمة لمهامه. تم تعيين الدور للمجموعة الضرورية ، ولكن لم يظهر وصول بعض الأشخاص. تم فحص تراخيص المحللين وحساباتهم ، ولكن دون جدوى. أظهر التحقق من الأدوار الفعالة من خلال واجهة برمجة التطبيقات للرسم البياني وجود دور ، ولكن لا يزال الشخص غير قادر على الوصول. بعد تحقيق مطول ، مع دعم Microsoft ، تم اكتشاف أن هناك حاجة إلى ترخيص (Intune في EMS E3 أو EMS E5) للمحللين. وكذلك ، يحتاج المحللون بدورهم إلى الهجرة إلى Intune Standalone. لم يتم توثيق الحاجة واستغرق حلها بضعة أسابيع.
في الوقت نفسه ، جذبت مجموعة من ممثلي المبيعات من دولة أوروبية إلى الهجرة ، والذين يستخدمون خدمة VPN بنشاط في عملهم اليومي ويعملون في كل من الترحيل نفسه
والخادم الذي تم تكوينه بشكل منفصل لـ Intune Standalone
NDES . في هذه الخطوة ، تم إلغاء الترحيل تقريبًا مع عودة جميع المستخدمين مرة أخرى.
لكي يتمكن المستخدم من استخدام خدمة VPN ، يتم تسليمها باستخدام ملف تعريف يقوم بتكوين عميل VPN باستخدام شهادة SCEP المحددة ، والتي تشير إلى Root CA. وبناءً على ذلك ، يجب أن يكون هناك زوج من الشهادات للعمل.
كان لدينا شهادة واحدة فقط (المرجع المصدق الجذر).
أبسط شيء هو افتراض أن المشكلة تكمن في خادم NDES. لكنها عملت بشكل مثالي ولم تتلق حتى طلبات للحصول على شهادات. عند فحص السجلات من الأجهزة نفسها ، اكتشفت أن الجهاز لم يتلق حتى الإعدادات اللازمة لطلب شهادة SCEP. قامت Microsoft بتصعيد هذه المشكلة إلى مطوري Intune الذين اكتشفوا أهمية ليس فقط الحصول على جميع الشهادات ، ولكن أيضًا الحاجة إلى تسليم جميع الشهادات والإعدادات إلى نفس مجموعات المستخدمين والأجهزة. في حالتنا ، تم تسليم Root CA إلى جميع الأجهزة ، و SCEP فقط إلى بعض الأجهزة.
وهكذا ، بدأنا في الترحيل من 1000 إلى 4000 مستخدم في موجة واحدة. استغرقت العملية 4 أسابيع. كنا مستعدين لأي شيء (نعلم جميعًا أنه نادرًا ما يسير كل شيء وفقًا للخطة). لكن كل شيء سار بسلاسة دون زيادة كبيرة في المكالمات إلى خدمة سطح المكتب.
الأجهزة القديمة
وفقًا لمعاييرنا ، نسعى جاهدين للحصول على الحد الأدنى من إصدارات نظام تشغيل الهاتف المحمول:
· T-1 لنظام التشغيل iOS.
· T-2 لنظام Android.
* T هو أحدث إصدار في الوقت الحالي.
إلى حد أقل ، ينطبق هذا على iOS ، مثل دعمت Apple أجهزتها منذ فترة طويلة. هذا صحيح أكثر بالنسبة لأجهزة Android. على سبيل المثال ، لا يزال الأشخاص يستخدمون Android 4.4.2 على الأجهزة التي يزيد عمرها عن 4 سنوات.
في هذه الحالة ، نجري حوارًا مع فريق تكنولوجيا المعلومات المحلي لتحديد توقيت استبدال الأجهزة ، حيث من الضروري إيجاد توازن بين الأمان والأموال التي تنفق على تحديثها.
ما هي الخطوة التالية؟
أدى تغيير القرار إلى تغييرات داخلية. على سبيل المثال ، كانت هناك برامج نصية لتنظيف SCCM من أجهزة قديمة مكتوبة في PowerShell ، والتي لا يمكن استخدامها الآن. في جميع حلولها الجديدة ، تقوم Microsoft بالترويج لواجهة برمجة التطبيقات API ، والتي يجب إتقانها.
تم إنشاء التقارير حتى وقت قريب على أساس SSRS ، والآن سنستخدم Power BI + oData Feed مع البيانات من Intune Data Warehouse.
ذكرت سابقًا الوصول الشرطي وإدارة تطبيقات الهاتف المحمول. تم تنفيذ الحل الأول بالفعل ، ونحن الآن نعمل على الحل الثاني. نقوم أيضًا باختبار Azure Application Proxy كبديل لـ VPN على الأجهزة المحمولة. إذا كانت مثيرة للاهتمام ، سأخبرها بكل سرور في مقالات جديدة.