![Bester Ansatz zum Bereitstellen von DLL-Dateiupdates für Win7-Clients](https://rvso.com/image/658349/Bester%20Ansatz%20zum%20Bereitstellen%20von%20DLL-Dateiupdates%20f%C3%BCr%20Win7-Clients.png)
Wir befinden uns in einer Windows 7-/Server 2008 R2-Domänenumgebung. Wir haben eine .NET-Anwendung mit zahlreichen internen Bibliotheken für verschiedene Benutzeroberflächen und andere Funktionen. Wir stellen sie von einer Freigabe aus bereit, in der für jede „Version“ ein Verzeichnis mit der neuesten Versionsnummer erstellt wird. Gelegentlich gibt es einige Abteilungen, die für ihre speziellen Anforderungen etwas an der Anwendung optimieren müssen und die die Änderung dringend vor der nächsten Version benötigen. Wir können dies tun, indem wir ihnen eine bestimmte Anzahl benutzerdefinierter DLL-Dateien mit den gewünschten Änderungen zur Verfügung stellen. Ich versuche, die zuverlässigste und effizienteste Methode zu finden, damit unsere Client-Rechner automatisch nach diesen „benutzerdefinierten“ Dateien suchen und sie kopieren. Ich möchte dies auf eine Weise tun, die möglichst effizient, zuverlässig, zentral verwaltet und mit dem geringsten Overhead für die Clients ist. Wenn wir benutzerdefinierte Dateien bereitzustellen haben, möchten wir, dass alle Clients diese vorzugsweise innerhalb von 24 Stunden nach dem Ablegen auf der Freigabe kopieren. Sie würden in einen Unterordner des aktuellen Netzwerk-Release-Verzeichnisses mit dem Namen „Benutzerdefiniert“ oder etwas Ähnlichem verschoben. Wir haben derzeit kein SCCM, daher prüfe ich die folgenden Optionen:
Batch-Datei-Anmeldeskript für Benutzer, das das Netzwerkverzeichnis überprüft und lokale Dateien mit Robocopy oder Xcopy herunterkopiert (überschreibt). Dazu müsste sich der Benutzer ab- und wieder anmelden, sodass es beim Abrufen benutzerdefinierter Dateien zu Verzögerungen kommen könnte. Benutzer hätten eine einfache und zuverlässige Möglichkeit, es auszulösen, was ein Plus wäre.
Geplante Aufgabe, die über das Element „Gruppenrichtlinieneinstellungen“ konfiguriert wurde, um das Netzwerkverzeichnis möglicherweise mehrmals täglich auf benutzerdefinierte Dateien zu prüfen. Dies könnte die Datei schneller abrufen als ein Benutzeranmeldeskript, aber ich habe keine Erfahrung mit Elementen für geplante GPP-Aufgaben. Ist es zuverlässig und einfach einzurichten und zu warten? Auch diese Aufgabe würde ein Batchskript ausführen, um nach Dateien im Netzwerk zu suchen und Robocopy mit der Option /xo zu starten. Wenn wir Dateien in das benutzerdefinierte Verzeichnis legen, gehen wir davon aus, dass sie benötigt werden, unabhängig von den Versionen. Eine einfache Überprüfung der Dateidaten sollte ausreichen, damit sie nicht immer wieder kopiert werden, wenn sie erst einmal vorhanden sind.
Eine geplante Aufgabe wie oben, die jedoch auf der Grundlage eines Ereignisprotokolleintrags ausgelöst wird. Ist das zuverlässig? Ich habe es nie ausprobiert. Es könnte von Vorteil sein, einen Ereignisauslöser zu finden, der anzeigt, dass die Anwendung gerade gestartet (oder geschlossen) wurde, und dann die Dateien sofort zu kopieren, damit die Wahrscheinlichkeit geringer ist, dass die Arbeit des Benutzers unterbrochen wird.
Ich weiß, dass es auch ein Gruppenrichtlinienelement zum Verwalten/Kopieren von Dateien gibt. Ich glaube, das wäre in diesem Fall zu viel Arbeit, da möglicherweise mehrere Dateien gleichzeitig über mehrere Versionen der Anwendung hinweg vorhanden sein könnten.
Ich habe auch über ein Powershell-Skript nachgedacht, das interessante Dinge tun könnte, wie beispielsweise die tatsächlichen DLL-Dateiversionen vergleichen usw., aber das würde wahrscheinlich mehr Ressourcen erfordern (langsamer laufen) und tut wirklich mehr als nötig.
Irgendwelche anderen Ideen, was am besten funktionieren könnte? Ist die einfachste Antwort (Benutzeranmeldeskript) hier wirklich die beste?
Antwort1
Ich habe mich letztendlich für Option Nr. 1 entschieden, ein Benutzeranmeldeskript, und das funktioniert nun schon seit einiger Zeit zuverlässig. Ich würde das ganze Skript hier posten, aber es ist voller interner Anwendungsdetails, die es für den allgemeinen Gebrauch weitgehend unbrauchbar machen würden. Das interessanteste Detail ist, dass wir wmic verwenden, um die interne Versionsnummer der lokal installierten Anwendung abzurufen und diese verwenden, um auf das richtige Versionsverzeichnis auf unserem Bereitstellungsserver zu verweisen. Dieser Code setzt eine Variable namens Version, die dem von wmic.exe zurückgegebenen Wert entspricht.
set "myfile=c:\\progra~2\\%AppFolder%\\AppName.exe"
for /f "tokens=*" %%f in ('wmic datafile where "name='%myfile%'" get version /value ^| findstr "="') do set "%%f"