由於幾個主要與安全相關的原因，PowerShell指令碼不像批處理指令碼那樣易於移植和使用。但是，我們可以將批處理指令碼與PowerShell指令碼捆綁在一起，以解決這些問題。在這裡，我們將向您展示一些問題領域，以及如何構建批處理指令碼來解決這些問題。

為什麼我不能把我的.ps1檔案複製到另一臺計算機上執行它呢？

除非目標系統已預先配置為允許以所需的許可權執行任意指令碼，並使用正確的設定，否則在嘗試執行此操作時很可能會遇到一些問題。

1. PowerShell與.PS1副檔名不關聯違約。我們最初是在我們的PowerShell極客學校系列中提出來的。預設情況下，Windows將.PS1檔案關聯到記事本，而不是將其傳送到PowerShell命令直譯器。這是為了防止惡意指令碼的意外執行，只需雙擊它們。有很多方法可以改變這種行為，但這可能不是你想在每臺隨身攜帶指令碼的計算機上都做的事情——特別是如果其中一些計算機不是你自己的。
2. PowerShell不允許透過預設值PowerShell中的ExecutionPolicy設定預設情況下阻止在所有版本的Windows中執行外部指令碼。在某些Windows版本中，預設設定根本不允許執行指令碼。我們在how to Allow the Execution of PowerShell Scripts on Windows 7中向您展示瞭如何更改此設定。然而，這也是你不想在任何電腦上做的事情。
3. 沒有管理員，某些PowerShell指令碼將無法工作許可權。甚至使用管理員級別的帳戶執行時，仍然需要透過使用者帳戶控制（UAC）來執行某些操作。我們不想禁用它，但是當我們可以使它更容易處理時，它仍然很好。
4. 某些使用者可能已自定義PowerShell環境。你呢可能不會經常遇到這種情況，但當您這樣做時，可能會使執行和排除指令碼的故障有點令人沮喪。幸運的是，我們可以繞過這個問題而不做任何永久性的改變。

第一步：雙擊執行。

讓我們從解決第一個問題開始–.PS1檔案關聯。不能雙擊執行.PS1檔案，但可以透過這種方式執行.BAT檔案。因此，我們將編寫一個批處理檔案，從命令列呼叫PowerShell指令碼。

因此，我們不必為每個指令碼重新編寫批處理檔案，或者每次移動指令碼時，它都將使用自引用變數為PowerShell指令碼構建檔案路徑。要使此工作正常，批處理檔案需要與PowerShell指令碼放在同一資料夾中，並且具有相同的檔名。所以如果你的PowerShell指令碼被呼叫“MyScript.ps1，您將要命名批處理檔案MyScript.bat檔案“並確保它在同一個資料夾中。然後，將這些行放入批處理指令碼中：

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

如果沒有其他的安全限制，從批處理檔案執行PowerShell指令碼就只需要這些了。事實上，第一行和最後一行主要只是偏好的問題——第二行才是真正起作用的。具體情況如下：

@ECHO OFF關閉命令回顯。這隻會防止批處理檔案執行時其他命令顯示在螢幕上。這條線本身被前面的at（@）符號所隱藏。

PowerShell.exe-命令“&amp；'%~dpn0.ps1'”實際執行PowerShell指令碼。PowerShell.exe當然，可以從任何CMD視窗或批處理檔案呼叫，以便像往常一樣將PowerShell啟動到裸控制檯。還可以使用它直接從批處理檔案執行命令，方法是包含-Command引數和適當的引數。用於將.PS1檔案作為目標的方法是使用特殊的dpn0變數。從批處理檔案執行，%~dpn0計算為批處理檔案的驅動器號、資料夾路徑和檔名（不帶副檔名）。由於批處理檔案和PowerShell指令碼將位於同一資料夾中並具有相同的名稱，%~dpn0.ps1將轉換為PowerShell指令碼的完整檔案路徑。

PAUSE只是暫停批處理執行並等待使用者輸入。通常，在批處理檔案的末尾有這樣一個選項很有用，這樣您就有機會在視窗消失之前檢視任何命令輸出。隨著我們對每個步驟進行測試，這一點的有用性將變得更加明顯。

因此，基本批處理檔案被設定。出於演示目的，此檔案另存為“D:\Script Lab”\MyScript.bat檔案“還有一個”MyScript.ps1“在同一個資料夾中。讓我們看看雙擊會發生什麼MyScript.bat檔案.

顯然PowerShell指令碼沒有執行，但這是意料之中的——畢竟我們只解決了四個問題中的第一個。然而，這裡展示了一些重要的資訊：

1. 視窗標題顯示批處理指令碼已成功啟動PowerShell。
2. 輸出的第一行顯示正在使用自定義PowerShell配置檔案。這是上面列出的潛在問題4。
3. 錯誤訊息演示了有效的ExecutionPolicy限制。這就是我們的問題2。
4. 錯誤訊息的下劃線部分（由PowerShell的錯誤輸出本機完成）顯示批處理指令碼正確地指向了預期的PowerShell指令碼（D:\script Lab）\MyScript.ps1). 因此，我們至少知道，許多工作正常。

在本例中，概要檔案是一個簡單的單行指令碼，用於此演示，以便在概要檔案處於活動狀態時生成輸出。如果您想自己測試這些指令碼，也可以自定義自己的PowerShell配置檔案來執行此操作。只需在配置檔案指令碼中新增以下行：

Write-Output 'Custom PowerShell profile in effect!'

此處測試系統上的ExecutionPolicy設定為RemoteSigned。這允許執行本地建立的指令碼（如profile指令碼），同時阻止來自外部源的指令碼，除非它們由可信機構簽名。出於演示目的，以下命令用於標記MyScript.ps1從外部來源：

Add-Content -Path 'D:\Script Lab\MyScript.ps1' -Value "[ZoneTransfer]`nZoneId=3" -Stream 'Zone.Identifier'

這就決定了區域識別符號備用資料流開啟MyScript.ps1所以Windows會認為檔案來自網際網路。可透過以下命令輕鬆反轉：

Clear-Content -Path 'D:\Script Lab\MyScript.ps1' -Stream 'Zone.Identifier'

第二步：繞過執行策略。

從CMD或批處理指令碼中繞過ExecutionPolicy設定實際上相當容易。我們只需修改指令碼的第二行，向PowerShell.exe命令。

PowerShell.exe -ExecutionPolicy Bypass -Command "& '%~dpn0.ps1'"

-ExecutionPolicy引數可用於修改生成新PowerShell會話時使用的ExecutionPolicy。這種情況不會持續到該會話之後，因此我們可以在需要時像這樣執行PowerShell，而不會削弱系統的總體安全態勢。既然我們已經解決了這個問題，讓我們再來一次：

現在指令碼已經正確執行了，我們可以看到它實際上做了什麼。它讓我們知道我們是以有限使用者的身份執行指令碼的。該指令碼實際上是由具有管理員許可權的帳戶執行的，但是使用者帳戶控制正在妨礙它。儘管指令碼如何檢查管理員訪問許可權的詳細資訊超出了本文的範圍，但下面是用於演示的程式碼：

if (([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {Write-Output 'Running as Administrator!'} else {Write-Output 'Running Limited!'} Pause

您還將注意到，現在在指令碼輸出中有兩個“暫停”操作—一個來自PowerShell指令碼，另一個來自批處理檔案。其原因將在下一步更加明顯。

步驟3:獲取管理員訪問許可權。

如果您的指令碼沒有執行任何需要提升的命令，並且您確信不必擔心任何人的自定義概要檔案會妨礙您，那麼您可以跳過其餘部分。但是，如果您執行的是一些管理員級cmdlet，則需要這篇文章。

不幸的是，無法從批處理檔案或CMD會話中觸發UAC進行提升。不過，PowerShell確實允許我們使用Start程序來實現這一點。在引數中與“-Verb RunAs”一起使用時，啟動程序將嘗試啟動具有管理員許可權的應用程式。如果PowerShell會話尚未提升，這將觸發UAC提示。要從批處理檔案中使用它來啟動指令碼，我們將生成兩個PowerShell程序—一個用於啟動啟動程序，另一個由啟動程序啟動以執行指令碼。批處理檔案的第二行需要更改為：

PowerShell.exe -Command "& {Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy Bypass -File ""%~dpn0.ps1""' -Verb RunAs}"

當批處理檔案執行時，我們將看到的第一行輸出來自PowerShell概要指令碼。然後，當啟動程序嘗試啟動時，將出現UAC提示MyScript.ps1.

單擊UAC提示符後，將生成一個新的PowerShell例項。當然，因為這是一個新例項，我們將再次看到profile指令碼通知。那麼，MyScript.ps1執行，我們看到，我們確實在一個提升的會議。

這也是我們在這裡有兩次停頓的原因。如果不是PowerShell指令碼中的一個，我們將永遠看不到指令碼的輸出–一旦指令碼執行完畢，PowerShell視窗將彈出並消失。如果批處理檔案中沒有暫停，我們就無法檢視啟動PowerShell時是否有任何錯誤。

第4步：瞭解自定義powershell配置檔案。

我們現在就把那個討厭的客戶資料通知處理掉，好嗎？在這裡，這甚至不是什麼麻煩事，但是如果使用者的PowerShell概要檔案以您在指令碼中沒有預料到的方式更改預設設定、變數或函式，那麼它們可能會非常麻煩。完全不使用概要檔案執行指令碼要簡單得多，所以您不必擔心這個問題。為此，我們只需再次更改批處理檔案的第二行：

PowerShell.exe -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%~dpn0.ps1""' -Verb RunAs}"

將-NoProfile引數新增到指令碼啟動的兩個PowerShell例項中，意味著在這兩個步驟中都將完全繞過使用者的配置檔案指令碼，並且我們的PowerShell指令碼將在相當可預測的預設環境中執行。在這裡，您可以看到在兩個生成的shell中都沒有自定義概要檔案通知。

如果在PowerShell指令碼中不需要管理員許可權，並且跳過了步驟3，則可以不使用第二個PowerShell例項，批處理檔案的第二行應該如下所示：

PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '%~dpn0.ps1'"

輸出將如下所示：

（當然，對於非管理員指令碼，此時也可以不在PowerShell指令碼中暫停指令碼結束，因為所有內容都捕獲在同一控制檯視窗中，並且無論如何都會被批處理檔案結束時的暫停保留在那裡。）

已完成批處理檔案。

根據您的PowerShell指令碼是否需要管理員許可權（如果不需要，您確實不應該請求管理員許可權），最終的批處理檔案應該如下所示。

沒有管理員許可權：

@ECHO OFF PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '%~dpn0.ps1'" PAUSE

具有管理員許可權：

@ECHO OFF PowerShell.exe -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%~dpn0.ps1""' -Verb RunAs}" PAUSE

請記住，將批處理檔案與要使用它的PowerShell指令碼放在同一資料夾中，併為其指定相同的名稱。然後，無論您將這些檔案帶到哪個系統，您都可以執行PowerShell指令碼，而不必在系統上亂搞任何安全設定。您當然可以每次手動進行這些更改，但這樣可以省去這些麻煩，而且您不必擔心以後恢復更改。

---

參考文獻：

• 從批處理檔案執行PowerShell指令碼—Daniel Schroeder的程式設計部落格
• 正在檢查PowerShell中的管理員許可權–嘿，指令碼編寫人員！部落格