Graph PowerShell SDK'sıyla SharePoint Çevrimiçi Dosyalar Raporu Oluşturma

Grafik PowerShell SDK'sını Kullanmak için SharePoint Çevrimiçi Dosyaları Rapor Komut Dosyasını Güncelleştirme

Temmuz 2022'de, SharePoint Online belge kitaplığındaki dosyaları raporlamak için Grafik API'lerini kullanma hakkında yazmıştım. Komut dosyası yapısı basitti: bir site seçin, site içinde bir belge kitaplığı seçin ve kitaplıkta bulunan dosya ve klasörleri rapor edin. Grafik API'lerini kullanarak SharePoint Online ile çalışmak benim için ilk fırsattı ve çok değerli bir öğrenme deneyimiydi.

Zaman ve teknoloji ilerliyor ve aynı işi Microsoft Graph PowerShell SDK ile yapmak mümkün. Çalışması daha kolay olduğu için mümkün olduğunda Graph PowerShell SDK'yı kullanmayı tercih ediyorum. Cmdlet'ler gerektiğinde erişim belirteçlerini yeniler ve verileri getirirken sayfalandırmayla ilgilenir. Cmdlet'ler PowerShell nesnelerinin çıktısını verir vb. Elbette, Graph PowerShell SDK'nın bazı rahatsız edici zaafları var, ancak genellikle mümkün olduğunda Graph API istekleri yerine cmdlet'lerini kullanmaya çalışıyorum.

Microsoft, 2023'te Graph PowerShell SDK'nın V2'sini yayımladı. SDK'nın SharePoint Online içeriğiyle baş etme konusunda ne kadar yetenekli olduğunu keşfetmek için betiği, Graph SDK cmdlet'lerini kullanacak şekilde yeniden yazmaya karar verdim. Microsoft, SharePoint Online yönetimi için, SharePoint Online yönetimi PowerShell modülünde bulunan bazı işlevleri taklit eden bir önizleme Grafik API'sine sahiptir. Bu modülü geliştirmek için fazla ilerleme kaydedilmedi ve bu konuyu burada ele almıyorum.

SharePoint Online, üç nokta menüsünde Excel'e Aktar seçeneğini içerir. Bu seçenek, SharePoint sitesindeki geçerli konuma bağlanmak ve öğeler ve klasörler hakkındaki bilgileri Excel çalışma kitabındaki bir tabloya aktarmak için bir Microsoft Excel Web Sorgu Dosyası (.iqy) oluşturur. Dışa aktarmanın varsayılan görünümde gösterilen tüm özellikleri içermesi faydalıdır. Açıklamak üzere olduğum komut dosyası yerine bu seçeneği kullanabilirsiniz, ancak o zaman Graph SDK cmdlet'lerini kullanarak SharePoint Online ile nasıl etkileşim kuracağınızı öğrenemezsiniz!

Siteler, Sürücüler ve DriveItems

İnsanlar SharePoint Online siteleri kavramına aşinadır. Komut dosyası, eşleşen görünen adlara veya açıklamalara sahip siteleri aramak için Get-MgSite cmdlet'ini kullanarak başlar. İlk örnek bir dize kullanarak, ikincisi ise bir değişken kullanarak arama yapar:

Get-MgSite -Search 'Projects'
$SiteName = 'Office 365'
Get-MgSite -Search ($SiteName)

SharePoint Online, oturum açan kullanıcının erişemediği siteleri hariç tutmak için site kümesini keser. SharePoint yöneticisi veya Genel yönetici rollerine sahip hesaplar bile site üyesi olmadıkları sürece siteye erişemez. Get-MgSite tarafından döndürülen siteler, Teams'in özel ve paylaşılan kanalları için oluşturulan siteleri içerir. Komut dosyası bunu kullanıcıdan bir site seçmesini isteyerek gerçekleştirir. Döndürülen değer, şuna benzeyen bir site tanımlayıcı içerir:

Office365itpros.sharepoint.com,acfe74d8-edfb-436d-924b-e018666605ee,a2aba197-5f1d-4864-a2c7-4daf0ff6379b

SharePoint Online sitelerinde Belgeler (İngilizce) adı verilen varsayılan bir belge kitaplığı bulunur. Ancak bir site birden fazla belge kitaplığını kapsayabilir. API terimlerinde bunlara sürücüler denir. Get-MgSiteDrive cmdlet'i bir sitedeki sürücü kümesini getirir:

[array]$Drives = Get-MgSiteDrive -SiteId $Site.Id

Her sürücünün şuna benzeyen bir tanımlayıcısı (ID) vardır:

b!2HT-rPvtbUOSS-AYZmYF7pehq6IdX2RIosdNrw_2N5t7xp_DBXMQTalVjpKlwdxk

Bir site tanımlayıcı ve bir sürücü tanımlayıcıyla, sürücüdeki öğeleri (sürücü öğelerini) getirebiliriz. Sürücüler dosya ve klasörleri içerir; bu nedenle, iki tür öğeyi işlemek için biraz çalışma yapılması gerekir. Komut dosyası, iç içe geçmiş klasörlerdeki öğelerin yinelemeli olarak işlenmesi de dahil olmak üzere, bir klasördeki dosyaları işlemek için Get-DriveItems adlı bir işlev içerir. Başlamak için komut dosyası kök (üst düzey) klasörde başlar:

Get-DriveItems -Drive $Drive.Id -FolderId "root"

Her dosya için toplanan bilgiler, dosyanın görünen adını, ait olduğu klasörü, yazarı ve dosyayı en son kimin değiştirdiğini, oluşturulduğu ve son değiştirildiği tarihleri, dosya boyutunu ve dosyaya saklama ve duyarlılık etiketleri atanıp atanmadığını içerir. Şekil 1, çalışan betiği göstermektedir.

Test ettiğim en büyük klasörde 6.523 dosya bulunuyordu.

Bir Dosyanın Saklama Etiketini Alma

Saklama etiketleri, Office 365 E3 ve üzeri sürüme sahip kiracılar tarafından desteklenir. Her kiracı bekletme etiketleri kullanmaz; bu nedenle yapılacak ilk şey, bekletme etiketlerinin mevcut olup olmadığını kontrol etmektir. Komut dosyası, saklama etiketlerini kontrol etmek için Get-MgSecurityLabelRetentionLabel cmdlet'ini kullanır. Cmdlet'in çalıştırılması RecordsManagement.Read.All izni için izin gerektirir.

# Discover if the tenant uses retention labels
[array]$RetentionLabels = Get-MgSecurityLabelRetentionLabel
If ($RetentionLabels) {
    $Global:RetentionLabelsAvailable = $true
} Else {
    $Global:RetentionLabelsAvailable = $false
}

Komut dosyası daha sonra bir dosyanın saklama etiketini almaya çalışıp çalışmayacağını bilir. Graph SDK cmdlet'leri, saklama etiketlerinin yönetimini kapsar ancak saklama etiketi bilgilerinin bir dosyadan alınmasını kapsamaz. Saklama etiketini almak için komut dosyası bir Grafik isteği kullanır:

If ($RetentionLabelsAvailable -eq $true) {
  Try {
    $Uri = ("https://graph.microsoft.com/v1.0/drives/{0}/items/{1}/retentionLabel" -f $Drive, $File.Id)
   [array]$RetentionLabelInfo = Invoke-MgGraphRequest -Uri $Uri -Method Get
   RetentionLabelName = $RetentionLabelInfo.name
   } Catch {
   Write-Host ("Error reading retention label data from file {0}" -f $File.Name) 
   }
}

Bir Dosyanın Hassasiyet Etiketini Alma

Get-MgBetaUserSecurityInformationProtectionSensitivityLabel cmdlet'i, oturum açmış kullanıcı hesabında mevcut olan (yayınlanan) duyarlılık etiketlerini alır ve bu, InformationProtectionPolicy.Read izni için izin gerektirir. Bu kod, duyarlılık etiketleri kümesini getirmek için cmdlet'i çalıştırır ve etiket tanımlayıcısından ve adından bir karma tablo oluşturur. Duyarlılık etiketleri tarafından desteklenen dosya türlerini içeren bir dizi de tanımlanır.

$Account = (Get-MgContext).Account
[array]$SensitivityLabels = Get-MgBetaUserSecurityInformationProtectionSensitivityLabel -UserId $Account
If ($SensitivityLabels) {
    $Global:SensitivityLabelsAvailable = $true
    [array]$Global:ValidFileTypes = "docx", "pptx", "xlsx", "pdf"
    $Global:SensitivityLabelsHash = @{}
    ForEach ($Label in $SensitivityLabels) {
        $SensitivityLabelsHash.Add($Label.Id, $Label.Name)
    }
} Else {
    $Global:SensitivityLabelsAvailable = $false
}

Bir dosyanın duyarlılık etiketini almak için komut dosyası, extractSensitivityLabels API'sini kullanır. Bir dosyanın birden fazla duyarlılık etiketi olabilir ancak yalnızca bir etiket, hak yönetimi tabanlı şifreleme yoluyla koruma uygulayabilir. Gördüğünüz gibi POST isteği kullanılıyor. Bunun nedeni, API'nin SharePoint Online sitesini duyarlılık etiketinin ayrıntılarıyla güncellemesidir. Daha önceki bir yazımda da belirttiğim gibi bu işlem uyumsuz etiket hatalarının oluşmasına neden olabilir.

If ($SensitivityLabelsAvailable -eq $true) {
  # Only check for sensitivity labels if they are available
  $FileType = $File.Name.Split(".")[1]
  If ($FileType -in $ValidFileTypes) { 
    $Uri = ("https://graph.microsoft.com/beta/sites/{0}/drive/items/{1}/extractSensitivityLabels" -f $Site.Id, $file.id)
    Try {
     [array]$SensitivityLabelInfo = Invoke-MgGraphRequest -Uri $Uri -Method POST 
     If ($SensitivityLabelInfo.labels.sensitivityLabelId) { 
       [array]$LabelName = $SensitivityLabelsHash[$SensitivityLabelInfo.labels.sensitivityLabelId]
     } Catch {
        Write-Host ("Error reading sensitivity label data from file {0}" -f $File.Name) 
       }
     }
}

Bazen dosyalardan hassasiyet etiketleri okunurken hatalar meydana gelebilir ve şunun gibi bir mesaj görürsünüz:

Bölüm 1 - Office 365'e Genel Bakış - Final.docx dosyasından duyarlılık etiketi verileri okunurken hata oluştu

Bunun olmasının bir nedeni, bir dosyanın duyarlılık etiketi yerine Office Bilgi Hakları Yönetimi (IRM) tarafından korunmasıdır. Çözüm, dosya bilgilerinin Belgeyi Koru bölümünü açarak ve korumayı sınırsız erişime ayarlayarak IRM'yi dosyadan kaldırmaktır (Şekil 2).

Diğer bir neden ise dosyaya, kiracıdan kaldırılmış veya bir alt etiket olarak değiştirilmiş veya bir alt etiketten değiştirilmiş bir duyarlılık etiketi atanmasıdır. Buradaki çözüm, (her zaman bir dosyayı açma hakkına sahip olan) yazardan dosyayı açmasını ve farklı bir duyarlılık etiketi atamasını istemektir. API'nin başarısız olmasının başka nedenlerinin de mevcut olduğundan eminim. Sadece bu koşullarla karşılaşmadım.

Rapor Çıktısı

Komut dosyası, dosyaları dakikada 225 ila 300 dosya arasında işler. Genel olarak, bir sitede duyarlılık etiketi bulunan dosya sayısı ne kadar az olursa, komut dosyası o kadar hızlı çalışır. Betiği daha hızlı çalıştırmak için, kiracıda tanımlanan duyarlılık etiketleri kümesi hakkında bilgi getiren satırları ve bir dosyadan duyarlılık etiketini almak için extractSensitivityLabels API'sini çağıran satırları kaldırmak üzere kodu düzenleyin.

Çıktı bir PowerShell listesidir (Şekil 3'te gösterilmektedir). Komut dosyası ayrıca listenin içeriğini bir CSV dosyasına aktarır.

Komut dosyasının tamamını GitHub'dan indirebilirsiniz.

Üretken Yapay Zeka Dijital Atıkları Tehlikeli Hale Getiriyor

Dosyaları SharePoint sitelerinde yalnız bırakma eğilimi mevcuttur. Saklama politikaları, artan dosya sayılarının kontrol altında tutulmasına yardımcı olur ancak daha uzun saklama süresine sahip saklama etiketine sahip dosyaları kaldırmaz. Şekil 3'te görebileceğiniz gibi, kullandığım sitelerden bazıları 2017'ye kadar uzanan dosyalar içeriyor. Kiracı depolama kotası baskı altında olmadığı sürece yöneticilerin eski ve potansiyel olarak yanıltıcı dosyaları bulup kaldırmaya zaman ayırması için hiçbir neden yok.

Ta ki üretken yapay zeka çağı gelene kadar. Microsoft 365 için Copilot gibi araçlar, oturum açan kullanıcının kullanabileceği herhangi bir sitedeki herhangi bir dosyaya erişebilir. Copilot'un bir dosyanın içeriğinin doğru veya alakalı olup olmadığı konusunda hiçbir fikri yoktur. İçerik, Copilot'un kullanıcı istemlerine (isteklerine) yanıt olarak çıktı ürettiği için üzerinde çalışabileceği daha fazla kelime sağlar. Copilot kullanıcıları oluşturulan çıktıyı incelemediği sürece yanlış bilgilerin sızma potansiyeli vardır. Bu, dijital enkazın yerinde birikmesine izin vermek yerine eski ve kullanılmayan dosyaları SharePoint Online'dan kaldırmak için iyi bir nedendir.

Bu betiğin insanların SharePoint Online sitelerinde gezinmek ve ne kadar eski içeriğin kaldığına dair fikir edinmek için Microsoft Graph PowerShell SDK'yı nasıl kullanacaklarını anlamalarına yardımcı olacağını umuyoruz. Mantıksal bir sonraki adım, tutulması gereken öğeleri kaldırmak ve geri kalanını Öğe Sil API'si tarafından kaldırılmak üzere girdi olarak kullanmak için CSV dosyasını düzenlemek olabilir. Bu başka bir yazıya değer bir konu!

İlgili makaleler