Powershell jobs ile paralel çalışma

Bir powershell betiğinde birkaç sunucudan sistem olay kayıtlarını çekmem gerek. Seri olarak bunları yapmak uzun sürdü. Paralel yapmak istedim.

Başlangıçta şöyle yapıyordum:

$ev1 = Get-WinEvent -Computername sunucu1 -FilterhashTable @{Logname="System";Id=4771;StartTime=(Get-Date).AddDays(-1)}
$ev1 = Get-WinEvent -Computername sunucu1 -FilterhashTable @{Logname="System";Id=4771;StartTime=(Get-Date).AddDays(-1)}

Paralel yapmanın birkaç yolu var. Bunlardan biri Powershell Job'larını kullanmak. Her bir sunucudan olayların çekilmesi için Start-Job ile birer görev oluşturdum.

$gorev1 = Start-Job -Name "g1" { Get-WinEvent -Computername sunucu1 -FilterhashTable @{Logname="System";Id=4771;StartTime=(Get-Date).AddDays(-1)} }
$gorev2 = Start-Job -Name "g2" { Get-WinEvent -Computername sunucu2 -FilterhashTable @{Logname="System";Id=4771;StartTime=(Get-Date).AddDays(-1)} }

Bu görevler eşzamanlı olarak bitmeyebilir. Onun için ikisinin de bittiğinden emin olmak için beklemem gerek. Bunu Wait-Job ile yapabilirim ama bu cmdlet çağrıldığında görevleri ekrana basar. Bunu görmek istemediğim için Out-Null ile çıkışı bastırıyorum.

Wait-Job -Jobs $gorev1, $gorev2 | Out-Null

Bu cmdlet işini bitirdikten sonra görevlerimin çıkışını okuyabilirim.

$olaylar1=Receive-Jobs -Job $gorev1
$olaylar2=Receive-Jobs -Job $gorev2

Her görev ayrı uzak sistemlerde çalıştığı için bu paralel çalışma, yaklaşık olarak iki görevin daha uzun süreni kadar zamanda bitiyor. Eğer bu iki görev de aynı yerel veya uzak sistemde çalışıyor olsaydı, duruma göre böyle bir kazanç elde edemeyebilirdim.

Bunu bir de Invoke-Command -Computername sunucuX { ... } -AsJob ile yapmak var.

Profil dosyası olmadan prompt oluşturmak

Tek renkli bir terminal çok tatsız görünüyor. Ama her makinede de profil dosyası oluşturamıyorum, çünkü Execution Policy'yi değiştirmek gerek. O işlere girmeden ne yapabilirim diye düşününce terminale inline bir prompt fonkisyonu yazmak geldi aklıma. En basiti:

function prompt {write-host "$pwd [$(date -u %R)]" -fore blue;"> "}

olabileceği gibi biraz daha yazabilirsem

function prompt {Write-Host $pwd -NoNewLine -ForegroundColor Blue;Write-Host " [$(date -u '%R, %d-%a')]" -;"> "}

de olabilir. Bu tek seçenek değil. Eğer profile.ps1 gibi bir profil dosyamız varsa ve bunu executionpolicy'ye takılmadan tek seferlik çalıştırmak istiyorsak

iex (gc D:\profile.ps1 -raw)

ya da prompt fonksiyonunu bir ortam değişkenine atabilirsek (ki bunu kısıtlı kullanıcı yetkileriyle yapabilirim), örneğin $PROFILE gibi

iex $env:PROFILE

$PROFILE ortam değişkeni şu şekilde tanımlanmış olabilir:

ni -path env: -name PROFILE -value "function profile { write-host `"$pwd [$(date -u %R)]`" -fore blue;`"> `"}"

string'in içinde çift tırnak karakterini yazabilmek back-tick (`) kullandım.

Bu arada, Execution Policy, kısıtlı kullanıcı hakları ile sadece mevcut kullanıcı için betik çalıştırma yetkisini değiştirilebiliyor. Benim olmayan bir makine üzerinde bu ayarı değiştmek istemiyorum, ama elbette:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

de yapılabilirdi.

Unicode - UTF-8 ilişkisi

İlk başta ASCII vardı. Her karakter 8 bitlik (1 byte) verilerle kodlanmıştı. A karakterine 10'luk düzende 65 numarası verilmişti.

Keşke herşey bu kadar kolay olsaydı. Arapça, Çince vs. dillerin de bilgisayarda ifade edilebilmesi için bu standardın büyütülmesi gerekti. Örneği Japon alfabesindeki 負 karakterinin ifadesi için onluk düzende 36000 değeri belirlendi. 65535'e kadar sayıların saklanması için 2 byte gerekti. Ama her karakteri 2 byte ile saklamak istersek bir çok karakter için yüksek basamaklar 0'dan ibaret olacaktı ve dosya boyutları doğrudan 2 katına çıkacaktı. Bunun üstesinden gelebilmek için karakterleri yeterli sayıda byte ile ifade edebilmek için UTF-8, UTF-16 (unicode transformation format) gibi standartlar geliştirildi. Üstelik Unicode karakterler için 2-byte sınırı da yok.

Örneğin Japoncadaki 負 kelimesinin unicode sistemindeki karşılığı 8CA0 ve buna unicode codepoint deniyor. Bu

U+8CA0

şeklinde ifade ediliyor. Kodlama için aşağıdaki tabloya göre hareket ediyoruz.

İlk code point	Son code point	Byte 1	Byte 2	Byte 3	Byte 4
U+0000	U+007F	0yyyzzzz
U+0080	U+07FF	110xxxyy	10yyzzzz
U+0800	U+FFFF	1110wwww	10xxxxyy	10yyzzzz
U+010000	U+10FFFF	11110uvv	10vvwwww	10xxxxyy	10yyzzzz

Bizim sayımız U+800 ile U+FFFF arasında olduğu için bu satıra göre işlem yapacağız. 3 byte ile ifade etmemiz gerek.

Önce sayımızı ikilik düzende (binary) olarak yazalım:

1000 1100 1010 0000
8    C    A    0

Tablonun 3. satırına göre bunu 3 parçaya bölmemiz gerek. Sağdan başlayarak 6 bit alalım. Sonra bunun başına, tablonun 3. satırının Byte-3 sütununda yazıdığı gibi 10 ekleyeceğiz.

10 100000 = A0

Byte-3'ü bu şekilde A0 olarak hesapladık. Benzer şekilde Byte-2'yi de yine tabloya bakarak sonraki en düşük 6 bitlik bölümü alıp başına yine 10 ekleyerek hesaplayacağız.

10 110010 = B2

Byte-2'yi de B2 olarak hesapladık. Geriye Byte-1 kaldı. Bunun için kalan 4 bit veriyi alıp başına 1110 ekleyeceğiz.

1110 1000 = E8

Sonuç: 負 karakteri, Unicode code point olarak U+36000 ifade ediliyor. UTF-8 olarak kaydedilmek istenirse diske 3 byte olarak E8 B2 A0 olarak yazılıyor.

Kayıt defterine powershell ile erişim

Windows kayıt defteri (registry) erişimi grafik arayüzle yapılabildiği gibi reg.exe aracı ile de yapılabiliyor. reg.exe'nin query, add, delete, import, export (bunlarla sınırlı değil) gibi komutları var. Örneğin bir anahtarı bir dosyaya yedeklemek için

reg export HKLM\Software\Microsoft\Windows\CurrentVersion\Run reg_export.reg

gibi bir komut, bir bozulma durumunda da bu anahtarı dosyadan geri yüklemek için

reg import reg_export.reg

yeterli. Benzer şekilde Run anahtarı altındaki değerleri sorgulamak için

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run

kullanılabilir. Bu anahtar altına yeni bir değer eklemek için

reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v YeniDeger /t REG_DWORD /d 9876

Ya da var olanı silmek için

reg delete HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v YeniDeger

Bunlar güzel, ama nesne çıktıları veren, daha yetenekli Powershell cmdlet'lerimiz de var. Bu cmdlet'ler kayıt defterine özel değil, tüm PSDrive nesneleri üzerinde kullanılabilen cmdlet'ler.

Kayıt defterindeki verileri 2 ana kategoride değerlendirelim. Anahtarlar ve bu anahtarların altındaki özellikler. Örneğin

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

bir anahtar, ve bu anahtarın altında oluşturduğum

YeniDeger = (REG_DWORD) 9876

verisi de özellik.

Bir anahtarı üzerinde işlem yaparken *-Item ile biten cmdlet'leri kullanıyoruz. Özellikler için ise *-ItemProperty cmdlet'lerini. Örneğin hedefimiz HKLM\Software\Microsoft\Windows\CurrentVersion\Run anahtarını bir değişkene atmak için Get-Item'ı şu şekilde kullanabiliriz

$anahtar = Get-Item -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run"

Powershell'de HKLM bir PSDrive olduğu için bundan sonra iki nokta üst üste ":" işareti koyarak bir sürücü yolu oluşturdum.

Bu anahtarın altındaki özellikleri (değişken ve değerlerini) dönmek için Get-ItemProperty cmdlet'ini ve -Name parametresini kullanabiliriz.

Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "Program1"

Sadece bu özelliğin değerini göstermek için 

(Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run").Program1

yapmak yeterli.

Aslında bu iki cmdlet'i sadece kayıt defteri erişiminde değil, diğer konularda da kullanabiliyoruz. Örneğin Get-Item'ı ortam değişkeni ProgramData'yı okumak için

Get-Item -Path env:ProgramData

şeklinde kullanabiliriz.

Get-ItemProperty bir öğenin özelliklerini okumak için kullanılır. Bu özellikleri ayarlamak için ise Set-ItemProperty cmdlet'i var. Bir dosyayı read-only (sadece okunbilir) duruma getirmek için şu şekilde kullanım mümkün

Set-ItemProperty -Path "C:\klasor\dosya.txt" -Name IsReadOnly -Value $true

Bir bilgisayara takılmış tüm USB cihazların listesinin tutulduğu HKLM\SYSTEM\CurrentVersion\ENUM\USB altındaki tüm HardwareID değerlerini özyinelemeli olarak listelemek için, kısaltmalarla:

dir "HKLM:\SYSTEM\CurrentControlSet\ENUM\USB" -rec -ea sil | gp | ? {$_.HardwareID} | select HardwareID

 

Windows ISO dosyalarının indirilmesi

Windows update hep yavaştı. Windows ISO dosyası indirme de öyle. Üstelik de düz HTTP üzerinden gerçekleşiyor. Bütün Linux dağıtımları güncellemelerini bile yüksek hızlı HTTPS bağlantıları üzerinden yaparken, Microsoft gibi bir firma bunu ~40 Mbps hızında, güvenli olmayan sunucular üzerinden yapıyor.

Bir Windows ISO dosyası indirmek için

https://www.microsoft.com/en-in/software-download/windows11

sayfasına gidip önce MediaCreationTool.exe'yi indirdikten sonra onu çalıştırıp ISO dosyası indirme süreci başladığında sorumluluk BITS'e bırakılıyor. Arka planda bu işlemi BITS yapıyor.

Get-BitsTransfer -AllUsers

JobId                                DisplayName               TransferType JobState     OwnerAccount
-----                                -----------               ------------ --------     ------------
acb23d6d-f557-4793-a84d-661a0499e879 Windows Dlp Manager       Download     Transferring metin

Kaynak izleyicisinde "Ağ" sekmesine geçip "Al" sütununu azalan şekilde sıraladıktan sonra en üstte svchost süreçlerinden biri en yüksek trafiği yapıyor gözüktü. Bu süreç kimliğini aradığımda BITS'ı buldum.

gcim win32_service | where ProcessId -eq 17730

Sonrasında da Get-BitsTransfer ile işin "Windows Dlp Manager" adı altında gerçekleştiğini buldum. En son olarak Get-NetTCPConnection ile bu sürecin hangi bağlantılarını listelediğimde 80/tcp bağlantısını gördüm.

Get-NetTCPConnection -OwningProcess 17730 | ft RemoteAddress, RemotePort, State -AutoSize

RemoteAddress          RemotePort       State
-------------          ----------       -----
92.223.40.60           80               Established

Powershell'de EFS altyapısını kullanarak dosya şifreleme

EFS (encrypting file system), Windows işletim sisteminin sadece NTFS dosya sistemi üzerinde bir dosya şifreleme yöntemi.

Bilgisayarımızda 2 kullanıcımız var, user1 ve user2. İkisinin de ortak erişiminin olduğu bir klasör olsun. C:\klasor gibi. Bu klasör içinde dosya.txt adında bir dosya var. Bu dosyaya da 2 kullanıcımızın erişimi var. user1 kullanıcısı bu dosyayı aşağıdaki gibi şifrelesin.

(Get-Item -Path "C:\klasor\dosya.txt").encrypt()

Bu işlem sonunda dosya user1 tarafından erişilmeye devam eder. Açılırken bir şifre falan sormaz, ama dosyanın simgesine sarı bir asma kilit sembolü eklenir. Aşağıda biri henüz şifrelenmemiş, diğeri şifrelenmiş 2 dosyanın simgeleri var.

 

Bu dosyayı sistemdeki başka bir kullanıcı açamaz. Dosya sadece NTFS biriminde şifrelenmeye devam edebileceği için dosya FAT veya desteklemeyen başka bir dosya sistemi üzerine taşınamaz. Dosya gezgini üzerinde dosya özelliklerinden "Gelişmiş" tıklandığında aşağıdaki gibi "Encrypt contents to secure data" veya Türkçe olarak "Veriyi korumak için içeriği şifrele" kutusu işaretli gözükür.

Powerhshell ile dosyanın öznitelikleri arasında Encrypted bulunur:

(Get-Item -Path "C:\klasor\dosya.txt").Attributes

Archive, Encrypted

Dosyayı şifrelemek için PKI (public key infrastructure) yapısı gereği bir "sertifikaya" ihtiyaç duyulur. Yetkili bir sertifika otoritesinin bulunduğu bir Active Directory ortamında değilsek, bilgisayarda da EFS amaçlı kullanılabilecek başka bir sertifika da yoksa, bilgisayar kendi kendine bir sertifika üretecektir. Bu işlem kullanıcı müdahalesine gerek kalmadan arka planda yapılır. Böyle bir sertifikanın varlığı

cipher /y

veya Powershell ile sertifika PSDrive içeriği sorgulanarak görülebilir.

Get-ChildItem Cert:\CurrentUser\My | 
	Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains 'Encrypting File System' }

Dosyayı tekrar şifrelenmemiş haline getirmek için 

(Get-Item -Path "C:\klasor\dosya.txt").decrypt()

kullanmak gerekir. Dosyayı şifrelenmemiş hale getirmek sertifikayı silmez.

Powershell'de "cannot validate argument on parameter" hatası

Uzak bir bilgisayara Powershell'in Copy-Item cmdlet'i ile, uzak oturumlar (PS remote sessions) kullanarak veri kopyalıyordum. Her zamanki gibi oturumu oluşturdum:

$oturum = New-PSSession -Computername 192.168.11.27

Var olduğunu bildiğim bir uzak klasöre, yerel bilgisayarımda var olduğunu doğruladığım bir exe dosyayı atmaya başladım.

Copy-Item -Path "C:\klasor\dosya.exe" -ToSession $oturum -Destination "C:\klasor"

Ama şu hata ile karşılaştım:

Copy-Item : Cannot validate argument on parameter 'b64Fragment'. The argument is null or empty. Provide an argument that is not n
ull or empty, and then try the command again.

Copy-Item : Failed to copy file C:\klasor\dosya.exe to remote target destination.
At line:1 char:1

Kullandığım komut tam olarak yukarıda yazdığım gibiydi, b46Fragment gibi bir parametre kullanmadım.

Aradım, ama bu hataya benzer bir hata ile karşılaşan birini bulamadım. Ama dosya karşı tarafa kopyalanmıştı. Yerel ve uzak dosya hash'lerini karşılaştırdım, fark bulamadım.

Get-FileHash -Path "C:\klasor\dosya.exe"

Invoke-Comand -Session $oturum -Script {Get-FileHash -Path "C:\klasor\dosya.exe")

Bu da böyle bir durum olarak kaldı.