9
ScheduledTask ohne Windows-Benutzeranmeldung: PowerShell Netzlaufwerk lässt sich nicht verbinden
Hallo,
ich habe auf einem Win 10 Ent. Host (HyperV) in einer Domäne über den TaskPlanner bzw. Aufgabenplanung erfolgreich ein Powershell Script laufen, welches über ein externen SMB3 Laufwerk (Strato HiDrive) Ordner auf bestimmte Inhalte prüft (BackUp Kontrolle). Das geprüfte Netzlaufwerk ist über den angemeldeten Benutzer gemapt, somit ist ein Mapping innerhalb des Scripts nicht notwendig.
Leider wird der Host auf Grund von div. Domänen-GPO's auch mal neu gestartet ohne automatische Benutzeranmeldung. Automatische Anmeldung kann wegen der Domänen GPO nicht eingestellt werden (wäre praktisch aber grundsätzlich bei diesem Host erlaubt - geht Auto-Anmeldung per Domänen-GPO, Stichwort Kiosk-PC/Modus? Evt. sekundärer Lösungsweg, primär würd ich gern die PowerShell Lösung). Effekt ist das der ScheduledTask nicht angestosen wird.
Damit das Script auch ohne Windows-Benutzeranmeldung ausgeführt werden kann habe ich es um das Laufwerksmapping und Einstellen des Arbeitsverzeichnisses ergänzt. So hier:
Alternativ funktioniert auch New-PSDrive.
Im Test in der PowerShell ISE läuft das auch alles einwandfrei. Task mit Windows-Benutzeranmeldung geht auch.
Das Problem:
Wenn der Task als Job ohne Windows-Benutzeranmeldung läuft liefert mir das Script ein Log ab, in dem die nicht gefundenen BackUps moniert werden. Anhand der gelisteten Verzeichnisse sehe ich das nicht das Netzlaufwerk, sondern das Windows\System32 Verzeichnis ausgewertet wurde.
Ich habe deshalb probiert das ganze per Admin-gestarteter PowerShell zu testen, da ich da auch autom. im Windows\System32 Verzeichnis arbeite und mich im selben Zustand wie im Task befinde (falscher Lösungsweg?).
Es ist mir aber Schlicht und ergreifend nicht möglich (auf div. Win10 PC's getestet mit/ohne Domäne & verschiedene Netzwerke) das Smb3 Laufwerk zu mappen. Fehler:
New-PSDrive geht auch nicht.
Habe alles mögliche probiert, auch mit Authentifizierung usw., im Test so OK, als Admin scheitere ich immer...
Im Netz gibt es allerhand Lösungen , die aber nicht die Tasks ohne Benutzer-Anmeldung berücksichtigen. ...oder ich suche falsch...
Das muß doch irgendwie machbar sein.... *verzweifel*
Gruß
ich habe auf einem Win 10 Ent. Host (HyperV) in einer Domäne über den TaskPlanner bzw. Aufgabenplanung erfolgreich ein Powershell Script laufen, welches über ein externen SMB3 Laufwerk (Strato HiDrive) Ordner auf bestimmte Inhalte prüft (BackUp Kontrolle). Das geprüfte Netzlaufwerk ist über den angemeldeten Benutzer gemapt, somit ist ein Mapping innerhalb des Scripts nicht notwendig.
Leider wird der Host auf Grund von div. Domänen-GPO's auch mal neu gestartet ohne automatische Benutzeranmeldung. Automatische Anmeldung kann wegen der Domänen GPO nicht eingestellt werden (wäre praktisch aber grundsätzlich bei diesem Host erlaubt - geht Auto-Anmeldung per Domänen-GPO, Stichwort Kiosk-PC/Modus? Evt. sekundärer Lösungsweg, primär würd ich gern die PowerShell Lösung). Effekt ist das der ScheduledTask nicht angestosen wird.
Damit das Script auch ohne Windows-Benutzeranmeldung ausgeführt werden kann habe ich es um das Laufwerksmapping und Einstellen des Arbeitsverzeichnisses ergänzt. So hier:
New-SmbMapping -LocalPath 'X:' -RemotePath '\\%SERVER%\%Freigabe%\%Ordner%'
start-sleep 5
# Arbeitsverzeichnis einstellen
Set-Location 'X:\' Alternativ funktioniert auch New-PSDrive.
Im Test in der PowerShell ISE läuft das auch alles einwandfrei. Task mit Windows-Benutzeranmeldung geht auch.
Das Problem:
Wenn der Task als Job ohne Windows-Benutzeranmeldung läuft liefert mir das Script ein Log ab, in dem die nicht gefundenen BackUps moniert werden. Anhand der gelisteten Verzeichnisse sehe ich das nicht das Netzlaufwerk, sondern das Windows\System32 Verzeichnis ausgewertet wurde.
Ich habe deshalb probiert das ganze per Admin-gestarteter PowerShell zu testen, da ich da auch autom. im Windows\System32 Verzeichnis arbeite und mich im selben Zustand wie im Task befinde (falscher Lösungsweg?).
Es ist mir aber Schlicht und ergreifend nicht möglich (auf div. Win10 PC's getestet mit/ohne Domäne & verschiedene Netzwerke) das Smb3 Laufwerk zu mappen. Fehler:
New-SmbMapping : Falscher Parameter.
In Zeile:1 Zeichen:1
+ New-SmbMapping -LocalPath 'X:' -RemotePath '\\%Server% ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (MSFT_SmbMapping:ROOT/Microsoft/...MSFT_SmbMapping) [New-SmbMapping], CimException
+ FullyQualifiedErrorId : Windows System Error 87,New-SmbMappingNew-PSDrive geht auch nicht.
Habe alles mögliche probiert, auch mit Authentifizierung usw., im Test so OK, als Admin scheitere ich immer...
Im Netz gibt es allerhand Lösungen , die aber nicht die Tasks ohne Benutzer-Anmeldung berücksichtigen. ...oder ich suche falsch...
Das muß doch irgendwie machbar sein.... *verzweifel*
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 614306
Url: https://administrator.de/forum/scheduledtask-ohne-windows-benutzeranmeldung-powershell-netzlaufwerk-laesst-sich-nicht-verbinden-614306.html
Ausgedruckt am: 23.12.2024 um 14:12 Uhr
9 Kommentare
Neuester Kommentar
'\\%SERVER%\%Freigabe%\%Ordner%'
Erstens werden Variablen in der Powershell mit $variable angesprochen und wenn in Anführungszeichen dann auch nur in Doppelten und nicht in Hochkommas, deswegen geht obige Angabe mit Prozentzeichen nicht das ist Batch-Gedöhns!Zweitens ist ein Mapping überflüssig weil man den Pfad auch so direkt über den UNC Pfad ansprechen kann.
Laufwerksmapping ohne Benutzeranmeldung geht eh nicht. Du kannst auch einen Benutzer in einer Domäne automatisch anmelden, dazu mußt Du registry editieren. Hier ist aber der erhebliche Nachteil, daß das Passwort im Klartext in die Registry eingetragen werden muß.
🖖
🖖
Hallo,
Da es eine öffentliches Share ist wollte ich nicht Teile des Pfades hier zeigen. Im Script sind keine Prozentzeichen drin. Bsp. verbessert:
Habe den Eindruck, das man gar nicht aus der PS Session "raus" kommen kann...
Zitat von @146189:
'\\%SERVER%\%Freigabe%\%Ordner%'
Erstens werden Umgebungsvariablen in der Powershell mit $env:Variable angesprochen, deswegen geht obige Angabe mit Prozentzeichen nicht das ist Batch-Gedöhns!Da es eine öffentliches Share ist wollte ich nicht Teile des Pfades hier zeigen. Im Script sind keine Prozentzeichen drin. Bsp. verbessert:
\\server\share\unterordnerZweitens ist ein Mapping überflüssig weil man den Pfad auch so direkt über den UNC Pfad ansprechen kann.
Hab es eben mal mit direkter Ansprache des UNC Pfades probiert, das geht über die normal getsartete Powershell. Wieder das gleiche Problem beim Ausführen des Task ohne Benutzeranmeldung bzw. Powershell Konsole mit Admin-Rechten :PS C:\WINDOWS\system32> Set-Location -Path \\smb3.hidrive.strato.com\Freigabe\Unterordner
Set-Location : Der Pfad "\\smb3.hidrive.strato.com\Freigabe\Unterordner" kann nicht gefunden werden, da er nicht vorhanden ist.
In Zeile:1 Zeichen:1
+ Set-Location -Path \\smb3.hidrive.strato.com\Freigabe\Unterordner ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (\\smb3.hidrive....\Datensicherung:String) [Set-Location], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommandHabe den Eindruck, das man gar nicht aus der PS Session "raus" kommen kann...
Sicher geht das, da du hier aber offensichtlich ein Share bei einem Hoster via SMB übers Internet ansprichst (war uns leider nicht bekannt) musst du vorher die Credentials für den FQDN auch im Tresor(Anmeldeinformationsverwaltung) desjenigen Users hinterlegen in dessen Kontext auch der Scheduled Task ausgeführt wird sonst fehlen diesem ja logischerweise die Authentifizierungsdaten!
Bedenke auch das bestimmte Principals keinen Netzwerkzugriff haben.
Also mach es richtig dann lüppt dat auch.
Bedenke auch das bestimmte Principals keinen Netzwerkzugriff haben.
Also mach es richtig dann lüppt dat auch.
Hallo,
Ich hatte einleitend erwähnt, das es ein externes SMB3 Share bei Strato bzw. ein HiDrive ist. Oder fehlt eine Info bzw. unklar formuliert?
Die Anmeldeinformationen sind tatsächlich in den Windowsbenutzern hinterlegt, deswegen klappt ein Mapping bzw. Set-Location des SMB3 Shares auch in BATCH und PowerShell (normal gestartet) ohne diese anzugeben. Mit funktioniert es auch, daran liegt es wohl nicht.
Eben nochmal mit NET USE in der PowerShell (als Admin) probiert...
Oder an welcher Stelle muß da für einen Windows-benutzer nachgeregelt werden das er über eine PowerShell Sizung ins WAN gucken darf? AD? GPO? Registry?
Sicher geht das, da du hier aber offensichtlich ein Share bei einem Hoster via SMB übers Internet ansprichst (war uns leider nicht bekannt) musst > du vorher die Credentials für den FQDN auch im Tresor(Anmeldeinformationsverwaltung) desjenigen Users hinterlegen in dessen Kontext auch der > Scheduled Task ausgeführt wird sonst fehlen diesem ja logischerweise die Authentifizierungsdaten!
Ich hatte einleitend erwähnt, das es ein externes SMB3 Share bei Strato bzw. ein HiDrive ist. Oder fehlt eine Info bzw. unklar formuliert?
Die Anmeldeinformationen sind tatsächlich in den Windowsbenutzern hinterlegt, deswegen klappt ein Mapping bzw. Set-Location des SMB3 Shares auch in BATCH und PowerShell (normal gestartet) ohne diese anzugeben. Mit funktioniert es auch, daran liegt es wohl nicht.
Eben nochmal mit NET USE in der PowerShell (als Admin) probiert...
PS C:\WINDOWS\system32> net use w: \\smb3.hidrive.strato.com\Freigabe\Unterordner /Persistent:YES
Systemfehler 53 aufgetreten.
Der Netzwerkpfad wurde nicht gefunden.Bedenke auch das bestimmte Principals keinen Netzwerkzugriff haben.
Der Windows-Benutzer ist in der Gruppe der Administratoren und sollte uneingeschränkt Zugriff auf Domäne/LAN/WAN haben.Oder an welcher Stelle muß da für einen Windows-benutzer nachgeregelt werden das er über eine PowerShell Sizung ins WAN gucken darf? AD? GPO? Registry?
Also mach es richtig dann lüppt dat auch.
Asche auf mein Haupt, genau deswegen frage ich ja ^^ ...bin der Meinung, das mein Script OK ist, aber anscheinend kapiere ich die Script-Umgebung (gestartet als Admin) nicht bzw. weiß nicht was dort zu beachten ist oder kenne bestehende Einschränkungen nicht richtig.\\smb3.hidrive.strato.com\Freigabe\Unterordner
Gemappt werden nur freigegebene Shares keine Unterordner! Also im Pfad nur den Server und den Freigabe-Namen angeben, keine weiteren Ordner!\\smb3.hidrive.strato.com\roothttps://www.strato.de/faq/cloud-speicher/so-stellen-sie-mit-dem-net-use- ...
https://www.strato.de/faq/cloud-speicher/wie-lauten-die-pfade-zu-ftp-smb ...
Danke für die schnelle Antwort, das kann ich aber so nicht akzeptieren.
Natürlich kann ich mit New-SmbMapping wundervoll alle Unterordner im Share ansteuern und mappen.... nur nicht im PowerShell mit erweiterten Rechten. Hier findet er das Share überhaupt nicht. Auch nicht wenn ich mich direkt aufs ROOT verbinde, kein Unterschied.
Normal gestartete PowerShell:
Das Selbe nochmal als Admin gestartet schlägt fehl:
Wüßte jetzt nicht auf welches Argument verwiesen wird, zumal es in der PowerShell daneben (normal gestartet) klappt. Teilweise habe ich auch mal bei den Tests System Error 63 bzw. 53 bekommen (Pfad nicht gefunden...).
Natürlich kann ich mit New-SmbMapping wundervoll alle Unterordner im Share ansteuern und mappen.... nur nicht im PowerShell mit erweiterten Rechten. Hier findet er das Share überhaupt nicht. Auch nicht wenn ich mich direkt aufs ROOT verbinde, kein Unterschied.
Normal gestartete PowerShell:
PS C:\Users\benutzer> New-SmbMapping -LocalPath 'X:' -RemotePath '\\smb3.hidrive.strato.com\root\xxx\yyy\zzz'
Status Local Path Remote Path
------ ---------- -----------
OK X: \\smb3.hidrive.strato.com\root\xxx\yyy\zzz
PS C:\Users\benutzer>Das Selbe nochmal als Admin gestartet schlägt fehl:
PS C:\WINDOWS\system32> New-SmbMapping -LocalPath 'X:' -RemotePath '\\smb3.hidrive.strato.com\root\xxx\yyy\zzz'
New-SmbMapping : Falscher Parameter.
In Zeile:1 Zeichen:1
+ New-SmbMapping -LocalPath 'X:' -RemotePath '\\smb3.hidrive.strato.com ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (MSFT_SmbMapping:ROOT/Microsoft/...MSFT_SmbMapping) [New-SmbMapping], C
imException
+ FullyQualifiedErrorId : Windows System Error 87,New-SmbMapping
PS C:\WINDOWS\system32>Wüßte jetzt nicht auf welches Argument verwiesen wird, zumal es in der PowerShell daneben (normal gestartet) klappt. Teilweise habe ich auch mal bei den Tests System Error 63 bzw. 53 bekommen (Pfad nicht gefunden...).
Natürlich kann ich mit New-SmbMapping wundervoll alle Unterordner im Share ansteuern und mappen
Dieses spezielle CMDLet kann das, ja das ist richtig, aber genau dieses funktioniert nicht gescheit in elevated Sessions und ist deswegen dafür ungeeignet! Die anderen dafür üblicherweise dafür genutzten Tools erwarten hier aber in der Regel ein Share und kein Subpfad.Lies
https://ss64.com/ps/new-smbmapping.html
This cmdlet should be run at a non-elevated session - the same privilege as Windows Explorer.
Deswegen besser gleich über die Angabe des UNC Pfads arbeiten, funktioniert hier übrigens einwandfrei auch in einer elevated Session, gerade mal mit einem Test-Account bei Strato getestet. Funktioniert wie nicht anders erwartet
Mit cmdkey die Credentials in der elevated Sessions vorher prüfen.
Btw. Ein Skript muss auch nicht zwingend elevated ausgeführt werden um ohne Benutzeranmeldung zu laufen wenn sowieso nur ein paar Pfade geprüft werden.
Hallo und danke für die Antwort,
komme jetzt erst dazu weiter zu testen.
Mit welchen CMDlets verbindet man den UNC Pfad? über New-PsDrive? Das bekomme ich nicht hin, schlägt immer fehl, wenn ich die credentials mitliefern möchte. Ohne Credentials geht es auf PC's die im Windows-Benutzer bzw. Passwortspeicher die Zugangdaten schon drin haben (oder schon ein bestehendes Mapping dahin haben). Auf einem PC, der noch nie mit dem HiDrive verbunden war schlägt es fehl. Wie teste ich in diesem Fall mit cmdkey?
Is schon klar, hatte ich ja erklärt oben, wieso ich das zum testen nutze. Wäre allerdings für andere Zwecke sinnvoll es auch "elevated" hin zu bekommen
komme jetzt erst dazu weiter zu testen.
Zitat von @146189:
OK, danke für den Hinweis. Habs gelesen und auch erfahren, warum nicht funktioniel... Schade, das solche Info's nicht irgendwie besser im Kontext verfügbar sind.Natürlich kann ich mit New-SmbMapping wundervoll alle Unterordner im Share ansteuern und mappen
Dieses spezielle CMDLet kann das, ja das ist richtig, aber genau dieses funktioniert nicht gescheit in elevated Sessions und ist deswegen dafür ungeeignet! Die anderen dafür üblicherweise dafür genutzten Tools erwarten hier aber in der Regel ein Share und kein Subpfad.Deswegen besser gleich über die Angabe des UNC Pfads arbeiten, funktioniert hier übrigens einwandfrei auch in einer elevated Session, gerade mal mit einem Test-Account bei Strato getestet. Funktioniert wie nicht anders erwartet
Mit cmdkey die Credentials in der elevated Sessions vorher prüfen.
Mit cmdkey die Credentials in der elevated Sessions vorher prüfen.
Mit welchen CMDlets verbindet man den UNC Pfad? über New-PsDrive? Das bekomme ich nicht hin, schlägt immer fehl, wenn ich die credentials mitliefern möchte. Ohne Credentials geht es auf PC's die im Windows-Benutzer bzw. Passwortspeicher die Zugangdaten schon drin haben (oder schon ein bestehendes Mapping dahin haben). Auf einem PC, der noch nie mit dem HiDrive verbunden war schlägt es fehl. Wie teste ich in diesem Fall mit cmdkey?
PS C:\WINDOWS\system32> $SecurePassword = ConvertTo-SecureString 'password' -AsPlainText -Force
$UserName = "user"
$Credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $UserName, $SecurePassword
New-PSDrive -Name "strato" -PSProvider FileSystem -Root "\\smb3.hidrive.strato.com\root\" -Credential $Credentials
New-PSDrive : Der Netzwerkpfad wurde nicht gefunden
In Zeile:5 Zeichen:1
+ New-PSDrive -Name "strato" -PSProvider FileSystem -Root "\\smb3.hidri ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (strato:PSDriveInfo) [New-PSDrive], Win32Exception
+ FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommandBtw. Ein Skript muss auch nicht zwingend elevated ausgeführt werden um ohne Benutzeranmeldung zu laufen wenn sowieso nur ein paar Pfade geprüft werden.
Is schon klar, hatte ich ja erklärt oben, wieso ich das zum testen nutze. Wäre allerdings für andere Zwecke sinnvoll es auch "elevated" hin zu bekommen
