Powershell scripts won't run from a network drive RRS feed

  • Question

  • Dear Scripters,

    I'm a bit astonished, that my Powershell scripts won't run on my new company (office) computer, if they are located on a network drive, which is mapped to a local (intranet) server share! My old WIn7 x64 Professional computer can still run these scripts!

    And I did adjust the ExecutionPolicy on my new computer:

    PS H:\Powershell> Get-ExecutionPolicy

    I can run my "Get-Date.ps1" script from eg. C:\fso,

    PS H:\Powershell> C:\fso\Get-Date.ps1

    Donnerstag, 9. August 2012 10:30:08

    but not after I copied it to H:\Powershell

    PS H:\Powershell> H:\Powershell\Get-Date.ps1
    Die Datei "H:\Powershell\Get-Date.ps1" kann nicht geladen werden. Die Datei "H:\Powershell\Get-Date.ps1" ist nicht digital sign
    iert. Das Skript wird auf dem System nicht ausgeführt. Weitere Informationen erhalten Sie mit "get-help about_signing"..
    Bei Zeile:1 Zeichen:27
    + H:\Powershell\Get-Date.ps1 <<<<
        + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
        + FullyQualifiedErrorId : RuntimeException

    The new computer is running Windows 7 Enterprise version (64 bit)

    I really don't know what, except the execution policy, could cause this behaviour ...

    kind regards, Klaus

    Thursday, August 9, 2012 8:33 AM


  • Correct, otherwise the first time they run the script they will get a prompt asking them if they trust the source.  Depending on what exactly you are using these scripts for that might be good enough for you.  As jrv stated if you get a certificate issued from your domain CA then it can be trusted across your domain automatically.

    Please remember to mark correct answers and helpful post.

    • Marked as answer by K_Schulte Friday, August 10, 2012 6:31 AM
    Thursday, August 9, 2012 8:23 PM

All replies

  • Remotesigned means that scripts run from a network location need to be signed.  A workaround would be to set your executionpolicy to "unrestricted".

    As your error message says, see:

    Get-Help about_signing

    Grant Ward, a.k.a. Bigteddy

    • Edited by Bigteddy Thursday, August 9, 2012 9:37 AM
    Thursday, August 9, 2012 9:35 AM
  • Hi Bigteddy,

    your are right ... and you are not .. :-)

    Infact the scripts that reside on our company's server shares could be run from my other computer and each other computer I ever used before, which means that they aren't "remote" in this case! They aren't signed either ...

    The new computer's configuration must be responsible for this behaviour and I stronly suspect that this has something to do with GPO settings and maybe security zones, like the ones that are used in IE.

    But I don't know the exact reasons and can't adress the source of this new problem by now! We always have to research and proove that we are right, when reporting "errors" :-)

    Thanks, Klaus.

    Thursday, August 9, 2012 10:14 AM
  • Have you actually tried setting your new computer to "unrestricted'?

    Grant Ward, a.k.a. Bigteddy

    Thursday, August 9, 2012 10:19 AM
  • Are you the Klaus Schulte from the Scripting Games?  That was fun, wasn't it?

    Grant Ward, a.k.a. Bigteddy

    Thursday, August 9, 2012 10:22 AM
  • Klaus - Grant is correct.

    Win 7 is set to remotesigned by default.  Pre Win 7 is set to restricted forcing everyone to cahge it immedaiately.  Yu probably set it to unresticted in the past.  Windows 7 may not be set to trust mapped drives by default. GP can play a role.  I highly recommend settng all plicy with Group Policy so that it is consistently applied.

    Any script you download from teh INternet will be tagged as such and will require remote signed even on a local drive.  YOu can clear the flag in the advanced properties for the file.

    Remember there are three set of settings.  Machine, user and process.

    From docs fo XP:

    The Windows PowerShell execution policies are as follows:

    "Restricted" is the default policy.

    type: help about_execution_policies


    Thursday, August 9, 2012 10:41 AM
  • @Bigtesddy: Yepp! I am the same Klaus Schulte, who battled with you in the scripting games :-)

    And it really was fun! I could already opt in for the next games ...

    @jrv: The Execution policy on my previous, still running, Win 7 machine and the policy of my new machine are both set to RemoteSigned and I can, and always could before, start scripts from our intranet network shares.

    Except from the new machine!

    So it definitely has something to do with the machine configuration itself! And, as I'm still no domain admin :-( I can't even change some of the security settings, that are set by GPOs which are probably causing the problem.

    The downside of this is, that our admins don't support powershell scripting in our company ( what a shame ) and they don't know exactly what I'm talking about when i try to explain the problem. my "company customers" should be able to execute some powershell scripts which are running in the background as part of some other batches and there is a need to execute them from a commonly accessible location. So I put these scripts always on a share, that they can access and run from

    We are still using Xp up to now but are rolling out WIN7 through the rest of this year, which will make the problem apparant as soon as other PCs are equipped with WIn7.

    I'm pretty sure that there will be an explananation found for this behaviour. GPOs and site trust are my favorite candidates!

    Thanks so far guys!


    Thursday, August 9, 2012 11:27 AM
  • Klause - you are only telling ius about one policy.  What are the three policy levels set to?

    get-executionpolicy -List|fl


    Thursday, August 9, 2012 11:38 AM
  • Hi jrv,

    the others are all undefined as they are on the other machine, which can still execute scripts ...

    PS C:\Users\Schulte> get-executionpolicy -List|fl

    Scope           : MachinePolicy
    ExecutionPolicy : Undefined

    Scope           : UserPolicy
    ExecutionPolicy : Undefined

    Scope           : Process
    ExecutionPolicy : Undefined

    Scope           : CurrentUser
    ExecutionPolicy : Undefined

    Scope           : LocalMachine
    ExecutionPolicy : RemoteSigned


    Thursday, August 9, 2012 11:46 AM
  • Then either your machine does not trust the share or the file is marked as Inernet and needs to be cleared.

    Reset all of you Internet Explorer settings to the defaulkts and restart the machine.

    I suspect if that doesn't work that you admins are having a bit of fun. and have given you new machine a little extra policy.

    We can require that shares be treated as remote of not depending on GP.  This could be assigned ot a single machine.


    Thursday, August 9, 2012 11:50 AM
  • @jrv: The files is not blocked.

    In fact I copied it from my local harddisk to the share.

    And I did check twice with "streams.exe" that there are not alternate streams in this location.

    (There is no Unblock button available anyway )I can't reset the IE settings to their defaults ( which I already tried to do ) because "some settings are controlled by GP and can#t be changed" ) So I finally agree with you, that the machine may not trust the network location! And that's probably the end of this story for me ... because I won't be able to dig deeper into that and will have to find a friendly admin who believes ( trust :-) me!

    Or are there any facts I could additionally reveal to proove "our theory" ?

    Thanks, Klaus.

    Thursday, August 9, 2012 12:13 PM
  • Your new X64 machine will have both 32 and 64 bit versions of Powershell, and each has it's own execution policy.  Did you set both of them?

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Thursday, August 9, 2012 12:28 PM
  • @mjolinor: I didn't up to now, because I only used the x86 versions of PS

    I just changed the execution policy of the x64 version, too ... but no changes!

    Scripts are still not runnable form my network share. So the IE trust maybe something to consider.

    Thanks, Klaus.

    Thursday, August 9, 2012 1:06 PM
  • Well, at least now that won't come back to bite you later.

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Thursday, August 9, 2012 1:07 PM
  • The ideal solution here would be that they work without signing.  However, since they do not I would recommend that you sign your scripts and that should fix your issues.  Do you have access to a code-signing certificate or Visual Studio?  The process is fairly simple and I have even written a function into my profile that enables me to do it with: 

    Sign-Code <./script.ps1>

    Hopefully this helps, and let me know if you have more questions.


    Please remember to mark correct answers and helpful post.

    Thursday, August 9, 2012 1:39 PM
  • Hi Chris,

    right, .... the best solution might be to deliver signed scripts inside our company!
    The other way around may be tobypass the execution policy which of course is not the preferred way!

    It would be great, if we had some company-wide certificates and use a central authority to manage signing

    Even though this might not be a manageble solution for myself in the long terms, I agree with you and maybe
    I should at least give it a try. I never did codesigning before and might have to dig deeper into this!

    A have VS 2010 on my machine but no certificate.

    Thanks, Klaus

    Thursday, August 9, 2012 2:29 PM
  • Helping you create a certificate is a little outside of the scope of this forum and my knowledge but I have heard that it can be done with visual studio for free.  I personally created one from our enterprise certificate server, but I understand that you likely do not have access to one of those.  (Sadly not everyone gets to work on the Infrastructure Team)  However, this is a function that I include in my powershell profile that will make your life easier once you do have a certificate to sign your code with.

    Function Sign-Code
    	Param ([Parameter(Mandatory=$true)][string]$scriptName)
    	$cert = (dir cert:currentuser\my\ -CodeSigningCert)
    	$timestampServer = ""
    	Set-AuthenticodeSignature $scriptName $cert -TimestampServer $timestampServer

    You can exclude the part with the timestamp server if you like.  What it allows is your script to continue using the cert once it expires because it can tell that it was still valid at the time of signing.  The choice of whether you use it or not depends on if you want your scripts to rely on your certificate to be currently valid or if you always want it to just work.  You can tell which I prefer...

    Sorry I cannot do more, but I do hope that this helps you.

    Maybe someone else on this forum has more expertise creating a free certificate for code-signing.


    Please remember to mark correct answers and helpful post.

    Thursday, August 9, 2012 7:34 PM
  • Microsoft Office VBA editor can generate a "self-signed" certificate.

    On the "Start/Miccrosoft Office/Microsoft Ofice Tools/Digital Certificate for VBA Projects".

    This generates a self-signed code signing certificate and adds it to the the Cert store. 

    With a self signed cert you do not need to use a timestamp.

    It is recommendedd that you have your admins assign a code signing cert t o you AD account. It needs to be one that is recognized as trusted by AD and teh domain.  This will allow the code signed with teh cert to work anywhere in hte domain.

    Self-signed certs are mostly only for testing.  If you want to distribute scripts on shares you will need a cert recognized by teh domain to allow other users to use your scripts transparently.


    Thursday, August 9, 2012 8:15 PM
  • Correct, otherwise the first time they run the script they will get a prompt asking them if they trust the source.  Depending on what exactly you are using these scripts for that might be good enough for you.  As jrv stated if you get a certificate issued from your domain CA then it can be trusted across your domain automatically.

    Please remember to mark correct answers and helpful post.

    • Marked as answer by K_Schulte Friday, August 10, 2012 6:31 AM
    Thursday, August 9, 2012 8:23 PM
  • Chris - rocks!


    Thursday, August 9, 2012 10:11 PM
  • @Chris and @jrv: you both do rock!

    @BigTeddy: I won't forget you! You are "rocking all over the world", too :-)

    So, I will see what I can do to get finally a "rock solid solution" that is not consisting of
    "a bypass" but of a "trusted" solution that can be used in are intranet without any restrictions
    that might apply now or in the future.

    It depends on the availabilty of a company code signing certificate of course, which is something
    where I don't know if I can get one.

    Thanks to all! Klaus.

    Friday, August 10, 2012 6:30 AM
  • Here is a free utility that will help you manage signing your scripts:


    Friday, August 10, 2012 6:58 AM
  •  add * or or thatspecificfileserver (if you're not mapping drives to FQDNs) or or the drive letter to the local intranet zone in internet explorer. powershell won't see scripts on your mapped drives as 'remote' anymore. 

    Wednesday, July 1, 2020 5:45 PM