1. 一個(gè)讓老項(xiàng)目組集體頭疼的報(bào)錯如果你手上還在維護(hù)基于 .NET Framework 4.0 的老系統(tǒng)尤其是那種跑在 Windows Server 2008 R2 或者 Win7 上的內(nèi)部管理平臺那你大概率見過這個(gè)場景代碼里用HttpWebRequest去請求一個(gè) HTTPS 接口本地開發(fā)環(huán)境跑得好好的一部署到服務(wù)器上就拋異常提示基礎(chǔ)連接已經(jīng)關(guān)閉: 無法建立 SSL/TLS 的安全通道或者未能創(chuàng)建 SSL/TLS 安全通道。更讓人抓狂的是同一臺服務(wù)器上用瀏覽器訪問那個(gè) HTTPS 地址完全正常用 curl 或者 Postman 也沒問題唯獨(dú) .NET 4.0 的程序一跑就掛。這個(gè)問題的核心矛盾在于.NET Framework 4.0 默認(rèn)只啟用了 SSL 3.0 和 TLS 1.0而現(xiàn)代 HTTPS 服務(wù)端基本都已經(jīng)禁用了 TLS 1.0 及以下版本只接受 TLS 1.2 甚至 TLS 1.3。你的程序在握手階段就被服務(wù)端拒絕了自然連不上。很多人第一反應(yīng)是去改代碼加一行ServicePointManager.SecurityProtocol SecurityProtocolType.Tls12;結(jié)果發(fā)現(xiàn) .NET 4.0 的SecurityProtocolType枚舉里壓根就沒有Tls12這個(gè)值——因?yàn)?TLS 1.2 的枚舉支持是 .NET 4.5 才正式加進(jìn)去的。那怎么辦升級框架老系統(tǒng)牽一發(fā)動全身升級 .NET Framework 版本可能引發(fā)一堆兼容性問題業(yè)務(wù)部門也不可能給你停機(jī)窗口去折騰。改代碼用第三方庫引入新依賴又要走安全審計(jì)和測試流程。這時(shí)候一個(gè)經(jīng)常被忽略但極其有效的方案就浮出水面了通過修改注冊表讓整個(gè)系統(tǒng)的 .NET Framework 強(qiáng)制啟用 TLS 1.2。這個(gè)方案不需要改一行業(yè)務(wù)代碼不需要升級框架只需要在服務(wù)器上導(dǎo)入一個(gè)注冊表文件重啟應(yīng)用即可生效。這篇文章就是把這個(gè)方案從頭到尾講透。我會說清楚它為什么有效、注冊表到底改了什么、不同 Windows 版本下鍵值怎么放、改完之后怎么驗(yàn)證、以及我在實(shí)際運(yùn)維中踩過的那些坑。如果你正好被這個(gè)問題卡住或者你負(fù)責(zé)的團(tuán)隊(duì)里有類似的老系統(tǒng)需要維護(hù)這篇內(nèi)容應(yīng)該能幫你省下不少排查時(shí)間。2. 為什么 .NET 4.0 默認(rèn)不認(rèn) TLS 1.22.1 從 SystemDefault 說起框架到底怎么選協(xié)議版本要理解注冊表方案為什么管用得先搞清楚 .NET Framework 在發(fā)起 HTTPS 請求時(shí)底層是怎么決定用哪個(gè) TLS 版本的。在 .NET 4.0 里ServicePointManager.SecurityProtocol的默認(rèn)值是SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls也就是 SSL 3.0 和 TLS 1.0 的組合。這個(gè)默認(rèn)值是在框架代碼里硬編碼的它反映的是 2010 年前后的安全實(shí)踐——那時(shí)候 TLS 1.2 還沒普及很多服務(wù)端還在用 TLS 1.0。當(dāng)你的程序調(diào)用HttpWebRequest.GetResponse()時(shí)運(yùn)行時(shí)會把這個(gè)協(xié)議偏好傳遞給底層的 SchannelWindows 的安全通道實(shí)現(xiàn)。Schannel 是操作系統(tǒng)層面的 SSL/TLS 提供者它負(fù)責(zé)實(shí)際的握手過程。問題就出在這里Schannel 本身是支持 TLS 1.2 的Windows 7 和 Server 2008 R2 在打了相應(yīng)補(bǔ)丁后都支持但 .NET Framework 傳給它的協(xié)議列表里沒有 TLS 1.2所以 Schannel 也不會去嘗試用 TLS 1.2 握手。這就好比你家門鎖其實(shí)支持三種鑰匙但物業(yè)只給了你其中兩把第三把明明能開門你就是拿不到。注冊表方案的本質(zhì)就是告訴 .NET Framework把第三把鑰匙也帶上。2.2 Schannel 與 .NET 的分工誰在真正決定握手協(xié)議這里有個(gè)容易混淆的點(diǎn)值得單獨(dú)說清楚。很多人以為 TLS 握手是 .NET Framework 自己實(shí)現(xiàn)的其實(shí)不是。.NET Framework 的SslStream和HttpWebRequest在 Windows 上都是委托給 Schannel 來做的。Schannel 是 Windows 系統(tǒng)組件它的行為受注冊表控制具體位置在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols在這個(gè)路徑下你可以看到SSL 2.0、SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2等子鍵每個(gè)子鍵下又有Client和Server兩個(gè)子鍵里面可以設(shè)置Enabled和DisabledByDefault等 DWORD 值。這套注冊表控制的是Schannel 層面的協(xié)議啟用狀態(tài)影響的是整個(gè)操作系統(tǒng)上所有使用 Schannel 的程序包括 IE、Edge部分場景、以及 .NET Framework。但光改這里還不夠。因?yàn)?.NET Framework 有自己的協(xié)議選擇邏輯它會在 Schannel 支持的協(xié)議基礎(chǔ)上再根據(jù)ServicePointManager.SecurityProtocol的值做一次過濾。所以你需要同時(shí)告訴 .NET FrameworkTLS 1.2 是可用的你可以用它。這就是SystemDefaultTlsVersions和SchUseStrongCrypto這兩個(gè)注冊表值的用武之地。2.3 兩個(gè)關(guān)鍵注冊表值SchUseStrongCrypto 和 SystemDefaultTlsVersions在 .NET Framework 的注冊表配置里有兩個(gè)值直接決定了 TLS 協(xié)議的選擇行為注冊表值作用適用框架版本SchUseStrongCrypto強(qiáng)制使用強(qiáng)加密算法并啟用 TLS 1.1/1.2.NET 4.0 及以上SystemDefaultTlsVersions讓 .NET 使用系統(tǒng) Schannel 的默認(rèn)協(xié)議設(shè)置.NET 4.7 及以上對于 .NET 4.0 來說關(guān)鍵是SchUseStrongCrypto。當(dāng)這個(gè)值設(shè)為 1 時(shí).NET Framework 會把 TLS 1.1 和 TLS 1.2 加入到可用的協(xié)議列表中即使ServicePointManager.SecurityProtocol沒有顯式設(shè)置。這個(gè)行為的官方說明在微軟的文檔里有記載但藏得比較深很多人不知道。SystemDefaultTlsVersions是后來 .NET 4.7 引入的它讓 .NET 完全跟隨 Schannel 的配置。如果你的系統(tǒng)是 .NET 4.0這個(gè)值不起作用但如果你后續(xù)升級到了 4.7建議也把它設(shè)上這樣協(xié)議選擇就完全交給系統(tǒng)統(tǒng)一管理了。注意SchUseStrongCrypto對 .NET 4.0 到 4.6.2 都有效但 .NET 4.7 之后行為有變化建議同時(shí)配置SystemDefaultTlsVersions以確保一致性。3. 注冊表到底改哪里32 位與 64 位的分叉路3.1 Wow6432Node 的坑為什么你改了注冊表卻沒生效這是我在實(shí)際運(yùn)維中見過最多的翻車點(diǎn)。很多教程只告訴你改HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319但沒告訴你32 位程序和 64 位程序讀取的注冊表位置是不一樣的。在 64 位 Windows 上32 位程序訪問HKLM\SOFTWARE時(shí)會被重定向到HKLM\SOFTWARE\Wow6432Node。如果你的 .NET 程序編譯目標(biāo)是 x86或者運(yùn)行在 32 位應(yīng)用池里那你改SOFTWARE\Microsoft\.NETFramework下的鍵值它根本讀不到。正確的做法是兩個(gè)位置都改64 位程序讀取HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.3031932 位程序讀取HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319我一般會直接寫一個(gè) .reg 文件把兩個(gè)位置都覆蓋到導(dǎo)入一次搞定。這樣不管你的應(yīng)用池是 32 位還是 64 位都能生效。3.2 完整的 .reg 文件內(nèi)容與逐行解讀下面是我常用的注冊表文件內(nèi)容你可以直接復(fù)制保存為enable-tls12.reg然后雙擊導(dǎo)入Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] SchUseStrongCryptodword:00000001 SystemDefaultTlsVersionsdword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] SchUseStrongCryptodword:00000001 SystemDefaultTlsVersionsdword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] Enableddword:00000001 DisabledByDefaultdword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] Enableddword:00000001 DisabledByDefaultdword:00000000逐段解釋一下第一段和第二段是給 .NET Framework 看的分別對應(yīng) 64 位和 32 位程序。SchUseStrongCrypto1讓框架啟用強(qiáng)加密和 TLS 1.1/1.2SystemDefaultTlsVersions1讓框架跟隨系統(tǒng) Schannel 配置對 4.7 有效4.0 下無害。第三段和第四段是給 Schannel 看的確保 TLS 1.2 在客戶端和服務(wù)端兩個(gè)方向都啟用。DisabledByDefault0表示不默認(rèn)禁用Enabled1表示顯式啟用。提示如果你的服務(wù)器上 TLS 1.0 已經(jīng)被安全策略禁用那不需要額外操作如果沒禁用但你想強(qiáng)制走 TLS 1.2可以在 Schannel 下把 TLS 1.0 的Enabled設(shè)為 0。不過這一步要謹(jǐn)慎確認(rèn)沒有其他老程序依賴 TLS 1.0 再動。3.3 導(dǎo)入之后必須做的兩件事重啟應(yīng)用池與驗(yàn)證注冊表導(dǎo)入之后不會立即對已經(jīng)運(yùn)行的進(jìn)程生效。.NET Framework 在進(jìn)程啟動時(shí)會讀取這些配置并緩存所以你需要重啟 IIS 應(yīng)用池如果是 IIS 托管的應(yīng)用或者重啟對應(yīng)的 Windows 服務(wù)/控制臺程序。如果應(yīng)用池有多個(gè)確認(rèn)目標(biāo)應(yīng)用池確實(shí)重啟了別只重啟了默認(rèn)的 DefaultAppPool。驗(yàn)證是否生效最直接的方法是寫一段小代碼打印當(dāng)前可用的協(xié)議using System; using System.Net; class Program { static void Main() { Console.WriteLine(SecurityProtocol: ServicePointManager.SecurityProtocol); Console.WriteLine(實(shí)際值: (int)ServicePointManager.SecurityProtocol); } }在 .NET 4.0 下如果注冊表生效你可能會看到輸出里包含了Tls11或Tls12的位標(biāo)志具體取決于框架版本和補(bǔ)丁級別。更可靠的驗(yàn)證方式是直接請求那個(gè)之前報(bào)錯的 HTTPS 地址看是否還能復(fù)現(xiàn)無法建立 SSL/TLS 安全通道的錯誤。4. 不同 Windows 版本下的差異與補(bǔ)丁依賴4.1 Windows 7 / Server 2008 R2 需要先打補(bǔ)丁這一點(diǎn)非常關(guān)鍵很多人改了注冊表還是不行就是因?yàn)橄到y(tǒng)層面根本不支持 TLS 1.2。Windows 7 和 Windows Server 2008 R2默認(rèn)是不支持 TLS 1.2 的需要安裝補(bǔ)丁 KB3140245。這個(gè)補(bǔ)丁的作用是讓 Schannel 支持 TLS 1.1 和 TLS 1.2并且提供了注冊表配置入口。安裝補(bǔ)丁后還需要確認(rèn)系統(tǒng)里已經(jīng)安裝了對應(yīng)的根證書更新。因?yàn)?TLS 1.2 握手時(shí)可能會用到新的加密套件和證書鏈如果系統(tǒng)的根證書庫太舊握手也會失敗。我一般會順手把 KB4474419SHA-2 代碼簽名支持也裝上避免后續(xù)遇到簽名算法不兼容的問題。Windows 8.1 / Server 2012 R2 及以上版本默認(rèn)就支持 TLS 1.2不需要額外補(bǔ)丁直接改注冊表即可。4.2 .NET 4.0 與 4.5 的行為差異對照不同 .NET Framework 版本對SchUseStrongCrypto的響應(yīng)是不一樣的這里整理一個(gè)對照表框架版本SchUseStrongCrypto 效果是否需要 SystemDefaultTlsVersions4.0啟用 TLS 1.1/1.2不需要不支持4.5啟用 TLS 1.1/1.2不需要4.5.2啟用 TLS 1.1/1.2不需要4.6啟用 TLS 1.1/1.2建議設(shè)置4.6.1啟用 TLS 1.1/1.2建議設(shè)置4.6.2啟用 TLS 1.1/1.2建議設(shè)置4.7行為變化建議用 SystemDefaultTlsVersions必須設(shè)置對于 .NET 4.0 來說SchUseStrongCrypto是唯一有效的開關(guān)。但要注意即使設(shè)了這個(gè)值ServicePointManager.SecurityProtocol的默認(rèn)值在代碼層面看起來可能還是Ssl3 | Tls實(shí)際握手時(shí)框架會額外嘗試 TLS 1.2。這個(gè)行為有點(diǎn)隱晦但實(shí)測有效。4.3 一個(gè)容易被忽略的點(diǎn)應(yīng)用池的 .NET 版本配置IIS 應(yīng)用池有一個(gè)基本設(shè)置里的 .NET CLR 版本選項(xiàng)通常選的是v4.0.30319。這個(gè)選項(xiàng)決定了應(yīng)用池加載哪個(gè)版本的 CLR但它不區(qū)分 4.0 和 4.5——因?yàn)?4.5 是 4.0 的就地升級CLR 版本號還是 4.0.30319。所以你在應(yīng)用池里看到的是 v4.0.30319實(shí)際運(yùn)行的可能是 4.5、4.6 甚至 4.8。這意味著如果你服務(wù)器上裝了 4.8那你的4.0 程序?qū)嶋H上跑在 4.8 的運(yùn)行時(shí)上SchUseStrongCrypto的行為會遵循 4.8 的規(guī)則。這一點(diǎn)在排查時(shí)很容易搞混建議先用clrver命令或者查看注冊表HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full下的Release值來確認(rèn)實(shí)際版本。5. 排查鏈路從報(bào)錯到定位的完整過程5.1 第一步確認(rèn)報(bào)錯到底出在哪一層遇到 HTTPS 請求失敗不要急著改注冊表先確認(rèn)問題層次。我通常按這個(gè)順序排查用瀏覽器訪問目標(biāo) HTTPS 地址如果瀏覽器能打開說明網(wǎng)絡(luò)連通性和服務(wù)端證書沒問題問題在客戶端程序。用 curl 或 PowerShell 測試curl -v https://目標(biāo)地址看握手用的 TLS 版本。如果 curl 能通進(jìn)一步確認(rèn)是 .NET 特有的問題。寫最小復(fù)現(xiàn)代碼用HttpWebRequest請求同一個(gè)地址捕獲異常并打印InnerException。如果內(nèi)層異常是AuthenticationException且消息包含SSL/TLS基本可以鎖定協(xié)議版本問題。檢查ServicePointManager.SecurityProtocol的當(dāng)前值在代碼里打印出來確認(rèn)默認(rèn)值是什么。這一步的目的是排除 DNS、防火墻、證書過期、代理配置等干擾因素。我見過有人折騰半天注冊表最后發(fā)現(xiàn)是服務(wù)器時(shí)間不對導(dǎo)致證書校驗(yàn)失敗白白浪費(fèi)時(shí)間。5.2 第二步用 Wireshark 或日志確認(rèn)握手失敗的具體原因如果條件允許抓包是最直接的。在客戶端抓包過濾tcp.port 443看 Client Hello 里攜帶的 TLS 版本。如果 Client Hello 里只有 TLS 1.0而服務(wù)端返回 Alert 或者直接 RST那就實(shí)錘了。沒有抓包條件的話可以看服務(wù)端的訪問日志。很多 HTTPS 服務(wù)端會記錄握手失敗的日志里面會寫明no shared cipher或者unsupported protocol。這些信息能幫你快速定位。另外.NET 的System.Net跟蹤日志也能派上用場。在 app.config 或 web.config 里開啟System.Net的 trace可以看到握手過程的詳細(xì)輸出。不過這個(gè)日志比較啰嗦建議只在排查時(shí)臨時(shí)開啟。5.3 第三步改注冊表后的驗(yàn)證與回滾方案改完注冊表、重啟應(yīng)用池之后重新跑一遍最小復(fù)現(xiàn)代碼。如果還是報(bào)錯按以下順序檢查注冊表路徑是否寫對了32 位和 64 位都改了嗎應(yīng)用池真的重啟了嗎可以在任務(wù)管理器里看 w3wp.exe 的啟動時(shí)間。系統(tǒng)補(bǔ)丁裝了嗎Windows 7/2008 R2 需要 KB3140245。有沒有其他安全軟件或組策略覆蓋了 Schannel 配置如果改完注冊表導(dǎo)致其他老程序出問題比如某些只支持 TLS 1.0 的內(nèi)部系統(tǒng)連不上了回滾很簡單把SchUseStrongCrypto的值改回 0 或者直接刪除該值重啟應(yīng)用池即可。Schannel 層面的 TLS 1.2 啟用一般不會導(dǎo)致兼容問題因?yàn)樗窃黾又С侄皇墙门f協(xié)議。注意在生產(chǎn)環(huán)境改注冊表之前務(wù)必先在測試環(huán)境驗(yàn)證并且做好注冊表導(dǎo)出備份。reg export命令可以快速備份指定路徑。6. 比改注冊表更穩(wěn)妥的替代思路6.1 代碼層顯式指定協(xié)議版本的可行性雖然 .NET 4.0 的SecurityProtocolType枚舉里沒有Tls12但你可以用數(shù)字強(qiáng)轉(zhuǎn)ServicePointManager.SecurityProtocol (SecurityProtocolType)3072; // Tls123072 是 TLS 1.2 的十進(jìn)制值。這段代碼在 .NET 4.0 下能編譯通過運(yùn)行時(shí)如果系統(tǒng)支持 TLS 1.2也能生效。但它的局限是需要改代碼并重新發(fā)布而且如果系統(tǒng)層面沒裝補(bǔ)丁強(qiáng)轉(zhuǎn)也沒用。對于不能改代碼的場景比如第三方組件內(nèi)部發(fā)起的請求這個(gè)方案就無能為力了。所以代碼方案和注冊表方案不是互斥的而是互補(bǔ)的。注冊表方案覆蓋全局代碼方案針對特定請求。我一般建議能改代碼就改代碼改不了或者想一勞永逸就上注冊表。6.2 升級到 .NET 4.5 的收益與成本如果條件允許升級到 .NET 4.5 或更高版本是最徹底的方案。4.5 原生支持SecurityProtocolType.Tls12而且后續(xù)版本對 TLS 的支持更完善。但升級的代價(jià)是需要重新編譯和測試所有依賴項(xiàng)目可能遇到第三方庫不兼容生產(chǎn)環(huán)境需要停機(jī)窗口某些老系統(tǒng)可能依賴 4.0 的特定行為對于維護(hù)期有限的老系統(tǒng)改注冊表往往是性價(jià)比最高的選擇。對于還在持續(xù)迭代的項(xiàng)目升級框架是更長遠(yuǎn)的方向。6.3 用 HttpWebRequest 之外的選擇如果項(xiàng)目允許引入新依賴可以考慮用HttpClient需要 .NET 4.5或者第三方 HTTP 庫。這些庫通常對 TLS 版本的處理更靈活有的甚至內(nèi)置了協(xié)議協(xié)商邏輯。但引入新庫同樣要走安全審計(jì)和測試流程不一定比改注冊表快。我的經(jīng)驗(yàn)是先試注冊表方案五分鐘就能驗(yàn)證是否有效。如果有效問題解決如果無效再考慮代碼或升級方案。這樣排查成本最低。7. 幾個(gè)我在實(shí)際運(yùn)維中踩過的坑第一個(gè)坑是只改了 64 位注冊表忘了 Wow6432Node。當(dāng)時(shí)應(yīng)用池配置的是 32 位模式我改了半天SOFTWARE\Microsoft\.NETFramework下的鍵值重啟了無數(shù)次應(yīng)用池都沒用。后來用 Process Monitor 監(jiān)控注冊表讀取才發(fā)現(xiàn)程序讀的是Wow6432Node下的路徑。這個(gè)坑讓我養(yǎng)成了兩個(gè)位置都改的習(xí)慣。第二個(gè)坑是以為改了注冊表就萬事大吉忘了系統(tǒng)補(bǔ)丁。在一臺 Windows Server 2008 R2 上我改完注冊表重啟應(yīng)用池還是報(bào)同樣的錯。查了半天才發(fā)現(xiàn)系統(tǒng)沒裝 KB3140245Schannel 根本不支持 TLS 1.2。裝上補(bǔ)丁重啟服務(wù)器后問題立刻解決。所以 Windows 7/2008 R2 環(huán)境下補(bǔ)丁是前置條件。第三個(gè)坑是應(yīng)用池沒真正重啟。IIS 里點(diǎn)回收和應(yīng)用池重啟是兩回事?；厥罩皇莿?chuàng)建新的工作進(jìn)程舊進(jìn)程可能還在處理請求重啟才是徹底停掉再啟動。我一般會直接iisreset /restart雖然粗暴但確保生效。如果是非 IIS 的 Windows 服務(wù)就在服務(wù)管理器里重啟。第四個(gè)坑是注冊表值類型寫錯。SchUseStrongCrypto必須是 DWORD32 位值有人寫成字符串 1結(jié)果不生效。用 .reg 文件導(dǎo)入一般不會錯但手動在 regedit 里改的時(shí)候要注意類型選擇。第五個(gè)坑是忽略了組策略的覆蓋。有些企業(yè)環(huán)境通過組策略統(tǒng)一配置了 Schannel 的協(xié)議設(shè)置你手動改的注冊表可能被組策略在下次刷新時(shí)覆蓋掉。這種情況需要聯(lián)系域管理員在組策略層面調(diào)整而不是在本地硬改。8. 寫在最后的一點(diǎn)個(gè)人體會這套注冊表方案我用了很多年幫不少老系統(tǒng)續(xù)了命。它的價(jià)值不在于技術(shù)有多高深而在于用最小的改動解決最實(shí)際的問題。在運(yùn)維一線很多時(shí)候我們不是追求最優(yōu)解而是追求在約束條件下最可行的解。改注冊表不需要改代碼、不需要停機(jī)升級、不需要走漫長的變更流程對于維護(hù)期的老系統(tǒng)來說這就是最務(wù)實(shí)的選擇。當(dāng)然我也要提醒一句注冊表方案是續(xù)命不是治本。如果系統(tǒng)還有長期維護(hù)計(jì)劃還是應(yīng)該規(guī)劃框架升級把 TLS 1.2 的支持做在代碼層面。注冊表方案更適合那些再跑一兩年就下線的系統(tǒng)或者短期內(nèi)無法安排升級窗口的緊急場景。最后分享一個(gè)小技巧如果你管理多臺服務(wù)器可以把那個(gè) .reg 文件放到共享目錄用 PowerShell 遠(yuǎn)程批量導(dǎo)入$servers (server1, server2, server3) foreach ($s in $servers) { Invoke-Command -ComputerName $s -ScriptBlock { reg import \\share\enable-tls12.reg iisreset /restart } }這樣一次搞定一批機(jī)器比一臺臺手動操作高效得多。不過記得先在測試機(jī)驗(yàn)證確認(rèn)沒問題再推到生產(chǎn)環(huán)境。