企业官网建设流程全解析

写这篇东西的起因挺简单：我一个同事在Win10笔记本上要管理几十台VMware虚拟机，天天开vSphere Client点点点，监控一堆虚拟机状态点得手麻，后来我直接给他在PowerShell里敲了两行命令，把全部虚拟机的CPU、内存、磁盘状态一次性拉了出来。他当场震惊，问我这是什么黑科技。其实这就是VMware PowerCLI，VMware官方出的PowerShell管理模块。这篇文章就围绕win10安装VMware PowerCLI这个主题，把从环境检查、安装、初始化到首次连接vCenter/ESXi的完整过程写清楚，顺手把我在安装和日常使用中踩过的坑也一并列出来，给后来人省点时间。

1. 安装前的核心思路：先搞清楚PowerCLI到底管什么

1.1 别搞混：PowerCLI不是给VMware Workstation用的

这些年搜VMware相关教程，十个有九个是在讲Workstation装虚拟机。很多新手以为装完VMware Workstation，再装个PowerCLI就能管虚拟机了，这其实是把两件事搞混了。VMware Workstation是跑在桌面系统上的虚拟化软件，给个人做测试用的；而PowerCLI的管理对象是vCenter Server和ESXi主机，也就是企业里那种跑在机房服务器上的虚拟化平台。说得再直白点，Workstation是单机玩具，PowerCLI管的是整个虚拟化集群。

Win10系统上装的PowerCLI，本质是一套PowerShell模块，通过调用vCenter或ESXi暴露的API接口来批量操作虚拟机、主机、存储、网络等资源。所以你先得有能连的vCenter或ESXi环境，否则装好PowerCLI也只能看看帮助文档，连接时报错是正常的。这篇文章主要讲Win10本地安装PowerCLI的完整流程，连接演示部分我会用vCenter环境来举例。

1.2 为什么必须要装PowerCLI：自动化是刚需

如果你只管三台五台虚拟机，鼠标点一点确实够用。但一旦虚拟机数量上了几十上百台，或者需要每天巡检、批量扩容、统一打标签、按部门统计资源消耗，图形界面就会变成灾难。PowerCLI的价值就体现出来了：

• 批量操作：一条命令给所有测试环境虚拟机加内存，不用一个个进设置界面
• 自动巡检：脚本定时跑一遍，自动导出所有主机的CPU、内存、存储使用率
• 可记录可回溯：命令历史就是操作记录，不像鼠标操作完全不可追踪
• 交接方便：把脚本交给别人，对方不需要知道你的点击路径也能完成操作
• 与CI/CD集成：虚拟机生命周期操作可以嵌入到自动化流水线里

我在实际工作中最常用的一个场景：每天早上一到公司，跑一条PowerCLI命令，自动抓取所有虚拟机的CPU就绪率、内存Swap率、磁盘延迟，生成Excel报表发到群里。这套流程以前靠手动点vSphere Client做，至少半小时，现在脚本跑完不到两分钟。这些需求就是我从vSphere界面切换到PowerCLI的最初动力。

1.3 版本选择逻辑：Win10环境下装哪个PowerCLI版本

PowerCLI从6.5 R1开始放弃独立的MSI安装包，改为从PowerShell Gallery发布模块，之后版本号一路从6.5升到10.x、11.x、12.x、13.x，到现在13.x和14.x也已经比较常见。Win10系统装PowerCLI，版本选择主要看两点：一是控制系统自带的PowerShell版本，二是要连接的vCenter版本。

Win10自带的是Windows PowerShell 5.1，这个版本可以兼容PowerCLI 12.x及以下的大部分版本。如果你要装最新版PowerCLI 13.x或14.x，官方要求最好用PowerShell 7.x，也就是PowerShell Core。不过对大部分人来说，在Win10上用Windows PowerShell 5.1装一个12.x版本的PowerCLI是最稳妥的路线，因为vCenter版本、ESXi版本、PowerCLI版本三者之间有兼容矩阵，新版PowerCLI不一定兼容旧的vCenter。我个人的建议是：如果你的vCenter还是6.7或7.0，不要盲目追新，PowerCLI 12.0到12.4这个区间足够用了；如果vCenter是8.0，可以考虑直接上12.5以上版本或者13.x。安装之前去VMware官方兼容性列表查一下最保险。也可以先用Get-Module -ListAvailable命令看看本机已经有什么版本，避免装重复。

2. 安装前置准备：Win10环境检查清单

PowerCLI安装本身不算复杂，但很多人装到一半卡住，基本都栽在前置环境上。这一节把Win10下需要检查的东西罗列完整，每一项都是我的实测经验，漏一项都可能让你白折腾半天。

2.1 确认PowerShell版本

PowerCLI模块要求Windows PowerShell 5.1及以上。Win10系统基本都自带Windows PowerShell 5.1，如果你的系统是较早的版本，可能需要手动开启。检查方法很简单：按Win+R，输入powershell，回车打开PowerShell窗口，输入下面命令：

$PSVersionTable.PSVersion

输出结果里看Major版本号是不是5或者7。如果是3或者4，那就要先升级PowerShell或者通过Windows Management Framework升级.NET环境。我自己在Win10 22H2上实测，默认就是5.1，直接用就行。

顺便说一下，Win10默认的控制台字体和配色在跑PowerCLI时看着比较费眼，字小、背景蓝，我一般会在PowerShell窗口标题栏右键选择“属性”，把字体调到Consolas 16号，屏幕缓冲区调大一点。这些虽然不影响安装，但对后续写脚本的体验提升很大。

2.2 执行策略和NuGet提供程序

PowerShell默认的执行策略是Restricted，不允许运行本地脚本，但Install-Module命令本身是允许执行的。不过为了后续导入模块和运行脚本方便，建议先放开执行策略。这里我只建议放开到RemoteSigned，意思是从本地创建的脚本可以运行，从网上下载的脚本必须有数字签名，这样既方便又不会把安全策略完全关掉。执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

然后输入Y确认。注意这里的Scope用了CurrentUser，只对当前用户生效，不需要管理员权限，比改LocalMachine要安全得多。

另一个影响安装的关键组件是NuGet提供程序。PowerCLI模块托管在PowerShell Gallery上，Install-Module下载模块时需要调用NuGet提供程序来解析包。如果系统里没有NuGet或者版本过低，装的时候会弹提示问你是否安装NuGet provider，输入Y回车，如果自动安装失败，可以手动装：

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

这里有个细节：如果PowerShell的版本比较旧，NuGet安装时会报“无法连接到远程服务器”之类的错误，解决办法往下看TLS的设置。

2.3 TLS 1.2配置：最容易被忽略的一步

很多Win10默认没开启PowerShell对TLS 1.2的支持，访问PowerShell Gallery时就会莫名失败，报错信息千奇百怪，例如“无法解析模块”“基础连接已关闭”等等。这个问题我见过太多次，每次帮同事排查都在这一步卡住。解决办法很简单，在PowerShell窗口里先执行：

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

然后重新执行Install-Module。如果只是为了临时安装，当前窗口设置一次就够了；如果你希望每次打开PowerShell都自动生效，可以把这行写进PowerShell配置文件里。写配置文件有个更简单的办法，在PowerShell里输入：

$profilePath = $PROFILE New-Item -Path $profilePath -ItemType File -Force Add-Content -Path $profilePath -Value '[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12'

之后再开新的PowerShell窗口，TLS配置就会自动生效。这一步对国内网络环境下访问PSGallery尤其重要，网络波动加上TLS不兼容，十有八九会让你怀疑是软件坏了。

2.4 Win10安全中心和SmartScreen可能造成的影响

安装PowerCLI时，Win10安全中心通常不会直接拦截 PowerShell 内部操作，但有两种情况会跳出来：一是如果你用管理员权限执行Install-Module时触发UAC弹窗，二是下载的脚本或模块被SmartScreen拦下来。网上天天有人搜“win10安全中心关闭”，但我在装PowerCLI时从未真正需要关闭安全中心。如果遇到SmartScreen拦截，正确做法是选择“仍要运行”或“更多信息-仍要运行”，而不是把整个系统的安全防护关掉。

还有个小概率情况：某些杀毒软件会把PowerShell的模块文件误报为风险程序，导致Install-Module中途失败。如果你装了第三方杀毒，建议先给PowerShell目录和模块文件夹加个白名单，路径一般是 $env:USERPROFILE\Documents\WindowsPowerShell\Modules 和 C:\Program Files\WindowsPowerShell\Modules。等你确认模块没问题后，可以再恢复防护策略。

3. 安装全流程实录：从PowerShell窗口到PowerCLI就绪

3.1 用管理员身份打开PowerShell

在Win10上安装PowerCLI，我建议用管理员身份打开PowerShell。虽然Install-Module加了-Scope CurrentUser就不需要管理员权限，但后面设置执行策略、配置模块路径、导入模块时，权限不够会报错。如果你加的-Scope是AllUsers，那就必须管理员权限了。操作方式：按Win键，输入PowerShell，在搜索结果里右键“Windows PowerShell”，选择“以管理员身份运行”。如果你是用PowerShell 7，同理操作。

打开后窗口标题栏应该显示“管理员: Windows PowerShell”。这一步不要跳过，我见过太多人装到一半报UnauthorizedAccess，就是没用管理员身份。

3.2 设置执行策略并确认PSGallery为受信任源

管理员窗口打开后，先配置执行策略：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force

接下来准备从PowerShell Gallery安装模块。PSGallery默认的安装策略是Untrusted（不受信任），安装时会弹确认提示。如果希望全程免交互，可以先设置PSGallery为受信任的存储库：

Get-PSRepository Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

这里注意一点：Set-PSRepository如果提示找不到仓库，说明你的PowerShellGet组件版本太老，可以先执行下面命令更新PowerShellGet：

Install-Module -Name PowerShellGet -Force -AllowClobber

更新完后重新开一个管理员PowerShell窗口。这一步对老系统特别管用。

3.3 Install-Module安装VMware.PowerCLI模块

一切就绪后，正式安装PowerCLI：

Install-Module -Name VMware.PowerCLI -Scope CurrentUser -Force

如果前面设置了PSGallery为Trusted且已经是管理员窗口，这条命令不会弹任何确认框，直接开始下载。VMware.PowerCLI不是一个小模块，它包含VMware.VimAutomation.Core、VMware.VimAutomation.CisClient、VMware.PowerCLI.VCenter等多个子模块，总下载体积可能上百MB，所以安装过程会比较久。看到进度条在走，别急着关窗口。

安装完成后，再执行Get-Module -ListAvailable验证一下：

Get-Module -ListAvailable -Name VMware.PowerCLI

如果输出里有VMware.PowerCLI的信息，说明模块已经装进当前用户模块目录了。这条命令同时也能看到版本号，方便你判断自己装的是哪一版。如果这里什么都看不到，检查一下模块安装路径是否在PSModulePath里，正常情况用户目录下的模块会被自动识别。

3.4 首次导入模块：EULA确认和CEIP设置

安装完成不等于可以马上用，还需要导入模块。第一次导入会弹一个License Agreement，询问是否接受VMware的最终用户许可协议。执行：

Import-Module VMware.PowerCLI

如果弹出EULA确认，英文界面，仔细看内容后，输入Y回车即可。这里有个坑：有些新手在EULA界面直接按了Ctrl+C，导致导入中断；实际上这个协议必须确认一次，之后就不会再弹了。

同时，PowerCLI首次使用还会询问是否参加客户体验改善计划（CEIP），就是收集使用数据发送给VMware。建议在生产环境直接关掉，没必要把操作数据往外传。关闭命令：

Set-PowerCLIConfiguration -ParticipateInCEIP $false -Confirm:$false

还需注意证书校验策略。国内很多企业机房用的vCenter证书是自签名或者不完整信任链的，PowerCLI默认会严格校验证书，导致Connect-VIServer时直接报证书错误。刚装完PowerCLI时可以先统一设置为忽略证书校验，等确认连接没问题再按需调回来。命令如下：

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

这个配置会写入当前用户目录下的配置文件，之后每次打开PowerShell都会自动加载，不需要重复设置。如果你所在的环境有合规要求，不允许忽略证书，那就在安装完证书链之后把InvalidCertificateAction改回Prompt或Fail。

3.5 验证安装结果与查看版本

导入成功后，验证PowerCLI是否可用。执行：

Get-Command -Module VMware.PowerCLI

会列出PowerCLI提供的所有命令，正常情况有几百条。如果输入后什么都没有，大概率是模块导入失败，看看是不是加载了多个冲突版本。

也可以直接查看PowerCLI版本：

Get-Module VMware.PowerCLI | Select-Object Name, Version

到这里，Win10上的PowerCLI环境就已经装好并能正常导入了。接下来就可以连vCenter试一下。

4. 首次连接vCenter/ESXi的实操验证

4.1 用Connect-VIServer建立连接

验证PowerCLI是否真正可用，最直接的方式就是连一个vCenter或ESXi主机。连接vCenter用Connect-VIServer命令：

Connect-VIServer -Server 192.168.100.10 -User admin@vsphere.local -Password '你的密码'

这里稍微解释下参数：-Server就是vCenter的IP或者FQDN；-User是vCenter账号；-Password是可选项，不写的话PowerShell会弹出安全输入框，避免密码出现在命令历史里。如果你在脚本里要自动化运行，再考虑明文传密码，平时练习建议先不加-Password。

连接成功后，PowerShell会返回vCenter的名称、版本、端口、会话等信息。如果报错，九成是证书问题，上一节已经设置了Ignore，如果你在设置之前就直接连接，会看到类似“SSL证书验证失败”的报错。

4.2 简单的巡检命令实例

连接成功之后，跑几条命令试试。比如列出所有虚拟机：

Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB

查看主机信息：

Get-VMHost | Select-Object Name, ConnectionState, Version, Build

查看存储信息：

Get-Datastore | Select-Object Name, CapacityGB, FreeSpaceGB

这些命令跑通，说明PowerCLI的安装和连接流程全部没问题。实际工作中，我会把这些命令拼成一个巡检脚本，每天定时跑，把结果导出成CSV或Excel，自动发送到指定目录。PowerCLI脚本本质上就是PowerShell脚本，所以PowerShell里能做的逻辑判断、循环、异常处理，在PowerCLI脚本里都能用。

举个例子，批量给所有名称包含test的虚拟机增加2GB内存：

Get-VM | Where-Object { $_.Name -like "*test*" } | Set-VM -MemoryGB ($_.MemoryGB + 2) -Confirm:$false

当然，Set-VM改内存需要虚拟机处于关机或者启动状态下都行，但如果虚拟机有快照，改配置会被某些约束限制，具体看环境配置。

4.3 断连和清理会话

测试完不要忘了断开连接，尤其是通过公网或者远程会话连接vCenter时，闲置连接会占用vCenter的会话资源。断开命令：

Disconnect-VIServer -Server 192.168.100.10 -Confirm:$false

断开后可以确认一下当前还有没有活动连接：

Get-VIServer

这条命令会列出所有当前PowerShell进程里建立的vCenter/ESXi连接。如果不需要连接了，可以用Disconnect-VIServer * -Confirm:$false 一次性全部断开。这个小习惯对长期自动化任务很有帮助，不至于产生一堆僵尸会话把vCenter的连接池耗尽。

5. 常见问题与排查技巧实录

PowerCLI安装和使用过程中，我遇到或者帮人解决的问题实在太多了，这里挑几个出现频率最高的，整理成速查表，方便你直接对号入座。

下面挑几个重点细说。

5.1 下载慢或反复失败的处理方案

从PSGallery下载PowerCLI受网络环境影响很大。如果你在公司网络环境里，出网速度慢或者有严格的安全策略，Install-Module可能跑一半就断。这时候不要反复重试同一招，换个思路：

• 优先使用PowerShell 7配合最新版PowerShellGet，下载稳定性会好不少
• 用离线安装方式：在一台网络正常的机器上把VMware.PowerCLI模块包下载下来，拷贝到目标Win10机器的模块目录下
• 公司有内网NuGet镜像的话，配置PSGallery源地址指向内部镜像

离线安装的具体操作说起来也不复杂：先从能联网的机器上执行 Save-Module -Name VMware.PowerCLI -Path D:\PowerCLIModule，把模块文件保存到本地文件夹，然后把整个文件夹拷贝到目标机的 $env:USERPROFILE\Documents\WindowsPowerShell\Modules 目录下面，再执行 Import-Module VMware.PowerCLI 就可以导入了。这个方法也适用于完全无法访问外网的生产环境。

5.2 证书报错不是洪水猛兽

很多新手第一次连vCenter，看到红色报错就慌，以为是账号密码不对。其实最常见的错误就是SSL证书校验失败，报错信息多半是“The server certificate is not trusted”或者“由于验证证书链的一部分已终止”。原因很简单：企业vCenter默认用的是VMware自签名证书，系统中没有对应的根证书，Win10自然不信任它。

解决办法有两种：一种是我前面提到的全局忽略证书校验，适合测试或内网环境；另一种是把vCenter的根证书导入到Win10的受信任根证书颁发机构存储里，适合生产环境。后者的操作为：浏览器访问vCenter的地址，下载证书文件，双击导入到“受信任的根证书颁发机构”。导入完成后再把PowerCLI的InvalidCertificateAction改回Prompt，这样安全性和可用性兼顾。

5.3 模块版本冲突怎么破

PowerCLI升级时最容易出问题。比如你原来装了12.0，现在又装了12.4，可能导致Import-Module时加载的版本不是你想要的。查版本：

Get-Module -ListAvailable -Name VMware.PowerCLI | Sort-Object Version -Descending | Select-Object Name, Version

如果非要指定某个版本导入：

Import-Module VMware.PowerCLI -RequiredVersion 12.4.0

彻底解决冲突的最好办法是先把旧版本卸载干净，再装新版本。卸载命令：

Get-Module -ListAvailable -Name VMware.PowerCLI | Uninstall-Module

然后重新安装指定版本。这里特别提醒：如果之前老版本是通过旧安装包方式装的，残留文件可能在C:\Program Files\WindowsPowerShell\Modules里，手动删除时用管理员权限。卸载干净后再装新版本，可以避免非常多的诡异报错。

6. 安装之后的版本管理与学习路径建议

6.1 版本升级与锁定

PowerCLI模块更新频率不算低，主要跟随vCenter新版本发布节奏。日常使用中，如果不是有明确的新功能需求，不建议频繁升级。因为升级后某些命令的参数可能会有破坏性变更，之前写的脚本可能跑不了了。我个人的做法是：在测试环境先装新版本，跑一遍核心脚本回归，没问题再在常用机器上升级。

如果想锁定某个版本，安装时加-RequiredVersion参数即可：

Install-Module -Name VMware.PowerCLI -RequiredVersion 12.4.0 -Force

升级时用Update-Module：

Update-Module -Name VMware.PowerCLI

也要提醒一下，Update-Module会把模块更新到最新版，如果你不想要最新版，同样用-RequiredVersion指定。PowerShell版本管理这块，越早养成锁版本的习惯，后面越省心。

6.2 从会装到会用的几个建议

装好PowerCLI只是起点，真正有价值的是拿它解决实际问题。给想深入的同学几个方向：

• 从Get-VM、Get-VMHost、Get-Datastore这几个基础命令入手，先把查询练熟
• 学会用Where-Object、ForEach-Object做条件筛选和循环，这是批量操作的基本功
• 学会把脚本参数化，比如写一个包含VLAN、CPU、内存参数的创建虚拟机脚本
• 尝试把PowerCLI集成到计划任务里，做定时巡检和报表
• 习惯看官方文档Get-Help Connect-VIServer、Get-Help Get-VM，很多参数用法查一查就明白了

日常写脚本时，我习惯在脚本开头加上一行连接操作并做判断，如果连接失败就退出；在脚本结尾用Disconnect-VIServer断开。这样即使脚本跑得再久，也不会留下悬空的vCenter会话。

6.3 离线环境下的等效方案

有些机房网络隔离严格，PowerCLI模块无法在线安装。离线安装前面提过，我再补充一个细节：离线安装时不仅要把VMware.PowerCLI主模块拷过去，还需要把它的依赖模块（常见的有VMware.VimAutomation.Core等）一起拷过去。Save-Module默认会把依赖一并保存到指定目录，所以拷贝整个目录就行，不要只拷一个nupkg文件。如果发现模块导入报错，提示找不到某某依赖模块，重新检查一下目录结构是否完整。

另外，如果离线环境下还要用PowerShell 7来跑PowerCLI 13，需要先在一台联网机器上把PowerShell 7的安装包也下载好，然后离线安装，再把模块目录指向PS7的模块路径。这种两层离线操作看起来繁琐，但熟练之后十分钟就能搞定。

我个人在实际操作中的体会是，PowerCLI安装这件事，90%的问题都出在前置环境上，真正模块本身出问题的概率很低。所以如果你装到一半卡住了，回头看TLS、NuGet、执行策略、网络这四件事，排掉其中任何一个坑基本就通了。最后再分享一个小技巧：装完之后，把刚才执行过的安装命令整理成一个文本文件，放到自己能找到的地方，下次换新电脑或者帮同事装的时候直接复制粘贴，省下的时间都是自己的。PowerCLI这东西，装好只是第一步，真正用得顺手，还得靠平时多写多试，把重复劳动一点点变成命令和脚本。