ConfigMgr خلال ربع قرن

كتبت في آخر الأسبوع الماضي عن المرحلة الرئيسية في تاريخ ConfigMgr الذي مر على إصداره ربع قرن، وأردت اليوم أن أتعمق أكثر في قصة هذا المنتج المذهل، وأشاركم إعلاناً هاماً، وأكشف لكم عن مقطع فيديو وثائقي جديد رائع(شاهد lookout Sundance!) الذي يقدم نظرة عميقة في نشأة وتطور المنتج الذي أدى إلى ظهور صناعة إدارة أجهزة الكمبيوتر الشخصي.

التالي، إعلان ConfigMgr:

وفي خضم هذا الإنجاز الحالي، أقدم لكم قصة ربما لم تسمعوا عنها من قبل:

كيف بدأ كل هذا

في آخر الأسبوع الماضي، انتهزت الفرصة لكي أقرأ مرة ثانية المستند الأصلي الخاص برؤية أو «مواصفات» Project Hermes. لم أرَ هذا المستند منذ سنوات، وكان شيئاً مدهشاً أن ترى كيف أن ConfigMgr حافظ حقاً على رؤيته الأصلية طوال هذه المدة. فلا تزال المقومات الأساسية التي تم إرساؤها في ذلك المستند تُستخدم اليوم وتُعد بمثابة ركيزة في تكوينه.

في عام1992، كانت المهمة الأصلية لمؤسسة Microsoft (وهي وجود جهاز كمبيوتر في كل منزل وعلى كل مكتب) قد وصلت إلى النجاح المطلوب. كانت المؤسسات تنتقل بشكل سريع من استخدام المحاكاة الطرفية إلى نموذج الحوسبة الموزعة x86، ولم يكن هناك أي سبيل لإدارة أجهزة الكمبيوتر على نطاق واسع. أدرك الفريق أن Project Hermes يجب أن يحدِث تأثيراً كبيراً.

كان الفريق الأصلي الذي عمل في SMS يتكون من مطورين يعملون بدوام كامل ومعهما متدرب اسمه كين بان.  عندما انضممت للفريق عام 2003، كان كين المتدرب يقود فريق المطورين بالكامل والذي كان يتكون من 150 مهندساً تقريباً. ولا يزال كين يقود الجهود الهندسية في SCCM وIntune بالنيابة عني منذ ذلك الوقت!

حقيقة طريفة:  حمل أول إصدار من Systems Management Server (SMS) رقم 245. لماذا لم يكن رقم 1؟ حسناً… أصدرت Windows في ذلك الوقت الإصدار رقم 300، ولم يرد الفريق أن يبدو متأخراً عن إصدار Windows – ولكنهم أدركوا أيضاً أن اختيار رقم قريب من 300 قد يثير الشك. لذلك اختاروا 245!

انطلق SMS رسمياً في 7 نوفمبر 1994. استغرق الإصدار الأول ما يزيد عن عامين – وها نحن اليوم نصدر إصدارات Insider جديدة كل شهر!

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

إذا رغبت في قراءة رسالة البريد تلك، يمكنك الرجوع إليها أسفل هذا المنشور.

دفع التصميم للأمام

تم إطلاق إصدارات 1.0 و1.1 و1.2 من SMS سريعاً، ونشأ سوق جديد تبعاً لذلك. وعملاً بمبدأ الطرق على الحديد وهو ساخن، بدأ فريق العمل على إصدار 2.0 من SMS.

وهنا بدأت الأمور… تتعقد.

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

طرأت تغييرات كثيرة على التصميم الخاص بكيفية بناء تطبيقات العميل-الخادم منذ 1992، حيث أعاد الفريق كتابة البنية الأساسية لخادم SMS من جديد في عامي 1997 و1998 لدفع مقياس أداء SMS للأمام، كما دمجوا تلك الجهود مع الإمكانات المستقبلية في خادم Windows 2000. كانت هذه هي المرة الأولى التي تمت فيها إعادة كتابة تصميم SMS لضمان أنه إصدار فريد من نوعه في ذلك الحين.

تم إصدار SMS 2.0 في يناير 1999، وشاع استخدامه سريعاً. في ذلك الوقت، كنت أعمل لدى Novell، أكبر منافس لـ SMS، كرئيس للفريق المسئول عن مجموعة Novell ZENworks. لا تسعفني الذاكرة لأتذكر عدد الساعات التي قضيتها مجتمعاً مع عملاء SMS متحدثاً معهم حول أن الاختلافات الجوهرية في ZENworks هي أنها مستندة إلى التركيز على العملاء (الهويات) مع ضمان تكامل الدليل!

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

نعم، إنه تيري مايرسون – رئيسي بالعمل ونائب الرئيس التنفيذي لدى Microsoft. أعتقد أن كل العظماء قد مروا على SMS خلال فترة معينة في مسيرتهم المهنية  (:

عندما انضممت إلى فريق SMS كانوا يكثفون الجهود للوصول إلى مضمون إصدار SMS لعام 2003.

ومرة أخرى، تمت إعادة كتابة أجزاء كثيرة في إصدار SMS 2003. تعتبر محاذاة SMS على WSUS للتحديث الجزئي إنجازاً هائلاً في ذلك الوقت. فقد أدى ذلك إلى محاذاة التحديث الجزئي من Microsoft من السحابة (Windows Update) إلى الأفراد والمؤسسات. وتستخدم WSUS نفس وحدات البت المستخدمة في Windows Update – فيما عدا تشغيل مركز البيانات.

ويُعد Windows Update أحد أكبر خدمات السحابة في العالم – حيث يقوم بتحديث أكثر من مليار جهاز كل شهر. فكر في هذا الأمر لدقيقة واحدة:  واحدة من العوامل الهامة التي تميز Microsoft فيما يخص خدمات السحابة العامة اليوم هي امتلاكنا لإمكانات متنوعة والقدرة على تشغيل سحابتنا العامة في مركز البيانات الخاص بك. كان تشغيل Windows Update في مركز بياناتك (عبر WSUS) خطوة غير مسبوقة وربما كانت بمثابة أول دليل على كوننا متنوعين ومتصلين بالسحابة. وتزامن مع ذلك تزايد استخدام الكمبيوتر المحمول بشكل ملحوظ، فتطلب ذلك منا إنشاء جهاز عميل جديد يعمل بنموذج وضع عدم الاتصال أو في وضع الاتصال غير المنتظم.

وعندما اقترب موعد إصدار SMS 2003، كنا نجتمع صباح يوم الجمعة من كل أسبوع مع مجموعة مكونة من ممثلي أقسام الشركة لتقييم حالة المشروع. وكان قسم تكنولوجيا المعلومات (MSIT) في Microsoft من أبرز المجموعات المدعوة لحضور الاجتماع. وفي خطوة غير مسبوقة في الشركة، منحت فريق تكنولوجيا المعلومات صلاحية مفتوحة في اتخاذ قرار تنزيل SMS 2003 في السوق، إذا رأوا أنه غير جاهز بعد. ومنذ ذلك الحين، كان فريق تكنولوجيا المعلومات في Microsoft أول وأفضل عميل لدينا – وأيضاً أحد أفضل مصادرنا للحصول على ملاحظات على الإصدارات الأولى.

وها نحن اليوم في Microsoft ندير أكثر من 500,000 جهاز كمبيوتر وجهاز محمول (هذا الرقم لا يدخل ضمن إصدارات MAD التي وصلت 100 مليار) باستخدام أداة نشر ConfigMgr واحدة فقط. ونقوم باستمرار بنشر وحدات بت جديدة عبر إصدارات Microsoft في كل إصدار شهري. نحن بالتأكيد نستخدم ما صنعته أيدينا. وهذه حقيقة طريفة أخرى:  يتولى فريقي مهمة الإشراف على النشر الداخلي لـ ConfigMgr. ومن المعروف أن أفضل طريقة للتعلم هي أن تفعل الشيء بنفسك.

أصدرنا بين عام 2003 و2007 إصدارين من «حزم الميزات». لم نرغب في الانتظار طويلاً حتى نصدر منتج جديد بالكامل يقدم وظيفة جديدة، لذلك ابتكرنا طريقة جديدة لإصدار الإمكانات. تم إنجاز العمل على المحاذاة في WSUS للتحديث الجزئي لدينا باستخدام حزمة الميزات الأولى. وجاءت حزمة الميزات الثانية عندما أصدرنا نشر OS.

وتلوح في ذهني الآن واحدة من أفضل ذكرياتي عن هذه الفترة حيث أعددنا عرضاً توضيحياً لحدث جرى في نوفمبر 2003 في أوروبا لعرض إمكانات نشر OS الجديدة. كان بيل غيتس يلقي الكلمة الرئيسية، وأثناء حديثه عن «أحدث الميزات في SMS»، قمنا بترقية 100 جهاز كمبيوتر على الهواء مباشرةً على حائط خلف بيل غيتس. وأطلقنا على هذا العرض التوضيحي «حائط النار».

هذه صورة التقطناها لبيل غيتس عندما أدار وجهه ليرى تنفيذ العرض التوضيحي:

هذه صورة لأعضاء فريق SMS الشجعان الذين نفذوا العرض التوضيحي على المسرح:

إحداث تأثير ملموس

في خريف 2004، استضاف بيل غيتس وستيف جوبز اجتماعاً خارجياً مع عدد قليل من القادة المتمرسين من أقسام الشركة المختلفة – وكانت الجلسة الأخيرة في اليوم عبارة عن فقرة أسئلة وأجوبة مفتوحة مع بيل وستيف.  سأل أحدهم بيل ما هو «أهم شيء حدث في Microsoft خلال العام الماضي» في رأيه. أجاب بيل: «صممنا SMS وActive Directory تصميماً صحيحاً منذ البداية – وسيكونا بمثابة أصول هائلة لنا في مسيرتنا نحو التطور».

كان ذلك اليوم أحد أفضل أيام حياتي المهنية حتى يومنا هذا!

وفي عام 2007، غيرنا الاسم من «SMS» إلى «ConfigMgr»، لكي يكون متسقاً مع شعار مركز النظام. احتلت ميزة Desired State Configuration (DSC) مكانة كأحدث السيناريوهات المطلوبة من العملاء وأكثرها ابتكاراً، لذلك طورنا التصميم مرة ثانية ليتيح لـ DSC أن يعمل بالطريقة المطلوبة. كما أعدنا كتابة التجربة الإدارية بالكامل.

في فبراير 2011، بينما بلغت مسيرة العمل الهندسي في SCCM 2012 منتصف الطريق، تولى ساتيا إدارة Server and Tools Business (STB)، وأعاد تسميته ليصبح Cloud and Enterprise (C+E)، ويصبح ساتيا مديري. في اجتماعنا المباشر وجهاً لوجه، جاء ساتيا إلى مكتبي وقضى معظم الوقت في التعرف على شخصيتي بشكل أفضل. لقد كان العمل مع ساتيا مباشرةً على مدار سنوات والتعلم من شخصيته الرائعة المحبة للاستطلاع، وعقليته المتفتحة وأسلوبه المتواضع في الإدارة تجربة ليس لها مثيل. أثر ساتيا في مستقبل وتصميم ConfigMgr أثناء ذلك الإصدار تأثيراً عظيماً.

في ConfigMgr 2012، غيرنا التصميم تغييراً جذرياً حيث جعلنا التصميم والتجربة يتمحوران حول العملاء – وليست الأجهزة فقط.

استشفينا من العملاء أن سهولة التنقل ستصبح السمة الرئيسية في المستقبل، وأدركنا أن سهولة التنقل لا تقتصر على الأجهزة وحسب – وإنما سهولة تنقل البشر أيضاً.  واستجابةً لهذه المعلومات، بسطنا التصميم لأقصى درجة ليعمل بأقل مساحة جهاز، وزودنا حدود نطاقه لأبعد مدى. هذه بالتحديد هي النقطة التي أصبحت فيها رحلتنا جادة حقاً، حيث قمنا بتوصيل ConfigMgr مع Microsoft Intune، وأصبح Intune هو السمة المميزة لـ ConfigMgr.

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

توجه ConfigMgr نحو السحابة

كان تطور التصميم التالي هو الأكثر تحدياً على الإطلاق.

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

التحدي هنا كان مهولاً.

فلو تتبعنا التسلسل التاريخي، نجد أن ConfigMgr تم إصداره خلال 2-3 سنوات. أتذكر عندما كنت أنظر لأول خطة نهائية لأجل SCCM 2007 وأنا أرى 16 شهراً من الاستقرار وإنشاء نموذج مبدئي في الفترة بين الوقت الذي أعلنا فيه اكتمال التعليمات البرمجية والإصدار. 16 شهراً!   كان من الواضح أننا نحتاج إلى «تعميم SaaS» على ConfigMgr وبذلك نتمكن من الاستمرار في الإصدار عدة مرات على مدار العام.

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

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

النتيجة، الآن، واضحة:  فاق الإنجاز الذي قام به هذا الفريق الهندسي المُتسم بقوة التركيز كل مقاييس الأداء وأطلقوا نهجاً جديداً قائماً على السحابة لإدارة أجهزة الكمبيوتر وهو ما أتاح لنا الانتقال إلى مرحلة الإصدار الشهري. لتتبع هذه التحديثات، تخلصنا من أرقام الإصدارات التقليدية (مثل 2003، 2007، 2012) وبدءوا الاسم باصطلاح سنة/شهر، وبذلك كان أول إصدار يحمل رقم 1511 لأننا أصدرناه في شهر ¹¹ من عام 2015.

ومنذ ذلك الحين، أصبحنا نصدر نسخاً جديدة من ConfigMgr تابعة لـ Insider كل شهر، وكذلك نصدر CurrentBranch رئيسي كل أربعة أشهر تقريباً.

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

كانت استجابة العميل لهذا النموذج القائم على السحابة مدهشة.

إلق نظرة على هذا الرسم البياني:

تمت بالفعل ترقية أكثر من نصف قاعدة ConfigMgr لنموذج current branch الجديد، وتتم الآن إدارةأكثر من 100 مليون جهاز بشكل نشط ويمكن إعادة إرسال بيانات تتبع الاستخدام.

100 مليون، يا للعجب!!!!

على حد علمي، هناك 3 خدمات مؤسسية فقط في العالم لديها أكثر من 100 مليون مستخدم أو جهاز نشط شهرياً خاضعين للإدارة ويتمتعون بخاصية إعادة إرسال بيانات تتبع الاستخدام:  Office 365 وAzure Active Directory وConfigMgr. ما العامل المشترك بين هؤلاء الثلاثة؟  جميعهم جزء من عرض Microsoft 365 المتكامل.

يوضح هذا المخطط مقدار استخدام الإصدارات الرئيسية من ConfigMgr Current Branch منذ إصدار 1511. لدينا لوحة معلومات تبين لنا البيانات في التوقيت الحقيقي، ونرسل هذا المخطط إلى فريقنا بالكامل صباح كل أحد الساعة 8:30.

صدقوني عندما أخبركم أن صباحات يوم الأحد الساعة 8:30 هي أفضل اللحظات بالنسبة لي كل أسبوع.

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

والآن يحظى Project Hermes بقدر من الاهتمام والحماسة أكثر من أي وقت مضى.

ما التالي؟

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

ومنذ 1511، أصبحت وتيرة الابتكار في تسارع مستمر. فالمؤسسات تنتقل سريعاً إلى عالم خدمات السحابة المتصلة بأجهزة المحمول، ولكي نلبي احتياجاتك في ظل هذه البيئة السريعة، خضعت البنية الأساسية لـ ConfigMgr لإجراءات كبيرة لتصبح خدمة سحابة حقيقية. أصبح الآن خدمة يتم تحديثها بإمكانات جديدة باستمرار، كما إنه يستخدم إمكانات الذكاء الاصطناعي المتوفرة في السحابة ليلائم احتياجاتك وليقدم لك الحماية المطلوبة، كما يتوفر كخدمة قائمة على السحابة قادرة على احتواء حتى 100 مليون جهاز حول العالم.

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

يُعد هذا بمثابة التطور التالي لكل منتجات Microsoft التي تستخدمها منذ سنوات – Windows وOffice وActive Directory وConfigMgr – وقد نقلناها جميعاً إلى السحابة في Microsoft 365.  يتحول المستخدمين بالمؤسسات حول العالم إلى السحابة (باستخدام Windows 10 as-aService، وOffice 365 وخدمات EMS) وهذا هو التطور التطبيعي لتصميم ConfigMgr.

يبدأ كل كيان وكل مؤسسة تجارية على هذا الكوكب من نموذج محلي اليوم حيث يستخدمون Active Directory وGroup Policy وConfigMgr كأدوات للإدارة. زادت الرغبة في التحول إلى العمل باستخدام نموذج أبسط وأحدث، لكن الوصول إلى هذا النموذج الحديث الجديد لم يكن سهلاً. لا يمكن لأي مؤسسة أن تحول المستخدمين/الأجهزة من AD/GP/ConfigMgr إلى AAD/Intune. ما تحتاجه منا هو جسر يجعل هذا التحول أبسط وأسرع ويزيل المخاطر. هنا تعلمنا الكثير من مشاهدة المؤسسات تتحول من on-prem Exchange إلى Exchange Online.

اليوم، نحن متحمسون للإعلان عن الإدارة المشتركة، وهي مجموعة جديدة من الإمكانات وتعتبر جسراً يساعد في تسريع الانتقال إلى الإدارة الحديثة من السحابة. باستخدام Fall Creators Update، يمكن للجهاز الذي يعمل بنظام التشغيل Windows 10 الانضمام إلى الإصدار المحلي من Active Directory (AD) وAzure AD في نفس الوقت.

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

لقد سهلنا العمل في وحدة تحكم ConfigMgr لأخذ الأجهزة الموجودة ضمن الإدارة وتسجيلها في الإدارة باستخدام Intune. يمكنك بعد ذلك تحديد مقدار حمل العمل الأول الذي تريد نقله إلى السحابة (وهو حرفياً عبارة عن شريط تمرير تنقله من ConfigMgr إلى Intune) ويتم بذلك نقل حمل العمل هذا إلى السحابة.

إحدى الإمكانات الفريدة لـ Microsoft 365 في هذا السيناريو الذي تتم إدارته بشكل مشترك هي أن ConfigMgr وIntune في اتصال مستمر. عند نقل حمل الأعمال، نفهم من هو المصدر الموثوق (Intune أو ConfigMgr) لكل سمة على المستخدمين والأجهزة – وهذا لتجنب تطبيق نُهج متعارضة.

وسيؤدي هذا إلى تسريع الانتقال إلى نظام التشغيل Windows 10 والإدارة الحديثة عبر السحابة.

* * * * *

الكتابة في هذا الموضوع كانت بمثابة جولة في ممرات الذاكرة. أثر كل من SMS/ConfigMgr/Intune تأثيراً عميقاً على حياتي، وحياة أسرتي، وحياة 1000 مهندس عملوا في هذه المشروعات، وأيضاً حياة الملايين من محترفي تكنولوجيا المعلومات الذين استخدموها ولا يزالون يستخدمونها اليوم. أنا أحب هذا المنتج وأحب هذا المجتمع.

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

إذا كنت ضمن أعضاء Ignite، فزر قسم الإدارة والأمان في مقصورة Microsoft وأخبرنا قصتك. يوجد هنا توجيهات بسيطة.

إذا لم تكن مشتركاً في Ignite، لا يزال الأمر سهلاً. أحكِ لنا قصتك من خلال تحميل ذكرياتك وقصصك حول ConfigMgr هنا aka.ms/ConfigMgr25. هذه بعض الإرشادات الأساسية.

سنستخدم هذه المراسلات لإنشاء الجزء الثاني – مقطع فيديو بعنوان:

«تاريخ الأشخاص مع ConfigMgr»

لا أستطيع الانتظار لرؤية هذا.

_______________________________________________