Ich habe die Antwort selbst gefunden und werde eine Lösung für alle Interessierten posten.
Die Ursache des Problems ist ziemlich schwer zu debuggen, da das Problem seinen Ursprung in der Behandlung von Benutzern und Prozessen durch IIS hat.
Wie ich dachte, war am Code selbst nichts auszusetzen.
Antwort
In IIS läuft eine Website in einem AppPool. Einem AppPool wird eine Benutzeridentität zugewiesen. Die Standardidentität ist ein virtuelles integriertes Konto namens ApplicationPoolIdentity . Dieser Benutzer hat (soweit ich weiß) keine Berechtigung, externe Batch-/Befehlsskripte aufzurufen.
Die Angabe eines Benutzernamens, Passworts und einer Domäne für einen administrativen Benutzer beim Starten eines neuen Prozesses hat für mich keine Lösung gebracht - Es könnte sein, dass ich das gesamte Konzept nur falsch verstehe.
Mit <identity impersonate="true" userName="domain\user" password="pass" /> in der webconfig hat auch nichts gelöst. Dies liegt anscheinend daran, dass der zugewiesene AppPool-Benutzer immer noch der Autor aller Prozesse ist.
Was mich wirklich gestört hat, war, dass ich .exe-Dateien ausführen konnte, aber keine .cmd- oder .bat-Dateien.
Die Lösung für mich bestand darin, einen neuen Benutzer mit Berechtigungen zum Ausführen von Stapelskripts zu erstellen und diesen Benutzer als AppPool-Benutzer in IIS auszuwählen.
Bearbeiten:Wie ich in den Kommentaren erwähnt habe, wird der Benutzer, mit dem ich arbeite, in einem Active Directory erstellt Server, da sich dieser bestimmte Dateiserver auf einer Netzwerkfreigabe befindet. Der Benutzer ist Teil der lokalen Servergruppe IIS_IUSRS auf meinem Webserver und hat Lesen/Schreiben/Ausführen Berechtigungen in dem Ordner, in dem die ausführbaren Programme gespeichert sind.
Edit2:Die Lösung funktioniert sowohl für lokale Benutzerkonten als auch solange der Benutzer Teil der lokalen Servergruppe IIS_IUSRS ist und hat Lesen/Schreiben/Ausführen Berechtigungen in dem Ordner, in dem die ausführbaren Programme gespeichert sind.