Using session to add central module path to remote machines

This topic contains 4 replies, has 3 voices, and was last updated by  Dave Wyatt 4 years ago.

  • Author
    Posts
  • #9647

    Jarrod Morrison
    Participant

    Hello powershell gurus

    I might be barking up the wrong tree here, but Im writing my first powershell script to make my life easier managing the patching deployment process across a number of sites I work with. So I thought I was doing well so far by first of all checking that I have no active backup jobs running with any servers, making sure my terminal servers have no one logged on and opening a session to all my servers. I next did a bit of googling and found that a module was written to already control the windows updates process which I tested manually on a machine

    http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc

    So my next step is to either deploy this module or host it centrally on a unc so I can use it with all my servers. What ive tried so far is playing around with $env:PSModulePath = $env:PSModulePath + ";\\myserver\myshare\PSWindowsUpdate" from inside a invoke-command using my session I opened which didnt work. Im wondering what others do in this situation, do you xcopy deploy the module to the servers or work with it centrally ? I guess being very new to powershell I want to try and do it the correct way

  • #9650

    Don Jones
    Keymaster

    $env can only change the path for the CURRENT process. That's a Windows thing. Take a look at the discussion at https://powershell.org/forums/topic/invoke-command-to-set-psmodulepath/.

  • #9655

    Dave Wyatt
    Moderator

    Rather than updating the PSModulePath variable on all your machines, a possible alternative is to use a full path to the module in the Import-Module command of whatever scripts are using it. I haven't tried using a UNC path in this situation, but it's worth a shot.

    Import-Module '\\server\share\folder\PSWindowsUpdate'
    

    From a performance perspective, it might be even better to have your script copy down the module to the local machine, then import the local copy into your PowerShell session:

    if ((Test-Path -Path "$home\Documents\WindowsPowerShell\Modules") -eq $false)
    {
        $null = New-Item -ItemType Directory -Path "$home\Documents\WindowsPowerShell\Modules"
    }
    robocopy '\\server\share\folder\PSWindowsUpdate' "$home\Documents\WindowsPowerShell\Modules\PSWindowsUpdate" /MIR /DST
    
    Import-Module PSWindowsUpdate
    
  • #9680

    Jarrod Morrison
    Participant

    Thanks for the quick response. Ive had a bit of a play with the copy down method and had to enable credssp for accessing the unc path which I setup. Is it considered standard practice to leave credssp enabled or do people turn it on and off all the time ?

  • #9681

    Dave Wyatt
    Moderator

    If you're running the sample code I posted with Invoke-Command against a remote computer, then yes, you'd need to use CredSSP to enable the "second hop" scenario. I'm not sure if there's a compelling reason to leave CredSSP support disabled on your machines, but maybe someone else here can pipe in on that.

    Assuming you don't want to leave it enabled, you have a couple of options:

    • Enable CredSSP on the target computer, use it, and disable it, all in the same script.
    • Have the calling script handle pushing the files from the UNC share to the target computer, so the script executed by Invoke-Command no longer has to access a remote resource.

You must be logged in to reply to this topic.