Vorspiel

Ich habe in letzter Zeit auf Arbeit mit einigen Rechnern gekämpft, die die AD-Gruppenrichtlinien nicht mehr ausführen wollten, genau genommen gar keine AD-Verbindung mehr hatten. Die Anzahl der Geräte, die sich bei meinem Deployment-Manager gemeldet haben, sank immer weiter.
Mit den PCs schien ansonsten alles in Ordnung: Domänenmitgliedschaft, Internet, Intranet, Serververbindung mit Netzlaufwerken, alles da.
Wie kommt’s?

weiterlesen

Intro

Das Deployment von Adobe Reader DC im Windows Netzwerk via GPO Batch-Startscript ähnelt der Verteilung des alten Adobe Readers sehr – dennoch fasse ich die wichtigsten Steps hier zusammen.

Vorbereitung

Ihr braucht für die Verteilung immer die DC-Basisversion (als .msi) und das aktuellste, gewünschte Update (als .msp).
Außerdem, um die Reader Installation vor dem Deployment anzupassen, den installierten Reader DC Customization Wizard.

Step-by-Step

  1. Lokale AIP-Installation (z.B. C:\adc1516\) der Basisversion mit:

    Das Bild zeigt den Reader DC Installationsdialog, der durch die AIP gestartet wurde
  2. Aktuellsten Patch in die lokale AIP-Installation Slipstreamen (lokalen .msi Pfad beachten):

    Das Bild zeigt den CMD Befehl um das aktuelle Reader DC Update in die lokale AIP Installation zu slipstreamen
  3. Im lokalen AIP Ordner C:\adc1516 eine leere setup.ini Datei erzeugen und die AcroRdrDC1500720033_de_DE.msi in AcroRead.msi umbenennen (Letzteres ist nur eine kosmetische Anpassung).
  4. Mit dem Adobe Reader DC Customization Wizard die C:\adc1516\AcroRead.msi öffnen und beliebig anpassen. Änderungen wie vorgegeben als AcroRead.mst speichern.
    Das Bild zeigt den Adobe Reader DC Customization Wizard
  5. (Es müssten jetzt 3 Dateien und 4 Ordner in C:\adc1516\ existieren.) Den lokalen AIP-Ordner auf euer Deployment-Laufwerk verschieben.
    Das Bild zeigt die fertige Reader DC Deployment Installation im Deployment Share
  6. Deployen mit der .msi und .mst:

infos, infos, infos, via

Skript und Deploy

Das Deployment habe ich seit Reader 11 etwas verändert. Statt „complete-Ordner“ setze ich nun auf eine Versionsüberprüfung der Programm-exe. Das ist dynamischer und lässt sich differenzierter behandeln. Im Falle von Reader DC ist die Versionierung jedoch etwas seltsam. Beispielsweise lautet das aktuellste Update „AcroRdrDCUpd1501720053.msp“, nach der Installation wird die Dateiversion der .exe jedoch mit 15.17.20050 angegeben. Möglicherweise haben hier die Entwickler geschlampt.

Jedenfalls ist für die Verteilung mit Versionsüberprüfung noch ein Zwischenschritt notwendig:
Schaut im gerade erstellten lokalen AIP-Ordner, bzw. den schon aufs Deployment-Laufwerk kopierten Ordner die Eigenschaften Datei AcroRd32.exe an (liegt unter .\program files\Adobe\Acrobat Reader DC\Reader\) – im Tab Details steht die Versionsnummer, die ihr ins Skript und somit auch als Ordnernamen im Deployment-Laufwerk angeben müsst:
Das Bild zeigt die Dateieigenschaften von AcroRd32.exe und die Verweise auf das Skript und das Deploymentlaufwerk
Außerdem wird die VersionCompare.exe benötigt.

Hier nun das Script:
Code anzeigenDen Code könnt ihr bequem mit den Links/Rechts Pfeiltasten horizontal bewegen.

Alternatives Deployment

Auf der Seite 404techsupport.com habe ich einen noch einfacheren Deployment-Guide gesehen. Dort wird nur anhand des aktuellsten Installers gearbeitet – leider hatte ich noch nicht die Zeit dieses Deployment zu testen. Das hole ich sicher noch nach und Update dann hier.
Einzige Einschränkung: Das Deployment funktioniert nur über .exe, ist also nicht für das normale GPO Softwaredeployment via .msi geeignet.
Hier die Zusammenfassung, die der Autor mir per Mail zukommen ließ:

I download the latest executable from Adobe’s FTP site for Adobe Reader DC and deploy that with a script.
ftp://ftp.adobe.com/pub/adobe/reader/win/AcrobatDC/1501620039/

I created a transform using the Adobe Customization Wizard and the .msi version of the installer.
My script then installs the executable and uses the transform as a parameter.

(The script runs at startup assigned by Group Policy. It checks a network location for a „receipt“ for that computer to see if it has run before, and if not, executes the above command. I empty the „receipts“ folder after I download the new installer to the share so that the script executes on their next startup.)

If that works for your deployment options, it’s pretty straight-forward and avoids the annoying .msp patching (security patch or quarterly patch?). If you need an .msi to deploy, you are probably stuck with your steps of creating the admin install.

Das Windows-Feature „User Account Control“ (UAC), im deutschen Windows auch Benutzerkontensteuerung genannt, ist seit Windows Vista verbaut und sorgt für sichereres Rechtehandling beim Ausführen von Programmen. Im Hintergrund steckt außerdem ein Sandboxing-Prinzip, wodurch unterschiedliche Programme in unterschiedlichen Nutzer- und Rechtekontexten auf einem Desktop vereint zusammen arbeiten können.
Das Bild zeigt den Dialog der UAC beim Starten eines Programms mit Adminrechten
Die Benutzerkontensteuerung kann auf eine von vier unterschiedliche Stufen gestellt werden; eine davon entspricht der Deaktivierung, die anderen drei realisieren unterschiedliche Sicherheitsstufen.

Das Bild zeigt die Einstellungen der Benutzerkonstensteuerung (UAC)Im (vertrauensvollen) Unternehmenseinsatz ist eine auf Stufe 1 gestellte UAC sinnvoll, damit administrative Aufgaben auch direkt aus der Anmeldung eines eingeschränkten Nutzers per Eingabe von Admin-Daten möglich ist. Diese lässt sich beispielsweise mit Batch und Registry konfigurieren und im Windows AD verteilen, hier der Code:

Die unterschiedlichen Werte der einzelnen Registry-Eigenschaften könnt ihr hier übersichtlich nachlesen. Es gibt noch weitere Punkte der UAC, die über die Registry gesteuert werden können.
PS: Das Konzept hinter der UAC ist äußerst komplex und es macht u.U. Spaß, sich als fortgeschrittener Windows-Nutzer darin einzulesen.

via, via

Nur eine kurze Hilfe für den Fehlercode: 0xc004f014, der beispielsweise beim Upgrade von Windows 10 Home auf Professional auftreten kann. Vor allem dann, wenn ein neues Gerät mit installiertem Windows 10 Home ausgeliefert wird und dann ein Upgrade auf Pro erfolgen soll.

Lösung:

  1. Windows-Symbol -> Einstellungen -> Update und Sicherheit -> Aktivierung -> Product Key ändern
  2. den offiziellen Universal-Key für Windows 10 Pro eingeben:
    VK7JG-NPHTM-C97JM-9MPGT-3V66T
  3. Tasse Kaffe machen und warten bis die Installation durchgeführt und der PC wieder hochgefahren ist
  4. Startmenü -> Einstellungen -> Update und Sicherheit -> Aktivierung -> Product Key ändern und nun den erworbenen Pro-Key eingeben

via

Klingt seltsam, funktioniert aber. Warum auch immer Microsoft solche Standardsituationen nicht ordentlich behandeln kann…
Dieses Bild zeigt die erfolgreiche Aktivierung des Windows 10 Professional Produkt Keys

Einfache Windows-Admin-Frage: Welcher Mitarbeiter ist in diesem Moment und seit wann an welchem PC eingeloggt?

Einfache Antwort, kurz und knackig: Batch!
Mit Hilfe von PsLoggedOn, welches sich im selben Verzeichnis befinden muss wie das Skript:

via (leicht angepasst)

Das Bild zeigt das gekürzte PsLoggedOn-Script, welches zu allen eingeschalteten Domänencomputern die eingeloggten Nutzer anzeigt.

Der Befehl sc aus der Windows Konsole, mit dem sich die Windows Dienste steuern lassen, hat einen entscheidenden Nachteil: Es sind keine Wildcards möglich, der Dienstname muss exakt so angegeben sein, wie er im System registriert ist.
Somit sind sc stop und sc delete schnell am Ende ihrer Möglichkeiten.

Angenommen ich habe einen oder mehrere Dienste mit einem bestimmten Namenspattern, die angesprochen und verarbeitet werden müssen. Das Namenspattern könnte beispielsweise sein: „[beliebige Zeichenkette]Manager“. Weitere Platzhalter wie „[beliebig]win[beliebig]svc[beliebig]“ sind ebenfalls möglich.

Im Gegensatz zu sc bietet wmic service entsprechende Möglichkeiten, mit Wildcards und komplexeren Anfragen umzugehen:

Abfragen:

Das Bild zeigt den Windows Konsolenbefehl wmic service mit Paaternsuche

Starten/Stoppen/Löschen:

via, via, via

Auch dieser Artikel reiht sich in die Liste der Software-Batch-AD-Deployment-Guides ein.
Im Falle von HipChat wird der Artikel recht kurz, denn hier passiert nichts ungewöhnliches.

Vorbereitung

Das Bild zeigt das HipChat Deployment Verzeichnis mit seinen üblichen DateienDer aktuellste HipChat-Installer (für Windows) ist als .exe immer unter dieser URL verfügbar.
Anschließend wird wieder ein übliches Deployment-Verzeichnis auf einem für die PCs verfügbaren Netzlaufwerk erstellt: Installer, Installer-Batch, allowedPCs.txt und deniedPCs.txt (mehr Informationen zum Clientfilter hier). Im Standardfall (so auch in diesem Deployment-Script) wird die deniedPCs.txt benutzt, um einzelne Clients von der Verteilung auszuschließen. Die Textdatei muss dann Computernamen enthalten, einen pro Zeile.
Der HipChat-Installer muss folgendermaßen umbenannt werden: „HipChat_[Version].exe“ und der Versionsstring muss in das Deployment-Script in Zeile 11.

Deployment-Script

19.09.2016: Version 4.27.1.1658 getestet und verteilt.

Hinweis: Wer nicht nur ein Update sondern eine komplette Reinstallation von Hipchat im Netzwerk ausrollen will, kann mein angepasstes Script – hier als Download – nutzen. Die benötigte VersionCompare.exe erhaltet ihr hier.

Hier das Script für ein normales Update:

Und das war’s auch schon. Bei einem Update muss nur die neue .exe-Datei heruntergeladen und die Version in Zeile 11 angepasst werden.
Das Script kommt als Computer-Startscript in das GPO und schon startet die Verteilung:
Das Bild zeigt die Logausgaben des HipChat-Deployments
Das Bild zeigt das Deployment der 1648er Version anhand des allnew-Update-Scripts (siehe Hinweis und Download oben). Dabei wird an jedem PC, unabhängig der installierten Version (deswegen wird überall „Version 0.0“ deinstalliert), HipChat komplett deinstalliert und neu installiert. Beim Umstieg auf 1648 würde ich das empfehlen, weitere Update werden ich auch wieder mit dem normalen Script erledigen.