WSUS cleanup – best solution

Nicht nur, um den Plattenplatz eines WSUS-Servers regelmäßig zu bereinigen, sondern gleichzeitig auch die SQL-Datenbank hübsch sauber und in reaktionsfreudigem Zustand zu behalten, empfiehlt sich über die grafisch erreichbaren Wartungstasks hinaus der Einsatz eines Wartungsscripts, das als geplanter Task auf dem Server regelmäßig ausgeführt wird.
Zudem kann es ohne regelmäßigen Aufräumtask im WSUS schon mal passieren, dass in der GUI bei der Anzeige aller Updates keine Rückmeldung mehr erfolgt oder die schon längst abgelehnten Treiber noch immer Speicherplatz verbrauchen.

Noch vor ein paar Jahren war das mit etwas Handarbeit verbunden. Ich hatte bis dorthin mit einem anderen Script gearbeitet.  Mittlerweile habe ich aber eine wesentlich bessere und zuverlässigere Lösung gefunden – nicht ganz ohne Grund spricht der Entwickler vom „last WSUS script you will ever need“ –
Adam Marshalls Clean-WSUS.

Windows 10-Clients, Windows Update und Fehler 0x8024000d bei WSUS-Nutzung

Mal wieder Probleme. Diesmal brachten Clients mit 1703 und auch 1709 beim Suchen nach Updates auf dem WSUS-Server den Fehler 0x8024000d.

Im Windowsupdate-Log waren entscheidend diese 3 Zeilen, die mich der Lösung näherbrachten:

2017.11.23 19:34:10.4010252 3540 5556 Agent Failed to parse extended metadata for 6D629889-8D3F-4F26-929A-E08B8F363F49.100, hr=8024000d
2017.11.23 19:34:10.4012989 3540 5556 Agent *FAILED* [8024000D] Failed to get extended update infos
2017.11.23 19:34:10.4499203 3540 5556 Agent Exit code = 0x8024000D

„Windows 10-Clients, Windows Update und Fehler 0x8024000d bei WSUS-Nutzung“ weiterlesen

Windows Server 2016 LTSC versus Server 1709

Windows 10 im Unternehmen mit gutem Admin-Gewissen einzusetzen, ist noch mal ein extra Thema. Hier seien nur die Begriffe „Enterprise-Edition“ und ggfs. LTSB bzw. LTSC zu erwähnen.

Aber auch bei den Server-Betriebssystemen wandelt es sich nun. Wo man bislang bis zum Server 2012 R2 noch das alte Schema hatte und sich lediglich alle 2-3 Jahre mal mit einer neuen Betriebssystem-Version beschäftigen musste, gilt nun bald auch hier „Windows as a service“.

Man kann nun entscheiden, auf das bisherige Modell als LTSC (alle 2-3 Jahre neue Version, 5 Jahre Support und Updates + 5 Jahre extended Support)  zu setzen oder die innovativen unter uns, die mit cloudbasierten Technologien arbeitend, immer „on the leading edge“ sein wollen oder müssen, die 1709 zu benutzen. Letztere gibt’s aber nur in der Core- oder Nano-Version.
Viel mehr Infos darüber gibt’s hier: https://docs.microsoft.com/en-us/windows-server/get-started/semi-annual-channel-overview

Firefox-Einstellungen im Unternehmen verteilen

Schon vor einiger Zeit wurde ich damit mal konfrontiert und hatte keine so richtig saubere Lösung parat. Geschweige denn eine genaue Ahnung von der Reihenfolge und über welche Settings-Dateien die zahlreichen Einstellungen des Firefox beim Start importiert und gelesen werden. Geschweige denn wie Einstellungen so mitgegeben werden können, dass sie für den Benutzer unveränderbar sind.

Zuletzt war ich auf der Suche nach der elegantesten Möglichkeit, das Stammzertifikat einer internen Zertifizierungsstelle auf die Firefox-Installationen im Unternehmen zu verteilen. Bei meinen Recherchen wurde ich hier auf ein recht neues Feature aufmerksam (ab FF 49), dass – einmal aktiviert – den Windows-Zertifikatsspeicher fragt, wenn eine SSL-verschlüsselte Seite „Firefox-Einstellungen im Unternehmen verteilen“ weiterlesen

Windows 10 1607 und WSUS

Yay, noch beim 1511er anniversary update für Windows 10 war einer der kursierenden Tipps, Firmen-Rechner per GPO mit Aktivierung der Einstellung „Feature-Updates zurückstellen“ oder „defer upgrades“ in den Current branch for business zu bringen.

Diese Policy wurde allerdings mit den neuen Policy-Templates für das 1607er-Update durch eine andere Einstellung ersetzt. Wenn man eine dieser beiden Einstellungen aktiviert hat und gleichzeitig „Keine Verbindung mit Windows Update-Internetadressen herstellen“ verwendet, erhält man beim Versuch nach Updates zu suchen, den Fehler 0x8024500c. „Windows 10 1607 und WSUS“ weiterlesen

Windows 10 und Family Safety

Ganz nach dem Motto Schema unfertiger Komponenten läuft Family Safety, wenn man es unter Windows 8 für seine Kinder konfiguriert hatte, nicht mehr unter Windows 10 weiter, da die Benutzerkonten der Kids nun als Microsoft-Konten konfiguriert werden müssen…

Das allerdings hat bei mir anfangs überhaupt nicht gut funktioniert, denn nach dem Anlegen der Konten kamen die invitation-Mails nicht an und ich musste mehrere Male das komplette Prozedere wiederholen. Auf der Family Safety-Seite von Microsoft kann man dann allerdings auch nur bedingt sinnvolle Einschränkungen – z.B. beim Zeitfenster – vornehmen. Da fehlt noch einiges, würde ich sagen…

Ich kann mir nicht vorstellen, dass sich damit jemand Ungeübtes auseinandersetzen soll.

Enterprise-CA auf einen anderen Server umziehen

Wenn ein Server unter Windows 2003 SP2, der gleichzeitig DC ist und die Enterprise-Zertifizierungsstelle führt, abgelöst und durch einen 2008 R2-Server ersetzt werden soll, kann man schon graue Haare (also noch mehr graue Haare, als sowieso schon) bekommen…
Ein verbreiteter Microsoft-Artikel beschreibt den Umzug unter der Empfehlung, dass der Zielservername und auch das Betriebssystem identisch sein sollten. Außerdem muss die Plattform identisch sein. Tja, da spätestens beißt sich die Katze in den Schwanz, denn ich kann den alten Server nicht einfach ausschalten, da er u.a. noch DC ist und die DC-Dienste bekomme ich nicht runter, weil die Zertifikatsdienste drauf sind. 🙂
Wie dem auch sei – nach längerem Suchen hier ein Guide, der den Umzug der CA von 2003 SP2 nach 2008 R2 unter Berücksichtigung unterschiedlicher Computernamen beschreibt. Man sollte allerdings locker 4-6 Stunden für das Durcharbeiten einplanen…

Active Directory Certificate Services Migration Guide.

Edit im Januar 2017: Hier der Nachfolge-Guide zur Migration der CA von einem DC mit 2008 R2 nach 2012 R2:

Active Directory Certificate Services Migration Guide for Windows Server 2012 R2

Deploying Adobe Reader through GPO

Update 2:

Es benötigt kein Entpacken mehr der .exe – mittlerweile gibt es die .msi-Files auch schon direkt von Adobe. Hier ist ein aktueller Howto.

Ergänzend dazu nur:

Bei der Verteilung über eine GPO muss in den erweiterten Optionen des Paketes angehakt werden, dass auch diese 32-Bit-Anwendung auf 64-Bit-Maschinen installiert werden soll.

Ursprünglicher Artikel:

  1. AdobeReader als .exe herunterladen.
  2. Die „Nosso“-komprimierte .exe entpacken lt. Deployment-Guide:

    AdbeRdr_de_DE.exe -nos_o“entpackt“ -nos_ne

  3. Das entpackte .msi aus dem o.g. Verzeichnis „entpackt“ mit dem Adobe Customization Wizard anpassen, speichern und das .mst danebenlegen.
  4. Das Ganze via Softwareverteilungs-GPO verteilen.

Einzelne Updates (z.B. Adobe Reader 9.3.1 für 9.3) werden als .msp bereitgestellt und können mittels Befehlszeile
msiexec /a AcroRead.msi /p AdbeRdrUpd931_all_incr.msp
in die ursprüngliche Installation integriert werden (slipstream).

UPDATE Januar ’15:
Beim Adobe Reader 11.0.0.10 gibt es bei obiger Befehlszeile ein Problem bei der Installation (fehlende Datei). Hier ist die Empfehlung, zwei Zeilen draus zu machen:

msiexec /a AcroRead.msi
msiexec /p <Acroread.msi_aus_a> AdbeRedUpd931_all_inc.msp

Anschließend ist der entpackte Inhalt PLUS der geslipstreamten .msi und des .mst’s in den zentralen Installationsordner zu kopieren.

Der sollte dann etwa so aussehen:

\Common
\CommonAppData
\program files
\Win
\Windows
\AdbeRdr110010_de_DE.msi
\AdbeRdr110010_de_DE.mst
\Setup.ini

 

WINS unter Server 2008-AD

LDAP://Yusufs.Directory.Blog/ – DNS vs. WINS.

Tja, trotz DNS und der Tatsache, dass die meisten Komponenten nun schon DNS verwenden, sollte man offenbar weiterhin das Feature WINS-Server in einem 2008-AD verwenden.

Also – kurz Feature hinzugefügt, Replikationspartner eingetragen, Eigenschaften des Netzwerkadapters für alle statischen Geräte (Server, …) angepasst, DHCP-Bereichsoption konfiguriert – fertig.