Microsoft 365 PowerShell Komut Dosyasında Uzmanlaşma

Microsoft 365 PowerShell'in Üç Temelini İyi Yapın ve Komut Dosyası Oluşturmak Artık Çok Daha Kolay

Bazılarınızın bildiği gibi çok fazla PowerShell yazıyorum. Çok iyi bir PowerShell geliştiricisi değilim. Kodumun çoğu, hata işleme gibi temelleri göz ardı ediyor çünkü komut dosyalarını, eksiksiz çözümler geliştirmek yerine işin yapılmasına ilişkin ilkeleri keşfetmek ve açıklamak için yazıyorum. Her durumda, bu benim bahanem.

Atlanta'daki TEC 2023 konferansında, Microsoft 365 için PowerShell komut dosyalarının nasıl yazılacağı konusunda bir teste tabi tutuldum. Microsoft 365 iş yükleriyle etkileşimde bulunmak için PowerShell'i ne kadar çok kullanırsam, yöneticiler için PowerShell bilgisinin özünün üçe indiğinden o kadar eminim şeyler:

• Nesneleri alın.
• Nesneleri yorumlayın.
• Nesneleri rapor edin.

Komut dosyalarının %95'i alma, yorumlama ve raporlama modelini takip eder. Bu, etkileşimli olarak çalışan betikler ve Azure Otomasyonu runbook'ları gibi bir zamanlamaya göre çalışan betikler için geçerlidir. Elbette, posta kutusu ayarları gibi şeyleri güncellemek için bazı küçük ayrıntılar olabilir, ancak genel olarak komut dosyalarım bu modeli takip eder. Yöneticilerin modeli iyi bir şekilde yürütmenin temellerini öğrenmeleri halinde, karmaşık otomasyon projelerini bile idare edebilecek kadar PowerShell uzmanlığına sahip olacaklarına inanıyorum. Neden böyle düşündüğümü açıklayayım.

Nesneleri Alma

Çoğu durumda otomasyon ihtiyacı, posta kutuları, siteler veya ekipler gibi bir dizi nesneye bir şeyler yapılması gerektiğinden ortaya çıkar. Komut dosyaları, farklı Microsoft 365 uç noktalarına bağlanmak için Connect-MgGraph veya Connect-ExchangeOnline gibi cmdlet'leri çalıştırarak ve ardından bazı değişkenleri başlatarak başlayabilir, ancak ilk gerçek iş, getirme sırasında yapılır. işlenecek nesneler.

Tüm Microsoft 365 modülleri, nesneleri getirmek için cmdlet'lerle iyi bir şekilde donatılmıştır. Bazen aynı nesneleri getirebilen birden fazla cmdlet bulunur; bu, işin püf noktasının hangi cmdlet'in kullanılacağı konusunda doğru seçimi yapmak olduğu anlamına gelir. Bu karar bağlama bağlıdır. Buna daha sonra değineceğiz.

Tablo 1, Microsoft 365'te kullanılan bazı temel nesneleri ve bu nesneleri getirmek için kullanılabilen cmdlet'leri listelemektedir.

Tablo 1'de göze çarpan şey, Microsoft Graph PowerShell SDK cmdlet'lerinin önemli Microsoft 365 nesnelerinin çoğuna erişebilmesidir. Posta kutuları bariz istisnadır. SDK cmdlet'leri mesajlarla etkileşimde bulunmak için kullanılabilir, ancak bu yalnızca Kullanıcıların uç noktası aracılığıyla yapılır. Örneğin, paylaşılan posta kutularını veya oda posta kutularını getirmek için SDK cmdlet'lerini kullanamazsınız.

Filtreleme ve Limitler

Bir sınıra ulaşmazsanız belirli türdeki her nesneyi elde etmek nispeten basittir. Microsoft 365, kullanıcıların gerekenden daha fazla kaynak kullanamamalarını sağlamak için farklı yerlerde kısıtlamalar uygular. PowerShell farklı değil. Elbette tek bir komutla birçok nesneyi getirebilirsiniz, ancak genel kural yalnızca işlemek istediğinizi almaktır.

Örneğin, Get-ExoMailbox cmdlet'ini filtresiz çalıştırmayın çünkü sonuçta kullanıcı, paylaşılan ve oda posta kutularından oluşan bir koleksiyonla karşılaşacaksınız. Bunun yerine, gereken posta kutusu türünü bulmak için RecipientTypeDetails parametresini belirtin. Daha da iyisi, ihtiyaç duyulan kesin nesne grubuna daha fazla odaklanmak için bir filtre ekleyin. İyi biçimlendirilmiş bir sorgu şuna benzer:

[array]$Mailboxes = Get-ExoMailbox -Filter {Office -eq "Dublin"} -RecipientTypeDetails UserMailbox -ResultSize Unlimited

Komut, PowerShell'e iki koşulla eşleşen bir posta kutusu dizisi oluşturmasını söyler: Office özelliği Dublin olarak ayarlanmıştır ve bunlar bir kullanıcı posta kutusudur. Komut eşleşen tüm posta kutularını kabul etmeye hazır. Exchange, farklı cmdlet'ler için farklı filtrelenebilir özellikleri destekler, ancak aynı özelliklerin sıklıkla kullanıldığını göreceksiniz.

Benzer şekilde, ortak bir gereksinim, lisanslara sahip Entra ID kullanıcı hesapları kümesini bulmaktır. Lisanslı hesapların aranması, paylaşılan posta kutuları, Microsoft Rezervasyonları ve benzeri amaçlarla oluşturulan kullanıcı hesaplarını kaldırır. Bu komut, işi yapmak için Get-MgUser cmdlet'ini kullanır:

[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member' and OfficeLocation eq 'Dublin'" -ConsistencyLevel eventual -CountVariable Records -All

Komut, lisansları olan ve OfficeLocation özelliği Dublin olan bir dizi kullanıcı hesabı oluşturur. Filtre çok değerli bir özelliği sorguladığından buna karmaşık sorgu denir. Entra ID açısından bu, sorgunun verilerin tüm kopyaları tutarlı olana kadar beklemesi gerektiği anlamına gelir (bu nedenle Consistencylevel parametresi mevcuttur).

Get-ExoMailbox ve Get-MgUser cmdlet'lerinin farklı türde filtreler kullandığı açıktır. Exchange cmdlet'lerinin kökleri PowerShell'in büyük bir Microsoft sunucu ürünündeki (Exchange Server 2007) ilk uygulamasına dayanır ve o sırada belirlenen sözdizimi kurallarına uyarlar. Graph SDK cmdlet'leri, Graph API sorgu kurallarını çoğaltır ve bu, bu örneklerde görülen farklı sözdizimlerini açıklar.

Ancak altın kuralın yalnızca işlemeniz gereken verileri getirmek olduğudur. İyi filtreler kullanmak bu hedefe ulaşmanın en iyi yoludur.

Nesneleri Yorumlama

Bazı nesneleri bulduğunuzda bir sonraki adım verileri anlamlandırmaktır. Çoğu PowerShell cmdlet'i kullanımı kolay özellikler döndürür ancak bazı Microsoft 365 cmdlet'lerinde dikkat edilmesi gereken birkaç nokta vardır.

Bazı durumlarda, bir özellik için döndürülen değer bir dizidir ve isteyebileceğiniz bilgilerin tamamını elde etmek için biraz çalışma yapılması gerekir. Bir dağıtım listesini kimin yönettiğini bulmaya ilişkin şu örneği düşünün:

Get-DistributionGroup -Identity VIPusers | Format-List ManagedBy

ManagedBy : {tony.redmond, Lotte.Vetler, d36b323a-32c3-4ca5-a4a5-2f7b4fbef31c}

ManagedBy özelliği, her sahip hesabının adını tutar. Sahipler hakkında daha fazla bilgi edinmek için adları Get-ExoMailbox gibi başka bir cmdlet ile kullanın. Örneğin:

[array]$ManagedBy = Get-DistributionGroup -Identity VIPUsers | Select-Object -ExpandProperty ManagedBy

$ManagedBy | Get-ExoMailbox | Format-Table DisplayName, Alias, Name

DisplayName         Alias        Name
-----------         -----        ----
Tony Redmond        Tony.Redmond tony.redmond
Lotte Vetler        Lotte.Vetler Lotte.Vetler
Kim Akers (She/Her) Kim.Akers    d36b323a-32c3-4ca5-a4a5-2f7b4fbef31c

Microsoft Graph PowerShell SDK cmdlet'lerinden bazıları değerli bilgileri gizler. Örneğin, Get-MgGroupMember cmdlet'i grup üyeleri için hesap tanımlayıcılarının bir listesini döndürür:

Get-MgGroupMember -GroupId (Get-MgGroup -Filter "Displayname eq 'System Innovation'").Id

Id                                   DeletedDateTime
--                                   ---------------
eff4cd58-1bb8-4899-94de-795f656b4a18
a3eeaea5-409f-4b89-b039-1bb68276e97d
67105a51-e817-493e-8094-f600babf5f62
d36b323a-32c3-4ca5-a4a5-2f7b4fbef31c

Grup üyelerinin ayrıntılarını istiyorsanız additionalProperties özelliğinden bilgi almak için farklı bir yaklaşım gereklidir:

$GroupId = (Get-MgGroup -Filter "displayName eq 'System Innovation'").Id
Get-MgGroupMember -GroupId $GroupId | Select-Object -ExpandProperty additionalProperties

Key               Value
---               -----
@odata.type       #microsoft.graph.user
businessPhones    {+1 713 633-5141}
displayName       Kim Akers (She/Her)
givenName         Kim
jobTitle          VP Marketing
mail              Kim.Akers@office365itpros.com
mobilePhone       +1 761 504-0011
officeLocation    NYC
preferredLanguage en-US
surname           Akers
userPrincipalName Kim.Akers@office365itpros.com

Siz sormadan önce, verileri bu şekilde döndüren şeyin Grafik olduğunu belirtelim.

Birleşik denetim günlüğü, Microsoft 365 kiracısında kimin neyi ne zaman yaptığına ilişkin değerli bilgiler içeren harika bir kaynaktır. İş yükleri, insanlar uygulamalarla etkileşime girdikçe denetim olaylarını yakalar ve bu olaylar sonunda denetim günlüğüne kaydedilir. Search-UnifiedAuditLog cmdlet'i (son zamanlarda bazı sorunlar yaşanmıştır) günlükteki verileri bulur. AuditData adı verilen JSON biçimindeki bir özellikte pek çok ilginç ayrıntı bulunur. Bu özellikten bilgi alabilmeniz için önce onu JSON'dan dönüştürmeniz gerekir.

Örneğin, bu komut, SharePoint Online'daki dosya düzenlemeleriyle ilgili olayları bulmak için denetim günlüğünü arar:

$Records = search-UnifiedAuditLog -StartDate 18-Oct-2023 -EndDate 19-Oct-2023 -Operations FileModified -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet

Doğru olayı bulduktan sonra AuditData özelliğini dönüştürebiliriz:

$AuditData = $Records[0].AuditData | ConvertFrom-Json

Ve sonra özellikteki tüm alanlar bir komut dosyasında kullanıma hazır hale gelir. Örneğin, değiştirilen belgenin site URL'si aşağıda verilmiştir:

$AuditData.SiteUrl
https://office365itpros.sharepoint.com/sites/BlogsAndProjects/

Bu noktada karşılaşabileceğiniz tüm uç durumlarla nasıl başa çıkacağınızı merak ediyor olabilirsiniz. Deneme yanılma ve iyi internet aramaları normal yanıttır. Birisi muhtemelen karşılaştığınız bir sorunla tanışmış ve üstesinden gelmiştir ve belki yardımcı olabilecek bir Practical365.com makalesi vardır. Sadece ısrarcı ol.

Nesneleri Raporlama

Sonunda, bir komut dosyası gerekli tüm verileri çıkarır ve bir tür rapor oluşturmanın zamanı gelir. Bir komut dosyası tarafından oluşturulan çıktıyı insanların kullanımına sunmanın yaygın yollarından bazıları şunlardır:

• HTML biçiminde bir belge oluşturup yazdırın veya dosyayı SharePoint Online'da saklayın.
• Raporu e-posta yoluyla dağıtma, verileri bir mesajın gövdesine ekleme veya ek olarak ekleme.
• Bilgileri bir Teams kanalına gönderme.
• SharePoint Online sitesindeki listeyi güncelleştirin.

Bu eylemler bir senaryonun son aşamasını işaretler. Bir betiğin herhangi bir şeyi gönderebilmesi, gönderebilmesi veya depolayabilmesi için nesnelerden alınan verilerin genellikle bir dizi veya liste olmak üzere bir PowerShell nesnesinde tutulması gerekir.

Tüm komut dosyalarındaki verileri kaydetmek için aynı yaklaşımı kullanıyorum. İlk önce bir PowerShell listesi oluşturuyorum:

$Report = [System.Collections.Generic.List[Object]]::new()

Daha sonra, komut dosyası bir nesneyi işledikten sonra, yakalanacak veriler, özel bir nesnenin özellikleri doldurularak ve listeye yazılarak işlenir. Performans açısından bu yaklaşım, bir diziye öğe eklemekten daha iyidir çünkü PowerShell her ekleme için diziyi yeniden oluşturur. Birkaç öğe için bu sorun değil ama binlerce öğeyle uğraşırken o kadar da iyi değil. Listeyi güncellemek basittir. Örneğin:

$ReportLine = [PSCustomObject]@{
     TimeStamp       = $M.Received
     Sender          = $M.SenderAddress
     Recipient       = $M.RecipientAddress
     Subject         = $M.Subject
     Status          = $M.Status
     Direction       = $Direction
     SenderDomain    = $SenderDomain
     RecipientDomain = $RecipientDomain
    }
$Report.Add($ReportLine)

Çıktı listesiyle çalışmak kolaydır ve diğer formlara dönüştürülmesi kolaydır. Örneğin, verileri bir HTML dosyasına dahil etmek için komut dosyası listeyi şu şekilde dönüştürebilir:

$HTMLData = $Report | ConvertTo-HTML -Fragment

Microsoft 365 PowerShell Hakkında Daha Fazla Bilgi Edinilecek Çok Şey

Burada PowerShell aracılığıyla Microsoft 365 verileriyle nasıl çalışılacağını öğrenmenin yalnızca yüzeyini çizdik. Umarım başarılı PowerShell betikleri yazmanın genellikle nesneleri alma, işleme ve raporlama formülünü takip ederek yapıldığına dair güçlü inancımı iletmişimdir. Bundan sonra, temelleri ustalıkla tamamlama meselesi. Bu ve insanların PowerShell ile otomasyon sorunlarını nasıl çözdüklerini ve kodlarını nasıl anladıklarını okumak.

Gerçek işlerin yapılması için PowerShell'in kullanılmasıyla ilgili yayınladığımız birçok Practical365.com makalesinin size yardımcı olacağını umuyoruz. Kodlara göz atmak istiyorsanız GitHub depoma göz atmaktan çekinmeyin. Orada bazı çalışan kodlar bile bulabilirsiniz.