Kaseya Community

Looking for an answer: Writing .zip contents to a protected folder

This question is answered
Procedure TESTING - Import PowerShell Windows Update Module(s).xml

Simple script (attached) to download a ZIP file from Microsoft and unzip to the C:\Windows\System32\WindowsPowerShell\v1.0\Modules directory which appears to be a protected folder as manually doing so prompts with a 'Destination Folder Access Denied' window with "You'll need to provide administrator permission to copy to this folder" despite being an administrator on the box. I have also tried to run under credentials - did not work.

Log file shows:   "Zip commands run - C:\######\PSWindowsUpdate.zip extracted to C:\Windows\System32\WindowsPowerShell\v1.0\Modules" but no folder/files are written.  Anybody have an idea for a fix/workaround for this?

Verified Answer
  • All - I was able to extract to the Working Directory and then Robocopy them to the target without an issue.  Not really a fix but it works.

All Replies
  • Hello TIm,

    There's probably a better way than this, but you could try the following:

    Add a step:

    ExecutePowershellCommand64bitUser with the below as argument

    Set-Content c:\kworking\a.ps1 -value 'Expand-Archive c:\kworking\PSWindowsUpdate.zip -DestinationPath c:\windows\system32\' -Force

    The above creates a file called a.ps1 inside the c:\kworking folder.

    Then add another step:

    ExecutePowershellCommand64bitSystem with the below as argument

    start-process powershell -verb runas -argument 'c:\kworking\a.ps1'

    Which will start powershell as administrator and let you be able to run the a.ps1 script we created before expanding the zip file unto c:\windows\system32

    You can delete a.ps1 afterward.


  • Look at the zip file properties - is it blocked?

    If so, download it to VSA and unblock it, then push the file from VSA and try.

    We generally avoid direct downloads to Windows because the alternate channel blocking causes issues for automation.


  • I should clarify - the zip file contains PowerShell scripts that then need to be imported so that you can then manipulate Windows Update (Refer to the site: gallery.technet.microsoft.com/.../2d191bcd-3308-4edd-9de2-88dff796b0bc)

  • @gbarnas Not blocked - I can unzip contents to the Working Directory and am beginning the idea of dropping there before sending them to the target location.

  • - I need to import them once they are in the correct location.

  • All - I was able to extract to the Working Directory and then Robocopy them to the target without an issue.  Not really a fix but it works.

  • Just an FYI, but we avoid using the "Working Directory" for anything temporary. We create a subfolder for each "project" in the TEMP folder, push files there and write logs there as well, when appropriate. When the process is complete, we can clean up by recursively deleting the folder we created. Same for ZIPs - they download to Temp\Project_XX and unzip to aa subfolder there - its usually easy to copy/move them to the right place.

    It's really about "housekeeping". When we work with MSPs to establish good automation practices, we always have to pick through the Working Directory and figure out what stays and what goes. Our practice is to create a tools folder to hold scripts and executables and a logs folder to hold logs from those tools in the Working Directory, and place configuration files directly in the Working Directory. All related config files have the same prefix in their name so its easy to remove them all and start clean. While these tools may be updated regularly, they are considered "permanent" and reside in the working directory structure.