locked
running scripts from network shares RRS feed

  • Question

  • i have a hypv-2016 core server which has mapped a file server share (\\FS\Powershell)

    BUT nothing from that share will run.  Files cannot be loaded because they are not digitally signed.

    The files are our own, not from the internet and not blocked

    The default domain policy and as shown by Get-Executionpolicy  is RemoteSigned

    I have followed the advice in "https://blogs.technet.microsoft.com/heyscriptingguy/2012/10/29/how-to-run-powershell-scripts-from-a-shared-directory/" . But this a core server I'm not sure how relevant IE enhanced security is. Anyway i set the "Intranet Sites: Include all network paths (UNCs)" as described, made no difference

    What must i do to allow running from this share ??

    thanks

    Sunday, February 10, 2019 2:22 PM

All replies

  • Why not sign all your scripts, especially those you use for production?

    If you have a CA in your AD forest you can create a certificate that will be trusted by all domain members. If you don't have a CA you can create a "private" CA and distribute the root certificate to the machines that need to run the scripts you sign.

    https://www.hanselman.com/blog/SigningPowerShellScripts.aspx


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Sunday, February 10, 2019 4:17 PM
  • Hmm I might have to go down that route but for the time being id prefer to understand why this is not working. It must be a common scenario, so why is this such a pain......

    While digging arround i found that the "Intranet Sites: Include all network paths (UNCs)" gpo option should modify the variable

    "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zonemap\UNCAsIntranet"

    to 1 but it is always 0. In fact if is use Windows Admin Centre - > Registry to modify it, (??)minutes later it has been reset to 0. Um Err Hmm why dat ?? I dont know if thats the answer but thats another bit of strange behaviour I'd like to understand


    • Edited by drave Sunday, February 10, 2019 5:10 PM
    Sunday, February 10, 2019 5:05 PM
  • You have trust issues.  A first step would be to restart both systems. If that fails then try rejoining both to the domain.

    The issue is not a striping issue and you will need to use normal troubleshooting procedures to track down why your system does not trust the remote system.  The issue can be caused by many things including malware.


    \_(ツ)_/

    Sunday, February 10, 2019 5:33 PM
  • The HYPV server has been restarted numerous times, but the file server cannot be rebooted. Or rather not by me and not on my whim.

    but that smacks of the old Windows trope "When in doubt reboot, rejoin the domain, redo the share, its the usual windows bitrot, etc" , i just cant accept that in a server operating system. 

    "striping" ?? Whats that.

    "normal troubleshooting" i dont normally debug trust issues, any suggestions greatfully received.

    Ive been using the Group Policy results Wizard and cant see any reason for UNCAsIntranet remaining or being reset to 0

    Sunday, February 10, 2019 8:23 PM
  • If you do 't restart both you cannot be sure the domain relationship is not damaged.

    Another simple thing is to be sure the time on both systems matches the time on all DCs or Kerberos will fail in weird ways.

    If you can't restart then you will have to start by doing a long tedious analysis of the systems event logs.  This may provide a clue and it will also require discovering the DC that handled the authentication requests.

    Again. This is not a scripting issue.  It is a break/fix issue that must be resolved by correct technical analysis of the failure until you discover all of the pieces of what failed.  Currently you have only one symptom but you have no idea of its etiology. 

    Restarting/joining is suggested because this fixes 70% or more of this type of issue  but is only necessary when you need to quickly resolve the issue. If the scripts are not critical then you have to take the slower analytical approach.

    I can also suggest talking to all admin/engineer responsible for each of the involved systems to see if they may know of issues that might be affecting you.  Normally this kind of issue is handled by network engineering/support and not by local techs.  That usually means escalating the issue.


    \_(ツ)_/

    Sunday, February 10, 2019 8:44 PM
  • If you've modified the group policy (to set the UNCAsIntranet value to 1) and your local changes to the registry are being reset to 0 then I'd say you're problem lies with the group policy.

    Are you sure the policy change is replicated to all your DC's? The policy should be checked periodically by each machine in the domain, but your machine may be looking at a copy of the policy on a DC that hasn't received the policy change . . . or it may be that the machine hasn't applied the new policy.

    Have you tried "gpupdate /force" on the machine?

    JRV has pointed out that the local time on one, or more, machines may not be correct. For Kerberos authentication to work at all the time must not differ on the machines by more than five minutes.

    Until that group policy change is functioning properly I don't think you can expect your script to work reliably.


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Monday, February 11, 2019 3:31 AM
  • Hi,

    Was your issue resolved?

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,

    Lee


    Just do it.

    Thursday, February 28, 2019 2:40 PM