The Big Book of PowerShell Gotchas
  • ReadMe
  • About this Book
  • Format Right
  • Where is the __ command?
  • PowerShell.exe isn't PowerShell
  • Accumulating Output in a Function
  • ForEach vs ForEach vs ForEach
  • Tab Complete!
  • -Contains isn't -Like
  • You Can't Have What You Don't Have
  • Filter Values Diversity
  • Not Everything Produces Output
  • One HTML Page at a Time, Please
  • Bloody. Awful. Punctuation.
  • Don't Concatenate Strings
  • $ Isn't Part of the Variable Name
  • Use the Pipeline, Not an Array
  • Backtick, Grave Accent, Escape
  • These Aren't Your Father's Commands
  • A Crowd isn't an Individual
  • Commands' Default Output Can Lie
  • Properties vs. Values
  • Remote Variables
  • New-Object PSObject vs. PSCustomObject
  • Running Something as the "Currently Logged-in User"
  • Commands that Need a User Profile May Fail When Run Remotely
  • Writing to SQL Server
  • Getting Folder Sizes
Powered by GitBook
On this page

Commands that Need a User Profile May Fail When Run Remotely

PreviousRunning Something as the "Currently Logged-in User"NextWriting to SQL Server

Last updated 7 years ago

CtrlK

Many commands act against the currently logged-on user’s profile. Those commands can sometimes fail when you run them over a Remoting connection, such as by using Invoke-Command or Enter-PSSession. For example, many installers default to creating per-user icons, and those can fail when run remotely – even when run in a “silent install” mode.

The problem is that, when you connect to a remote computer, you aren’t spinning up a complete user environment. You’re technically not “logging on” to the machine in the usual sense. You’re authenticating, yes, but in much the same way that you’d authenticate to a shared folder. Your remote connection doesn’t have a complete user profile, and so anything that’s expecting one can get errors and fail (even if they don’t show those errors).

There’s no easy fix for this, unfortunately.