Jump to content

Netlogon Scripte: Anfängerfragen


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo in die Runde,

 

wie bereits im Betreff genannt habe ich ein paar Fragen zu Logon Scripten.

Das ich mich zuletzt überhaupt mit solchen Dingen beschäftigen musste ist fast 20 Jahre her, dementsprechend eingerostet ist mein Wissen und vermutlich sind die rudimentären Reste, die noch vorhanden sind inzwischen hoffnungslos veraltet.

 

Ich benötige jedoch ein paar Infos, weil ich mit jemandem beim Kunden eine Diskussion führe / führen muss, über Dinge, die seiner Meinung nach nicht funktionieren, meiner Meinung nach jedoch schon funktionieren würden, wenn es genügend Willen zur Zusammenarbeit zwischen den entsprechenden Abteilungen gäbe.

Nur fehlt es mir an fachlich versierter Expertise, meine Aussagen entsprechend zu untermauern.

Der Klassiker, es gibt eine Abteilung die möchte eine Lösung implementiert haben, die jemand anderes partout nicht will und der nun immer wieder neue, und jedes mal abenteuerlichere Behauptungen aus dem Hut zaubert, warum etwas nicht funktionieren kann, was sich andere überlegt haben.

 

Ich sitze mal wieder zwischen allen Stühlen und versuche zu vermitteln.

 

Szenario (bei eben jenem Kunden)

Konkret geht es um die Ausführung von Logon-Scripten und der Problematik bei Usern, die nicht mit der Domäne verbunden sind.

Ziel ist die Ausführung einer Datei (.exe), die in einem zentralen Share liegen soll und die eine wmi-Abfrage auf dem Client-System ausführen soll.

Das Ergebnis dieser Abfrage soll in ein vorgegebenes Verzeichnis zurückgeschrieben werden. 

Dabei übernimmt die exe-Datei bei Aufruf mit den korrekten Parametern die wmi-Abfrage, das Schreiben des Ergebnisses in eine XML-Datei und das speichern dieses Ergebnisses in ein entsprechendes Verzeichnis. Diese muss nur vorhanden sein.

 

Ich denke Die Aufgabenstellung ist damit zunächst erst einmal klar und ich halte diese jetzt nicht für sonderlich anspruchsvoll.

 

Des weiteren habe ich noch folgende weiterführenden Informationen:

Die Login Scripte für User liegen in der Domäne im Netlogon Verzeichnis auf dem DC.  (//dc01/netlogon)

Hier existiert für jeden User eine cmd-Datei (das habe ich heute selbst sehen können).

Als Muster hier mal der Inhalt einer solchen cmd-Dateit:

(ich habe kundenrelevante Informationen durch allgemeine Infos ersetzt. Sollte es deswegen zu Missverständnissen oder Fragen kommen, dann bitte einfach eine Info an mich, ich versuche dann zu beantworten oder zu lösen.)

Die Zeilennummern Z00 bis Znn habe ich dem einfacheren Verständnis halber hinzugefügt, die gibt es im Original natürlich nicht.

Z00		@echo off
Z01		echo Executing Logon Script Mustermann, Max
Z02		
Z03		net use j:  /d
Z04		net use j: \\test\kunde\ordner_1                      /persistent:no
Z05		net use k:  /d
Z06		net use k: \\test\kunde\ordner_2                      /persistent:no
Z07		net use q: /d
Z08		net use q: \\test\kunde\ordner_3                      /persistent:no
Z09		net use r: \\test\kunde\ordner_4\ordner_4.1           /persistent:no
Z10		rem net use t: \\test\kunde\ordner5\ordner_5.1        /persistent:no
Z11		net use v: \\test\kunde\vorlagen                      /persistent:no
Z12		rem net use w: \\net\kunde\word\word_1                /persistent:no
Z13		net use s: \\test\kunde\IT                            /persistent:no
Z14		net use p: \\test\kunde\user\MustermannMax            /persistent:no
Z15		
Z16		call pcinfo.cmd
Z17		
Z18		exit

Zunächst hätte ich zu diesem Script ein paar Verständnisfragen:

Z00:

nach meinem Verständnis schaltet der Befehl "@echo off" die Ausgabe von Meldungen für die gesamte Stapelverabreitungsdatei aus.

Ausnahmen müssen entweder per "echo" für einzelne Zeilen definiert werden oder es wird die Ausgabe generell mit "@echo on" wieder eingeschaltet.

Korrekt? Ja oder Nein?

 

Z01:

Wenn meine Frage in Z00 mit "Ja" beantwortet wird, dann müsste mit dieser Zeile der Text "Executing Logon Script Mustermann, Max" auf dem Bildschirm angezeigt werden. (also im Konsolenfenster natürlich).

Im Regelfall solle die Ausführung aber derart schnell von statten gehen, dass dieser Befehl nur in den seltensten Fällen zu sehen ist, er dient meiner Meinung nach nur einer zusätzlichen Absicherung. (z.B. wenn das Script aus welchem Grund auch immer hängen bleibt, dann bleibt ein "DOS-Fenster" in der Taskleiste in dem diese Meldung stehen würde. Der User sieht dann nur diese Meldung kann damit aber zumindest dem Administrator einen Hinweis geben, was für Fenster das überhaupt ist.

Gibt es andere Gründe diese Zeile an diese Stelle einzufügen?

 

Z03: (und weitere mit selbigem Aufrufparameter wie Z05 und Z07)

Der Aufruf in der Zeile mit der Option "/d" als Kurzform für "/delete" canceled eine Netzwerk-Verbindung, in dem Fall die zum Laufwerk "J:"

Ich gehe davon aus, dass dieser Aufruf deshalb erfolgt um sicher zu gehen, dass nicht aus irgendwelchen anderen Gründen der Laufwerksbuchstabe bereits für eine andere Verbindung genutzt wird und eine Verbindung zum im Unternehmen üblichen Laufwerk "J:" wie er in Zeile Z04 erfolgt gesichert ist.

 

Sollte genau dies damit beabsichtigt sein, dann frage ich mich jedoch, warum man dies nicht bei sämtlichen Laufwerksverbindungen so macht, denn die Problematik könnte dann ja auch bei allen anderen Laufwerken, die hier aufgerufen werden dieselbe sein.

Sieht jemand einen Grund dafür diesen Aufruf nicht bei allen Laufwerken vorneweg zu setzen?

 

Meiner Meinung nach könnte man auch zu Beginn den Befehl:

net use * /d 

setzen. Dieser würde dann aber vermutlich sämtliche Verbindungen trennen, auch jene, die z.B. vom User händisch selbst angelegt wurden und gar nicht über das Logon Script aufgerufen wurden.

Damit wären beim Aufruf dieses Befehls dann auch jedes mal alle anderen Laufwerksverbindungen getrennt, was unter Umständen zu Problemen, zumindest aber zu Irritationen bei Usern führen könnte.

 

In der Diskussion kam hier ein Disput darüber zustande, dass der Aufruf von Zeile Z03 eigentlich komplett unterbleiben könnte, weil das Logon-Script ja beim Start des Systems als erstes ausgeführt wird, also zu einem Zeitpunkt zu dem überhaupt noch keine anderweitigen Netzwerkverbindungen bestehen. Man könne also garnichts trennen, denn es existiere ja nichts trennbares. 

Ich würde dieser Aussage zwar zustimmen, aber eine Verknüpfung zur entsprechenden CMD-Datei hat jeder User auf seinem Desktop liegen.

Dort heißt die Verknüpfung dann "Netzlaufwerke verbinden nach dem Aufbau einer VPN-Verbindung".

Dann macht es meiner Meinung nach wiederum Sinn, eben genau diese Trennung der Netzlaufwerke in die CMD-Datei mit aufzunehmen, denn wenn ein User mit seinem Gerät unterwegs ist (z.B. Notebook) dann kann das Login-Script ja gar nicht ausgeführt werden, weil es überhaupt keinen DC gibt, an dem man sich anmelden kann.

Erst nach der Anmeldung (das Login-Script wäre also eigentlich schon gelaufen) wird erst eine Verbindung zum Netzwerk mit dem händischen Aufruf der VPN-Verbindung über den Verbindungsmanager gestartet.

Um nun die üblichen Laufwerke gemountet zu bekommen wird also das sonst im Unternehmen übliche Login-Script durch den User erneut händisch aufgerufen.

 

Z04, Z06, Z08, Z09, Z11, Z13, Z14:

rufen jeweils Netzwerkpfade als Laufwerke auf. Welche das letztlich sind ist ja weniger relevant

 

Z16:

Ich habe dazu kein spezielles Programm finden können. Ich vermute hier eine weitere Batch, und versuche gerade herauszubekommen, um welchen Aufruf es sich dabei handelt.

 

Was spricht also dagegen, hier noch eine weitere Zeile an das Script anzufügen mit dem eine auf einem zentralen Share, z.B. auch auf dem DC liegende Script Datei aufgerufen wird.

Spricht etwas dagegen, wegen der Erreichbarkeit diese ebenfalls ins Netlogon Verzeichnis zu legen?

 

Wie gesagt man kann der Datei Parameter mitgeben, über die die Ausgabe des Ergebnisses definiert wird.

Bei der aufzurufenden Datei geht es um die scriptbasierte Inventarisierung von Docusnap.

Ich habe mal die Optionen als Screenshot mit angehängt, nur damit ihr euch ein Bild davon machen könnt.

 

DocusnapScript_hilfe.jpg

 

Bin für jede (Teil-) Antwort dankbar.

 

 

Gruß

Jörg

 

 

 

 

 

Link zu diesem Kommentar
vor 16 Minuten schrieb j.bussmann:

Man könne also garnichts trennen, denn es existiere ja nichts trennbares. 

Wieso sollten keine vorhanden sein? /persistent:no impliziert ja, dass es auch /persistent:yes gibt, oder? ;) Da du aber immer nur die bestehenden im Logon Script mit /persistent:no loggst, sollten die eher selten anderweitig vergeben sein, aber um auf Nummer sicher zu gehen, kann man das durchaus so tun.

Link zu diesem Kommentar

Ich hab dazu wso viele Anregungen und Meinungen, daß ich möglicherweise die Größengrenze eines einzelnen Beitrags sprengen könnte, wenn ich jetzt alles dazu schreibe :-)

 

1. Batch ist Grütze. Nicht nur, weil Powershell unendlich flexibler ist, sondern auch, weil Batch über UNC extreme Performance-Issues hat. Vor allem über langsame Leitungen. Datei öffnen, Zeile lesen, Positionsmarker setzen, Datei schließen, Zeile ausführen. Und das für JEDE EINZELNE ZEILE im Batch...

2. @echo off schaltet nur die Ausgabe des jeweiligen Befehls in der Konsole ab. Die Ausgaben der Befehle an sich werden sehr wohl ausgegeben.

3. Batch-Verschachtelung ist so Grütze wie Batch. Wenn schon, alles in eins rein.

4. Läuft das asynchron oder synchron? Wenn asynchron: Probleme mit Netzlaufwerken in Explorer oder Anwendungen sind vorprogrammiert. Wenn synchron: Desktop erscheint erst, wenn es fertig ist. Wenn die Shares nicht erreichbar sind: 30 Sekunden Wartezeit pro Share... (Genauer 29,56 :-) ).

5. bis 99. spare ich mir hier mal - kannst mich ja mal direkt kontaktieren.

Edit: Grad fällt mir 5. ein: Net use x: /d trennt die Verbindung. Aber nur, wenn da keine offenen Dateien sind, sonst kommt ne Rückfrage und das Skript bleibt stehen. Wenn schon "net use x: /d /y"...

Edit 2 Ich werfe noch 6. hinterher: Startup und Logon Skripts sollten IMMER lokal liegen und lokal aufgerufen werden. Nur dann laufen sie auch, wenn keine Domänenverbindung besteht. Bei dem Skript hier ist das aber sinnfrei, weil es keinerlei Errorhandling oder "Situationserkennung" implementiert. Damit also dann auch nicht weiß, daß es offline ist (RootDSE nicht erreichbar) und nichts (oder nur wenig) machen sollte. Und man kann das nach dem Herstellen einer VPN-Verbindung auch automatisch ausführen, da gibt es so komische Events, die das signalisieren :-)

Um noch die Anfangsfrage zu beantworten - Datei ausführen, Ergebnis als XML erstellen;

Beides sollte rein lokal passieren, und ins Netz kopiert wird dann, wenn das Netz auch verfügbar ist. Dann klappt es auch mit dem Nachbarn.

bearbeitet von daabm
Link zu diesem Kommentar
Zitat

5. bis 99. spare ich mir hier mal - kannst mich ja mal direkt kontaktieren.

Ok, auch wenn ich bei vielen Dingen jetzt selber ganz viele Fragezeichen über dem Kopf schweben habe, ich würde Dein Angebot gerne annehmen Martin.

Vielleicht kannst Du mir da ein wenig auf die Sprünge helfen und die Fragezeichen über meinem Kopf ein wenig lichten.

 

Ich schreibe Dich mal per PN an und gebe Dir noch ein paar weitere Hintergrundinformationen.

Link zu diesem Kommentar

Ich habe kein Problem damit die Diskussion hier auch öffentlich zu führen. Wollte lediglich der Bitte von Martin nachkommen.

Meine Absicht war es dabei keineswegs jemanden zu verprellen oder vor den Kopf zu stoßen.

 

Daher hier an dieser Stelle noch ein paar weitere Hintergrundinformationen, die allen Beteiligten vielleicht noch etwas helfen mein Problem zu verstehen.

 

Ich agiere beim Kunden als Lizenzprüfer, nicht im Auftrag eines Herstellers, sondern quasi von der Unternehmensleitung beauftragt um für den Fall einer Auditierung gerüstet zu sein.
Dabei haben wir festgestellt, dass niemand im Unternehmen die genaue Anzahl der Client PCs beziffern kann. (Das Unternehmen ist nicht gerade klein).

  • Ein Tool zur Software-Verteilung welches agentenbasiert arbeitet hat rund 2000 PCs in der Verwaltung
  • Schaue ich in die AD, rechne noch Machinensteuerungen und andere nicht AD System hinzu komme ich auf über 5000 (hier gibt es sicherlich eine erhebliche Anzahl an Karteileichen, die AD ist mangelhaft gepflegt.
  • Ruft man die Antivirus Management Konsole auf und schaut nach welche Geräte sich regelmäßig Pattern-Files in der Domäne herunterladen, so komme ich auf über 4000 Systeme
  • Ein internes aber nicht ausgereiftes Tool zum IT-Asset Management spricht von 3000 Systemen

jede Abteilung fetzt sich mit der anderen, jeder für eine Lösung zuständige beharrt darauf, dass seine Zahlen korrekt sind.

 

Dass hier grundsätzlich etwas im Argen liegt und man auch grundsätzliche Dinge mal völlig neu aufziehen müsste ist mir klar, ist einigen Personen beim Kunden klar, aber betriebsintern durch Übernahmen, Auslandsgesellschaften und zum Teil offene Feindschaften untereinander ein Problem, welches wir an dieser Stelle nicht diskutieren brauchen.

 

Beim Kunden kommt neben den oben erwähnten Tools außerdem noch Docusnap der Firma itelio zum Einsatz, was ich im Prinzip recht gut kenne.

Dieses bietet die Möglichkeit mit Hilfe einer Script-Datei zu inventarisieren. (Man kann auch Netzwerkscans usw. machen, die haben aber natürlich das Problem, dass immer mal wieder Geräte nicht erreichbar sind und daher würde die Erfassung immer unvollständig bleiben).

Grundsätzlich würde sich auch bei einem klassischen Logon-Script diese Erfassung als relativ unproblematisch darstellen. 

Mit dem Logon wird einfach die Datei ausgeführt, per Parameter die Daten in ein entsprechendes Share geschrieben und fertig.

Der Docusnap Server holt die erfassten Daten aus diesem Share ab und importiert sie.

 

Aber es gibt beim Kunden zahlreiche User, die über sehr lange Zeiträume weltweit unterwegs sind. Ein Logon Script wäre daher nicht wirklich zielführend, denn die Systeme würden unter Umständen wiederum Monate oder gar Jahrelang nicht erfasst. Der Softwarebestand wäre also immer noch mehr als nebulös. 

 

Meine Idee war nun die, nach einer Lösung zu suchen, die dieses Problem umgeht.

 

Die mobilen User, auch wenn sie sich über Monate nicht an der Domäne anmelden starten jedoch regelmäßig eine VPN Verbindung und führen dann das ihnen zugewiesene Login-Script manuell aus, weil es als Verknüpfung auf dem Desktop liegt. (auch dass kann man sicherlich wesentlich eleganter lösen.)

 

Meine erste Frage zielte also darauf ab, das Login Script des Kunden zu verstehen, um dem Kunden ggf. eine Lösung anzubieten, wie sich das in das Login Script integrieren lässt.

 

Allerdings zeigen Teile der IT beim Kunden dagegen eine bemerkenswerte Abneigung, die aber im wesentlichen eine generelle Abneigung gegen alles ist. 

Ich muss also irgendwie eine relativ wasserdichte, überzeugende Lösung finden.

 

Argumente die dagegen sprechen:

- Probleme wenn das Share nicht erreicht werden kann (die gäbe es mit dem bisherigen Script natürlich ebenso, aber das zählt ja nicht, ist ja immer so) 

- Wenn die Ausführung des Programms hängt, muss der Mitarbeiter lange warten.

- Die Ausführung des Scriptes kann mehrere Minuten dauern, läuft aber "silent" im Hintergrund. Der Kunde hegt aber Zweifel ob das immer so ist und befürchtet, dass die User glauben die Anmeldung würde nicht funktionieren.

- ich habe bestimmt ncoh Dinge vergessen....

 

Ach ja, eine Verteilung des Scripts auf die Clients kommt nicht in Frage. Zum einen erreichen die Tools zur Software Verteilung ja eben nicht alle Geräte und sind selbst eine Ursache für die abweichenden Gerätezahlen.

Zum anderen ändert sich das Script sehr häufig und müsste dann jedes Mal erneut verteilt werden. Dies sollte auf jeden Fall vermieden werden.

 

daabm's Ansatz war das nicht mit einem klassischen Batch-basierten Loginscript zu lösen sondern per Powershell, aber das ist ein Bereich, da muss ich leider völlig passen. Ich habe davon ehrlich gesagt null Ahnung. 

Sein Angebot war mir dabei im persönlichen Austausch unter die Arme zu greifen. Ich denke nicht, dass das gegen das Forum gerichtet war, sondern eher darum gehen sollte Euch nicht mit meinen Anfängerproblemen zuzutexten.

 

Ich hoffe nun ist einiges klarer geworden. Niemand fühlt sich vor den Kopf gestoßen und ich bekomme vielleich auf von Euch noch ein paar gute Ideen und Lösungsansätze.

 

Danke

Jörg

 

 

 

 

Link zu diesem Kommentar

Liest sich für mich wie ein Kobayashi Maru Test :aetsch2:.

Ich denke, Du wirst keine Lösung finden, die 100% abdeckt unter den gegebenen Umständen. Die beschriebenen innerbetrieblichen "Probleme" und "Animositäten" werden das leider erfolgreich verhindern. Deine Auftraggeber sollten diese als erstes beseitigen. Das in so einem Szenario überhaupt produktiv gearbeitet werden soll/kann ist schon ein Wunder.

 

Hilfreich wären Information zum Aufbau der Struktur/Hierarchie der IT in dem Unternehmen. Ist das komplett Zentral oder gibt es Regionen/Standorte mit "Unterabteilungen" ? Wie ist die AD Struktur im Hinblick auf Reginonen/Standorte aufgebaut ?

vor 21 Stunden schrieb j.bussmann:

Aber es gibt beim Kunden zahlreiche User, die über sehr lange Zeiträume weltweit unterwegs sind.

Diese User sind doch aber nicht während dieser Zeit ausschließlich "offline" unterwegs oder ? Inventarisierung hat auch nicht unbedingt was mit einer aktiven AD Anmeldung zu tun. Ein Konstrukt aus einem im Internet erreichbaren Server, einem "Agenten" der die Information übermittelt und einem Inventarisierungs Tool welches mit dem AD synchronisiert sollte reichen.

 

Wie gesagt: Die UL muss die Hüte und somit die Verantwortlichkeiten verteilen. Auf "Nein" Sager oder "Ich bin gegen Alles" Mitarbeiter darf da keine Rücksicht genommen werden.

 

Viel Erfolg wünsche ich Dir natürlich trotzdem.

 

Greetings Ralf

Link zu diesem Kommentar
vor 41 Minuten schrieb Userle:

Liest sich für mich wie ein Kobayashi Maru Test :aetsch2:.

Ich denke, Du wirst keine Lösung finden, die 100% abdeckt unter den gegebenen Umständen. Die beschriebenen innerbetrieblichen "Probleme" und "Animositäten" werden das leider erfolgreich verhindern. Deine Auftraggeber sollten diese als erstes beseitigen. Das in so einem Szenario überhaupt produktiv gearbeitet werden soll/kann ist schon ein Wunder.

 

Hilfreich wären Information zum Aufbau der Struktur/Hierarchie der IT in dem Unternehmen. Ist das komplett Zentral oder gibt es Regionen/Standorte mit "Unterabteilungen" ? Wie ist die AD Struktur im Hinblick auf Reginonen/Standorte aufgebaut ?

Diese User sind doch aber nicht während dieser Zeit ausschließlich "offline" unterwegs oder ? Inventarisierung hat auch nicht unbedingt was mit einer aktiven AD Anmeldung zu tun. Ein Konstrukt aus einem im Internet erreichbaren Server, einem "Agenten" der die Information übermittelt und einem Inventarisierungs Tool welches mit dem AD synchronisiert sollte reichen.

 

Wie gesagt: Die UL muss die Hüte und somit die Verantwortlichkeiten verteilen. Auf "Nein" Sager oder "Ich bin gegen Alles" Mitarbeiter darf da keine Rücksicht genommen werden.

 

Viel Erfolg wünsche ich Dir natürlich trotzdem.

 

Greetings Ralf

 

Das es keine 1005 Lösung gibt ist mir klar, ebenso, dass Prozesse optimiert werden und die Animositäten beseitigt werden müssen, weil es sonst immer wieder Probleme gibt.

Daran arbeite ich beim Kunden ja auch, dass ist Teil meiner Aufgabe als Lizenzmanager.

Aber so quasi "nebenbei" und auch unentgeltlich liefere ich, wenn ich es kann auch mal Lösungen am Rande für Probleme mit.

Man muss nicht für alles die Hand offen halten und in Geld denken (zumal ich nur Angestellter bin und kein Selbständiger Berater, der dann mit fremden Wissen beim Kunden Geld verdient).

 

Mir geht es auch nicht um das ganze drum herum, dass wollte ich hier eigentlich gar nicht diskutieren und euch auch damit nicht belasten, sondern es geht mir nur darum dem Kunden ein Stück weit zu helfen, ihm einen Schubs in die richtige Richtung zu geben denn der Kunde hat sich inzwischen selbst in eine "Geht nicht, weil will ich nicht"-Situation verrannt.

 

Mit einem gangbaren Lösungsansatz würde man ein Zeichen setzen, auf den Kunden zugehen und sagen, "schau doch mal, ich habe mich mal erkundigt, habe da vielleicht einen auch für Dich akzeptablen Lösungsansatz, lass und doch mal schauen ob uns das nicht weiterbringt..."

 

Aber wie bereits in meinem ersten Posting gesagt, fehlt es mir an technischer Tiefe und daher habe ich Hilfe gesucht.

 

Die zentrale Fragestellung ist, wie bekomme ich (idealer Weise) per Login-Script oder ähnlichem die Ausführung des Docusnap-Scripts realisiert, welches in einem zentralen Laufwerk liegen sollte.

Cloud-Nutzung ist für den Kunden aus Gründen, die an dieser Stelle nicht diskutiert werden können keine Option. Mehr möchte ich an dieser Stelle nicht sagen um nicht wieder einen nächsten Diskussionsthread innerhalb der Problemstellung aufzumachen, der letztlich aber nicht zur Lösung führt.

 

Zur IT des Kunden.

Die ist zentral an einem Standort (also die zentrale Infrastruktur (oder sie soll es zumindest werden) Ausnahmen gibt es nur an Standorten, Deren Bandbreitenanbindung nicht gut genug ist. Dazu zählen einige asiatische Standorte, aber auch das stellt kein Problem dar. Das Problem würde sich dort lokal ebenfalls genauso stellen wie hier.

 

Es gibt eine AD "Kunde.de" mehr nicht. (Wie gesagt, kleine Ausnahmen, die aber auch Stück für Stück abgebaut werden, sie spielen aber bei der Betrachtung zunächst keine Rolle.

 

Mir geht es nur darum eine exe-Datei zentral abzulegen (die Datei unterliegt einer sehr hohen Änderungsquote, eine Verteilung auf einzelne Systeme macht daher keinen Sinn und würde den adminstrativen Aufwand noch mehr erhöhen), diese Datei ausführen zu lassen und das Ergebnis in ein Verzeichnis zurück zu schreiben.

 

Lokal ist das auch gar kein Problem. Bei Standorten mit entsprechender Anbindung ebenfalls nicht.

 

Diskussionen gibt es nur bei den sogenannten "Mobilen Usern" da sich diese über Wochen oder Monate nicht an der AD anmelden, sondern ihr Login Script händisch nach dem Aufbau der VPN Verbindung starten. Hier sieht der Kunde (einige Admins) ein Problem, in dieses Script den Aufruf der Exe-Datei mit einzubauen.

 

Das der Kunde eigentlich ganz andere Probleme hat usw. brauchen wir an dieser Stelle nicht erneut thematisieren, das ist bekannt. Die Frage ist nur, was ist die einfachste Lösung (und die funktionalste, den Aufruf der exe-Datei zu ermöglichen)

Ich hätte diesen Aufruf jetzt einfach an letzter Stelle in das Login Script gepackt. Aber da gibt es dann eben Fragen wie, was passiert, wenn die Verarbeitung nicht abgeschlossen werden kann?

Bleibt das System dann ggf. minutenlang einfach "hängen"

 

Ich suche also nach Ideen, diese ExeDatei auszuführen und dabei möglichst wenig Probleme zu bekommen.

 

Es gab auch schon die Überlegung das per Windows Taskplaner zu realisieren, der sich auch über Policies steuern lässt, aber der Windows Tasklpaner hat sich nicht als sonderlich zuverlässig erwiesen. Wir haben da schon Effekte von "geht, geht nicht, geht, geht nicht" gehabt, die wir nie so richtig lösen konnten.

 

Also wenn jemand eine Idee hat, wie man diese exe-Datei am besten, zuverlässigsten und einfachsten aufgerufen bekommt, gerade dann, wenn beim Start des Systems keine Verbindung zur AD besteht, dann bin ich an einem Vorschlag sehr interessiert.

 

Das dann natürlich eine Verbindung existieren muss, das ist mir klar, sonst könnte weder die Exe-Datei aufgerufen werden, noch das Ergebnis weggeschrieben werden.

 

 

 

vor 7 Minuten schrieb Dukel:

Gibt es keine Prozesse die Bestellungen und verschrottungen von Rechnern erfasst?

Ich würde dann einfach von der höchsten Zahl ausgehen, bis die Firma das gegenteil beweisst -> seine Prozesse oder eine Inventarisierung in den Griff bekommt.

Nein, die Prozesse gibt es nicht oder sie sind äußerst mangelhaft, diese sollen ja implementiert werden, wir befinden uns aber im Prinzip noch drei Schritte davor.

Es geht auch nicht darum, dass hier der Kunde etwas beweisen muss, es ist kein offizielles Audit, wenn es das wäre, dann würde ich dem Kunden einfach die höchsten Zahlen um die Ohren hauen, die ich ermitteln kann und er müsste dann zahlen. Hier geht es darum den Kunden abzuholen und nicht weiteren Groll von Abteilungen und Mitarbeitern gegeneinander zu schüren.

Ich möchte dem Kunden die Möglichkeit geben aufeinander zuzugehen, vor allem intern.

Schranken und Blockaden abzubauen. Das gelingt am ehesten in dem man nicht auf Zuständigkeiten verweist und jemandem Vorhält, dass das sein Problem wäre, was er zu lösen hätte, sondern das funktioniert meiner Erfahrung nach am Besten, wenn man dem Kunden einen möglichen Lösungsweg aufzeigt, ihm also ein Stück weit entgegenkommt, ihn an der Stelle abholt um dann ggf. gemeinsam eine Lösung zu erarbeiten.

 

Mir fehlt es dazu aber, wie ich eingangs bereits sagte an tiefergehendem Know-How. Ich weiß, dass es eine Lösung gibt, wenn man denn will, der Kunde (oder Teile des Kunden behaupten "nein") und so stehen sich zwei Seiten gegenüber die so nicht zusammenkommen. Also versuche ich mir das nötige Wissen anzueignen um einen Schritt auf die andere Seite zugehen zu können und genau deshalb habe ich hier um Hilfe gebeten.

 

Und ich würde mich sehr freuen, wenn sich hier Leute finden würden, die mir da auf die Sprünge helfen könnten.

Link zu diesem Kommentar

Du könntest die Anwendung versteckt im Hintergrund starten. Dann sollte es kein Problem sein, wenn sie etwas länger hat wegen einer schlechten Verbindung oder so. Das Anmeldescript würde dann nicht "hängen". Es gibt dafür verschiedene Möglichkeiten; ich würde es mit PowerShell probieren: https://winaero.com/blog/run-a-program-hidden-in-windows-10/

Link zu diesem Kommentar

Man könnte den Aufruf der EXE in einen geplanten Task packen, den Task per GPP auf die Rechner bringen. Den Task dann alle 10 oder 15 Minuten, oder auch stündlich starten. Läuft der Task länger stört er niemanden, ist er erfolgreich, auch gut.

vor einer Stunde schrieb j.bussmann:

Es gab auch schon die Überlegung das per Windows Taskplaner zu realisieren, der sich auch über Policies steuern lässt, aber der Windows Tasklpaner hat sich nicht als sonderlich zuverlässig erwiesen. Wir haben da schon Effekte von "geht, geht nicht, geht, geht nicht" gehabt, die wir nie so richtig lösen konnten.

Dann wäre es evtl. zielführender an der Stelle anzusetzen als immer nur neue/andere Lösungen auszuprobieren. Der Taskplaner ist zuverlässig, man muss es einfach nur richtig konfigurieren.

Link zu diesem Kommentar
vor 1 Minute schrieb Sunny61:

Man könnte den Aufruf der EXE in einen geplanten Task packen, den Task per GPP auf die Rechner bringen. Den Task dann alle 10 oder 15 Minuten, oder auch stündlich starten. Läuft der Task länger stört er niemanden, ist er erfolgreich, auch gut.

Dann wäre es evtl. zielführender an der Stelle anzusetzen als immer nur neue/andere Lösungen auszuprobieren. Der Taskplaner ist zuverlässig, man muss es einfach nur richtig konfigurieren.

Hast Du da vielleicht einen Ansatz?
Also wie bringt man den Task per GPP auf die Rechner. Versuche mich da parallel schon einzulesen in die ganze Thematik, aber die Wissenlücken zu schließen geht in meinem Alter nicht mehr so flott! ;-)

 

Link zu diesem Kommentar
23 minutes ago, j.bussmann said:

Hast Du da vielleicht einen Ansatz?
Also wie bringt man den Task per GPP auf die Rechner. Versuche mich da parallel schon einzulesen in die ganze Thematik, aber die Wissenlücken zu schließen geht in meinem Alter nicht mehr so flott! ;-)

Wieso willst du eine technische Lösung umsetzen? Wieso nicht die Firma selbst bzw. dessen IT?

Link zu diesem Kommentar

Man erstellt den Task auf einem Rechner auf dem auch die GPMC.MSC (Gruppenrichtlinienverwaltungskonsole) installiert ist. Natürlich verwendet man im Task nur UNC Pfade, als Ausführender Benutzer kann man SYSTEM aus dem AD verwenden. Auf der Freigabe in dem die EXE liegt, müssen authentifizierte Benutzer Leserechte haben, dann kann die EXE ausgeführt werden.

 

Ein neues GPO anlegen, Computereinstellungen >Systemsteuerungseinstellungen > Geplante Aufgaben. Neue Geplante Aufgabe, mind. W7. Über die drei ... rechts kannst Du bestehende Aufgaben auswählen und übernehmen. Aktion ist Aktualisieren. Der Rest sollte selbsterklärend sein. Natürlich muss man so einen Task vorher sauber testen. Auch von extern über VPN, ansonsten kann man sich die Arbeit sparen.

 

Ich habe langsam den Eindruck, hier ist nichts wie es scheint.

bearbeitet von Sunny61
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...