ทำให้ทีมเป็นระเบียบเรียบร้อยด้วยระบบอัตโนมัติ

ปัญหาเกี่ยวกับการแผ่ขยายกลุ่ม

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

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

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

หมายเหตุ: ตัวอย่างโค้ดที่สรุปไว้ในบทความนี้มีอยู่ใน GitHub เพื่อช่วยคุณในการเริ่มต้นใช้งานโซลูชันของคุณเอง

ประเด็นสำคัญที่ต้องควบคุม

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

การตั้งชื่อกลุ่ม: นโยบายการตั้งชื่อกลุ่มในศูนย์การจัดการ Microsoft Entra ช่วยให้ฟังก์ชันการทำงานแบบแผนการตั้งชื่อพื้นฐานบางอย่างสำหรับกลุ่ม Microsoft 365 (และทีม) แต่ในความเป็นจริงแล้ว นโยบายเหล่านี้ขาดความยืดหยุ่นอย่างมาก การกำหนดชื่อกลุ่มตามคุณลักษณะผู้ใช้แบบคงที่เป็นความคิดที่ดีในทางทฤษฎี แต่พลาดกรณีการใช้งานที่สำคัญหลายกรณี เช่น ทีมข้ามแผนก หรือการแยกความแตกต่างระหว่างทีมภายในและภายนอกที่มีอยู่ อีกแง่มุมหนึ่งของการตั้งชื่อที่อาจมีประโยชน์ในองค์กรขนาดใหญ่คือการควบคุม URL ของไซต์ SharePoint ที่ใช้ ตามค่าเริ่มต้น Microsoft 365 จะใช้ชื่อเล่นเมลกลุ่มเพื่อกำหนด URL สำหรับไซต์ที่เกี่ยวข้อง ขึ้นอยู่กับโครงสร้าง SharePoint ภายในผู้เช่า ซึ่งอาจละเอียดไม่เพียงพอ

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

การควบคุมการเข้าถึงและการแบ่งปัน: ด้วยกลุ่มหรือทีมประเภทต่างๆ ทั่วทั้งองค์กร จึงมีระดับการเข้าถึงและการแบ่งปันที่แตกต่างกันที่ควรพิจารณา ตัวอย่างเช่น ทีมโครงการที่ต้องพบปะกับลูกค้าควรมีการกำหนดค่าการเข้าถึงภายนอกที่แตกต่างกันอย่างมากสำหรับทีมแผนกทรัพยากรบุคคล n การกำหนดค่าสำหรับประเภทกลุ่มต่างๆ ได้รับการกำหนดค่าอย่างง่ายดายโดยใช้ป้ายกำกับความไว ดังที่อธิบายไว้ในชุดข้อมูลสามส่วนนี้เกี่ยวกับการใช้ป้ายกำกับความไวกับไซต์ SharePoint, Microsoft Teams และ M365 Groups น่าเสียดายที่การกำหนดป้ายกำกับความลับโดยทางโปรแกรมจำเป็นต้องใช้สิทธิ์ที่ได้รับมอบหมายกับ Graph API ซึ่งทำได้ยากเมื่อทำงานแบบไม่โต้ตอบ สำหรับวัตถุประสงค์ของตัวอย่างนี้ ฉันกำหนดการตั้งค่ากลุ่มและไซต์โดยตรงแทนที่จะใช้ป้ายกำกับ

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

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

จะเริ่มตรงไหน?

พื้นที่ที่ฉันกล่าวถึงเป็นเพียงส่วนหนึ่งของโซลูชันและการตั้งค่าต่างๆ ที่พร้อมใช้งานใน Microsoft 365 ซึ่งแสดงถึงส่วนหนึ่งของโซลูชันเพียงอย่างเดียว การนำแต่ละชิ้นส่วนมารวมกันและทำให้เป็นอัตโนมัติคือจุดที่เราเพิ่มมูลค่าได้อย่างแท้จริง (และประหยัดเวลา)

กระโดดเข้าสู่การสร้างโซลูชันโดยตรง Azure Automation เหมาะสมอย่างยิ่งในการทำบางสิ่งเช่นนี้ให้เป็นอัตโนมัติ เนื่องจากทำงานได้อย่างน่าเชื่อถือและปลอดภัย นอกจากนี้ยังมีตัวอย่างดีๆ มากมายทางออนไลน์ที่แสดงให้เห็นว่า Azure Automation ใช้กับ Microsoft 365 และ Microsoft Graph SDK ได้อย่างไร

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

เตรียมสภาพแวดล้อม

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

• GroupMember.ReadWrite.All (เพื่อจัดการสมาชิกกลุ่ม)
• Group.Create (เพื่อสร้างกลุ่ม)
• User.ReadWrite.All (เพื่อจัดการสมาชิกกลุ่ม)
• Group.ReadWrite.All (เพื่อจัดการกลุ่ม)
• Directory.ReadWrite.All (เพื่อจัดการการตั้งค่าไดเรกทอรีและนโยบายวงจรการใช้งาน)
• Sites.FullControl.All (เพื่อจัดการการตั้งค่าไซต์)

หมายเหตุ: มีการทับซ้อนกันในการอนุญาตข้างต้น โดยเฉพาะกับ “Directory.ReadWrite.All” แต่ฉันได้รวมการอนุญาตขั้นต่ำสำหรับแต่ละงานเพื่อให้สามารถแก้ไขได้อย่างง่ายดายสำหรับสคริปต์ของคุณ สิทธิ์ Directory.ReadWrite.All เป็นสิทธิ์ระดับที่มีสิทธิพิเศษสูง ซึ่งปัจจุบันเป็นข้อกำหนดสำหรับการเพิ่ม Groups ลงในใบอนุญาตวงจรการใช้งานกลุ่ม สิ่งนี้ไม่เหมาะ แต่จนกว่าจะมีการให้สิทธิ์ในระดับที่ละเอียดยิ่งขึ้น นี่เป็นวิธีเดียวที่จะบรรลุเป้าหมายนี้ผ่าน Microsoft Graph

เรายังต้องการสิทธิ์ "Office 365 SharePoint Online" ต่อไปนี้:

• Sites.FullControl.All (เพื่ออนุญาตการเข้าถึง PNP)

สคริปต์ต่อไปนี้กำหนดสิทธิ์ที่ระบุไว้ข้างต้นให้กับบริการหลักโดยใช้โมดูล Microsoft.Graph PowerShell:

##List Required Permissions
$Permissions = @(
    "“GroupMember.ReadWrite.All"”
    "“User.ReadWrite.All"”
    "“Group.ReadWrite.All"”
    "“Directory.ReadWrite.All"”
    "“Sites.FullControl.All"”
    "“Group.Create"”
)
##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.FullControl.All"”
)
##Get Roles for Permissions
$GraphApp = Get-MgServicePrincipal -Filter "“AppId eq '‘00000003-0000-0ff1-ce00-000000000000'’"” # SharePoint Online
[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 SharePoint permission
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MIID -BodyParameter $AppRoleAssignment
}

จำเป็นต้องมีสิทธิ์ที่เพิ่ม (แสดงในรูปที่ 1) สำหรับตัวอย่างที่ฉันให้ไว้ที่นี่ แต่สิ่งสำคัญคือต้องพิจารณาว่าคุณต้องการสิทธิ์ Microsoft Graph ใดบ้างและปรับให้เหมาะกับสคริปต์ของคุณเอง

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

• Microsoft.Graph.Authentication
• Microsoft.Graph.Groups
• Microsoft.Graph.Identity.DirectoryManagement
• Microsoft.Graph.Teams
• PnP.PowerShell
• Az.Accounts (อันนี้ควรติดตั้งในบัญชีอัตโนมัติแล้ว)

การสร้างสคริปต์

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

• SiteURL - นี่คือ URL ที่เกี่ยวข้องของไซต์ SharePoint ที่เกี่ยวข้อง มันถูกใช้เพื่อเติมชื่อเล่นเมลของกลุ่ม ซึ่งจากนั้นจะใช้เพื่อสร้าง URL ของไซต์
• AdminURL - นี่คือ URL ผู้ดูแลระบบของอินสแตนซ์ SharePoint Online ของคุณ
• GroupName - นี่คือชื่อของกลุ่มที่จะสร้างสำหรับทีม
• GroupDescription - นี่คือค่าคำอธิบายของกลุ่ม
• DefaultOwner1 - นี่คือเจ้าของไซต์
• DefaultOwner2 - เนื่องจากเราต้องการเจ้าของขั้นต่ำสองคน นี่คือเจ้าของคนที่สอง
• InternalOnly - นี่คือค่าบูลีนเพื่อกำหนดว่าไซต์ควรทำเป็นการภายในเท่านั้นหรือไม่ การตั้งค่านี้เป็นเท็จจะทำให้บุคคลภายนอกสามารถเข้าถึงไซต์ได้ เพิ่มเติมเกี่ยวกับเรื่องนี้ในภายหลัง

Param
(
  [Parameter (Mandatory= $true)]
  [String] $SiteURL,

  [Parameter (Mandatory= $true)]
  [String] $adminURL,

  [Parameter (Mandatory= $true)]
  [String] $GroupName,

  [Parameter (Mandatory= $true)]
  [String] $GroupDescription,

  [Parameter (Mandatory= $true)]
  [String] $DefaultOwner1,

  [Parameter (Mandatory= $true)]
  [String] $DefaultOwner2,

  [Parameter (Mandatory= $true)]
  [bool] $InternalOnly
)

พื้นที่สำคัญถัดไปคือการเชื่อมต่อกับ Microsoft Graph โดยใช้ข้อมูลประจำตัวที่มีการจัดการของบัญชีอัตโนมัติ ในปัจจุบัน จำเป็นต้องใช้ Get-AzAccessToken cmdlet เพื่อรับโทเค็น ซึ่งจากนั้นจะส่งต่อไปยัง Connect-MgGraph cmdlet เมื่อเชื่อมต่อแล้ว เราจะสลับไปยังตำแหน่งข้อมูลเบต้าเพื่ออนุญาตการกำหนดค่าการตั้งค่าไดเรกทอรี ซึ่งไม่มีในเวอร์ชัน 1.0 หากต้องการทดสอบโค้ดนี้ในเครื่อง คุณจะต้องติดตั้งโมดูล Microsoft.Graph, AZ และ PNP.PowerShell บนเครื่องของคุณ

##Connect to Azure to retrieve an access token
Connect-AzAccount -Identity
$Token = (Get-AzAccessToken -ResourceURL "https://graph.microsoft.com").token

##Connect to Microsoft Graph
Connect-MgGraph -AccessToken $Token
select-mgprofile beta

เมื่อสร้างกลุ่ม เราจะใช้ตัวแปรพารามิเตอร์ที่ประกาศไว้ข้างต้นเพื่อสร้างเนื้อหาของคำขอและส่งต่อไปยัง New-MgGroup cmdlet จากนั้นหยุดสคริปต์ชั่วคราวเป็นเวลา 60 วินาทีเพื่อให้มีเวลาในการสร้างกลุ่มอย่างสมบูรณ์ก่อนดำเนินการต่อ นี่เป็นวิธีเบื้องต้นในการหลีกเลี่ยงข้อผิดพลาด ซึ่งส่วนใหญ่รวมไว้ที่นี่เพื่อให้คุณเริ่มต้นได้ ก่อนที่จะนำโซลูชันของคุณเองไปใช้จริง คุณควรเพิ่มการจัดการข้อผิดพลาดที่มีประสิทธิภาพมากกว่านี้เสียก่อน เนื้อความของกลุ่มประกอบด้วยการตั้งค่ากลุ่มพื้นฐานและปรับแต่งได้สำหรับกรณีการใช้งานใดๆ ที่คุณอาจมี

##Build Parameters for new M365 Group
$GroupParam = @{
    DisplayName = $GroupName
    description = $GroupDescription
    GroupTypes = @(
        "Unified"
    )
    SecurityEnabled     = $false
    IsAssignableToRole  = $false
    MailEnabled         = $false
    MailNickname        = $SiteURL
    "Owners@odata.bind" = @(
        "https://graph.microsoft.com/v1.0/users/$DefaultOwner1",
        "https://graph.microsoft.com/v1.0/users/$DefaultOwner2"
    )
}

#Provision M365 Group
$Group = New-MgGroup -BodyParameter $GroupParam

##Wait for Group to finish provisioning
start-sleep -seconds 60

ต่อไป เราจะทำตามขั้นตอนเดียวกันเพื่อเปิดใช้งานทีมสำหรับกลุ่มที่สร้างขึ้น ปรับแต่งได้อีกครั้งตามความต้องการของคุณ ตัวอย่างเช่น ฉันเลือกที่จะสร้างช่องชื่อ “ยินดีต้อนรับ!” สำหรับแต่ละทีม นี่เป็นตัวอย่างที่ค่อนข้างง่าย แต่สามารถขยายเพิ่มเติมได้ด้วยช่องทางที่กำหนดเอง/ข้อความช่องทาง ฯลฯ เพื่อสร้างเค้าโครงและการปรับแต่งทีมที่เฉพาะเจาะจง

##Build Parameters for new Team

$TeamParam = @{
       "Template@odata.bind" = "https://graph.microsoft.com/v1.0/teamsTemplates('standard')"
       "Group@odata.bind" = "https://graph.microsoft.com/v1.0/groups('$($Group.id)')"
       Channels = @(
             @{
                    DisplayName = "Welcome!"
                    IsFavoriteByDefault = $true
             }
       )
       MemberSettings = @{
             AllowCreateUpdateChannels = $false
             AllowDeleteChannels = $false
             AllowAddRemoveApps = $false
             AllowCreateUpdateRemoveTabs = $false
             AllowCreateUpdateRemoveConnectors = $false
       }
}

##Add Team to group
New-MgTeam -BodyParameter $TeamParam

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

##Add Group to tenant group lifecycle policy
Add-MgGroupToLifecyclePolicy -GroupLifecyclePolicyId (Get-MgGroupLifecyclePolicy).id -GroupId $Group.id

สุดท้ายนี้ หากทีมควรพร้อมใช้งานภายในเท่านั้น (ตามพารามิเตอร์ IsInternal) เราจะใช้การตั้งค่าไดเรกทอรี Azure AD เพื่อบล็อกการเพิ่มผู้ใช้ที่เป็นแขก และใช้ PNP เพื่อกำหนดการตั้งค่าการแชร์ไซต์เพื่อบล็อก การแบ่งปันข้อมูลภายนอก

##If the Team is internal only, block guest access and external sharing
if($InternalOnly){

##Block Guest Access to Group if required
$Template = Get-MgDirectorySettingTemplate | ?{$_.displayname -eq "Group.Unified.Guest"}

$TemplateParams = @{
       TemplateId = "$($template.id)"
       Values = @(
             @{
                    Name = "AllowToAddGuests"
                    Value = "false"
             }
       )
}
New-MgGroupSetting -BodyParameter $TemplateParams -GroupId $Group.id

##Connect to PNP
Connect-PnPOnline -ManagedIdentity -Url $adminURL

##Set Sharing policy to internal only
$site = Set-pnptenantsite -SharingCapability Disabled -Url $url

}

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

การเรียกใช้สคริปต์

การเรียกใช้สคริปต์ผ่าน Azure Automation นั้นตรงไปตรงมาและพร้อมท์ให้ใส่พารามิเตอร์ในขณะรันไทม์ (รูปที่ 2)

การตรวจสอบทีมงาน

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

การเช็คอินทีม ทีมจะได้รับการจัดเตรียมการตั้งค่าที่ให้ไว้ และข้อความ "ยินดีต้อนรับ!" มีช่องสัญญาณอยู่ (ดังรูปที่ 4)

สุดท้ายนี้ ไม่สามารถเพิ่มแขกภายนอกเข้าทีมได้ แสดงว่าการตั้งค่าไดเร็กทอรีถูกนำไปใช้เรียบร้อยแล้ว (ดังแสดงในรูปที่ 5)

การสร้างทีมอัตโนมัติ

ด้วยความพยายามเพียงเล็กน้อย การจัดเตรียม Teams ในองค์กรสามารถทำให้เป็นอัตโนมัติได้ เพื่อตอบสนองความต้องการของธุรกิจตลอดจนไอที การเรียกใช้สคริปต์โดยตรงจาก Azure Automation เป็นเรื่องปกติ แต่การก้าวไปข้างหน้าและพิจารณาวิธีการต่างๆ เพื่อทริกเกอร์ Runbook ช่วยให้องค์กรต่างๆ มีความคิดสร้างสรรค์ในการจัดโครงสร้างกระบวนการนี้ เมื่อสคริปต์หลักพร้อมแล้ว ทำไมไม่เรียกใช้ runbook จากเครื่องมือ ITSM ของคุณล่ะ หรือจาก PowerApp? ซึ่งสามารถทำได้ค่อนข้างง่ายโดยใช้ Webhook และเรียกใช้จากแอปพลิเคชันที่คุณเลือกในขณะที่ส่งพารามิเตอร์ที่ต้องการ คุณสามารถสร้าง Webhook ได้ใน Azure Automation ดังแสดงในรูปที่ 6 ซึ่งมีการกล่าวถึงในรายละเอียดเพิ่มเติมในชุดนี้เกี่ยวกับวิธีใช้การทำงานอัตโนมัติของ Azure เพื่อทำงานกับ SharePoint Online

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

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

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