Otomasyon Sayesinde Ekipleri Düzenli Tutmak

Grubun Yayılması Sorunu

Microsoft 365 Grupları uzun zamandır ortalıkta dolaşıyor ve Paylaşılan Posta Kutularına bir alternatif ve korkunç Ortak Klasörlerin potansiyel bir alternatifi gibi şüphesiz bazı iyi kullanımlar olsa da, Microsoft Teams ile gerçekten büyük ilerleme kaydettiler. Her Ekip bir Microsoft 365 Grubu tarafından desteklenir ve her Grup, platformun farklı alanlarından çeşitli bileşenler içerir ve birden fazla kullanım senaryosuna sahip tek bir nesne (bir tür) oluşturur.

Grubun dağılması sorunu Teams'e özgü değildir, ancak Teams'in hızlı benimsenmesi ve son kullanıcılar için varsayılan olarak kolay oluşturulması, meşgul kiracı yöneticilerinin ortamlarını düzenli tutmalarına kesinlikle yardımcı olmamıştır. Son kullanıcılara Teams'in sorumlu bir şekilde nasıl yönetileceği konusunda eğitim sağlamak yardımcı olabilir, ancak Microsoft 365'teki çoğu şey gibi bu da biraz hareketli bir hedef olabilir.

Yöneticilerin kullanabileceği, Grupları/Ekipleri biraz daha kolaylaştıran çeşitli kontroller mevcuttur, ancak yerel olarak birleşik, uçtan uca bir çözüm yoktur. Bununla birlikte, biraz yaratıcılık ve biraz otomasyonla, Teams oluşturma işlemini çok fazla yük olmadan kontrol etmenin yolları var.

Not: Bu makalede özetlenen kod örneklerinin tümü, kendi çözümünüzü kullanmaya başlamanıza yardımcı olmak için GitHub'da mevcuttur.

Kontrol Edilecek Anahtar Alanlar

Kiracınızdaki her şeyi düzenli tutmak için Teams'in daha ayrıntılı düzeyde kontrol edilmesi yararlı olan bazı önemli alanları vardır. Teams otomasyon komut dosyalarınızı planlarken, farklı Teams türleri için kuralları tanımlamaya gerçekten yardımcı olabileceğinden aşağıdaki alanların dikkate alınması önemlidir.

Grup Adlandırma: Microsoft Entra yönetim merkezindeki grup adlandırma ilkeleri, Microsoft 365 Grupları (ve Ekipleri) için bazı temel adlandırma kuralı işlevlerine izin verir, ancak gerçekte ciddi anlamda esneklikten yoksundurlar. Grup adlarını statik kullanıcı özelliklerine dayandırmak teoride iyi bir fikirdir ancak departmanlar arası Ekipler veya dahili ve harici olarak kullanılabilen Ekipler arasında ayrım yapılması gibi bazı önemli kullanım durumlarını gözden kaçırır. Adlandırmanın büyük kuruluşlarda yararlı olabilecek başka bir yönü de kullanılan SharePoint sitesi URL'sinin denetlenmesidir. Varsayılan olarak Microsoft 365, ilişkili sitenin URL'sini tasarlamak için Grup posta takma adını kullanır. Kiracı içindeki SharePoint yapısına bağlı olarak bu yeterince ayrıntılı olmayabilir.

Grubun Sona Ermesi: Grubun sona ermesi, eski Grupları kiracınızdan çıkarmanın yararlı bir yoludur. Azure AD Grup Yaşam Döngüsü ilkesi bunu yapılandırmanın kolay bir yoludur, ancak yalnızca tek bir ilke mevcuttur ve tüm grupları buna dahil etmediğiniz sürece, dahil etmek veya hariç tutmak istediğiniz her grup için güncelleştirilmesi gerekir.

Erişim ve Paylaşım Denetimleri: Bir kuruluştaki farklı Grup veya Ekip türlerinde dikkate alınması gereken farklı erişim ve paylaşım düzeyleri vardır. Örneğin, müşteriye yönelik bir proje Ekibinin, bir İK departmanı ekibinden çok farklı bir harici erişim yapılandırmasına sahip olması gerekir. Farklı Grup türlerine yönelik yapılandırma, Hassasiyet Etiketlerini SharePoint siteleri, Microsoft Teams ve M365 Grupları ile kullanmaya ilişkin bu üç bölümlü seride açıklandığı gibi, Hassasiyet etiketleri kullanılarak kolayca yapılandırılabilir. Ne yazık ki, duyarlılık etiketlerinin programlı olarak atanması, Graph API ile devredilmiş izinlerin kullanılmasını gerektirir ve etkileşimli olmayan bir şekilde çalışırken bunu başarmak zordur. Bu örneğin amacı doğrultusunda, grup ve site ayarlarını etiket kullanmak yerine doğrudan yapılandırıyorum.

Sahiplik: Artık sahipsiz Gruplar (artık sahibi olmayan Gruplar) Microsoft 365'te yaşamın bir gerçeğidir. Bunu, Grup Sahipliği Yönetişim İlkeleri hakkındaki bu makalede tartışılan ilkeler veya komut dosyaları aracılığıyla yönetmeye yönelik bazı yöntemler vardır. . Gruplar, oluşturma sırasında varsayılan olarak en az bir sahibin olmasını gerektirir, ancak en az iki sahibin olması iyi bir fikirdir.

Yetki Yönetimi: Hassas Gruplar için ilk kurulum işin yalnızca yarısıdır. Belirli Gruplara veya sitelere verilen erişimin sürekli olarak incelenip onaylanmasını sağlamak önemlidir. Bu, birçok yöneticinin karşılaştığı ve Microsoft 365'e özgü olmayan daha geniş bir sorundur. Kaynaklara erişimin yaşam döngüsünü yönetmek, ortamınızı güvende tutmanın anahtarıdır. Bunu kontrol altına almanın iyi bir yolu, bu seride tartışıldığı gibi Yetki Yönetimi'dir: Yetki yönetimi kılavuzu.

Nereden başlamalı?

Bahsettiğim alanlar, Microsoft 365'te bulunan ve kendi başlarına bir çözümün parçasını temsil eden farklı çözümlerden ve ayarlardan yalnızca birkaçıdır. Her bir parçayı bir araya getirmek ve otomatikleştirmek, gerçekten değer kattığımız (ve zamandan tasarruf ettiğimiz) noktadır.

Doğrudan bir çözüm oluşturmaya atlayan Azure Otomasyonu, güvenilir ve emniyetli bir şekilde çalıştığı için böyle bir şeyi otomatikleştirmek için kolayca iyi bir seçimdir. Ayrıca Azure Otomasyonunun Microsoft 365 ve Microsoft Graph SDK ile nasıl kullanıldığını gösteren çok sayıda iyi örnek çevrimiçi olarak mevcuttur.

Ancak Graph API'yi kullanırken, özellikle de SharePoint Online'ı yapılandırmak için bazı sınırlamalar vardır. Microsoft yakın zamanda Graph beta uç noktasına SharePoint Çevrimiçi Kiracı Ayarları için (çok) sınırlı Microsoft Graph desteği ekledi ancak bu, henüz her siteyi yapılandırmak için gereken ayrıntı düzeyine izin vermiyor. Bu sorunu aşmak için PNP PowerShell modülü boşlukları doldurur.

Ortamı hazırlayın

Azure AD'de kayıtlı bir uygulama oluşturmaya ve gerekli kimlik doğrulama ve izin parametrelerini oluşturmaya yönelik pek çok öğretici vardır, bu nedenle burada bu yapılandırma üzerinde çok fazla durmayacağım. Kısacası, yönetilen kimliklerin Microsoft Graph SDK ile kullanılması hakkındaki bu makaleye benzer şekilde, sistem tarafından atanan yönetilen kimliğe sahip yeni bir Otomasyon Hesabı sağlıyoruz. Otomasyon Hesabı oluşturulduktan sonra yönetilen kimlik için aşağıdaki uygulama izinleri gereklidir:

• GroupMember.ReadWrite.All (Grup üyeliğini yönetmek için)
• Group.Create (Grup oluşturmak için)
• User.ReadWrite.All (Grup üyeliğini yönetmek için)
• Group.ReadWrite.All (Grupları yönetmek için)
• Directory.ReadWrite.All (Dizin Ayarlarını ve yaşam döngüsü politikalarını yönetmek için)
• Sites.FullControl.All (Site ayarlarını yönetmek için)

Not: Yukarıdaki izinlerde, özellikle "Directory.ReadWrite.All" ile bazı örtüşmeler vardır, ancak komut dosyanız için kolayca değiştirilebilmeleri amacıyla her görev için minimum izni dahil ettim. Directory.ReadWrite.Tüm izinler, şu anda Grupları bir grup yaşam döngüsü politikasına eklemek için gerekli olan yüksek ayrıcalıklı bir izin düzeyidir. Bu ideal değildir ancak daha ayrıntılı bir izin düzeyi sağlanana kadar bunu Microsoft Graph aracılığıyla gerçekleştirmenin tek yolu budur.

Ayrıca aşağıdaki “Office 365 SharePoint Online” izinlerine de ihtiyacımız var:

• Sites.FullControl.All (PNP erişimine izin vermek için)

Aşağıdaki komut dosyası, Microsoft.Graph PowerShell modülünü kullanarak yukarıda listelenen izinleri bir hizmet sorumlusuna atar:

##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
}

Eklenen izinler (Şekil 1'de gösterilmektedir) burada verdiğim örnek için gereklidir, ancak hangi Microsoft Graph izinlerine ihtiyacınız olduğunu bulmanız ve kendi betiğinize göre ayarlamanız önemlidir.

Daha sonra otomasyon hesabının gerekli modüllerin kurulmasına ihtiyacı vardır. Bu örnekte aşağıdaki modüller kullanılmıştır ancak ihtiyaçlarınıza bağlı olarak doğru modüllerin kurulu olduğundan emin olun:

• Microsoft.Graph.Authentication
• Microsoft.Graph.Groups
• Microsoft.Graph.Identity.DirectoryManagement
• Microsoft.Graph.Teams
• PnP.PowerShell
• Az.Accounts (Bu, otomasyon hesabında zaten yüklü olmalıdır)

Komut dosyasını oluşturma

Yeniden kullanılabilir herhangi bir otomasyon görevi için, koda statik referanslar koymaktan mümkün olduğunca kaçınmak istersiniz. Bu sadece komut dosyalarını yeniden kullanılabilir hale getirmek için iyi bir uygulama değildir, aynı zamanda başkalarının da komut dosyanızı yeniden kullanmasına ve geliştirmesine yardımcı olur. Bu, çalışma zamanında iletilen koddaki parametrelerin oluşturulmasıyla yapılır. Bu komut dosyasında, aşağıdaki giriş parametrelerini tanımlıyorum:

• SiteURL - Bu, ilişkili SharePoint sitesinin göreli URL'sidir. Grubun posta takma adını doldurmak için kullanılır ve bu daha sonra site URL'sini oluşturmak için kullanılır.
• AdminURL - Bu, SharePoint Online örneğinizin yönetici URL'sidir.
• GroupName - Bu, Ekip için oluşturulacak Grubun adıdır.
• GroupDescription - Bu, Grubun açıklama değeridir.
• DefaultOwner1 - Bu sitenin sahibidir.
• DefaultOwner2 - Minimum iki sahip istediğimiz için bu ikinci sahiptir.
• InternalOnly - Bu, sitenin yalnızca dahili hale getirilmesi gerekip gerekmediğini tanımlayan bir Boolean değeridir; bunun false olarak ayarlanması siteye harici erişime izin verecektir. Bu konuda daha sonra daha fazla bilgi vereceğiz.

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
)

Bir sonraki önemli alan, otomasyon hesabının yönetilen kimliğini kullanarak Microsoft Graph'a bağlanmaktır. Şu anda bunun, daha sonra Connect-MgGraph cmdlet'ine aktarılacak bir belirteç elde etmek için Get-AzAccessToken cmdlet'ini kullanması gerekiyor. Bağlandıktan sonra v1.0'da bulunmayan dizin ayarı yapılandırmasına izin vermek için beta uç noktasına geçiyoruz. Bu kodu yerel olarak test etmek için makinenizde Microsoft.Graph, AZ ve PNP.PowerShell modüllerinin yüklü olması gerekir.

##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

Grubu oluştururken, isteğin gövdesini oluşturmak ve bunu New-MgGroup cmdlet'ine iletmek için yukarıda belirtilen parametre değişkenlerini kullanırız. Ardından, devam etmeden önce grubun tamamen oluşturulmasına zaman tanımak için komut dosyasını 60 saniye duraklatın. Bu, hataları önlemenin temel bir yoludur ve esas olarak başlamanız için burada yer almaktadır. Kendi çözümünüzü üretime geçirmeden önce, daha sağlam hata yönetimi eklemeye değer. Grubun gövdesi temel Grup ayarlarını içerir ve sahip olabileceğiniz her türlü kullanım senaryosuna göre özelleştirilebilir.

##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

Daha sonra, oluşturulan Grup için bir Ekibi etkinleştirmek için aynı süreci izliyoruz. Bu yine ihtiyaçlarınıza göre özelleştirilebilir. Örneğin “Hoş Geldiniz!” adında bir kanal oluşturmayı seçtim. her Takım için. Bu oldukça basit bir örnektir ancak belirli Ekip düzenleri ve özelleştirmeleri oluşturmak için özel kanallar/kanal mesajları vb. ile genişletilebilir.

##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

Ayrıca Ekibi kiracıların Grup Yaşam Döngüsü Politikasına eklemeyi de seçtim. Politikanız tüm gruplar için yapılandırılmışsa buna gerek kalmayacaktır ancak birçok kuruluş, önemli Grupları yaşam döngüsü politikalarının dışında bırakmak isteyecektir. Politikada herhangi bir hariç tutma parametresi bulunmadığından Grup oluşturulduğunda bunun eklenmesi gerekir.

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

Son olarak, Ekibin yalnızca dahili olarak kullanılabilir olması gerekiyorsa (IsInternal parametresine göre), konuk kullanıcıların eklenmesini engellemek için Azure AD Dizini ayarını uygularız ve site paylaşım ayarlarını engelleyecek şekilde yapılandırmak için PNP'yi kullanırız. Verilerin harici paylaşımı.

##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

}

Farklı giriş parametreleri kullanılarak her Takımın tam konfigürasyonu tamamen özelleştirilebilir. Bu basit bir dahili/harici Ekip örneğidir, ancak betiğin farklı Ekip seçeneklerine izin verecek şekilde nasıl yapılandırılacağı konusunda size bir fikir verecektir.

Komut Dosyasını Çalıştırma

Betiği Azure Otomasyonu aracılığıyla çalıştırmak basittir ve çalışma zamanında parametreler istenir (Şekil 2).

Takımın Doğrulanması

Komut dosyası tamamlandıktan sonra, tanımlanan ayarlarla sağlanan ve kullanıma hazır yeni bir Ekip olacaktır. SharePoint Online'ı kontrol ettiğimizde (Şekil 3'te gösterilmektedir), sitenin yalnızca dahili dosya paylaşımına izin verecek şekilde kısıtlandığını görüyoruz.

Teams'te check-in yapılırken, Ekip'e sağlanan ayarlar ve "Hoş Geldiniz!" kanal mevcut (Şekil 4'te gösterildiği gibi)

Son olarak, harici konuklar Ekibe eklenemiyor, bu da dizin ayarının başarıyla uygulandığını gösteriyor (Şekil 5'te görüldüğü gibi)

Ekip Oluşturmayı Otomatikleştirme

Nispeten küçük bir çabayla, bir kuruluşta Teams'in sağlanması, BT'nin yanı sıra işin gereksinimlerini de karşılayacak şekilde otomatikleştirilebilir. Betiği doğrudan Azure Otomasyonundan çalıştırmak iyidir, ancak bunu bir adım ileriye taşımak ve runbook'u tetiklemek için farklı yöntemlere bakmak, kuruluşların bu süreci nasıl yapılandıracakları konusunda yaratıcı olmalarına olanak tanır. Çekirdek komut dosyası yerleştirildikten sonra neden runbook'u ITSM araçlarınızdan tetiklemiyorsunuz? Veya bir PowerApp'ten mi? Bu, bir Webhook kullanılarak ve gerekli parametreleri geçerken seçtiğiniz uygulamadan çağrılarak oldukça kolay bir şekilde yapılabilir. Şekil 6'da gösterildiği gibi Azure Otomasyonu'nda bir Web kancası oluşturulabilir. Bu, SharePoint Online ile çalışmak için Azure otomasyonunun nasıl kullanılacağına ilişkin bu seride daha ayrıntılı olarak tartışılmaktadır.

Burada verdiğim çok basit örnek GitHub'da mevcut ve hata işleme ve optimizasyon açısından çok az şey içeriyor. Ancak kendi sürecinizi geliştirirken başlamak için iyi bir yerdir ve Teams'in otomatikleştirilmiş bir süreç sağlamasına izin vermek, kullanıma hazır çok daha fazla kontrol sağlar.

Microsoft Platform Geçiş Planlaması ve Konsolidasyonu

Kullanıcılar için maliyetleri, riskleri ve kesintileri en aza indirirken geçiş planlamasını basitleştirin, geçiş zorluklarının üstesinden gelin ve projeleri daha hızlı tamamlayın.