一、为什么用PowerShell来做配置管理

配置管理听起来是个大词，其实说白了就是：把你需要在一台电脑上做的事情，提前写成一段能反复执行的“说明书”。过去我帮同事配置开发环境时，总是靠鼠标点来点去：打开设置、改环境变量、装软件、调服务。每来一个新同事，这套操作就得再来一遍，浪费时间不说，还容易漏掉某一步。后来改用 PowerShell 以后，我把整个流程写成脚本，跑一次就能把环境从一个空白状态收拾得整整齐齐。

PowerShell 并不是只能执行“安装软件”这种大操作，它更像一个能跟 Windows 系统深度对话的翻译官。注册表、服务、防火墙、计划任务这些藏得很深的系统配置，它都能轻松读写。你可能会问：这些东西平时谁改？恰恰是这些不起眼的地方，最容易造成线上故障。比如某台服务器因为缺少一个补丁，或者某个服务启动类型被改成了“手动”，就会引发奇怪的问题。有了 PowerShell，你就可以把所有关键设置统一管理起来，一眼看清哪台机器符合标准，哪台跑偏了。

当然，一开始接触 PowerShell 会觉得它有点啰嗦。命令往往很长，参数也很多。但是当你习惯了它的套路之后，就会发现它非常有规律。比如“想拿什么就 Get-什么”，“想新建什么就 New-什么”，“想改什么就 Set-什么”。这种极简的命名方式，其实比记一堆按钮位置要轻松得多。接下来，我们一起从最基础的操作开始，慢慢把配置管理这套功夫练起来。

二、从零开始：几个最常用的配置管理操作

2.1 先看看这台电脑是什么状态

不管什么时候，配置管理的第一步都是“看清楚现状”。手动操作时代，我们靠一个个窗口猜；脚本化之后，一条命令就能把系统信息抓出来。下面的例子用来查看电脑基本信息：

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 获取操作系统名称、版本和计算机名
Get-ComputerInfo -Property "OsName", "OsVersion", "CsName"

# 查看当前登录用户的用户名
whoami

# 查看 C 盘剩余空间，注意这里拿到的 Free 和 Used 都是字节
Get-PSDrive -Name C | Select-Object Used, Free

这几条命令看起来简单，但它们是很多自动化脚本的开胃菜。比如你可以在给服务器做体检时，把所有机器的配置信息汇总成一个表格，用来快速发现某些机器是不是内存不足，或者系统版本是不是该升级了。

2.2 管理环境变量

配置管理最常遇到的是环境变量。以前我装 Java 时，总要到“高级系统设置”里手填 JAVA_HOME，还要小心别把路径写错。PowerShell 里可以用命令直接管理，还能区分是临时生效还是永久生效。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 设置一个只在当前窗口临时生效的变量
$env:MY_APP_HOME = "C:\Apps\MyApp"

# 把变量永久写入当前用户的环境变量列表
[Environment]::SetEnvironmentVariable("MY_APP_HOME", "C:\Apps\MyApp", "User")

# 读取当前用户的这个环境变量
[Environment]::GetEnvironmentVariable("MY_APP_HOME", "User")

# 删除当前用户环境变量，把值设为 $null 即可
[Environment]::SetEnvironmentVariable("MY_APP_HOME", $null, "User")

这里要特别说明一下：$env:MY_APP_HOME 这种写法只对当前 PowerShell 窗口有效。想让其他程序以后也能看到这个变量，就一定要用 [Environment]::SetEnvironmentVariable 这个写法。很多新手踩过坑，就是因为在命令行里设置成功了，关掉窗口又不见了，原因就在这里。

2.3 修改注册表配置

注册表是 Windows 的“超级档案室”，很多软件的行为都靠它控制。手动改注册表又危险又麻烦，用 PowerShell 却非常顺手。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 定义一个注册表路径
$path = "HKCU:\Software\MyCompany\MyApp"

# 如果这个键不存在，就创建它；存在的话也不会报错
New-Item -Path $path -Force | Out-Null

# 在这个键下面写入一个属性值，用来控制软件是否记录日志
Set-ItemProperty -Path $path -Name "EnableLogging" -Value 1

# 读取刚才写入的值，验证是否成功
Get-ItemProperty -Path $path | Select-Object EnableLogging

每次写注册表之前，我都习惯先在测试机器上验证一次，毕竟注册表改错可能导致某些程序无法启动。合理的做法是：把要改的键和值先打印出来，再决定是否提交。上述脚本里 Out-Null 是管道里很常见的“消音器”，让多余文字不糊到屏幕上。

2.4 管理服务的启动和关闭

很多应用都依赖后台服务，比如打印服务、数据库服务。配置文件管理里，保证服务是“正在运行”的非常重要。这个需求可以用下面几条命令解决。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 查看一个服务的当前状态
Get-Service -Name "Spooler" | Select-Object Name, Status, StartType

# 启动服务
Start-Service -Name "Spooler"

# 把服务启动类型改成自动，这样开机后服务自动跑起来
Set-Service -Name "Spooler" -StartupType Automatic

需要注意的是，有些服务启动后还要等它真正进入“Running”状态。更稳妥的方式是加上 -ErrorAction Stop，再等待几秒钟做二次检查。

三、把配置写进文件，再按需应用

刚才那些例子都属于“临时命令”，适合手动排查。真正的配置管理要把配置内容集中到一个文件里，形成项目清单。这样修改配置时不用翻脚本，直接改文件即可。我比较喜欢用 JSON 文件存放配置，因为阅读起来不费劲，PowerShell 对 JSON 的支持也特别好。

3.1 在 PowerShell 里生成一个 JSON 配置文件

下面这段脚本会在磁盘上生成一个标准的 JSON 文件。你可能看不出它和普通文件有什么特别，但它其实是一个很完整的配置模板，包含了应用名、版本号、安装目录和是否自启动等关键信息。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 定义一个 JSON 格式的配置内容，这里使用了 PowerShell 中的 here-string
$config = @'
{
  "appName": "演示程序",
  "version": "1.0.0",
  "settings": {
    "installdir": "C:\\Program Files\\MyApp",
    "autoStart": true
  }
}
'@

# 将内容写入文件，使用 UTF-8 编码防止中文乱码
$config | Out-File -FilePath "C:\config.json" -Encoding utf8

这里要留意：JSON 里面反斜杠需要写成双反斜杠，因为在 PowerShell 字符串里 \ 不是转义字符，但为了保持 JSON 文件的合法性，我们要把路径写成 C:\\Program Files\\MyApp。如果你觉得容易记混，也可以直接用单引号 here-string，避免被 PowerShell 做额外的变量解析。

3.2 读取 JSON 配置并应用

拿刚才的配置举个例子。我们要在目标机器上创建一个安装目录，并且根据配置决定要不要启动某个服务。下面的脚本会把 JSON 文件读进来，再转换成 PowerShell 对象，非常直观。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 读取 C 盘根目录下的 config.json，转换为对象
$config = Get-Content -Path "C:\config.json" -Raw | ConvertFrom-Json

# 输出配置里的关键信息
Write-Host "应用名称：$($config.appName)"
Write-Host "版本号：$($config.version)"

# 如果安装目录不存在就创建它
New-Item -Path $config.settings.installdir -ItemType Directory -Force | Out-Null

# 如果配置中允许自动启动，就把指定服务设置为自动并启动
if ($config.settings.autoStart) {
    Set-Service -Name "MyService" -StartupType Automatic
    Start-Service -Name "MyService"
}

这套组合拳特别适合应用发布场景。每次上线前，只需要把配置文件里的版本号和开关改一改，脚本这边不用动，就能完成大部分环境准备工作。配置文件本身也可以放到 Git 仓库里，追踪每一次改动是谁做的、为什么做，这点对团队协作非常友好。

3.3 批量管理多台机器

单机操作只是入门，配置管理真正厉害的地方是批量处理。只要目标机器开启了远程管理（WinRM），你就可以在本地电脑上同时对很多台服务器下达指令。下面的例子演示了如何在三台服务器上查询系统信息。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 定义服务器列表
$servers = @("web01", "web02", "db01")

# 在这三台机器上执行同一个操作
Invoke-Command -ComputerName $servers -ScriptBlock {

    # 下面的代码是在远程电脑上执行的
    $osInfo = Get-ComputerInfo -Property OsName, OsVersion
    Write-Output "$($osInfo.CsName) 是 $($osInfo.OsName)"
    
} -Credential (Get-Credential)

执行之后，PowerShell 会弹出一个登录窗口，让你输入有管理权限的账号和密码。这种交互方式比把密码写死在脚本里安全得多。如果是自动化平台使用，可以改用更安全的证书认证，这里不展开，但至少你要知道：不要用明文密码。

四、进阶：用 DSC 让配置保持稳定一致

4.1 DSC 到底是什么

PowerShell 里有一个叫 DSC（Desired State Configuration）的功能，名字听起来高深，其实思路非常简单。普通脚本是“你让我做什么我就做什么”，而 DSC 是“我告诉你最后应该长成什么样，你自己判断缺什么就补什么”。有点像装修时，你给施工队一张效果图，他们自己检查墙是不是白的、地板是不是木色的，不是就调整为效果图的样子。这样做的好处是：脚本可以反复执行，不会因为重复运行而反复制造垃圾配置。

4.2 一个简化版的 DSC 配置示例

DSC 配置看起来像一座工厂，里面声明了各种“我要的状态”。下面这个例子声明了四件事：安装 Web 服务器功能、创建网站目录、复制配置文件、确保服务在运行。

# 技术栈：Windows PowerShell 5.1（DSC 功能）

# 定义一个名为 MyWebServer 的配置
Configuration MyWebServer {

    # 引入 DSC 自带的资源模块
    Import-DscResource -ModuleName PSDesiredStateConfiguration

    # 针对本机进行配置
    Node "localhost" {

        # 1. 确保 Web-Server 功能已经安装
        WindowsFeature WebServer {
            Name   = "Web-Server"
            Ensure = "Present"
        }

        # 2. 确保网站在目录存在
        File SiteFolder {
            DestinationPath = "C:\inetpub\wwwroot\myapp"
            Ensure          = "Present"
            Type            = "Directory"
        }

        # 3. 确保已经发布出来的 web.config 被复制过去
        File SiteConfig {
            DestinationPath = "C:\inetpub\wwwroot\myapp\web.config"
            Ensure          = "Present"
            SourcePath      = "D:\release\web.config"
            DependsOn       = "[File]SiteFolder"
        }

        # 4. 确保自定义服务正在运行，并且开机自启
        Service MyService {
            Name        = "MyAppService"
            State       = "Running"
            StartupType = "Automatic"
        }
    }
}

# 编译上面这个配置，生成目标机器可以识别的文件
MyWebServer -OutputPath "C:\DSC\MyWebServer"

# 把配置应用到本机
Start-DscConfiguration -Path "C:\DSC\MyWebServer" -Wait -Verbose -Force

这段代码里最重要的关键词是 Ensure = "Present"，意思是“我要求它存在”。如果系统已经满足，DSC 就什么也不做；如果不满足，DSC 会主动改变系统状态。这种“声明式”的写法和命令式脚本相比，最大的优势是可靠，你不用担心跑两遍会出问题。

4.3 DSC 的优缺点

DSC 的优点很明显：它能把配置变成一种“事实”，每次执行前都会自动比较当前状态和目标状态，省去大量的人工判断。它还支持将配置推送到多台服务器，适合做集群环境。不过它的缺点也不小，首先是模块和资源种类繁多，有些第三方资源需要额外下载安装；其次是排错比较麻烦，错误信息往往不会告诉你“到底是哪一步没对上”，需要经验。对于初学者来说，不用急于掌握所有细节，先知道有这个概念，等遇到重复跑脚本的情况时再回来深入学习。

五、应用场景详解

下面是我自己用过的一些典型场景，希望能帮你把这个工具放进真实的工作里。

5.1 开发环境初始化

新同事入职时，最怕听到“你帮我装一下 JDK、Node、数据库，再配一下环境变量”。这些事情完全可以写成脚本，跑一次就能完成。推荐用 winget 搭配 PowerShell 来安装软件，非常方便。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 设置系统时区为中国标准时间
Set-TimeZone -Id "China Standard Time"

# 创建统一开发目录
New-Item -Path "C:\dev" -ItemType Directory -Force | Out-Null

# 使用 winget 安装 Visual Studio Code
winget install --id Microsoft.VisualStudioCode --source winget --accept-package-agreements --accept-source-agreements

# 设置 Git 全局配置
git config --global core.autocrlf true

这种脚本最大的价值在于“标准化”。团队里每个人的电脑环境都长得一样，后续协作时就不会出现“我这儿能跑，你那儿跑不了”的经典问题。

5.2 服务器上线前检查

在接手一台新云主机时，我会先运行一组检查脚本，看看主机名是否符合规范、时区是否正确、防火墙是否开放指定端口、有没有多余的临时用户。这些操作如果全部用鼠标点，耗时很长，但用命令就能很快完成。

5.3 应用发布时的配置刷新

发布系统时，经常要从配置中心拉取最新配置，然后覆盖到本地配置文件，再重启服务。下面这个思路可以套用：

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 从配置中心下载最新配置
Invoke-WebRequest -Uri "http://config-server/app1/config.json" -OutFile "C:\app1\config.json"

# 重启应用服务
Restart-Service -Name "App1Service" -Force

这样做的好处是发布过程可以被追踪，不会出现“手动改乱了某个参数”的情况。

六、技术优缺点分析

PowerShell 在配置管理中的优点非常突出。

第一，它和 Windows 系统是“一家人”，不需要额外安装很重的代理程序。注册表、服务、安全策略这些 Windows 特色功能，用别的脚本语言很难碰，但 PowerShell 能直接处理。

第二，命令风格统一，几乎都是“动词-名词”的结构。比如 Get-Process、Stop-Service、Set-Item。虽然一开始要查文档，但熟悉后特别好猜。

第三，它面向对象。你拿到的不只是文字，而是带有属性和方法的对象。比如 Get-Service 返回的服务对象可以用 .Start() 方法启动，也可以取出 .Status 属性做判断，这比解析纯文本强得多。

不过它也有短板。

首先，尽管现在有支持 Linux 和 macOS 的 PowerShell Core，但一些 Windows 专属模块只能在 Windows 环境使用，跨平台能力始终比不上 Ansible 这类工具。

其次，PowerShell 的语法陷阱不少。比如变量名大小写不敏感，但命令参数有严格大小写要求；算术运算里 + 既能加数字也能拼接字符串，容易混淆。这些细微之处对新手不太友好。

最后，权限太高，意味着破坏力也大。一个不小心，就可能把系统服务停掉或者注册表改乱。所以使用前一定要有敬畏之心，宁可多写几条检查命令，也不要盲目执行。

七、注意事项

结合我的实际经验，这里有几条值得特别注意的事项。

执行策略是第一道门槛。新安装的 Windows 系统默认可能禁止运行脚本，所以要先查看并调整策略。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 查看当前执行策略
Get-ExecutionPolicy

# 允许本地脚本直接运行，来自网络的脚本必须签名
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

权限管理要谨慎。普通配置操作使用当前用户即可，涉及系统级设置时要用“管理员身份”启动 PowerShell。不要把每次操作都以管理员身份运行，更不要为了方便把执行策略改成 Unrestricted。

错误处理不能少。写脚本时要假设每一步都可能失败，然后做好异常捕获。

# 技术栈：PowerShell 7 或 Windows PowerShell 5.1

# 尝试获取一个不存在的服务，并捕获错误
try {
    Get-Service -Name "不存在的服务" -ErrorAction Stop
}
catch {
    Write-Host "捕获到错误：$($_.Exception.Message)" -ForegroundColor Yellow
}

配置文件要纳入版本控制。很多事故源于“有人改了服务器上的配置文件，但没人知道改了什么”。把脚本和 JSON 配置一起放进 Git 仓库，每次修改都留痕，这会让你安心很多。

敏感信息不要硬编码。数据库密码、API 密钥这类内容千万不要直接写在脚本里。更好的做法是用 PowerShell 的 SecretManagement 模块，或者至少把密码保存在受控的凭据文件里，并在使用后及时清理。

最后，上线前一定要先在测试环境跑一遍。PowerShell 的威力大，风险也大，在真实生产机上直接跑没有验证过的脚本，就像不系安全带开车，非常危险。

八、文章总结

配置管理不是为了炫技，而是为了让重复劳动变得可控、可追溯。PowerShell 作为 Windows 环境下的脚本利器，既能处理简单的环境变量、注册表项，也能通过 DSC 实现复杂的状态一致。这篇文章从最基础的状态检查讲到了配置文件管理、远程批处理以及 DSC 的入门示例，基本上覆盖了日常配置管理会用到的核心手段。更重要的是，我们反复强调了对执行策略、权限、错误处理和敏感信息的关注，这些才是真正决定自动化项目能不能安全落地的关键。希望你能从一个小例子开始，试着用 PowerShell 解决身边的重复工作，慢慢积累成自己的配置管理工具箱。