PowerShell使用Start-Process执行共享目录MSI时身份验证失败问题

Hey there, let's break down why you're hitting that "invalid username/password" error—even though you're entering the correct domain credentials—when trying to run the MSI from your network share. I’ve seen this quirk with PowerShell and network-based installs a few times, so here are actionable fixes to try:

1. Why Start-Process with UNC Paths Fails #

When you use Start-Process -Credential with a network UNC path, the credential launches the process, but Windows often doesn’t pass that credential to the SMB connection for the share. This creates a disconnect: the process runs under your domain account, but the share access still tries to use your local session’s permissions (which don’t have access to the network share).

2. Fix 1: Map the Network Share First (Recommended) #

Instead of pointing directly to the UNC path, map the share to a drive letter using your domain credentials first. This ensures the SMB connection uses the correct identity before launching the MSI. Adjust your script like this:

$domaincred = Get-Credential

# Map the network share to a drive letter (Z: in this example)
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\ofs1\shared\admin\original\screenconnect" -Credential $domaincred -Persist

# Run the MSI from the mapped drive, adding -Wait to let it finish before cleanup
Start-Process -FilePath "Z:\Mity-Corporate.msi" -ArgumentList "/quiet" -Wait

# Optional: Remove the mapped drive once the install completes
Remove-PSDrive -Name Z

3. Fix 2: Use Invoke-Command for Isolated Session Execution #

Another approach is to use Invoke-Command to run the install in a separate session that explicitly uses your domain credentials. This bypasses the SMB credential gap because the entire session runs under the specified account:

$domaincred = Get-Credential

Invoke-Command -ComputerName localhost -ScriptBlock {
    # Inside this block, we're running as the domain user, so share access works seamlessly
    Start-Process -FilePath "\\ofs1\shared\admin\original\screenconnect\Mity-Corporate.msi" -ArgumentList "/quiet" -Wait
} -Credential $domaincred

4. Double-Check Your Credential Format #

Even though you said you’re using domain/username, confirm the format matches what Windows expects:

• Use DOMAIN\Username (all caps for the domain can help avoid edge cases, though it’s usually case-insensitive)
• Or try Username@domain.com (UPN format) if your domain is part of a larger forest

You can verify your machine’s domain with $env:USERDOMAIN in PowerShell to ensure you’re using the correct value.

5. UAC Notes to Keep in Mind #

MSI installs almost always require admin rights. If your domain account has local admin privileges, that’s great—but note that Start-Process -Verb RunAs (for elevation) can’t be used alongside the -Credential parameter. If elevation is needed, make sure the domain credential you’re using is a local admin on the machine, or temporarily adjust UAC settings as a troubleshooting step.

The reason your local C:\ MSI works is simple: no network authentication is required for local files, so the process runs under your already authenticated session without issues.

内容的提问来源于stack exchange，提问作者StevenT