0

i have a strange Problem and i hope someone can help me.

What I’m doing:
I am creating a Scheduled Task via GPO, which starts a Powershell script which is located on a network share. The Script should run under the "System" Account. The creation is so far, working.

But when I start the Task it is exiting immediately with Exit code 0x1

The Action triggered is looking like that:

Program to start: powershell.exe Parameter: -command "& '\\%ServerFQDN\Path\Scriptname.ps1.ps1' -executionpolicy bypass"

When I change the Server FQDN to the Server name only, without the domain part, it is working.

Or, when I change the running user to my admin account it is also working. (With FQDN and with the Server name Only)

Ok so my first suggestion was: That must be an Kerberos Issue. Server name falls back to NTLM and the local system account has some kind of problem with Kerberos. So i wanted to dig deeper and get an detailed error. So, I builded a local Wrapper script which calls the subscript on the network with the FQDN in the path.

And what should I say: It worked...

To summarize again: FQDN / System Account --> Not Working
Servername / System Account --> Working
Store the File on the local File System / System Account --> Working
FQDN / Domain Account --> Working
Servername / Domain Account --> Working
FQDN / System Account / Started by a wrapper script --> Working

Possible Solutions: Using Server name only --> Not Possible because we want to get rid of NTLM and i want to get it working in other domains.
Using a domain account --> I don’t want, that the credentials are getting cached on the Server.
Using a local Wrapper script --> that’s not the idea of storing a script on a network device.

Can someone explain me, why this is happening?

################################## 10.03.25 22:45 Update:
In the Windows Powershell Log i found an Entry, that he is not executeing the Script because of the RemoteExecution Policy. It looks like he is ignoring my ExecutionPolicy Bypass parameter. I signed the Script and trusted the Certificate and it worked.

I still can not explain, why it is working with the Hostname instead of the fqdn. Because the Hostname alone should not be an trusted Location. The Sever itself is not in the Trusted Zones List. But the Domain (Incl. Wildcard) is.

Improve this question
4
  • Exit code 1 is "error". You need to click on the event log record to view the details of the error. That event log is available from task scheduler. There is probably other events in the security event log, based on the auditing enabled. Commented Mar 10 at 18:03
  • Also be aware that access to the network from the LocalSystem account is very limited. Commented Mar 10 at 18:27
  • @GregAskew I lockend into that Eventlog and it is only saying: <br> Aktion powershell.exe with returncode 2147942401 was successfull. Commented Mar 10 at 18:39
  • I see a double file extension, is that accurate, or a question formatting issue? Commented Mar 10 at 19:47

1 Answer 1

Reset to default
0

OK here is the Solution:
The Parameter -ExecutionPolicy Bypass was never working.

The Thing is, that in our company the Trusted intranet zone is defined on UserLayer.
so:
When you execute a script under the System account there is a default setting, which marks all Domains without a dot (Servernames only) to the intranet zone. But the Userdefined Intranetzone is not applied because the System Account has no "User Part"
Now when you use a fqdn he can't map the intranet zone and the "Remote Signed" Policy which ich default at our location kicks in.

When i execute it as a Domain account, Zonemapping is done and the "RemoteSigned" ExecutionPolicy is ok.
Microsoft hint:
https://learn.microsoft.com/de-de/troubleshoot/windows-client/networking/intranet-site-identified-as-an-internet-site

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.