PowerShell Komut Dosyalarının Çalıştırılmasını Kolaylaştırmak için Toplu Dosya Nasıl Kullanılır

Birçok nedenden dolayı, çoğunlukla güvenlikle ilgili olan PowerShell scriptleri, taşınabilir scriptler kadar kolay bir şekilde taşınabilir ve kullanılamaz. Ancak, bu sorunların giderilmesi için toplu komut dosyasını PowerShell komut dosyalarımızla birlikte paketleyebiliriz. Burada, size bu sorun alanlarından birkaçını ve bunların üstesinden gelmek için bir toplu komut dosyasının nasıl oluşturulduğunu göstereceğiz..

Neden sadece .PS1 dosyamı başka bir bilgisayara kopyalayıp çalıştıramıyorum?

Hedef sistem isteğe bağlı komut dosyalarının çalıştırılmasına izin verecek şekilde önceden yapılandırılmadıysa, gerekli ayrıcalıklarla ve doğru ayarları kullanmıyorsa, bunu yapmaya çalıştığınızda bazı sorunlar yaşayabilirsiniz.

1. PowerShell, varsayılan olarak .PS1 dosya uzantısı ile ilişkili değildir.
   Bunu başlangıçta PowerShell Geek School serimizde gündeme getirdik. Windows, .PS1 dosyalarını PowerShell komut yorumlayıcısına göndermek yerine varsayılan olarak Not Defteri ile ilişkilendirir. Bu, kötü amaçlı komut dosyalarının yanlışlıkla çift tıklatılmasını yanlışlıkla önlemek içindir. Bu davranışı değiştirmenin bazı yolları vardır, ancak muhtemelen komut dosyalarınızı taşıdığınız her bilgisayarda yapmak istediğiniz bir şey değildir - özellikle de bu bilgisayarların bazıları size ait değilse.
2. PowerShell, varsayılan olarak harici komut dosyasının yürütülmesine izin vermiyor.
   PowerShell'deki ExecutionPolicy ayarı, Windows'un tüm sürümlerinde dış komut dosyalarının varsayılan olarak yürütülmesini önler. Bazı Windows sürümlerinde, varsayılan kod çalıştırma işlemine izin vermez. Bu ayarı nasıl değiştireceğinizi, Windows 7'de PowerShell Komut Dosyalarının Yürütülmesine İzin Verme bölümünde gösterdik. Ancak, bu aynı zamanda herhangi bir bilgisayarda yapmak istemediğiniz bir şeydir..
3. Bazı PowerShell scriptleri Yönetici izinleri olmadan çalışmaz.
   Yönetici düzeyinde bir hesapla bile çalışsanız bile, belirli işlemleri gerçekleştirmek için Kullanıcı Hesabı Denetimi'ni (UAC) geçmeniz gerekir. Bunu devre dışı bırakmak istemiyoruz, ancak başa çıkmayı biraz daha kolaylaştırabildiğimizde hala güzel.
4. Bazı kullanıcılar özelleştirilmiş PowerShell ortamlarına sahip olabilir..
   Muhtemelen bu sık sık karşılaşmayacaksınız, ancak bunu yaptığınızda, komut dosyalarınızı çalıştırmayı ve sorun gidermeyi biraz sinir bozucu hale getirebilir. Neyse ki, kalıcı değişiklikler yapmadan da bunun üstesinden gelebiliriz..

1. Adım: Çalıştırmak için çift tıklayın.

İlk sorunu ele alarak başlayalım - .PS1 dosya ilişkilendirmeleri. .PS1 dosyalarını çalıştırmak için çift tıklayamazsınız, ancak bir .BAT dosyasını bu şekilde çalıştırabilirsiniz. Böylece, PowerShell betiğini bizim için komut satırından çağırmak için bir toplu iş dosyası yazacağız.

Bu nedenle, her bir komut dosyası için toplu iş dosyasını yeniden yazmak zorunda değiliz, ya da bir komut dosyasını her hareket ettirdiğimizde, PowerShell komut dosyası için dosya yolunu oluşturmak için kendi kendini referans alan bir değişken kullanacak. Bu işlemi yapmak için toplu iş dosyasının PowerShell betiğinizle aynı klasöre yerleştirilmesi ve aynı dosya adına sahip olması gerekir. Bu nedenle, PowerShell betiğinize “MyScript.ps1” deniyorsa, toplu iş dosyanızı “MyScript.bat” olarak adlandırın ve aynı klasörde olduğundan emin olun. Sonra bu satırları toplu komut dosyasına koyun:

@ECHO OFF PowerShell.exe -Command "& '% ~ dpn0.ps1'" DURAKLATMA

Yerindeki diğer güvenlik kısıtlamaları için olmasaydı, bir PowerShell betiğini toplu iş dosyasından çalıştırmak gerçekten yeterli olurdu. Aslında, ilk ve son satırlar esasen bir tercih meselesidir - gerçekten işi yapan ikinci satırdır. İşte dağılım:

@EKO KAPALI komut yankısını kapatır. Bu sadece toplu iş dosyası çalışırken diğer komutlarınızın ekranda görünmesini engeller. Bu çizginin kendisi, önünde (@) sembolünün kullanılmasıyla gizlenir..

PowerShell.exe -Command “& '% ~ dpn0.ps1'” aslında PowerShell betiğini çalıştırır. PowerShell.exe elbette, PowerShell'i her zamanki gibi çıplak bir konsola başlatmak için herhangi bir CMD penceresinden veya toplu iş dosyasından çağrılabilir. -Command parametresini ve uygun argümanları dahil ederek komutları doğrudan bir toplu iş dosyasından çalıştırmak için de kullanabilirsiniz. Bunun .PS1 dosyamızı hedeflemede kullanılan yolu özel% ~ dpn0 değişkenidir. Bir toplu iş dosyasından çalıştırıldığında,% ~ dpn0, toplu iş dosyasının sürücü harfini, klasör yolunu ve dosya adını (uzantı olmadan) değerlendirir. Toplu iş dosyası ve PowerShell betiği aynı klasörde ve aynı ada sahip olduğundan,% ~ dpn0.ps1, PowerShell betiğinin tam dosya yoluna çevrilecektir.

DURAKLAT sadece toplu işlemi durdurur ve kullanıcı girişi için bekler. Bu genellikle toplu iş dosyalarınızın sonunda olması yararlıdır, böylece pencere kaybolmadan önce herhangi bir komut çıktısını gözden geçirme şansınız olur. Her adımın testinden geçerken, bunun faydası daha belirgin hale gelecektir.

Böylece, temel toplu iş dosyası ayarlandı. Gösterim amacıyla, bu dosya “D: \ Script Lab \ MyScript.bat” olarak kaydedilir ve aynı klasörde “MyScript.ps1” vardır. MyScript.bat dosyasına çift tıkladığımızda ne olacağını görelim..

Açıkçası, PowerShell betiği çalışmadı, ama bu beklenen bir şeydi - sonuçta sadece dört sorunun ilkini ele aldık. Bununla birlikte, burada gösterilen bazı önemli bitler vardır:

1. Pencere başlığı, toplu komut dosyasının PowerShell'i başarıyla başlattığını gösterir..
2. İlk çıktı satırı, özel bir PowerShell profilinin kullanımda olduğunu gösterir. Bu yukarıda listelenen potansiyel sorun 4'tür.
3. Hata mesajı yürürlükte ExecutionPolicy kısıtlamaları gösterir. Bu bizim sorunumuz # 2.
4. Hata mesajının altı çizili kısmı (yerel olarak PowerShell'in hata çıktısı tarafından yapılır) toplu iş komut dosyasının amaçlanan PowerShell komut dosyasını (D: \ Script Lab \ MyScript.ps1) doğru bir şekilde hedeflediğini gösterir. Bu yüzden en azından bunun doğru şekilde çalıştığını biliyoruz..

Profil, bu durumda, profil etkin olduğunda bu çıktının üretilmesi için bu gösteride kullanılan tek satırlı bir komut dosyasıdır. Bu komut dosyalarını kendiniz test etmek istiyorsanız, bunu yapmak için kendi PowerShell profilinizi özelleştirebilirsiniz. Profil komut dosyasına aşağıdaki satırı eklemeniz yeterlidir:

Yazma Çıktısı 'Özel PowerShell profili etkin!'

Buradaki test sistemindeki ExecutionPolicy RemoteSigned olarak ayarlanmıştır. Bu, yerel olarak oluşturulan komut dosyalarının yürütülmesine izin verir (profil komut dosyası gibi), güvenilir bir otorite tarafından imzalanmadıkça dış kaynaklardan gelen komut dosyalarını engeller. Gösterim amacıyla, aşağıdaki komut MyScript.ps1'i harici bir kaynaktan bayrak olarak işaretlemek için kullanıldı:

Ek İçeriği -Yol 'D: \ Script Lab \ MyScript.ps1' -Değer "[ZoneTransfer] 'nZoneId = 3" -Stream' Zone.Identifier '

Bu, Zone.Identifier öğesinin MyScript.ps1'deki alternatif veri akışını ayarlar; böylece Windows, dosyanın Internet'ten geldiğini düşünür. Aşağıdaki komutla kolayca tersine çevrilebilir:

İçeriği Temizle -Yol 'D: \ Komut Dosyası Laboratuvarı \ MyScript.ps1' -Stream 'Zone.Identifier'

Adım 2: ExecutionPolicy'de gezinme.

ExecutionPolicy ayarını dolaşmak, CMD veya toplu komut dosyasından geçmek gerçekten çok kolaydır. PowerShell.exe komutuna bir parametre daha eklemek için komut dosyasının ikinci satırını değiştirdik.

PowerShell.exe -GecelGeçişli Bypass -Command "& '% ~ dpn0.ps1'"

-ExecutionPolicy parametresi, yeni bir PowerShell oturumu oluştururken kullanılan ExecutionPolicy'yi değiştirmek için kullanılabilir. Bu, bu oturumun ötesinde devam etmeyecek, böylece sistemin genel güvenlik duruşunu zayıflatmadan ihtiyaç duyduğumuzda PowerShell'i bu şekilde çalıştırabiliriz. Şimdi bunu düzelttik, hadi bir tane daha deneyelim:

Şimdi senaryo düzgün bir şekilde yürüdüğünde, aslında ne yaptığını görebiliriz. Senaryoyu Sınırlı kullanıcı olarak çalıştırdığımızı bize bildirir. Betik aslında Yönetici izinlerine sahip bir hesap tarafından çalıştırılıyor, ancak Kullanıcı Hesabı Denetimi engelliyor. Komut dosyasının Yönetici erişimi için nasıl denetlediğinin ayrıntıları bu makalenin kapsamı dışında olsa da, gösterim için kullanılan kod:

if (([[Security.Principal.WindowsPrincipal]] [Security.Principal.WindowsIdentity] :: GetCurrent ()).] IsInRole ([Security.Principal.WindowsBuiltInRole] "Yönetici")) Yazma Çıktısı Yönetici olarak çalışıyor! ' else Yazma Çıktısı 'Running Limited!' Duraklat

Ayrıca komut dosyası çıktısında iki tane “Duraklat” işlemi olduğunu fark edeceksiniz - biri PowerShell komut dosyasından, diğeri toplu iş dosyasından. Bunun nedeni bir sonraki adımda daha belirgin olacak.

Adım 3: Yönetici erişimi alma.

Komut dosyanızın yükseltme gerektiren herhangi bir komut çalıştırmaması durumunda ve kimsenin özel profillerinin bu şekilde girmesi konusunda endişelenmenize gerek kalmayacağından eminseniz, bunun geri kalanını atlayabilirsiniz. Bazı Yönetici düzeyinde cmdlet'ler kullanıyorsanız, bu parçaya ihtiyacınız olacak.

Ne yazık ki, bir toplu iş dosyası veya CMD oturumunun içinden UAC'yi yükseltmek için tetiklemenin bir yolu yoktur. Ancak, PowerShell bunu Start-Process ile yapmamıza izin veriyor. Bağımsız değişkenlerinde “-Verb RunAs” ile birlikte kullanıldığında, Start-Process, Yönetici izinleriyle bir uygulamayı başlatmaya çalışır. PowerShell oturumu zaten yükseltilmemişse, bu bir UAC istemini tetikler. Bunu komut dosyamızı başlatmak için toplu iş dosyasından kullanmak için, iki PowerShell işleminin doğmasına neden olacağız - biri Başlat İşlemini ve diğeri de Başlat İşlemi tarafından başlatılmış, komut dosyasını çalıştırmak için. Toplu iş dosyasının ikinci satırının şu şekilde değiştirilmesi gerekiyor:

PowerShell.exe -Command "& Başlat İşlemi PowerShell.exe -ArjumentList '-ExecutionPolicy Bypass -Dosya" "% ~ dpn0.ps1" "' -Verb RunAs"

Toplu iş dosyası çalıştırıldığında, göreceğimiz ilk çıktı satırı PowerShell profil komut dosyasından gelir. Ardından, Başlat İşlemi MyScript.ps1'i başlatmaya çalıştığında bir UAC istemi olacak.

UAC istemine tıkladıktan sonra, yeni bir PowerShell örneği ortaya çıkar. Elbette bu yeni bir örnek olduğundan, profil komut dosyası bildirimini tekrar göreceğiz. Ardından, MyScript.ps1 çalışır ve gerçekten yüksek bir oturumda olduğumuzu görürüz.

Burada da iki duraklamamızın sebebi var. PowerShell betiğindeki kişi için olmasa bile, betiğin çıktısını asla göremeyiz - PowerShell penceresi, komut dosyası çalışırken biter bitmez açılır ve kaybolur. Toplu iş dosyasındaki duraklama olmadan, PowerShell'i ilk etapta başlatırken herhangi bir hata olup olmadığını göremeyiz..

Adım 4: Özel PowerShell profillerinde gezinme.

Şimdi o pis özel profil bildirimlerinden şimdi kurtulalım, olur mu? Burada pek sıkıntı bile yaşanmaz, ancak kullanıcının PowerShell profili, varsayılan ayarları, değişkenleri veya işlevleri betiğinizle önceden tahmin etmeyeceğiniz şekillerde değiştirirse, gerçekten sıkıntılı olabilir. Komut dosyanızı profilsiz olarak çalıştırmak çok daha kolaydır, böylece endişelenmenize gerek kalmaz. Bunu yapmak için, toplu iş dosyasının ikinci satırını bir kez daha değiştirmemiz gerekiyor:

PowerShell.exe -NoProfil -Command "& Başlat İşlemi PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -Dosya" "% ~ dpn0.ps1" "' -Verb RunAs"

-NoProfile parametresini, komut dosyası tarafından başlatılan PowerShell örneklerinin her ikisine de eklemek, kullanıcının profili komut dosyasının her iki adımda da tamamen atlanacağı ve PowerShell komut dosyanızın oldukça öngörülebilir, varsayılan bir ortamda çalışacağı anlamına gelir. Burada, ortaya çıkan kabukların hiçbirinde özel profil bildirimi olmadığını görebilirsiniz..

PowerShell betiğinizde Yönetici haklarına ihtiyacınız yoksa ve 3. Adımı atladıysanız, ikinci PowerShell örneği olmadan yapabilirsiniz ve toplu iş dosyanızın ikinci satırı şöyle görünmelidir:

PowerShell.exe -Hayır Dileği -ÇıkaltmaPolicy Bypass -Command "& '% ~ dpn0.ps1'"

Çıktı daha sonra şöyle görünecektir:

(Tabii ki, Yönetici olmayan komut dosyaları için, PowerShell betiğinizde her şey aynı konsol penceresinde yakalandığından ve orada tutulduğundan, bu noktada da betiğin sonu duraklatılmadan bunu yapabilirsiniz. toplu iş dosyası yine de.)

Tamamlanan toplu iş dosyaları.

PowerShell betiğiniz için Yönetici iznine ihtiyacınız olup olmamasına bağlı olarak (ve istemiyorsanız gerçekten istemezsiniz), son toplu iş dosyası aşağıdaki ikisinden birine benzemelidir.

Yönetici erişimi olmadan:

@ECHO OFF PowerShell.exe -Hayır_dosyası -ÇıkarmaPolicy Bypass -Command "& '% ~ dpn0.ps1'" PAUSE

Yönetici erişimiyle:

@ECHO OFF PowerShell.exe - NoProfile - Komut "& Başlat İşlemi PowerShell.exe - Argüman Listesi" - NoProfil - ExecutionPolicy Bypass -Dosya ""% ~ dpn0.ps1 "" '-Verb RunAs "

Toplu iş dosyasını kullanmak istediğiniz PowerShell betiğiyle aynı klasöre koymayı ve aynı adı vermeyi unutmayın. Daha sonra, bu dosyaları hangi sisteme götürürseniz götürün, PowerShell betiğinizi sistemdeki güvenlik ayarlarından herhangi biri ile uğraşmak zorunda kalmadan çalıştırabilirsiniz. Bu değişiklikleri kesinlikle her seferinde manuel olarak yapabilirsiniz, ancak bu durum sizi bu konuda kurtarır ve değişiklikleri geri almak konusunda endişelenmenize gerek kalmaz.

Referanslar:

• PowerShell scriptlerini bir toplu iş dosyasından çalıştırmak - Daniel Schroeder'in Programlama Blogu
• PowerShell'deki Yönetici izinlerini kontrol etme - Hey, Scripting Guy! Blog