How to Run PowerShell Scripts from a Shared Directory

Summary: Guest bloggers Judith Herman and June Blender discuss how to run Windows PowerShell scripts from a shared directory.

Microsoft Scripting Guy, Ed Wilson, is here. Today, we have a guest blog with two writers Judith Herman and June Blender. June has been a guest blogger before (see more here), but this is the first time for Judith. Judith has this to say about herself: I work in Windows Server as a Senior Technical Writer. I have been involved with testing and documenting Group Policy since Windows 2000. Before coming to work at Microsoft, I worked on movies, rockets, and computer networks. Here is a photo of Judith.

Photo of Judith

Ed suggested we write about new Windows PowerShell 3.0 features, but we hit a gotcha that seems even more urgent.

The hard-working elves in our Updatable Help office at the North Pole were trying to run the scripts that assemble the Updatable Help files for Windows Server modules. The scripts are stored in a shared file system directory.

But, instead of a clean run, they got an error. Here’s what happened.

PS C:\> \\Server01\Share\Scripts\Get-HelpFilesForCoolModules.ps1
File cannot be loaded. The file \\Server01\Share\Scripts\Get-HelpFilesForCoolModules.ps1 is not digitally signed. The script will not execute on the system. For more information, see about_Execution_Policies at

At line:1 char:1

+ \\Server01\Share\Scripts\Get-HelpFilesForCoolModules.ps1

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : SecurityError: (:) [], PSSecurityException

    + FullyQualifiedErrorId : UnauthorizedAccess

This error occurs when you try to run a script that was downloaded from the Internet and does not have a digital signature. But the scripts on the file share weren’t downloaded from the Internet! We wrote them and put them right there on the share on our favorite file server.

Lee Holmes (author of Windows PowerShell Cookbook, 3rd Edition) solved the mystery for us. Lee often solves mysteries, which is why we call him “Holmes.”

By default, computers running Windows Server include UNC paths in the Internet security zone. Windows PowerShell is actually responding to the security zone when it throws the error for the UNC paths. Windows does the same thing.

You might think that changing the execution policy to Unrestricted fixes this. But it doesn’t. We tried. There are, however, several ways to run scripts with UNC paths. They all incur some security risk, so please consider the consequences carefully before implementing any fix.

The best fix is to add the UNC server—in our case, Server01—to the Local intranet security zone, either manually or by using the Intranet Sites: Include all network paths (UNCs) Group Policy setting. This takes a few minutes, but it is the right way to do it.

In Group Policy Management Editor, you’ll find this policy setting under both the Computer Configuration and the User Configuration sections in the following path:

\Windows Components\Internet Explorer\Internet Control Panel\Security Page\ Intranet Sites: Include all network paths (UNCs)

The elves wanted to know which magic hat we used to find this GP setting. We just used the latest Group Policy Settings Reference Spreadsheet. Click the Administrative Template tab on the spreadsheet, and then search for UNCAsIntranet.

The easy, but more risky, method is to turn off Internet Explorer Enhanced Security Configuration. Think carefully before you try this one. Many data centers prohibit this action.

Also, in the “don’t try this in a production environment” category is editing the registry. You can set the UNCAsIntranet registry setting that adds UNC paths to the Local security zone. It’s in HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\UncAsIntranet, and you can read about it here. I’m pretty risk-averse at work (ye of little faith and much experience), but this might appeal to you.

In the end, we solved our problems and our elves got back to work running scripts from the UNC directory. And happy elves mean more Updatable Help.

Thank you, Judith and June. This is indeed a timely and helpful article.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Comments (8)

  1. K_Schulte says:

    Hi Judith, Hi June

    thank you very much for this interesting blog article!

    But first of all, I'd like to tell you, That we all cross our fingers here … hoping that "Sandy" will not do too much harm to the (east of the) United States!!!

    I thought that we have the problem which you are presenting here, too!

    Since I have received my new company workstation running WIN7 x64 Enterprise, I couldn't run scripts from an intranet network share. My old PC running WIN7 x64 Pro, still doesn't complain when I try to run my scripts.

    So it must have something to do with the workstation settings itself.

    I had been told, that the new PC has been put into another new AD OU and will reveive some different group policies.

    So I already asked people in the forum here, what I could do to prevent my PowerShell scripts from being blocked,

    because I always received the error message telling me, that my files are not digitally signed.

    The proposed final solution was: Sign your scripts! Which is not a bad idea of course, but nearly impossibe here.

    I did relax the execution policy to unrestricted which is not a good idea, but it still was accompanied with warnings, telling me that it may be dangerous to run my scripts.

    So I tried to set the registry key UNCasIntranet now, which is an option that I can still change on my own,

    But this is still no solution to the problem, because I can't recognize any different behaviour by now. In fact the "local intranet options" are grayed out and always show " Include all network paths (UNCs)" to be checked regardless of any changes to the registry key. This seems to be preset by GPOs and if I got you right, this should be the correct setting anyway.

    It would be great, if you can help me out … if you still have any ideas, what might solve the riddle here …


  2. Ed Wilson says:

    @K_Schulte One thing you may want to see is where your shared scripts are stored. For instance if they are on \webserver1shared but on your computer \webserver1 is NOT listed in Trusted Sites in Internet Explorer, then you will still be prompted with warnings when you try to run the script — EVEN if you have the Script Execution Policy set to Unrestricted. This is because PowerShell trusts Internet Explorer to set the security zones. NOW, if you ADD \WebServer1 to the Trusted Sites in Internet Explorer, if your settings are set to Unrestricted, then you will not be prompted for a warning. It is possible that when you ended up in a different OU, then you have a different Group Policy. Often in a corporate environment Trusted Sites is set via Group Policy (but it is a registry setting). If you cannot make these changes, start powershell with the execution policy of BYPASS and you will not be prompted.

  3. Roderick McBan says:

    I found a different workaround for this issue.

    On the server where I wanted to run the powershell script, I created a directory link pointing to the unc path containing my PS1 file.

    Running powershell -f [dir_link]myScript.ps1 went through with no problems.

    It appears to work on several of my servers.


  4. Doug says:

    Interesting.  I'm testing execution policy and added a Zone.Identifier ADS to one of my scripts.  When I try to run that script on my local machine with policy set to Remote Signed, I get the error noted above as expected.  However, if I try to run that script from another machine specifying the UNC path to the script, again with policy set to RemoteSigned, the script runs without error, which I did not expect.  So, it seems to ignore the ADS if I run the script from another machine?

  5. The solution to trust all UNC pathes follows not the least privilege principle.

    I think the best solution is to trust only selected shares.

    read the article I have linked here. There is a good write up!:…/running-powershell-scripts-from-unc.html

  6. David says:

    How to do if the network share is not \SERVER but \DOMAIN_NAME (with DFS) ?
    Because it seems that PowerShell thinks it’s an untrusted location !
    Please help 🙂

  7. What is really weird is blocking when I use the FQDN for a share but not the NetBIOS short name.

    I created a script locally, want it to run by a GPO. Copying it to the central share and trying to run it directly using \\BIOSName.somewhere.mydomain\share\myscript.ps1 tells me it is unsigned (correct) and cannot run, because my execution policy is remotesigned (correctly). But when I run it as \\BIOSName\share\myscript.ps1 it runs. Right-clicking the script doesn’t show the ‘unblock’ button, and anyway I ran unblock-file on it but still the same result.

    I really don’t understand what is going on here!


    1. Further – tried adding the FQDN to trusted sites. That worked only if I turned off the requirement of https. With the https requirement turned on, the script won’t run with the FQDN.

Skip to main content