ConfigMgr ที่ 25 ปี
ช่วงปลายสัปดาห์ที่แล้ว ผมเขียนเกี่ยวกับความสำเร็จในช่วง 25 ปี ของ ConfigMgr และวันนี้ ผมอยากเจาะลึกเกี่ยวกับเรื่องราวที่มาของผลิตภัณฑ์อันน่าทึ่งนี้ ประกาศสองสามเรื่อง และเปิดตัวสารคดีใหม่ที่น่าตื่นตาตื่นใจ (ระวังไว้ ซันแดนซ์!) ซึ่งแสดงมุมมองเจาะลึกของที่มาและการเติบโตของผลิตภัณฑ์ที่เป็นจุดเริ่มต้นของอุตสาหกรรมการจัดการพีซี
ต่อไปนี้คือการประกาศ ConfigMgr:
จากความสำเร็จในทุกวันนี้ ต่อไปนี้คือเรื่องราวที่คุณอาจไม่เคยได้ยินมาก่อน:
เรื่องราวเริ่มต้นมาอย่างไร
ปลายสัปดาห์ที่แล้ว ผมได้มีโอกาสอ่านเอกสารวิสัยทัศน์หรือ “ข้อมูลจำเพาะ” ของ Project Hermes ฉบับดั้งเดิมซ้ำอีกครั้ง ผมไม่ได้เห็นเอกสารฉบับนี้มาหลายปีแล้ว และผมรู้สึกทึ่งที่ได้เห็นว่า ConfigMgr ยังคงยึดหลักวิสัยทัศน์เดิมเอาไว้ได้อย่างไร ส่วนพื้นฐานที่อธิบายอยู่ในเอกสารฉบับดังกล่าวยังคงใช้งานในทุกวันนี้ และยังคงเป็นส่วนหนึ่งของรากฐานอีกด้วย
ในปี 1992 ภารกิจดั้งเดิมของ Microsoft (ซึ่งก็คือ ทุกบ้านและทุกโต๊ะทำงานต้องมีพีซี) เป็นเพียงจุดเริ่มต้นเล็กๆ เท่านั้น องค์กรเปลี่ยนจากการจำลองเทอร์มินัลไปใช้โมเดลการคำนวณแบบกระจาย x86 และในตอนนั้น ก็ยังไม่มีโซลูชันสำหรับจัดการพีซีในสเกลดังกล่าว ทีมทราบว่า Project Hermes จะต้องสร้างการเปลี่ยนแปลงได้
ทีม SMS รุ่นดั้งเดิมมีนักพัฒนาเต็มเวลาเพียงสองคนและเด็กฝึกงานที่ชื่อ Ken Pan เท่านั้น เมื่อผมเข้าร่วมกับทีมในปี 2003 Ken เด็กฝึกงานได้กลายเป็นผู้นำทีมนักพัฒนาที่มีวิศวกรเป็นลูกน้องประมาณ 150 คน Ken นำทีมทำงานด้านวิศวกรรมเกี่ยวกับ SCCM และ Intune และนำผมมาตั้งแต่ตอนนั้น!
เรื่องน่ารู้: Systems Management Server (SMS) รุ่นแรกสุดคือ 245 ทำไมถึงไม่ใช่ 1 ล่ะ ก็เพราะ… ตอนนั้น Windows เป็นรุ่น 300 และทีมไม่อยากให้เลขดูตามหลังจนเกินไป แต่ก็ทราบดีว่าการเลือกตัวเลขใกล้ 300 เกินไปจะทำให้ดูน่าสงสัย พวกเขาจึงเลือก 245!
SMS เปิดตัวอย่างเป็นทางการครั้งแรกเมื่อวันที่ 7 พฤศจิกายน 1994 รุ่นแรกมีการใช้งานนานกว่าสองปี ส่วนทุกวันนี้เราปล่อย Insider รุ่นใหม่ๆ ทุกเดือน!
เหตุการณ์ครั้งยิ่งใหญ่ตั้งแต่การเปิดตัวครั้งนั้นคือ Bill Gates ส่งอีเมลถึงพนักงาน Microsoft ทุกคนเพื่ออธิบายว่าเราปรับใช้ SMS ทั่วทั้งบริษัทแล้ว ด้วยความเป็นวิศวกร Bill ได้ชี้แจงในอีเมลนั้นถึงวิธีการลบซอฟต์แวร์ SMS ออกจากเครื่อง หากคุณต้องการ (:
ถ้าคุณต้องการอ่านอีเมลฉบับดังกล่าว ผมได้แนบไว้ที่ด้านล่างของโพสต์นี้เรียบร้อยแล้ว
การผลักดันสถาปัตยกรรมให้ก้าวไปข้างหน้า
SMS 1.0, 1.1 และ 1.2 ปล่อยออกมาอย่างรวดเร็ว และตลาดใหม่ก็เกิดขึ้นตามลำดับ ทีมเริ่มต้นทำงานพัฒนา SMS 2.0 อย่างไม่รอช้า
นั่นคือจุดที่สิ่งต่างๆ เริ่ม…ซับซ้อน
และด้วยความสัตย์จริง เราตัดสินใจบางเรื่องได้แย่มาก ส่วนสำคัญของกรอบความคิดแบบเติบโตคือความสามารถในการเรียนรู้อย่างรวดเร็ว นี่คือหลักการของทีม SMS ตั้งแต่ช่วงเริ่มต้น
สถาปัตยกรรมการสร้างแอปพลิเคชันไคลเอ็นต์-เซิร์ฟเวอร์ได้เปลี่ยนแปลงไปอย่างมากตั้งแต่ปี 1992 ทำให้ทีมจำเป็นต้องเขียนโครงสร้างพื้นฐานของเซิร์ฟเวอร์ SMS ขึ้นใหม่ในปี 1997 และ 1998 เพื่อขยายขนาดและประสิทธิภาพของ SMS และพวกเขาได้ผสานรวมกับความสามารถที่กำลังจะมาถึงในตอนนั้นของ Windows Server 2000 นี่เป็นครั้งแรกที่สถาปัตยกรรม SMS ถูกเขียนขึ้นใหม่เพื่อให้มั่นใจว่าจะเป็นสถาปัตยกรรมที่ล้ำสมัยในยุคนั้น
SMS 2.0 ปล่อยออกมาในเดือนมกราคม 1999 และการเริ่มนำไปใช้และการใช้งานก็เพิ่มขึ้นอย่างรวดเร็ว ในตอนนี้ ผมยังทำงานกับ Novell คู่แข่งรายใหญ่ที่สุดของ SMS โดยผมเป็นผู้นำทีม Novell ZENworks นับไม่ได้เลยว่าผมต้องเสียเวลากี่ชั่วโมงไปกับการพูดคุยกับลูกค้า SMS เกี่ยวกับตัวสร้างความแตกต่างของ ZENworks ที่มุ่งเน้นไปที่ผู้ใช้ (ข้อมูลประจำตัว) กับการผสานรวมไดเรกทอรีอย่างล้ำลึก!
ระหว่างที่ผมกำลังเขียนโพสต์นี้ ผมก็นึกขึ้นได้ว่า SMS 2.0 มีไข่อีสเตอร์อยู่ด้วย ไข่อีสเตอร์คือวิดีโอที่แสดงชื่อและรูปภาพของผู้คนที่ทำงานพัฒนาผลิตภัณฑ์ และเมื่อผมนำวิดีโอดังกล่าวกลับมาดูอีกครั้งในสัปดาห์นี้ ผมก็เห็นชื่อหนึ่งเด่นขึ้นมา:
ใช่แล้ว Terry Myerson เจ้านายของผมและรองประธานกรรมการบริหารของ Microsoft ผมเดาว่าบุคคลที่ยอดเยี่ยมทั้งหลายล้วนเคยทำงานกับ SMS ในช่วงใดช่วงหนึ่งของเส้นทางอาชีพ (:
ผมเข้าร่วมทีม SMS ในช่วงกำลังพัฒนาสิ่งที่จะกลายเป็น SMS 2003
ใน SMS 2003 มีหลายส่วนของผลิตภัณฑ์ที่เขียนขึ้นใหม่ อีกครั้ง ความสำเร็จครั้งใหญ่ในตอนนั้นคือการจัดให้ SMS อยู่บน WSUS เพื่อแก้ไข ซึ่งเป็นการจัดการแก้ไขของ Microsoft จากระบบคลาวด์ (Windows Update) ไปยังผู้บริโภคและองค์กร โดยพื้นฐานแล้ว WSUS เป็นตัวเดียวกันกับที่ใช้สำหรับ Windows Update เว้นแต่ว่าทำงานในศูนย์ข้อมูลของคุณ
Windows Update คือหนึ่งในบริการบนระบบคลาวด์ที่ใหญ่ที่สุดในโลก ซึ่งมีการอัปเดตอุปกรณ์มากกว่า 1 พันล้านเครื่องต่อเดือน ใช้เวลาคิดเกี่ยวกับเรื่องนี้สักครู่: หนึ่งในตัวสร้างความแตกต่างหลักในระบบคลาวด์สาธารณะของ Microsoft ในทุกวันนี้คือความสามารถแบบไฮบริดและความสามารถของคุณในการเรียกใช้ระบบคลาวด์สาธารณะในศูนย์ข้อมูลของคุณ การเรียกใช้ Windows Update ในศูนย์ข้อมูลของคุณ (WSUS) เป็นการบุกเบิกอย่างแท้จริงและเป็นตัวอย่างแรกๆ ของการเชื่อมต่อกับระบบคลาวด์แบบไฮบริด ช่วงเวลาดังกล่าวยังเป็นช่วงที่มีการใช้งานแล็ปท็อปเพิ่มขึ้นอย่างมาก และเราต้องสร้างไคลเอ็นต์แบบใหม่ที่รองรับการทำงานในโมเดลแบบออฟไลน์หรือเชื่อมต่ออย่างหละหลวม
ในช่วงที่เราใกล้จะเปิดตัว SMS 2003 เราจะประชุมกับกลุ่มจากทั่วทั้งบริษัททุกเช้าวันศุกร์เพื่อประเมินสถานะของโครงการ หนึ่งในกลุ่มหลักที่ได้รับเชิญให้เข้าร่วมการประชุมก็คือแผนก IT ของ Microsoft (MSIT) เนื่องจากเป็นการเปลี่ยนแปลงที่ไม่เคยเกิดขึ้นมาก่อนในบริษัท ผมจึงมอบสิทธิ์ให้ทีม IT สามารถปฏิเสธการตัดสินใจเผยแพร่ SMS 2003 ได้ ถ้าพวกเขารู้สึกว่ายังไม่พร้อม ตั้งแต่ตอนนั้น MSIT ก็กลายเป็นลูกค้ารายแรกและลูกค้าที่ดีที่สุดของเรา และยังเป็นหนึ่งในแหล่งคำติชมที่ดีที่สุดของรุ่นแรกๆ อีกด้วย
วันนี้ เราจัดการพีซีและอุปกรณ์เคลื่อนที่มากกว่า 500,000 เครื่องที่ Microsoft (ตัวเลขนี้ยังไม่รวม MAD 100 ล้านเครื่อง) ผ่านการปรับใช้ ConfigMgr เพียงครั้งเดียว เรายังคงปรับใช้ข้อมูลใหม่ๆ ทั่วทั้ง Microsoft อย่างต่อเนื่อง เมื่อเราสร้างรุ่นรายเดือนแต่ละรุ่น แน่นอนว่าเราทดลองใช้ผลิตภัณฑ์ของเราเอง เรื่องน่ารู้อีกเรื่องหนึ่ง: ทีมของผมคอยตรวจตราการปรับใช้ ConfigMgr ภายในจริงๆ ไม่มีวิธีเรียนรู้ใดที่จะดีไปกว่าการลงมือทำ!
ระหว่างปี 2003 และ 2007 เราปล่อย “ชุดรวบรวมคุณลักษณะ” สองชุด เราไม่ต้องการรอให้ผลิตภัณฑ์ใหม่พร้อมสำหรับการมอบฟังก์ชันใหม่ เราจึงคิดค้นวิธีใหม่เพื่อปล่อยความสามารถเหล่านี้ ชุดรวบรวมคุณลักษณะชุดแรกจบลงที่การจัดให้ตัวงานอยู่บน WSUS เพื่อการปะซ่อมของเรา ชุดรวบรวมคุณลักษณะชุดที่สองเกิดขึ้นเมื่อเราเผยแพร่การปรับใช้ OS
หนึ่งในเหตุการณ์ที่น่าจดจำมากที่สุดสำหรับผมคือตอนที่เราสาธิตตัวอย่างที่งานกิจกรรมในยุโรปในเดือนพฤศจิกายน 2003 เพื่อแสดงความสามารถการปรับใช้ OS ใหม่ ตอนนั้น Bill Gates กำลังแสดงปาฐกถานำ และระหว่างหัวข้อ “มีอะไรใหม่ใน SMS” เราได้อัปเกรดพีซี 100 เครื่องบนผนังด้านหลัง Bill เราเรียกการสาธิตตัวอย่างนี้ว่า “Wall of Fire”
ต่อไปนี้คือรูปถ่ายของ Bill เมื่อเขาหันหลังกลับมาดูการสาธิตตัวอย่าง:
ต่อไปนี้คือรูปถ่ายของสมาชิกทีม SMS ผู้กล้าหาญที่สาธิตตัวอย่าง:
สร้างการเปลี่ยนแปลง
ในฤดูใบไม้ร่วงปี 2004 Bill และ Steve จัดการประชุมนอกสถานที่กับผู้นำอาวุโสจากทั่วทั้งบริษัท และเซสชันสุดท้ายของวันนั้นคือช่วงถามตอบกับ Bill และ Steve มีคนถาม Bill ว่า “สิ่งที่สำคัญที่สุดที่เกิดขึ้นกับ Microsoft เมื่อปีที่แล้ว” คืออะไร Bill ตอบว่า: “เรามี SMS และ Active Directory และทั้งสองอย่างจะเป็นทรัพย์สินชั้นเยี่ยมในการก้าวไปข้างหน้าของเรา”
วันนั้นยังคงเป็นหนึ่งในวันที่ดีที่สุดในอาชีพของผมจนถึงวันนี้!
ในปี 2007 เราเปลี่ยนชื่อ “SMS” เป็น “ConfigMgr” เพื่อปรับให้เข้ากับแบรนด์ศูนย์กลางระบบ การกำหนดสถานะตามความต้องการ (Desired State Configuration หรือ DSC) คือนวัตกรรมใหม่ล่าสุดที่ลูกค้าร้องขอ เราจึงต้องพัฒนาสถาปัตยกรรมให้สามารถใช้งาน DSC ได้ตามที่ลูกค้าต้องการอีกครั้ง นอกจากนี้ เรายังเขียนประสบการณ์ด้านการควบคุมดูแลขึ้นใหม่จนเสร็จสมบูรณ์อีกด้วย
ในเดือนกุมภาพันธ์ 2011 เรามาถึงการออกแบบทางวิศวกรรมของ SCCM 2012 ครึ่งทางแล้ว Satya เข้าครอบงำกิจการ Server and Tools Business (STB) และได้เปลี่ยนชื่อเป็น Cloud and Enterprise (C+E) และได้กลายเป็นเจ้านายของผม ในการประชุมตัวต่อตัวครั้งแรกของเรา Satya มาที่สำนักงานของผมและใช้เวลาทำความรู้จักกันให้มากขึ้น การประชุมครั้งนั้นเป็นประสบการณ์ที่ยอดเยี่ยมในการทำงานกับ Satya โดยตรงเป็นเวลาหลายปี และได้เรียนรู้จากนิสัยอยากรู้อยากเห็นที่น่าทึ่ง กรอบความคิดแบบเติบโต และความเป็นผู้นำที่นอบน้อมต่อผู้ตามของเขา Satya ได้สร้างการเปลี่ยนแปลงให้กับอนาคตและสถาปัตยกรรมของ ConfigMgr ในรุ่นนี้
โดยพื้นฐานแล้ว ใน ConfigMgr 2012 เราได้เปลี่ยนแปลงสถาปัตยกรรมให้มุ่งเน้นไปที่สถาปัตยกรรมและประสบการณ์ของผู้ใช้ ไม่ใช่เพียงอุปกรณ์
ลูกค้าบอกกับเราว่าความคล่องตัวจะกลายเป็นปัจจัยสำคัญในอนาคต และเราเข้าใจว่าความคล่องตัวดังกล่าวคือความคล่องตัวของผู้ใช้ ไม่ใช่อุปกรณ์เพียงอย่างเดียว จากข้อมูลนี้ เราได้ทำให้สถาปัตยกรรมเรียบง่ายยิ่งขึ้นเพื่อลดจำนวนฮาร์ดแวร์ที่ต้องใช้ และเราได้เพิ่มขีดจำกัดขนาดอีกด้วย นี่คือจุดที่เราจริงจังกับการมุ่งหน้าสู่ระบบคลาวด์อย่างแท้จริง เราเชื่อมต่อ ConfigMgr กับ Microsoft Intune และ Intune ก็ได้กลายเป็นจุดเชื่อมโยงของ ConfigMgr
การกำหนดค่าแบบไฮบริดนี้กลายเป็นโมเดลที่ช่วยให้เราสามารถคิดค้นนวัตกรรมในระบบคลาวด์ และมอบคุณค่าใหม่ๆ ให้กับ ConfigMgr ในองค์กรผ่านทางการปรับใช้แบบไฮบริดได้ เราเชื่อว่าระบบคลาวด์จะช่วยให้เราสามารถทำสิ่งที่เราไม่เคยทำได้มาก่อนในอดีต และ Satya ก็มองเห็นศักยภาพของระบบคลาวด์ในการจัดการอุปกรณ์ และเขาก็ผลักดันให้เราคิดค้นนวัตกรรมและทดลองที่นี่
ConfigMgr มุ่งสู่ระบบคลาวด์
วิวัฒนาการสถาปัตยกรรมครั้งต่อมาคือความท้าทายครั้งใหญ่ที่สุด
เมื่อเราได้เรียนรู้ว่าจะมีการมอบ Windows 10 เป็นบริการที่มีการอัปเดตหลายครั้งในแต่ละปี เราก็ทราบได้ทันทีว่า ConfigMgr จะต้องทำตามและย้ายไปยังระบบคลาวด์
ความท้าทายครั้งนี้เป็นเรื่องยากลำบากมาก
ในอดีต มีการปล่อย ConfigMgr รุ่นใหม่ทุกๆ 2-3 ปี ผมจำตอนที่ดูแผนการทำงานแรกสำหรับ SCCM 2007 และเห็นเวลาการปรับความเสถียรและรุ่นเบต้าถึง 16 เดือนระหว่างช่วงเวลาที่เราประกาศโค้ดที่สมบูรณ์และช่วงที่เผยแพร่ 16 เดือน! เป็นที่ชัดเจนว่าเราต้องทำให้ ConfigMgr “กลายเป็น SaaS” เพื่อให้เราสามารถรักษาจังหวะการเผยแพร่รุ่นหลายครั้งต่อปีได้
เมื่อทราบว่ามีงานที่ยากลำบากรออยู่ข้างหน้า เราจึงตั้งทีมขนาดเล็กที่มีสมาชิกเป็นวิศวกรและผู้จัดการโปรแกรมที่ผ่านการคัดเลือกและรู้จัก ConfigMgr เป็นอย่างดี มีกรอบความคิดแบบเติบโต และมีความหลงใหลในการทำงานเพื่อลูกค้าเหมือนกัน เราเชื่อว่าวิธีเดียวที่จะจัดการงานนี้ได้คือการใช้ทีมเฉพาะทางขนาดเล็กแก้ไขสถาปัตยกรรมใหม่ทั้งหมดและสร้างบริการบนระบบคลาวด์ใหม่ตั้งแต่ต้น
เมื่อผมดูตารางเวลาของการแก้ไขครั้งนี้ ผมยอมรับว่ามีความข้องใจผสมกับการมองโลกในแง่ดีอันเหลือเฟือตามปกติของผม การทำสิ่งต่างๆ ให้ลุล่วง งานนี้กลายเป็นภาระหน้าที่ที่ไม่น่าเชื่ออย่างรวดเร็ว
ตอนนี้ ผลลัพธ์ก็เป็นที่คาดเดาได้: ทีมวิศวกรรมเฉพาะทางนี้ทดสอบทุกครั้งได้เหนือความคาดหมายและได้มอบวิธีการทำงานบนระบบคลาวด์แบบใหม่ให้กับการจัดการพีซี ทำให้เราเปลี่ยนไปใช้วงจรการเผยแพร่รายเดือนได้อย่างราบรื่น เพื่อติดตามการอัปเดตเหล่านี้ เราได้ยกเลิกหมายเลขเวอร์ชันแบบเก่า (เช่น 2003, 2007, 2012) และแทนที่ด้วยการตั้งชื่อโดยใช้ปี/เดือน ซึ่งรุ่นแรกก็คือเวอร์ชัน 1511 เนื่องจากเผยแพร่ในเดือนที่ 11 ของปี 2015
นับจากนั้น เราได้ปล่อย ConfigMgr เวอร์ชัน Insider ใหม่ๆ ทุกเดือน และรุ่น CurrentBranch ทุกๆ ประมาณ 4 เดือน
ไม่ต้องสงสัยเลยว่าการทำงานครั้งนั้นเป็นหนึ่งในการทำงานทางวิศวกรรมที่น่าทึ่งที่สุดที่ผมเคยมีส่วนร่วม
การตอบสนองของลูกค้าต่อโมเดลการเผยแพร่บนระบบคลาวด์แบบใหม่นี้เป็นเรื่องที่น่าเหลือเชื่อ
ลองดูกราฟิกนี้:
มีการอัปเกรดรากฐาน 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 จะได้รับความน่าสนใจและน่าหลงใหลมากไปกว่าตอนนี้แล้ว
มีอะไรอีก
เราเริ่มเดินทางสู่ระบบคลาวด์ด้วย ConfigMgr Current Branch รุ่น 1511 ในเดือนพฤศจิกายน 2015 ในตอนนั้น เราทราบดีว่าขั้นตอนนี้จะเป็นก้าวสำคัญ ซึ่งนำไปสู่สิ่งที่เราต้องการ เราทราบดีว่ามีงานอีกมากมายที่ต้องทำให้ลุล่วง
ความเร็วในการคิดค้นนวัตกรรมตั้งแต่รุ่น 1511 เพิ่มขึ้นเรื่อยๆ องค์กรมุ่งเข้าสู่โลกของบริการบนระบบคลาวด์ที่เชื่อมต่อกับอุปกรณ์เคลื่อนที่อย่างรวดเร็ว ทำให้เราต้องเร่งทำงานเพื่อมอบสิ่งที่คุณต้องการ โครงสร้างพื้นฐาน ConfigMgr ได้ผ่านขั้นตอนสำคัญของการเป็นบริการบนระบบคลาวด์อย่างแท้จริง ซึ่งตอนนี้ ConfigMgr ได้กลายเป็นบริการที่ได้รับการอัปเดตความสามารถใหม่ๆ อย่างต่อเนื่อง โดยใช้ประโยชน์จากความสามารถ AI ของระบบคลาวด์เพื่อปรับให้เข้ากับความต้องการของคุณและมอบการป้องกันที่คุณต้องการ นอกจากนี้ ยังเป็นบริการบนระบบคลาวด์ที่สามารถรองรับอุปกรณ์ได้หลาย 100 ล้านเครื่องทั่วโลก
ทั้งหมดนี้เป็นสิ่งย้ำเตือนผมถึงเรื่องธรรมดาที่สุดที่ผมได้ยินจากผู้นำด้าน IT ทั่วโลก: พวกเขาหงุดหงิดกับความซับซ้อนที่พวกเขาและทีมต้องจัดการเพื่อทำงานให้ลุล่วง องค์กรกำลังมองหาวิธีการลดความซับซ้อนของสิ่งที่พวกเขาปรับใช้ และพวกเขาต้องการวิธีการแบบครบวงจรที่ทำให้ผู้ใช้สามารถทำงานได้บนอุปกรณ์ทุกชนิด ซึ่งต้องมีการจัดการและการรักษาความปลอดภัยที่พวกเขาต้องการด้วย นี่เป็นสาเหตุที่ทำให้เราสร้าง Microsoft 365 M365 มอบพื้นที่ทำงานที่ทันสมัยและปลอดภัย พร้อมกับบริการที่ผสานรวมช่วยให้ผู้ใช้ทำงานได้มากขึ้น ซึ่งผ่านการออกแบบทางวิศวกรรมให้ฝ่าย IT สามารถมอบความสมบูรณ์แบบและส่งเสริมสภาพแวดล้อมการทำงานที่เป็นที่รักของผู้ใช้และเป็นที่น่าเชื่อถือของฝ่าย IT
นี่เป็นวิวัฒนาการขั้นถัดไปของผลิตภัณฑ์ทั้งหมดจาก Microsoft ที่คุณใช้งานมาหลายปี ไม่ว่าจะเป็น Windows, Office, Active Directory, ConfigMgr และเราจะย้ายผลิตภัณฑ์ทั้งหมดไปยังระบบคลาวด์ด้วย Microsoft 365 ลูกค้าระดับองค์กรทั่วโลกกำลังโยกย้ายไปยังระบบคลาวด์ (ใช้ Windows 10 เป็นบริการ, Office 365 และบริการ EMS) ซึ่งเป็นวิวัฒนาการขั้นถัดไปอย่างเป็นธรรมชาติของสถาปัตยกรรม ConfigMgr
ทุกวันนี้ บริษัทและองค์กรเชิงพาณิชย์เกือบทุกองค์กรทั่วโลกเริ่มต้นจากการใช้โมเดลในองค์กร ซึ่งพวกเขาเลือกใช้ Active Directory, นโยบายกลุ่ม และ ConfigMgr เป็นเครื่องมือจัดการ หลายๆ องค์กรต้องการเปลี่ยนไปใช้โมเดลที่สะดวกและทันสมัยยิ่งขึ้น แต่การเข้าถึงโมเดลที่ทันสมัยใหม่ๆ ดังกล่าวไม่ใช่เรื่องง่ายเลย จู่ๆ องค์กรจะดีดนิ้วสั่งย้ายผู้ใช้/อุปกรณ์จาก AD/GP/ConfigMgr ไปยัง AAD/Intune เลยไม่ได้ สิ่งที่คุณต้องการจากเราคือสะพานเชื่อมโยงที่ทำให้การย้ายครั้งนี้ง่ายขึ้น เร็วขึ้น และปราศจากความเสี่ยง เราได้รับบทเรียนมากมายจากการติดตามองค์กรที่เปลี่ยนจาก 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 ส่งผลกระทบต่อชีวิตของผม ชีวิตของครอบครัว ชีวิตของวิศวกรหลายพันคนที่ร่วมทำงานในโครงการ และชีวิตของผู้เชี่ยวชาญด้าน IT อีกหลายล้านคนที่ใช้งานและยังคงใช้งานอยู่ทุกวันนี้ ผมรักผลิตภัณฑ์นี้และผมรักชุมชนนี้
ผมมีความสุขที่ได้เห็นสารคดีเกี่ยวกับประวัติของ ConfigMgr ถูกนำมารวมกันในวันนี้ แต่นี่เป็นเพียงตอนที่ 1 เท่านั้น และแน่นอน ตอนที่ 2 มีความสำคัญกว่านี้มาก เพราะว่าคุณจะต้องเป็นผู้เขียนตอนที่ 2 เอง
ถ้าคุณไปที่ Ignite โปรดแวะชมบูธส่วนการจัดการและการรักษาความปลอดภัยของ Microsoft และเล่าเรื่องราวของคุณ นี่คือตำแหน่งของบูธ
ถ้าคุณไม่ได้ไปที่ Ignite คุณก็ยังสามารถมีส่วนร่วมได้อย่างง่ายดาย บอกเล่าเรื่องราวของคุณโดยการอัปโหลดเหตุการณ์และเรื่องราวเกี่ยวกับ ConfigMgr ของคุณที่นี่ aka.ms/ConfigMgr25 ต่อไปนี้คือคำแนะนำขั้นพื้นฐานบางส่วน
เราจะใช้ข้อมูลที่คุณส่งเข้ามาในการสร้างตอนที่ 2 ของวิดีโอที่เราอยากจะเรียกว่า:
“ประวัติ ConfigMgr ของทุกคน”
ผมแทบรอชมไม่ไหวแล้ว
_______________________________________________