Homeserver Forum

Hallo zusammen,

ich habe auf meinem WHS das c't-Offline-Update installiert, um damit meine XP Clients lokal aktualisieren zu können. Damit immer die aktuellen Patches zur Verfügung stehen, habe ich eine Task geplant, die regelmäßig den Download anstößt. Die Task soll mit einem speziell dafür angelegten Benutzer ausgeführt werden - wird sie aber nicht. Der Download findet nicht statt, und ich kann in der Ereignisanzeige keine Hinweise auf die Ursache finden. Wenn ich mich per Remote-Desktop als dieser Benutzer anmelde, kann ich das Skript ohne Probleme ausführen und der Download wird durchgeführt.

Hat jemand eine Idee, wo ich die Ursache suchen kann?

Danke und Grüße,
-- mvordeme

Hallo mvordeme.

Bei Deiner Frage zum c't-Offline-Updater, gibt es einige Stolpersteine.
Zum einen währe da der von Dir angelegte Benutzer.
Hier spielen die Rechte eine extrem große Rolle.
Vorschlag: Probier es mit dem Administrator.
Und schau Dir nochmal die Einstellungen des Tasks an, ob hier vielleicht der ein oder andere Fehler zu finden ist.
Außerdem kann es vorkommen, dass ein Programm sich nicht als geplanter Task starten lässt, bzw. die Funktion beeinträchtigt ist, da die GUI (also das Fenster) fehlt.

Mein Vorschlag:
Schau Dir mal diesen Beitrag an:
viewtopic.php?f=11&t=464
Dort geht um den WSUS (Windows Server Update Service).


Gruß
sTunTe

Also hier mal weiter.....

Kann es sein, dass der User angemeldet sein muss, damit der Task angestossen wird??

steve0564 hat geschrieben:Kann es sein, dass der User angemeldet sein muss, damit der Task angestossen wird??

Hängt davon ab, welchen Starttyp Du im Task ausgewählt hast.

Gruß
sTunTe

Danke für die Hilfe. Hier die Ergebnisse:

sTunTe hat geschrieben:Zum einen währe da der von Dir angelegte Benutzer.
Hier spielen die Rechte eine extrem große Rolle.
Vorschlag: Probier es mit dem Administrator.

Mit dem Administrator geht es, aber das ist letztendlich nicht Sinn der Übung. Ich will nicht, dass eine Task, die Dinge aus dem Internet herunter lädt, Administrationsrechte hat. Ich hatte mir schon gedacht, dass es irgendwie an den Rechten liegt. Die Rechteverwaltung ist beim WHS ja ziemlich versaubeutelt worden. Kennst Du Dich da aus?

sTunTe hat geschrieben:Und schau Dir nochmal die Einstellungen des Tasks an, ob hier vielleicht der ein oder andere Fehler zu finden ist.

Sieht eigentlich gut aus, und funktioniert ja auch mit dem Administrator.

sTunTe hat geschrieben:Außerdem kann es vorkommen, dass ein Programm sich nicht als geplanter Task starten lässt, bzw. die Funktion beeinträchtigt ist, da die GUI (also das Fenster) fehlt.

Habe ich ausprobiert. Es funktioniert auch, wenn niemand angemeldet ist. Schließlich ist es nur ein Skript.

sTunTe hat geschrieben:Schau Dir mal diesen Beitrag an:
viewtopic.php?f=11&t=464
Dort geht um den WSUS (Windows Server Update Service).

Den würde ich nicht so gerne nehmen. Unter meinen Rechnern ist einer, der bei der Echtheitsprüfung durchfällt, obwohl ich die XP-Lizenz regulär gekauft habe. Die Echtheitsprüfung ist beim c't-Offline-Update geblacklistet.

steve0564 hat geschrieben:Kann es sein, dass der User angemeldet sein muss, damit der Task angestossen wird??

Habe ich nicht so eingestellt.

Danke und Grüße,
-- mvordeme

mvordeme hat geschrieben: Die Rechteverwaltung ist beim WHS ja ziemlich versaubeutelt worden.

Das kann ich nicht bestätigen ... die Berechtigungs von Gruppen auf Ressourcen ist eigentlich eien normale Vorgehensweise

Ich glaube deine Probleme haben primär nichts mit dem WHS zu tun sondern mit den benötigten Rechten des Tools, ich vermute es fehlen Rechte auf WINDOWS bzw. den Unterverzeichnissen ... um heraus zu bekommen welche, könntest du die Überwachung einschalten

Nobby1805 hat geschrieben: Das kann ich nicht bestätigen ... die Berechtigungs von Gruppen auf Ressourcen ist eigentlich eien normale Vorgehensweise

Ja, aber der WHS hat dann noch das merkwürdige Berechtigungstool in der WHS-Konsole. Ich hatte schon genügend Probleme, dem Benutzer das Recht zum Remote Login zu geben, damit ich überprüfen kann, ob er das Skript überhaupt ausführen kann. Das Hinzufügen zur Gruppe Remotedesktopbenutzer allein reicht auf dem WHS nämlich dazu nicht aus.

Nobby1805 hat geschrieben: Ich glaube deine Probleme haben primär nichts mit dem WHS zu tun sondern mit den benötigten Rechten des Tools, ich vermute es fehlen Rechte auf WINDOWS bzw. den Unterverzeichnissen ... um heraus zu bekommen welche, könntest du die Überwachung einschalten

Nehmen wir mal an da ist etwas dran. Welches Tool, welche Überwachung, und wie mache ich das?

Danke und Grüße,
-- mvordeme

mvordeme hat geschrieben:Die Rechteverwaltung ist beim WHS ja ziemlich versaubeutelt worden. Kennst Du Dich da aus?

Ja, ich kenne mich damit aus.
Daher kann ich das "versaubeutelt" auch nicht so ganz nachvollziehen.
Auch wenn hier die Benutzerverwaltung im Gegesatz zum "echten" Server ein wenig beschnitten wurde.
Ich ahne aber, wo bei Dir der Fehler liegt....
s. unten.

mvordeme hat geschrieben:Es funktioniert auch, wenn niemand angemeldet ist. Schließlich ist es nur ein Skript.

Aber auch bei einem Skript, müssen gewisse Berechtigungen erfüllt sein.

mvordeme hat geschrieben:Unter meinen Rechnern ist einer, der bei der Echtheitsprüfung durchfällt, obwohl ich die XP-Lizenz regulär gekauft habe.

Warum rufst Du dann nicht die MS-Hotline an?
Die können Dir dann auch erzählen, warum dir Echtheitsprüfung fehl schlägt.
In den meisten Fällen liegt hier ein "zuviel an Hardwareänderungen" vor, was sich aber im Normalfall mit der netten, jungen Dame am Telefon recht schnell beheben lässt.

mvordeme hat geschrieben:Ja, aber der WHS hat dann noch das merkwürdige Berechtigungstool in der WHS-Konsole.

Gehe ich recht in der Annahme, dass Du genau diese Console verwendet hast, um den Benutzer anzulegen?
Falls ja, ist es kein Wunder, das sich der Task nicht starten lässt.
Diese Bernutzer unterliegen den Gruppen "Benutzer" und "Windows Home Server User".
Und diese haben generell nicht die Möglichkeit sich am WHS (aktiv oder interaktiv) anzumelden.

Meld Dich am WHS per RDP an und schau in die Computerverwaltung unter "Lokale Bentzer und Gruppen".
Dort legst Du Deinen neuen Benutzer an und fügst Ihn zur Gruppe "Hauptbenutzer" hinzu.
Achte auf die Passwortrichtlinie!!!
Anschließend meldest Du Dich einmal mit diesem Benutzer am WHS an, damit das Profil erstellt werden kann.
Ebenfalls musst dem User oder der Gruppe Vollzugriff auf den Ordner geben, in dem die Updates landen.
Zu guter Letzt erstellst Du noch den Task und stellst unter "Task ausführen" z.B. "Wöchentlich" ein.
"Beim Starten des Computers", "Beim Anmelden" und "Einmalig" sind für Dein Vorhaben tabu.

Gruß
sTunTe

Sorry für die lange Pause, aber ich bin im Moment etwas unter Wasser und kann wenig ausprobieren.

Ich hatte den Benutzer absichtlich über die Konsole angelegt, weil an dieser Stelle eindringlich dazu geraten wird: WHS Benutzer Rechteverwaltung. Ich hatte ihn deswegen extra noch mal gelöscht und neu angelegt, um bloß keinen Fehler zu machen. Danach war wie gesagt die Einrichtung der Remote-Desktop-Verbindung etwas komplizierter (lässt sich dort ebenfalls nachlesen), aber es hat am Ende funktioniert, und der Benutzer konnte das Skript dann auch ausführen. An den Berechtigungen auf Dateisystemebene lag es also nicht. Trotzdem wurde die Task nicht ausgeführt.

Ich habe jetzt aber mal Deinen Rat befolgt und den Benutzer ein zweites Mal gelöscht und diesmal über die Benutzerverwaltung neu angelegt. Dann habe ich im Vollzugriff auf das Verzeichnis gegeben, in dem die c't-Software liegt und auch ihre Daten abspeichert, und ihn in die Gruppe der Hauptbenutzer aufgenommen. Dann habe ich ohne Erfolg versucht, die Task starten zu lassen. Um überprüfen zu können, was die Ursache ist, habe ich ihn in die Gruppe der Remotedesktopbenutzer aufgenommen. Danach konnte er sich dieses Mal ohne weitere Hampelei per Remote-Desktop anmelden. Als ich allerdings auf das Verzeichnis zugreifen wollte, in dem die Software liegt, bekam ich die Meldung, dass ich darauf keinen Zugriff habe.

Ich habe eine ungefähre Ahnung, woran das liegen könnte. Dieses Verzeichnis ist ein Share, und die Shares werden wohl per WHS-Konsole verwaltet, mit der ich diesen Benutzer ja aber jetzt nicht angelegt habe. Hast Du eine Idee, wie ich das hinbekomme?

Das meine ich übrigens mit versaubeutelt. Ein Benutzer ist ein Benutzer. Wenn er eine bestimmte Aufgabe übernehmen soll, braucht er gewisse Rechte. Dafür füge ich ihn der passenden Gruppe hinzu, und gut ist. Es ist doch völlig idiotisch, dass es davon abhängt, ob der Benutzer mit dem einen oder dem anderen Tool angelegt wurde.

Das Fehlschlagen der Echtheitsüberprüfung ist laut MS wohl darauf zurückzuführen, dass mir der Händler (aus England) eine Windows-Lizenz angedreht hat, die Teil einer Sammellizenz ist und nicht einzeln verkauft werden darf. Da ich das angeblich hätte merken müssen, da der Lieferung nur ein Lizenz-Hologramm beigefügt war und nicht zwei (Woher soll man das beim Kauf seiner ersten Windows-Lizenz eigentlich wissen?), habe ich keinen Anspruch auf Ersatz über das Austauschprogramm. Pech gehabt. Da ich es nicht akzeptiere, Pech gehabt zu haben, habe ich einen Weg gefunden, die Einschränkungen zu umgehen.

Grüße,
-- mvordeme

P.S.: Entschuldigt übrigens, wenn ich hier etwas ungehalten rüberkomme. Das hat nichts mit Euch zu tun. Mir geht nur dieses Windows ziemlich auf die Nerven.

mvordeme hat geschrieben:Ich habe eine ungefähre Ahnung, woran das liegen könnte. Dieses Verzeichnis ist ein Share, und die Shares werden wohl per WHS-Konsole verwaltet, mit der ich diesen Benutzer ja aber jetzt nicht angelegt habe. Hast Du eine Idee, wie ich das hinbekomme?

Die Konsole ist nur eine GUI um die Berechtigungen ohne Admin-Lehrgänge richtig einstellen zu können. Wie du einem Share die Berechtigungen zuweist ist völlig egal, Hauptsache du machst es richtig.

Warum geht es dann nicht? Der Benutzer hat Vollzugriff auf das Verzeichnis, kann es aber nicht lesen.

Außerdem scheint das eben nicht zu stimmen. Um einem Benutzer, den ich per Konsole angelegt habe, Zugriff per Remote-Desktop zu geben, musste ich ziemliche Klimmzüge machen. Ein Benutzer, der per Benutzerverwaltung angelegt wurde, kann das sofort. Dafür kann der erstere nach Freigabe des Shares darauf zugreifen, der letztere aber nicht.

Jetzt sag mir bitte nicht, ich solle es einfach richtig machen. Etwas konkretere Vorschläge wären willkommen.

mvordeme hat geschrieben:Warum geht es dann nicht? Der Benutzer hat Vollzugriff auf das Verzeichnis, kann es aber nicht lesen.

Weil der User immernoch Berechtigungsprobleme hat.

mvordeme hat geschrieben:Außerdem scheint das eben nicht zu stimmen. Um einem Benutzer, den ich per Konsole angelegt habe, Zugriff per Remote-Desktop zu geben, musste ich ziemliche Klimmzüge machen.

Und wozu braucht ein User der lediglich einen geplanten Task ausführen soll, Remotezugriff auf den Server???

mvordeme hat geschrieben:Ein Benutzer, der per Benutzerverwaltung angelegt wurde, kann das sofort.

Das glaube ich weniger, es sei denn Du hast ihn zur Gruppe der Administratoren oder Remote-Desktopbenutzer hinzugefügt.

mvordeme hat geschrieben:Dafür kann der erstere nach Freigabe des Shares darauf zugreifen, der letztere aber nicht.

Wieder Fehler mit den Berechtigungen.

mvordeme hat geschrieben:Jetzt sag mir bitte nicht, ich solle es einfach richtig machen. Etwas konkretere Vorschläge wären willkommen.

Den konkreteren Vorschlag habe ich Dir oben bereits geschrieben.


Gruß
sTunTe

sTunTe hat geschrieben:Weil der User immernoch Berechtigungsprobleme hat.

sTunTe hat geschrieben:Wieder Fehler mit den Berechtigungen.

Welche denn?

sTunTe hat geschrieben:Und wozu braucht ein User der lediglich einen geplanten Task ausführen soll, Remotezugriff auf den Server???

1. Weil ich ausprobieren wollte, warum es nicht geht. Wie hätte ich sonst feststellen sollen, dass er gar nicht auf das Verzeichnis zugreifen kann?
2. Damit ich mich wie von Dir beschrieben einloggen kann und das Profil erstellt werden kann.

sTunTe hat geschrieben:Das glaube ich weniger, es sei denn Du hast ihn zur Gruppe der Administratoren oder Remote-Desktopbenutzer hinzugefügt.

Ich habe ihn zur Gruppe der Remotedesktopbenutzer hinzugefügt. Dafür ist sie ja da. Wie ich bereits schrieb, hatte ich das auch mit dem per Konsole angelegten Benutzer gemacht, was bei diesem aber nicht ausreichte.

sTunTe hat geschrieben:Den konkreteren Vorschlag habe ich Dir oben bereits geschrieben.

Den Vorschlag habe ich doch wie oben bereits beschrieben befolgt. Es geht aber immer noch nicht.

Noch mal eine Zusammenfassung:

1. Versuch: Benutzer mit WHS-Konsole angelegt

• funktioniert: Zugriff auf den Share Software erteilen. Der Benutzer hat Zugriff auf das Verzeichnis und kann das Skript manuell ausführen.
• funktioniert nicht: Remote-Zugriff aktivieren. Trotz Hinzufügen zur Gruppe Remotedesktopbenutzer kann der Benutzer sich nicht remote einloggen. Dieses Problem konnte durch ein Bearbeiten der Sicherheitsrichtlinien und ein Erlauben des Remote-Zugriffs mittels WHS-Konsole behoben werden (siehe hier).
• funktioniert nicht: Task wird nicht ausgeführt. Es gibt keine Hinweise auf ein Problem in der Ereignisanzeige.

2. Versuch: Benutzer mit Benutzerverwaltung angelegt

• funktioniert nicht: Zugriff auf den Share Software erteilen. Trotz Vollzugriffs kann der Benutzer das Verzeichnis nicht lesen.
• funktioniert: Remote-Zugriff aktivieren. Hinzufügen zur Gruppe Remotedesktopbenutzer genügt.
• funktioniert nicht: Task wird nicht ausgeführt. Klar, wenn kein Zugriff auf das Skript besteht.

Hallo.

Da ich momentan wenig Zeit habe, mach ich's ganz kurz...
Vermutlich kommt Dir hier die Console in die Quere...
Am besten nimmst Du den Benutzer dort raus und legst ihn über RDP in der windowseigenen Benutzerverwaltung an.
Anschließend erstell bitte einen Screenshot der Gruppen (Systemsteuerung -> Verwaltung -> Computerverwaltung -> Lokale Benutzer und Gruppen -> Gruppen). Hier sind die Gruppen RO_xx und RW_xx von Interesse.
Ich schau mir das dann heute abend an...

Gruß
sTunTe

sTunTe hat geschrieben:Am besten nimmst Du den Benutzer dort raus und legst ihn über RDP in der windowseigenen Benutzerverwaltung an.

Das hatte ich doch längst auf Deinen Rat hin gemacht.

sTunTe hat geschrieben:Anschließend erstell bitte einen Screenshot der Gruppen (Systemsteuerung -> Verwaltung -> Computerverwaltung -> Lokale Benutzer und Gruppen -> Gruppen). Hier sind die Gruppen RO_xx und RW_xx von Interesse.

Es fällt auf, dass alle Gruppen "doppelt" vorhanden sind. Der erste Satz ist jeweils komplett leer. Der zweite enthält die Benutzer, die laut Konsole Zugriff haben sollten. Ich habe den Benutzer mal versuchsweise in die Gruppe RW_I aufgenommen, aber das hilft leider nicht.