การใช้ Power Automate และ Azure Automation เพื่อจัดการวงจรการใช้งานของไซต์ SharePoint

SharePoint Sprawl เป็นปัญหาที่แท้จริง

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

ในบทความนี้ ฉันสำรวจวิธีการรวมทักษะพื้นฐานของ PowerShell และ Azure Automation เข้ากับ Power Automate เพื่อสร้างวิธีที่สะอาดและมีประสิทธิภาพในการทำให้ผู้เช่า Microsoft 365 ของคุณปลอดจากการแผ่ขยายมากเกินไป

เหตุใดนโยบายการหมดอายุของกลุ่มจึงไม่เหมาะกับคุณ

คำตอบของ Microsoft ต่อการแผ่ขยายกลุ่ม/ทีมคือนโยบายการหมดอายุของกลุ่ม ในระดับพื้นฐาน การหมดอายุทำงานได้ดีเป็นวิธีง่ายๆ ในการลบกลุ่มที่เก่ากว่าหรือไม่ได้ใช้งานภายในผู้เช่า Microsoft 365 แม้ว่าสัญญาณที่จำกัดจาก Microsoft Graph จะทำให้การหมดอายุตามกิจกรรมไม่น่าเชื่อถือก็ตาม นโยบายการหมดอายุอนุญาตให้เจ้าของกลุ่มอนุมัติการลบกลุ่มหรือต่ออายุกลุ่มเพื่อป้องกันการลบ โดยส่งการแจ้งเตือนหลายครั้งไปยังผู้ใช้เพื่อให้แน่ใจว่าจะไม่พลาดการต่ออายุ

ปัญหาเกี่ยวกับนโยบายการหมดอายุคือเมื่อข้อกำหนดของคุณไม่สอดคล้องกับวิสัยทัศน์ของ Microsoft เกี่ยวกับการหมดอายุของกลุ่ม ตัวอย่างเช่น รองรับนโยบายการหมดอายุของกลุ่มเดียวเท่านั้นต่อผู้เช่า ทุกกลุ่มที่อยู่ในขอบเขตของนโยบายการหมดอายุจะมีระยะเวลาหมดอายุเท่ากัน อีกตัวอย่างหนึ่งคือเมื่อคุณมีกลุ่มที่คุณไม่ต้องการรวมไว้ในนโยบายการหมดอายุ นโยบายการหมดอายุมีการตั้งค่าสองแบบสำหรับการมอบหมาย: กลุ่มทั้งหมดหรือกลุ่มที่เลือก (สูงสุด 500) นอกจากนี้ นโยบายการหมดอายุของกลุ่ม (ตามที่คุณบอกได้ด้วยชื่อ) จะเน้นไปที่ไซต์ทีมที่เชื่อมต่อกับกลุ่มโดยเฉพาะ และไม่ครอบคลุมไซต์ SharePoint Online อื่นๆ เช่น ไซต์การติดต่อสื่อสาร นโยบายการหมดอายุของกลุ่มยังจำเป็นต้องมีใบอนุญาต Entra ID Premium ซึ่งอาจเป็นตัวบล็อกสำหรับบางองค์กรได้

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

การรวม Azure Automation และ Power Automate

บทความมากมายเกี่ยวกับ Practical 365 แสดงให้เห็นถึงคุณค่าของ Azure Automation เมื่อต้องเผชิญกับความจำเป็นในการดำเนินการด้านการดูแลระบบแบบอัตโนมัติ ตัวอย่างเช่น ก่อนหน้านี้ฉันเคยเขียนหัวข้อที่คล้ายกันในเรื่องการทำให้ Teams เป็นระเบียบเรียบร้อยด้วยระบบอัตโนมัติ สำหรับงานแบบเป็นโปรแกรมที่ทำซ้ำได้ Azure Automation เป็นเครื่องมือที่ยอดเยี่ยมสำหรับผู้ดูแลระบบผู้เช่าที่ควรมีในกล่องเครื่องมือ Azure Automation สามารถทำงานหนักได้มากสำหรับโซลูชันนี้ แต่สิ่งหนึ่งที่ไม่สามารถให้ได้ (เนื่องจากลักษณะของ Azure Automation ที่ใช้งานสคริปต์แบบง่ายบนกล่อง Linux ที่โฮสต์) คือกระบวนการอนุมัติสำหรับการลบวัตถุ

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

สุดท้ายนี้ จำเป็นต้องรักษารายชื่อไซต์ที่จะรวมและเวลาหมดอายุที่เกี่ยวข้องไว้ มีหลายตัวเลือกในการจัดเก็บรายชื่อกลุ่มที่ต้องตรวจสอบการหมดอายุ เช่น ไฟล์ CSV ใน SharePoint หรือ Azure Storage หรือตาราง Dataverse สำหรับตัวอย่างนี้ ฉันใช้รายการ SharePoint เนื่องจากง่ายต่อการบำรุงรักษาและรองรับประวัติเวอร์ชันพื้นฐานและการบันทึกการตรวจสอบ เมื่อทุกอย่างเข้าที่แล้ว ผังกระบวนการจะเป็นไปตามโครงร่างในรูปที่ 1

รายการติดตามของ SharePoint

ในการติดตามสถานะการอนุมัติ ฉันใช้รายการ SharePoint เพื่อเก็บรายละเอียดสำคัญที่จำเป็นในการจัดการการหมดอายุของไซต์ รายการประกอบด้วยคอลัมน์ที่แสดงในตารางที่ 1

Column Name

รายละเอียด

SiteName

ฟิลด์บุคคลใช้เพื่อกำหนดผู้อนุมัติตั้งแต่หนึ่งรายขึ้นไปสำหรับแต่ละไซต์

SiteURL

URL ของเว็บไซต์

RetentionDays

ระยะเวลาหมดอายุเป็นวันสำหรับไซต์

RemainingDays

ใช้เพื่อติดตามว่าเหลืออีกกี่วันจึงจะหมดอายุ

MarkedforDeletion

ฟิลด์ตัวเลือกเพื่อติดตามว่าควรลบไซต์หรือไม่ ทางเลือกที่มีคือ: “ใช่” “ไม่ใช่” และ “รอการอนุมัติ”

DeletedOn

ใช้เพื่อติดตามวันที่ที่ไซต์ถูกลบ

Approver

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

รายการติดตาม (รูปที่ 2) เก็บรายละเอียดและสถานะปัจจุบันของแต่ละไซต์ภายในขอบเขตของกระบวนการหมดอายุ หากไซต์ไม่อยู่ในรายการ ไซต์นั้นจะไม่มีวันหมดอายุ

เมื่อสร้างรายการติดตาม ตรวจสอบให้แน่ใจว่าได้จัดทำดัชนีคอลัมน์ “Deletedon”, “MarkedforDeletion” และ “SiteURL” เพื่อให้ค้นหาได้จากคำขอ Graph API การตั้งค่าดัชนีสำหรับรายการนี้แสดงในรูปที่ 3

พาวเวอร์ โฟลว์อัตโนมัติ

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

โฟลว์ Power Automate สำหรับกระบวนการหมดอายุเริ่มต้นด้วยทริกเกอร์ที่กำหนดเวลาไว้เพื่อให้ทำงานวันละครั้ง ในแต่ละวัน โฟลว์จะตรวจสอบรายการติดตาม และหากค่า "วันที่เหลือ" ไม่เป็น 0 ก็จะลดลง กระบวนการทริกเกอร์แสดงไว้ในรูปที่ 4

หากค่า "RemainingDays" อยู่ที่ 0 แสดงว่าไซต์หมดอายุ และดำเนินการกระบวนการอนุมัติ คอลัมน์ "MarkedForDeletion" ได้รับการอัปเดตด้วยค่า "PendingApproval" และการอนุมัติจะถูกส่งไปยังผู้ใช้ที่แสดงอยู่ในคอลัมน์ผู้อนุมัติ การกำหนดค่าสำหรับโฟลว์แสดงในรูปที่ 5

การอนุมัติจะถูกส่งไปยังรายชื่อผู้อนุมัติผ่านทางทั้ง Teams และ Outlook ผู้อนุมัติมีตัวเลือกในการอนุมัติการลบหรือปฏิเสธและรีเซ็ตอายุการใช้งานของกลุ่มอีกครั้ง (รูปที่ 6)

สุดท้าย หากผู้อนุมัติคนใดคนหนึ่งอนุมัติคำขอ โฟลว์จะอัปเดตฟิลด์ "MarkedforDeletion" เป็น "ใช่" หากพวกเขาปฏิเสธคำขอ โฟลว์จะรีเซ็ต “วันที่เหลืออยู่” เพื่อให้ตรงกับค่า “วันเก็บรักษา” โดยเริ่มเวลาหมดอายุอีกครั้ง (รูปที่ 7)

Azure Automation Runbook

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

• Microsoft.Graph.Authentication เป็นสิ่งจำเป็นในการตรวจสอบสิทธิ์ Microsoft Graph API
• Microsoft.Graph.Groups เป็นสิ่งจำเป็นในการประมวลผลการลบไซต์ที่เชื่อมต่อกับกลุ่ม
• Microsoft.Graph.Sites เป็นสิ่งจำเป็นในการรวบรวมข้อมูลในแต่ละไซต์
• PnP.PowerShell จำเป็นต้องประมวลผลการลบไซต์การสื่อสาร เนื่องจาก Microsoft Graph API ยังไม่รองรับ

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการติดตั้งและอัปเดตโมดูลสำหรับ Azure Automation โปรดดูบทความนี้

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

• Microsoft Graph - Group.ReadWrite.All - จำเป็นในการลบไซต์ที่เชื่อมต่อกับกลุ่ม
• Microsoft Graph - Sites.FullControl.All - จำเป็นในการดึงข้อมูลไซต์และจัดการไซต์
• Office 365 SharePoint Online - Sites.Manage.All - จำเป็นในการลบไซต์การติดต่อสื่อสารผ่าน PNP PowerShell

รหัสตัวอย่างนี้แสดงวิธีการเพิ่มสิทธิ์กราฟและ SharePoint ไปยังบัญชี Azure Automation โค้ดจะแสดงรายการสิทธิ์กราฟที่จำเป็นก่อน รับรหัสหลักของบริการบัญชีอัตโนมัติ รับหลักการบริการของแอปพลิเคชัน Microsoft Graph จากนั้นจึงกำหนดสิทธิ์ให้กับบัญชีอัตโนมัติ กระบวนการนี้จะถูกทำซ้ำสำหรับแอป Office 365 SharePoint Online กระบวนการนี้มีรายละเอียดเพิ่มเติมในบทความนี้เกี่ยวกับการใช้ Azure Automation Managed Identities กับ RBAC สำหรับแอปพลิเคชัน

##List Required Permissions
$Permissions = @(
    "Group.ReadWrite.All"
    "Sites.FullControl.All"
)
##Add Managed Identity ID
$MIID = "<Replace with Managed Identity Service Principal ID>"”
##Get Roles for Permissions
$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" # Microsoft Graph
[array]$Roles = $GraphApp.AppRoles | Where-Object {$Permissions -contains $_.Value}
##Loop through and add each role
foreach($role in $roles){
    $AppRoleAssignment = @{
        "PrincipalId” = $MIID
        "ResourceId" = $GraphApp.Id
        "AppRoleId" = $Role.Id
    }
    # Assign the Graph permission
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MIID -BodyParameter $AppRoleAssignment
}
##List Required Permissions
$Permissions = @(
    "Sites.Manage.All"
)
##Get Roles for Permissions
$SPApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0ff1-ce00-000000000000'" # SharePoint Online
[array]$Roles = $SPApp.AppRoles | Where-Object {$Permissions -contains $_.Value}
##Loop through and add each role
foreach($role in $roles){
    $AppRoleAssignment = @{
        "PrincipalId" = $MIID
        "ResourceId" = $SPApp.Id
        "AppRoleId" = $Role.Id
    }
    # Assign the SharePoint permission
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MIID -BodyParameter $AppRoleAssignment
}

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

โซลูชันที่ยืดหยุ่น

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

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