ความท้าทายของการเขียนสคริปต์ PowerShell ใน Microsoft 365

โมดูลที่เลิกใช้ การเปลี่ยนแปลง Cmdlet และพารามิเตอร์หายไป

คำพูดทั่วไปที่ว่า “ถ้ามันได้ผล อย่าแก้ไข” ไม่เป็นความจริงอย่างเคร่งครัดในโลกของการประมวลผลแบบคลาวด์ สำหรับกระบวนการทางธุรกิจที่ขึ้นอยู่กับสคริปต์และโมดูล PowerShell การไม่ดูแลรักษาโค้ดในเชิงรุกอาจกลายเป็นปัญหาได้อย่างรวดเร็วเนื่องจากการเปลี่ยนแปลงที่ Microsoft ทำกับโมดูลและ cmdlets นั่นคือ เว้นแต่องค์กรต่างๆ จะไม่มีปัญหาเรื่องการเลิกจ้างอัตโนมัติ ซึ่งมักจะสร้างความประหลาดใจอันไม่พึงประสงค์ในวันแรกของเดือนถัดไป

ในบทความนี้ ซึ่งเกี่ยวข้องกับการนำเสนอชื่อเดียวกันที่จัดขึ้นที่การประชุมผู้เชี่ยวชาญประจำปี 2023 ผมจะกล่าวถึงความท้าทายบางประการที่ผู้ดูแลระบบอาจพบกับสคริปต์ PowerShell นอกจากนี้ ฉันยังให้คำแนะนำและชี้ให้เห็นเครื่องมือบางอย่างที่สามารถช่วยในการเขียนใหม่หรือปรับโครงสร้างโค้ดใหม่ได้ เช่น การอัปเดตโค้ดโดยยังคงรักษาฟังก์ชันการทำงานภายนอกไว้ ด้วยเหตุนี้ ฉันหมายถึงวิธีการเรียกโค้ดที่ต้องถูกรักษาไว้ เช่น การรักษาพารามิเตอร์ให้เหมือนกัน

การรับรู้

ปัจจัยที่ซับซ้อนในการบำรุงรักษาคือบางองค์กรไม่ทราบถึงการพึ่งพาทั้งหมดที่ซ่อนอยู่ในโครงสร้างพื้นฐานของตน ตัวอย่างเช่น ยังคงมีโซลูชันของบริษัทอื่นจำนวนมากที่ต้องอาศัยสคริปต์และโมดูล PowerShell และการขึ้นต่อกันเหล่านั้นมีวันสิ้นสุด

ต่อไปนี้เป็นข้อความบางส่วนที่ได้ยินจากลูกค้า:

• พาร์ทเนอร์ X ดำเนินงานที่อำนวยความสะดวกในการจัดเตรียมและการออกใบอนุญาต ฉันคาดหวังว่าพวกเขาจะแจ้งเราเมื่อเราจำเป็นต้องทำอะไรบางอย่าง
• ฉันอ่านเจอว่าโมดูล PowerShell X จะเลิกใช้ในวันที่ Y เราจำเป็นต้องทำอะไรสักอย่างไหม
• เรามีชุดสคริปต์ PowerShell เพื่อรองรับงานด้านการดูแลระบบ เราจะเริ่มต้นที่ไหน?

แทนที่จะรอจนถึงสัปดาห์สุดท้ายก่อนที่ Microsoft จะเลิกใช้โมดูล PowerShell หรือเอนหลังเมื่อ Microsoft เลื่อนการเลิกใช้ ฉันไม่สามารถเน้นได้มากพอที่คุณควรปรับใช้จุดยืนเชิงรุก การคงความทันสมัยไม่เพียงแต่ใช้กับเทคโนโลยีและในกรณีนี้คือโมดูล PowerShell แต่ยังรวมถึงความรู้และทักษะด้วย ตัวอย่างเช่น จำนวนผู้ดูแลระบบที่มีความรู้เกี่ยวกับ Microsoft Graph PowerShell SDK มีน้อยมาก ในเวลาเดียวกัน มีการเขียนบนผนังเป็นเวลาหลายปีว่าทั้งโมดูล Microsoft Online Services และ Azure AD กำลังมุ่งหน้าไปสู่ทางออก

แรงจูงใจในการติดตามการเปลี่ยนแปลง

แล้วอะไรทำให้ผู้ดูแลระบบจำเป็นต้องตรวจสอบสคริปต์และเครื่องมือที่มีอยู่? จากประสบการณ์ของผม นอกเหนือจากการปรับให้เหมาะสมและการปรับเปลี่ยนเพื่อรองรับการเปลี่ยนแปลงในกระบวนการทางธุรกิจอื่นๆ แล้ว ยังมีตัวขับเคลื่อนหลักสองประการ:

1. ความปลอดภัย ตัวอย่างล่าสุดคือการเลิกใช้การรับรองความถูกต้องขั้นพื้นฐานใน Exchange Online ขั้นตอนนี้กำหนดให้ผู้ดูแลระบบต้องตรวจสอบสคริปต์และเครื่องมือของตนเพื่อตรวจจับการใช้งานการตรวจสอบสิทธิ์ขั้นพื้นฐาน และอัปเดตโดยใช้การตรวจสอบสิทธิ์สมัยใหม่
   
   อีกตัวอย่างหนึ่งคือการใช้การตรวจสอบสิทธิ์ตามใบรับรองผ่านวลีรหัสผ่าน (ข้อมูลลับ) และข้อมูลประจำตัวที่บันทึกไว้หรือ Microsoft 365 เริ่มต้องการ TLS 1.2 ในบางจุด ในบางกรณี การเปลี่ยนแปลงเช่นนี้นำไปสู่การนำการเปลี่ยนแปลงไปใช้ในฝั่งไคลเอ็นต์
   
2. วงจรชีวิต โมดูล PowerShell ขึ้นอยู่กับวงจรการใช้งาน ดังนั้นการสังเกตการเปลี่ยนแปลงในโมดูลเหล่านั้นที่อาจส่งผลกระทบต่อองค์กรของคุณ เช่น วงจรการใช้งาน จึงมีความสำคัญสูงสุด ตัวอย่างปัจจุบันคือโมดูล Microsoft Online Services และ AzureAD ซึ่งมีกำหนดเลิกใช้งานครั้งสุดท้ายในวันที่ 30 มีนาคม 2024
   
   นอกจากนี้ โมดูลอาจไม่เข้ากันกับระบบปฏิบัติการพื้นฐานหรือ PowerShell เวอร์ชันที่ใหม่กว่า ตัวอย่างเช่น โมดูล AzureAD และ Microsoft Commerce ไม่ได้รับการสนับสนุนบน PowerShell v7 ซึ่งทำให้เกิดภาวะที่กลืนไม่เข้าคายไม่ออกหากคุณต้องการใช้คุณลักษณะ PowerShell v7 เช่น การทำขนานไปป์ไลน์ ใช่ คุณสามารถนำเข้าในโหมดความเข้ากันได้โดยใช้โมดูลนำเข้าพร้อมสวิตช์ UseWindowsPowerShell แต่สิ่งนี้นำไปสู่ปัญหาที่ไม่คาดคิดอย่างรวดเร็ว

การดูแลทำความสะอาดโมดูล

เพื่อให้โมดูลอัพเดตบนไคลเอ็นต์หรือเซิร์ฟเวอร์โลคัล สคริปต์จำนวนมากที่มีอยู่ในชุมชนอาจช่วยเหลือในงานนี้ Connect-Office365Services มีฟังก์ชันตัวช่วยสำหรับการรายงานและอัปเดตชุดโมดูล PowerShell ที่เกี่ยวข้องกับเวิร์กโหลด Office365 ที่รู้จักกันดี หลังจากโหลดสคริปต์ในเซสชันปัจจุบันของคุณหรือผ่านโปรไฟล์ PowerShell โดย dot-sourcing ([PS]>. .\Connect-Office365Services.ps1) ให้ใช้ Report-Office365Modules เพื่อรายงานเกี่ยวกับโมดูลที่เป็นตัวเลือกสำหรับการอัปเดต หรือใช้ Update -Office365Modules เพื่ออัปเดต โปรดทราบว่าในการตรวจสอบและติดตั้งโมดูลการแสดงตัวอย่าง คุณจะต้องระบุสวิตช์ AllowPrerelease หรือใช้สคริปต์เพื่อช่วยในการอัปเดตโมดูลที่เผยแพร่โดย Tony Redmond: UpdateOffice365PowerShellModules.ps1

เมื่อพูดถึงสคริปต์ที่ทำงานเป็นส่วนหนึ่งของฟังก์ชัน Azure หรือ Azure Runbook สคริปต์เหล่านั้นก็มีการขึ้นต่อกันเช่นกัน ซึ่งหมายความว่ากระบวนการตรวจสอบเดียวกันนี้ใช้กับโค้ดนั้นด้วย โปรดทราบว่าวิธีการอัปเดตโมดูลใน Azure นั้นแตกต่างกันเล็กน้อย ดังที่อธิบายไว้ที่นี่

แลกเปลี่ยนออนไลน์

โมดูล Exchange Online Management เวอร์ชัน 3 (v3) เป็นเวอร์ชันปัจจุบันสำหรับการจัดการ Exchange Online ผ่าน PowerShell โมดูล v2 เวอร์ชัน GA ยังคงมีอยู่แต่ไม่แนะนำ ไม่เพียงแต่ขึ้นอยู่กับไคลเอ็นต์ WinRM สำหรับ PowerShell Remoting ซึ่งจำเป็นต้องเปิดใช้งานการรับรองความถูกต้องขั้นพื้นฐาน แต่ v2 ยังหยุดรับการอัปเดตตั้งแต่เดือนกันยายน 2022 ในการเปลี่ยนแปลงอย่างต่อเนื่องที่เกิดขึ้นใน Microsoft 365 นั่นฟังดูเหมือนตลอดชีวิต ข้อเท็จจริงที่น่าสนุกก็คือ เดิมทีโมดูล v3 เริ่มต้นเป็นโมดูลดูตัวอย่าง v2 ซึ่งก่อนหน้านี้ได้บล็อกองค์กรที่มีนโยบาย "ไม่แสดงตัวอย่างในการใช้งานจริง" ไม่ให้ใช้งาน

ตัวอย่างอย่างง่ายของการอัปเดตรหัส Exchange ที่มีอยู่ ซึ่งสามารถเป็นส่วนหนึ่งของสคริปต์ที่คุณใช้กับ Exchange ภายในองค์กรได้แสดงอยู่ด้านล่าง ในที่นี้ คำสั่งในสคริปต์ที่ใช้ในการเชื่อมต่อกับ Exchange จำเป็นต้องได้รับการแก้ไขเพื่อใช้การรับรองความถูกต้องสมัยใหม่ ซึ่งเกี่ยวข้องกับการระบุผู้เช่าและ ID แอปพลิเคชันที่สร้างโดยแอปพลิเคชันที่ลงทะเบียนใน Entra ID เพื่อจุดประสงค์นี้ ร่วมกับใบรับรองหรือข้อมูลลับที่กำหนดค่าเป็นวิธีการตรวจสอบสิทธิ์ที่เป็นไปได้ ด้วยใบสมัครที่ลงทะเบียนไว้ นอกจากนี้ คำสั่งที่เกี่ยวข้องกับ Exchange เช่น Get-Mailbox อาจถูกแทนที่ด้วย Get-EXOMailbox ที่ใช้ REST และการเปลี่ยนแปลงโค้ดเพิ่มเติมบางอย่างเพื่อให้ได้ประโยชน์จากประโยชน์ด้านประสิทธิภาพเหนือ REST- cmdlet รับกล่องจดหมาย ที่ได้รับการสนับสนุน

Remote PowerShell

การจัดการการแลกเปลี่ยนออนไลน์ v3

New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<fqdn>/PowerShell/ -Authentication Kerberos -Credential $Credential | Import-PSSession Connect-ExchangeOnline –Credential ..

Connect-ExchangeOnline
-องค์กร ..onmicrosoft.com
-AppId .. -CertificateThumbprint ..

Get-Mailbox

รับ-EXOMailbox

รหัสเข้า

ความท้าทายของโมดูลที่ใช้สำหรับการจัดการ Entra ID ก็เหมือนกับการจัดการ Exchange Online แต่มีการเปลี่ยนแปลง สำหรับ Entra ID มีโมดูลเก่าสองโมดูลให้เลือกใช้: Microsoft Online Services (MSOnline) และ AzureAD ครั้งแรกมีมาตั้งแต่รุ่งอรุณของ Business Productivity Online Suite (BPOS) รุ่นก่อนของ Office 365 อย่างหลังเห็นแสงสว่างในปี 2559 โดยเป็นโมดูล PowerShell ที่สามารถจัดการได้ของ PowerShell (MSOnline เคยต้องมีการติดตั้ง) และการเปลี่ยนแปลงใน API ใน Office 365 เนื่องจาก AzureAD ไม่เคยนำเสนอความเท่าเทียมกันของฟีเจอร์เต็มรูปแบบเมื่อเทียบกับ MSOnline ทั้งสองจึงยังคงอยู่รอบ ๆ สคริปต์ ผลิตภัณฑ์ และเอกสารจำนวนมาก แม้กระทั่งเขียนโดย Microsoft ก็ยังคงอ้างถึงโมดูลเหล่านี้ แม้แต่ฝ่ายสนับสนุนของ Microsoft ก็ยังแจกคำแนะนำตามโมดูล MSOnline และ AzureAD สคริปต์และคำแนะนำเหล่านี้จะไม่ถูกต้องและใช้งานไม่ได้เร็วๆ นี้

วันของโมดูลเหล่านี้จะถูกกำหนดหมายเลข เนื่องจากไลบรารีพื้นฐานและ API ที่ใช้ในการเชื่อมต่อกับ Entra ID จะถูกยกเลิก ขณะนี้กำหนดวันเลิกใช้จริงเป็นวันที่ 30 มีนาคม พ.ศ. 2567 หลังจากที่ Microsoft เลื่อนออกไปสองสามครั้งเพื่อให้ผู้ขายและองค์กรมีเวลามากขึ้นในการทำการเปลี่ยนแปลงที่จำเป็น API ใบอนุญาตที่ใช้โดย cmdlets ในโมดูลเหล่านี้เพื่อมอบหมายใบอนุญาต Office 365 ที่เลิกใช้แล้วในวันที่ 30 กันยายน 2023

การวางแผนและการรวมบัญชีการย้ายแพลตฟอร์ม Microsoft

ลดความซับซ้อนในการวางแผนการย้ายข้อมูล เอาชนะความท้าทายในการย้ายข้อมูล และดำเนินโครงการให้เสร็จเร็วขึ้น พร้อมทั้งลดต้นทุน ความเสี่ยง และการหยุดชะงักให้กับผู้ใช้

โอบกอดกราฟ

แทนที่จะเป็น MSOnline และ AzureAD Microsoft กำลังกระตุ้นให้องค์กรและผู้ขายยอมรับ Microsoft Graph PowerShell SDK ซึ่งเป็นชุดโมดูล PowerShell ที่เสนอ cmdlets เพื่อพูดคุยกับ Microsoft Graph แต่ในกรณีที่โมดูล MSOnline และ AzureAD เสนอสิทธิ์แบบ 'ครอบคลุม' ในพื้นที่ Entra ID นั้น Graph ต้องการสิทธิ์ตามข้อกำหนดที่ละเอียดมากขึ้น ผู้ดูแลระบบอาจจำเป็นต้องเรียนรู้เกี่ยวกับแนวคิดที่พวกเขาอาจไม่คุ้นเคย เช่น ขอบเขตสิทธิ์ หรือเมื่อใดจึงควรใช้การสืบค้นขั้นสูง นอกจากนี้ยังมีการแยกตำแหน่งข้อมูลสำหรับกราฟเมื่อติดต่อกับตำแหน่งข้อมูลปกติ (v1) สำหรับการใช้งานด้านประสิทธิภาพการทำงานหรือรุ่นเบต้าซึ่งมีการพัฒนาล่าสุด แต่ไม่ใช่สำหรับการใช้งานจริง

คล้ายกับการอัปเดตรหัสสำหรับ Exchange Online ด้วยการรับรองความถูกต้องสมัยใหม่ หลักการเดียวกันนี้ใช้กับสคริปต์และเครื่องมือ MSOnline และ AzureAD ที่นี่ คำสั่งจำเป็นต้องได้รับการอัปเดตเป็น Microsoft Graph PowerShell SDK ซึ่งสื่อสารกับ Microsoft Graph แทน Azure Active Directory Authentication Library (ADAL) ที่จะเลิกใช้งาน และ Azure AD Graph API ที่ใช้โดยทั้งสองโมดูล

เพื่อให้สิ่งต่าง ๆ ซับซ้อนขึ้นเล็กน้อย เมื่อเร็วๆ นี้ Microsoft Graph PowerShell SDK ได้แยกโมดูลออกเป็นสองโมดูล (V1.0 หรือเวอร์ชันที่ใช้งานจริงและเบต้า) และปลายทางทั้งสองมีโมดูลของตัวเอง สิ่งนี้สร้างอุปสรรคเล็กน้อยสำหรับผู้ดูแลระบบที่ใช้ PowerShell Graph SDK อยู่แล้ว เนื่องจากต้องตรวจสอบโค้ดของตน ประเด็นของฉันคือ ยังแสดงให้เห็นว่าเมื่อคุณได้เปลี่ยนไปใช้ PowerShell Graph SDK ในที่สุด คุณจะยังคงเผชิญกับความท้าทายเดิมๆ บ้างเป็นครั้งคราว

คำแนะนำและเครื่องมือ

เมื่ออ่านข้อความข้างต้นแล้ว อาจมีคนคิดว่านี่เป็นเรื่องของการดำเนินการค้นหาและแทนที่แบบง่ายๆ สิ่งนี้อาจเป็นจริงสำหรับพื้นที่เก็บข้อมูลขนาดเล็ก แต่ควรใช้แนวทางที่มีระเบียบวิธีมากกว่าเมื่อต้องจัดการกับชุดสคริปต์และเครื่องมือที่หลากหลาย

วิธีการตรวจสอบรหัสที่เกี่ยวข้องกับ Exchange คือการใช้สคริปต์ที่ฉันพัฒนาขึ้นมาเพื่อตรวจสอบสคริปต์สำหรับการใช้งานการรับรองความถูกต้องขั้นพื้นฐาน วิเคราะห์-ExoScript โดยจะเปรียบเทียบคำสั่งที่มีอยู่ในโมดูล Exchange Online Management กับสคริปต์ตั้งแต่หนึ่งสคริปต์ขึ้นไป ด้วยเหตุนี้ จึงใช้ประโยชน์จากสิ่งที่เรียกว่า Abstract Syntax Tree เพื่อตีความโค้ด ซึ่งช่วยให้คุณทำสิ่งที่ชาญฉลาดได้ เช่น ส่งออกคำสั่งเฉพาะ Exchange แสดงตำแหน่งที่ใช้ Connect-ExchangeOnline ร่วมกับพารามิเตอร์ Credentials หรือระบุตำแหน่งที่คำสั่งที่ใช้ REST สามารถทำได้ พิจารณาด้วยเหตุผลด้านประสิทธิภาพ ฉันเขียนเกี่ยวกับกระบวนการนี้ที่นี่

Microsoft ให้คำแนะนำทั่วโลกสำหรับการแปลงสคริปต์ที่ใช้ MSOnline และ AzureAD เป็น PowerShell Graph SDK เท่านั้น โชคดีที่ชุมชนไม่นิ่งเฉย Merill Fernando พนักงานของ Microsoft ซึ่งเป็น PM หลักของ Entra ได้พัฒนาเครื่องวิเคราะห์ Conversion PowerShell แบบกราฟออนไลน์ เว็บไซต์นี้สามารถใช้เพื่อช่วยในการแปลงคำสั่ง MSOnline และ AzureAD ไปเป็นคำสั่ง Microsoft Graph PowerShell SDK โดยการคัดลอกและวางโค้ด โบนัสพิเศษคือการวิเคราะห์ประกอบด้วยสิทธิ์ในขอบเขตที่จำเป็นในการดำเนินการ Microsoft Graph PowerShell SDK cmdlet ที่เกี่ยวข้อง

ในกรณีที่ตัววิเคราะห์คอนเวอร์ชันเหมาะสำหรับการใช้งานครั้งเดียวเนื่องจากลักษณะการโต้ตอบ PowerShell Azure Migration Advisor หรือ PSAzureMigrationAdvisor เท่านั้น สามารถวิเคราะห์ชุดของสคริปต์ได้ ซึ่งคล้ายกับสคริปต์วิเคราะห์ Exchange ที่กล่าวถึงก่อนหน้านี้ PSAzureMigrationAdvisor เป็นโมดูล PowerShell ที่ต้องติดตั้งบนเวิร์กสเตชัน จากนั้นคุณสามารถให้วิเคราะห์สคริปต์ได้ เช่น

รับ ChildItem C:\ADScripts | อ่าน-AzScriptFile. คำสั่งนี้จะส่งออกสคริปต์ที่ประมวลผล บรรทัดใดประกอบด้วยคำสั่ง MSOnline หรือ AzureAD และคำสั่งที่เหมือนกัน (รูปที่ 1) นี่เป็นข้อบ่งชี้ว่า 'ปัญหา' นั้นใหญ่แค่ไหน แต่ยังสามารถใช้เป็นรายการตรวจสอบที่จะเป็นประโยชน์เมื่ออัปเดตพื้นที่เก็บข้อมูลขนาดใหญ่ขึ้นกับทีมงาน

คำมั่นสัญญาของเอไอ

ChatGPT หรือ Copilot สำหรับ GitHub จะไม่มีบทบาทใดๆ ในแบบฝึกหัดการแปลงนี้หรือไม่ คำตอบคือ “มันขึ้นอยู่กับ” ประการแรก ต้องมี เพราะเช่นเดียวกับเครื่องมือวิเคราะห์ Copilot สามารถช่วยให้คุณวิเคราะห์สคริปต์และสร้างร่างเริ่มต้นของการแปลงได้อย่างรวดเร็ว ถ้าอย่างนั้นก็ไม่มี เพราะเอาต์พุตที่ AI สร้างขึ้นยังคงต้องมีการตรวจสอบและทดสอบโค้ดโดยมนุษย์ที่ชาญฉลาด และอาจต้องมีการแก้ไขจุดบกพร่องบ้าง เนื่องจากบางครั้ง AI ก็ทำผิดพลาด ตัวอย่างนี้คือสมการง่ายๆ $var eq 'string' ซึ่ง ChatGPT สร้างขึ้นเมื่อถูกขอให้สร้างโค้ด PowerShell แต่เนื่องจาก "eq" ไม่ใช่ตัวดำเนินการ PowerShell (-eq is) โค้ดจึงไม่ทำงาน อย่างไรก็ตาม การพัฒนา AI ไม่ได้หยุดนิ่ง ดังนั้นจึงแนะนำให้พิจารณาโซลูชัน AI เหล่านี้เป็นระยะ และแน่นอนว่าการเรียนรู้ทักษะใหม่จะไม่มีผลเมื่อคุณปล่อยให้ AI ทำหน้าที่นี้

บทสรุป

คุณอาจคิดว่าการรักษาสคริปต์และกระบวนการโดยใช้ PowerShell นั้นเป็นงานหนัก และบอกตามตรงว่าสามารถเป็นได้ เช่นเดียวกับ “นักพัฒนาตัวจริง” ผู้ดูแลระบบควรวางแผนและดำเนินการรอบการตรวจสอบโค้ดเพื่อรองรับการเปลี่ยนแปลงในโมดูลและอินเทอร์เฟซที่โค้ดขึ้นอยู่กับ การมีภาพรวมที่ดีของสคริปต์และเครื่องมือ ตลอดจนการขึ้นต่อกันและการเชื่อมต่ออาจเร่งการตรวจสอบโค้ด และช่วยระบุผลที่ตามมาจากการเปลี่ยนแปลงภายนอก

ผู้ดูแลระบบ โปรดใช้จุดยืนเชิงรุกเกี่ยวกับโค้ดของคุณและคาดหวังการเปลี่ยนแปลงในอนาคต อัปเดตสคริปต์และเครื่องมือเมื่อทำได้ ไม่ใช่เมื่อจำเป็น และเวลาและทรัพยากรก็ขาดแคลน