WSUS und Windows Server 2022

Natürlich kann man auch Windows Server 2022 über den WSUS mit Updates versorgen, damit das klappt hat Microsoft einen Test vorangestellt! Den im Gegensatz zu den Versionen von Windows Server 2003 bis einschließlich Windows Server 2019, gibt es für Windows Server 2022 keinen Eintrag unter Products im WSUS.

image

Mit dem Release von Windows Server 2022, hat Microsoft eine neue Benennung eingeführt.

Windows Server 2022 und auch Azure Stack HCI OS heißen nun, Microsoft Server operating system-21H2.

image

Warum nun operating system für Windows Server 2022 klein geschrieben wird, kann ich auch nicht sagen. Der Haken dort, bringt aber die Updates für Windows Server 2022 mit.

Aufmerksame Beobachter der Updates auf einem Windows Server 2022, können die neue Benennung aber auch dort erkennen.

image

Dort steht nämlich, in der Beschreibung des Updates ebenfalls Microsoft server operating system version 21H2.

Enjoy it, b!

WSUS Reporting auf dem Windows Server 2012R2

Für Windows Server 2012R2 gilt “Oldie but Goldie” und ich muss gestehen, dass ich davon noch einige in Betrieb habe. Die meisten davon als SBE (Windows Server mit der Small Business Essentials Rolle) und damit auch als WSUS tätig.

Hat man nun den WSUS am Laufen, will man bestimmt auch den einen oder anderen Report generieren. Dazu sind eine Reihe Schritte notwendig, die ich im Folgenden erläutern werde.

Ohne konfiguriertes Reporting erscheint die folgende Fehlermeldung (Klick mit der rechten Maustaste auf einen Computer / Status Report), die man durchaus als irreführend bezeichnen kann.

image

Versucht man den Link zu öffnen, erhält man ein freundliches “We’re sorry …”

image

Es geht aber letztendlich doch Smile

Voraussetzungen

Der WSUS muss laufen, dass ist klar und sinnvoller Weise mit der WID (Windows Internal Database) da inzwischen die SUSDB gerne mal die 10GB Grenze knackt und damit der SQL Server Express nicht mehr damit umgehen kann.

  • Installierter und funktionsfähiger WSUS mit WSUS Management MMC
  • SQL Server System CLR Type
  • Microsoft Report Viewer Runtime 2008

Darüber hinaus brauchen wir das .Net Framework 3.5, das entweder über den Servermanager oder PowerShell installiert werden kann.

image

# Anzeige ob das .Net Framework installiert ist oder nicht
Get-WindowsFeature -Name NET-Framework-Core
# Installation des .Net Framework
Install-WindowsFeature Net-Framework-Core -source \\network\share\sxs

Zusätzlich ist die SQL Server System CLR Type notwendig, die es unter dem folgenden Link zum Download gibt

http://go.microsoft.com/fwlink/?LinkID=239644&clcid=0x407

oder hier ausgewählt werden kann:

https://www.microsoft.com/en-us/download/details.aspx?id=56041

Wichtig ist, dass man die richtige SQLSysClrTypes.msi erwischt. Jene die bei mir funktioniert hat war die unten, mit einer Größe von ca. 2,4MB.

image

image

Nachdem Download wird die Runtime mit einem Doppelklick installiert. Jetzt fehlt nur noch die Microsoft Report Viewer Runtime 2008. Hier der Link, direkt bei Microsoft:

https://www.microsoft.com/en-us/download/confirmation.aspx?id=3203

Auch hier, einfach mit einem Doppelklick installieren und fertig ist das Reporting.

image

Damit haben wir ein funktionierendes Reporting des WSUS auf dem Windows Server 2012R2.

image

Enjoy it, b!

Auslesen der Seriennummer einer SSD mit PowerShell

Nachdem ich in ein Notebook eine neue SSD eingebaut hatte und das Gerät auch schon zuverlässig seinen Dienst tat, fiel mir auf das ich mir die Seriennummer nicht notiert hatte.

Wenn man nochmals, z.B. über die Fernwartung oder RDP Zugriff auf das Gerät erhält kann man die Seriennummer über PowerShell und das WMI auslesen.

# Auslesen der Seriennummer
Get-WmiObject -Class Win32_PhysicalMedia | Format-List Tag, Serialnumber

image

PowerShell braucht dazu nicht einmal mit administrativen Rechten gestartet werden.

Enjoy it, b!

WSUS zusammen mit der WID auf Laufwerk D

Fügt man den Windows Server Update Service (WSUS) auf einem Windows Server (2016 oder 2019) hinzu, dann werden weitere für die Rolle notwendigen Dienste und Funktionen hinzugefügt.

image

Darunter auch die Windows Internal Database (WID), als SQL-Server für die Bereitstellung der WSUS-Datenbank.

image

Die WID ist nur zur Verwendung von Windows eigenen Diensten, wie dem WSUS gedacht und nicht zur Bereitstellung von Datenbanken für externe Anwendungen.

Neben dieser Einschränkung hat die WID einen großen Vorteil: Im Gegensatz zur kostenlosen SQL Server Express Edition besitzt sie keine Begrenzung der maximalen Größe einer Datenbank auf 10GB (bis zum SQL Server 2008R2 war das Limit sogar nur 4GB).

Wird der WSUS über PowerShell hinzugefügt, erfolgt ebenfalls die Installation und Verwendung der WID.

image

Hier die Installation über PowerShell:

Install-WindowsFeature UpdateServices -IncludeManagementTools -Restart

Wird die WID mit dem WSUS verwendet, dann unterliegt dessen Datenbank, die SUSDB, nicht der 10GB Begrenzung wie das bei der Verwendung der SQL Server Express Edition der Fall ist.

Das ist ein Vorteil, da die SUSDB gerne mal die 10GB Grenze, vor allem wenn die Wartung vernachlässigt wird, übersteigt.

Der Haken an der Sache ist, dass die WID nach ihrer Installation auf dem Laufwerk C liegt und dort will ich sie nicht haben.

Umkonfigurieren der WID auf ein anderes Laufwerk

Die WID muss daher nicht auf Laufwerk C verbleiben, sondern kann auf ein anderes Laufwerk gelegt werden. Dazu sind die folgenden Tools und Schritte notwendig.

  • Nachdem der WSUS und damit die WID hinzugefügt wurde, aber noch bevor eine Konfiguration des WSUS erfolgt, sollte die WID auf ein passendes Laufwerk gelegt werden. Ich nehme dazu gerne Laufwerk D, dass ich in Form einer 256GB großen Platte bereitstelle
  • Damit die WID auf Laufwerk D verschoben werden kann, empfiehlt es sich das ohnehin für die Wartung der SUSDB hilfreiche SQL Server Management Studio zu installieren
  • Nicht notwendig, aber für mich immer praktisch ist Notepad++ oder Visual Studio Code als Editor auf dem Server

Für ein Verschieben der WID auf Laufwerk D, sind die folgenden Schritte notwendig.

Start der Windows Internal Database über die Services oder PowerShell

image

image

# Starten der WID
Start-Service -Name 'MSSQL$MICROSOFT##WID'
# Ändern des StartupTypes auf Automatic (delayed)
Set-Service -Name 'MSSQL$MICROSOFT##WID' -StartupType Automatic

Nun ist es möglich, mit dem folgenden String eine Verbindung zur WID über das SQL Server Management Studio (SSMS) herzustellen.

np:\\.\pipe\MICROSOFT##WID\tsql\query

Das SSMS muss dazu mit administrativen Rechten (rechte Maustaste Run as Administrator) gestartet worden sein.

image

Der weitere Ablauf ergibt sich aus den folgenden Schritten.

  • Stoppen der WID, durch das SSMS, PowerShell oder auch den Services Manager
  • Anlegen des Data und Log Verzeichnisses auf Laufwerk D (als Administrator)

image

  • Verschieben des Inhalts von C:\Windows\wid\data und C:\Windows\wid\log nach Laufwerk D:

image

# Verschieben von Data und Log auf Laufwerk D
move C:\Windows\wid\data\* 'D:\Microsoft SQL Server\WID\Data\' 
move C:\Windows\wid\log\* 'D:\Microsoft SQL Server\WID\Log\'
  • Ändern der folgenden drei Einträge in der Registry, für die Lokation der master. mdf, master.ldf und error.log Dateien

image

  • Der neue Pfad geht auf Laufwerk D mit den Unterverzeichnissen

image

  • Danach folgt die Berechtigung des WID Service Accounts auf die Verzeichnisse auf Laufwerk D … der Einfachheit nehme ich hier immer das WID-Verzeichnis selbst.

image

NT SERVICE\MSSQL$MICROSOFT##WID
  • Danach kann die WID gestartet werden und die Verbindung über das SSMS klappt auch ohne Probleme.

image

Die Installation des WSUS erfolgt über den Post-Configuration Task oder kann über den folgenden Aufruf erfolgen.

# wsusutil.exe liegt im Verzeichnis C:\Program Files\Update Services\Tools
.\wsusutil.exe postinstall SQL_INSTANCE_NAME="LOCALHOST" CONTENT_DIR=D:\WSUS

image

Enjoy it, b!

WSUS Offline Update 12

Mit dem Update auf die Version 12 von WSUS Offline, bekommt dieses für mich sehr nützliche Tool die Möglichkeit die Windows 10 Versionen besser zu steuern.

image

Dabei ist es sinnvoll, wenn gelegentlich das Zielverzeichnis (target directory) zu löschen und vollständig neu zu laden. Besonders dann, wenn man auf die eine oder andere Version von Windows 10 nicht mehr angewiesen ist.

Das Update selbst erfolgt automatisch, oder kann von der Homepage heruntergeladen werden.

image

Mit dem Update wurde auch der Support für Windows 7 und den Server 2008R2 entfernt. Hier ein Auszug aus dem Release Notes:

  • Support removed for Windows 7 and Server 2008(R2) since Microsoft discontinued support for it on January 14th, 2020
  • Support removed for Microsoft Security Essentials, Windows 7 Defender, Service Packs, Remote Desktop Client and Silverlight (download switches /includemsse and /excludesp, update switches /instmsse, /instmssl and /updatetsc)
  • Support removed for Windows 10 version 1703 since Microsoft discontinued support for it on October 8th, 2019
  • Split Windows 10 download into version specific parts

Enjoy it, b!

Microsoft SQL Server Login Probleme

Auf einem SQL Server 2012 Express (der eigentlich nur die Datenbank für den WSUS) bereit stellt, kam es zu dem Problem das ich mich nicht mehr über das SQL Server Management Studio anmelden konnte, oder das zwar die Anmeldung klappte aber der Zugriff auf die WSUS Datenbank (SUSDB) mit fehlenden Rechten verweigert wurde. Den SA konnte ich dazu auch nicht mehr aktivieren, obwohl ich Domain-Admin war.

Die Ursache des Problems

Das Problem lag darin, das während des Setups der Benutzer als Administrator zum SQL-Server hinzugefügt wurde. Irgendwann, wurde aber genau dieser Administrator gelöscht und wieder neu angelegt. Damit war der Zugriff auf den SQL Server nicht mehr möglich.

image

How to fix this

Die Lösung ist, wenn man sie kennt, relativ einfach. In einem ersten Schritt müssen wir herausfinden wie die Instanz des SQL Servers heißt. Das geht am einfachsten mit net start, im Anschluss wird die Instanz mit net stop gestoppt. Am einfachsten ist es alle Schritte in einer PowerShell oder Command Line mit erhöhten Rechten aus zu führen. Die Abfrage an sich geht zwar auch ohne, aber zum Stopp sind diese Rechte notwendig.

net start
...
SQL Server (MSSQLSERVER)
...

Stopp der SQL Server Instanz.

net stop "SQL Server (MSSQLSERVER)"

Der ganze Ablauf sieht dann wie folgt aus.

image

Sollte bei der Abfrage der SQL Server Agent auftauchen, so muss dieser ebenfalls gestoppt und deaktiviert werden! Wie hier, im Bild oben zu sehen ist, war das aber nicht notwendig.

Nun wird die SQL Server Instanz mit dem optionalen Schalter /m im Single-User Mode gestartet. Nun kann lediglich EIN einziger Benutzer die Verbindung zur Datenbank aufbauen (was auch die Grund ist den Agenten zu stoppen, startet dieser nämlich wieder zusammen mit dem SQL Server, dann ist die eine Verbindung belegt). Der Start im Singe-User Mode ermöglicht einem Mitglied der lokalen Administratoren die Verbindung als SYSADMIN auf zu bauen, damit haben wir die notwendigen Rechte um unser Problem zu fixen.

Der Start der SQL Server Instanz funktioniert analog zum Stopp, nur das dazu der Parameter /m verwendet wird.

net start "SQL Server (MSSQLSERVER)" /m

image

Nachdem die SQL Server Instanz erfolgreich gestartet wurde, kann eine Verbindung mit dem SQL Server Management Studio hergestellt werden und da wir mit SYSADMIN Rechten unterwegs sind, das Problem mit dem Login korrigiert werden.

Das SQL Server Management Studio starte ich in diesem Fall ebenfalls mit erhöhten Rechten (rechte Maustaste, …).

Nun wird unter Security/Logins der Benutzer (DOMAIN\USER) aus dem AD hinzugefügt und mit den folgenden Server Rollen ausgestattet:

  • public (Default)
  • sysadmin

image

Zusätzlich habe ich auch den SA mit einem schweren Passwort versehen und aktiviert.

Nach dem beenden des SQL Server Management Studios, muss die SQL Server Instanz gestoppt und wieder normal gestartet werden.

net stop "SQL Server (MSSQLSERVER)"
...
net start "SQL Server (MSSQLSERVER)"

image

Nach dem Neustart fehlte lediglich die Zuweisung des wieder angelegten Benutzers als DBO zur Datenbank. Der nun folgende Befehl wird im SQL Server Management Studio ausgeführt und ordnet den Benutzer zu.

ALTER AUTHORIZATION ON DATABASE::SUSDB TO [DOMAIN\USER];

image

Nun ist der volle Zugriff auf die SUSDB wieder vorhanden und ich kann sie endlich kleiner machen.

Enjoy it, b!

Windows Versions aus dem WSUS

Nachdem Microsoft Build 1809 für Windows 10 bereitgestellt hat, lässt sich über den WSUS (natürlich nur wenn alle PCs und Server darin gemanaged sind) recht einfach herausfinden welche PCs den nun welchen Build installiert haben.

Dazu braucht man nur in der Statusleiste der jeweiligen WSUS-Gruppe (hier Update Services Computers) die Version (Grün) einzublenden.

image

Das erfolgt durch einen Rechtsklick auf die Leiste (Orange) und der Auswahl von Version.

image

Nun sehen wir, dass immerhin drei PCs schon Build 1809 installiert haben. Darüber hinaus dazu noch einen Uralt-Fehler des WSUS, nämlich die Unfähigkeit den Microsoft Hyper-V Server korrekt an zu zeigen:

Windows (Version 10.0) = Microsoft Hyper-V Server 2016

Enjoy it, b!

Goodmorning WSUS

Hier mal wieder ein Beitrag zu meiner Lieblingstechnologie, dem WSUS.

Prinzipiell ermöglicht der WSUS die Nutzung einer Vielzahl von SQL Server Editionen, besonders häufig treffe ich auf die Installation des WSUS in Verbindung mit der SQL Server Express Edition. Diese Edition verwende ich (nicht zuletzt, weil sie nichts kostet) ebenfalls sehr gerne auch für andere Anwendungen. Allerdings muss man hier auf eine Kleinigkeit achten, eine Datenbank darf nicht größer als 10GB werden und damit kommen wir wieder zum WSUS. Die 10GB Grenze sprengt der WSUS bei einer Reihe meiner Installationen, bzw. bewegt sich knapp darüber. Nun stellt sich die Frage: Wie bekomme ich die WSUS Datenbank (die übrigens immer noch SUSDB heißt) wieder klein, also unter die 10GB Grenze.

Die Überschreitung dieser, kündigt sich übrigens auch im Application Eventlog des Servers an.

image

Ist die WSUS Datenbank größer als 10GB geworden, haben wir zwei Möglichkeiten. Wechsel der Datenbank Editon im Hintergrund (SQL Server Standard zum Beispiel) was aber mit Kosten verbunden ist oder versuchen die WSUS Datenbank zu verkleinern.

Verkleinern der WSUS Datenbank

Dazu sind drei Schritte (mit möglichen Wiederholungen) notwendig.

  1. Entfernen von nicht mehr notwendigen Updates, etc.
  2. Ein auf T-SQL basierender WSUS Maintenance Task, https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61
  3. Abschließender „Shrink“ der WSUS Datenbank

Klingt eigentlich ganz einfach und das ist es eigentlich auch Winking smile 

Schritt 1 – Entfernen von nicht mehr notwendigen Updates …

Für das Entfernen von nicht mehr notwendigen Updates hat Microsoft den Server Cleanup Wizard in den WSUS integriert.

image

Der funktioniert auch gelegentlich, insofern man nicht gleiche alle Optionen auf einmal wählt. In letzter Zeit hatte ich häufig den Fall, dass sich der WSUS im Hintergrund beendet oder der Wizard selbst die gewählten Aufgaben nicht vollständig zu Ende bringen konnte. Einfacher und deshalb von mir bevorzugt finde ich das Durchführen der Bereinigung mit PowerShell.

Invoke-WsusServerCleanup -DeclineSupersededUpdates -DeclineExpiredUpdates -CleanupObsoleteComputers -CleanupObsoleteUpdates

Der Aufruf läuft zwar auch nicht auf Anhieb durch, kann aber im Falle einer Terminierung problemlos nochmals gestartet werden. Ich musste das auf einem Server 9x wiederholen, wichtig dabei ist das eine Bereinigung stattfinden nur leider nicht fertig wird. Ein wiederholter Aufruf (Pfeil Oben-Taste in der PowerShell Konsole) macht da weiter wo der Abbruch stattfand und kommt nach einigen Durchläufen zu einem positiven Ergebnis.

Der folgende Screenshot zeigt die letzten beiden Timeouts des Befehls (#7 und #8) und letztendlich die erfolgreiche Bereinigung (Obsolete Updates Deleted: 103).

image

Im nächsten Schritt müssen wir die SQL Datenbank des WSUS (SUSDB) einem Maintenance Task unterziehen.

Schritt 2 – WSUS Database Maintenance Task

Dafür verwenden wir in Script aus der Technet Gallery …

/******************************************************************************
This sample T-SQL script performs basic maintenance tasks on SUSDB
1. Identifies indexes that are fragmented and defragments them. For certain
   tables, a fill-factor is set in order to improve insert performance.
   Based on MSDN sample at http://msdn2.microsoft.com/en-us/library/ms188917.aspx
   and tailored for SUSDB requirements
2. Updates potentially out-of-date table statistics.
******************************************************************************/

USE SUSDB;
GO
SET NOCOUNT ON;

-- Rebuild or reorganize indexes based on their fragmentation levels
DECLARE @work_to_do TABLE (
    objectid int
    , indexid int
    , pagedensity float
    , fragmentation float
    , numrows int
)

DECLARE @objectid int;
DECLARE @indexid int;
DECLARE @schemaname nvarchar(130); 
DECLARE @objectname nvarchar(130); 
DECLARE @indexname nvarchar(130); 
DECLARE @numrows int
DECLARE @density float;
DECLARE @fragmentation float;
DECLARE @command nvarchar(4000); 
DECLARE @fillfactorset bit
DECLARE @numpages int

-- Select indexes that need to be defragmented based on the following
-- * Page density is low
-- * External fragmentation is high in relation to index size
PRINT 'Estimating fragmentation: Begin. ' + convert(nvarchar, getdate(), 121) 
INSERT @work_to_do
SELECT
    f.object_id
    , index_id
    , avg_page_space_used_in_percent
    , avg_fragmentation_in_percent
    , record_count
FROM 
    sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'SAMPLED') AS f
WHERE
    (f.avg_page_space_used_in_percent < 85.0 and f.avg_page_space_used_in_percent/100.0 * page_count < page_count - 1)
    or (f.page_count > 50 and f.avg_fragmentation_in_percent > 15.0)
    or (f.page_count > 10 and f.avg_fragmentation_in_percent > 80.0)

PRINT 'Number of indexes to rebuild: ' + cast(@@ROWCOUNT as nvarchar(20))

PRINT 'Estimating fragmentation: End. ' + convert(nvarchar, getdate(), 121)

SELECT @numpages = sum(ps.used_page_count)
FROM
    @work_to_do AS fi
    INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id
    INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id

-- Declare the cursor for the list of indexes to be processed.
DECLARE curIndexes CURSOR FOR SELECT * FROM @work_to_do

-- Open the cursor.
OPEN curIndexes

-- Loop through the indexes
WHILE (1=1)
BEGIN
    FETCH NEXT FROM curIndexes
    INTO @objectid, @indexid, @density, @fragmentation, @numrows;
    IF @@FETCH_STATUS < 0 BREAK;

    SELECT 
        @objectname = QUOTENAME(o.name)
        , @schemaname = QUOTENAME(s.name)
    FROM 
        sys.objects AS o
        INNER JOIN sys.schemas as s ON s.schema_id = o.schema_id
    WHERE 
        o.object_id = @objectid;

    SELECT 
        @indexname = QUOTENAME(name)
        , @fillfactorset = CASE fill_factor WHEN 0 THEN 0 ELSE 1 END
    FROM 
        sys.indexes
    WHERE
        object_id = @objectid AND index_id = @indexid;

    IF ((@density BETWEEN 75.0 AND 85.0) AND @fillfactorset = 1) OR (@fragmentation < 30.0)
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';
    ELSE IF @numrows >= 5000 AND @fillfactorset = 0
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD WITH (FILLFACTOR = 90)';
    ELSE
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD';
    PRINT convert(nvarchar, getdate(), 121) + N' Executing: ' + @command;
    EXEC (@command);
    PRINT convert(nvarchar, getdate(), 121) + N' Done.';
END

-- Close and deallocate the cursor.
CLOSE curIndexes;
DEALLOCATE curIndexes;


IF EXISTS (SELECT * FROM @work_to_do)
BEGIN
    PRINT 'Estimated number of pages in fragmented indexes: ' + cast(@numpages as nvarchar(20))
    SELECT @numpages = @numpages - sum(ps.used_page_count)
    FROM
        @work_to_do AS fi
        INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id
        INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id

    PRINT 'Estimated number of pages freed: ' + cast(@numpages as nvarchar(20))
END
GO


--Update all statistics
PRINT 'Updating all statistics.' + convert(nvarchar, getdate(), 121) 
EXEC sp_updatestats
PRINT 'Done updating statistics.' + convert(nvarchar, getdate(), 121) 
GO

… das über das SQL Server Management Studio ausgeführt wird.

image

Einfach reinkopieren und (New Query) und mit Execute ausführen, dass Script selektiert die SUSDB gleich zu Anfang und beginnt die Indizes neu zu organisieren.

Nun kann die SUSDB verkleinert (Shrink) werden.

Schritt 3 – Verkleinern (Shrink) der SUSDB

Dazu wählen wir im Object Explorer des Microsoft SQL Server Management Studios die SUSDB aus.

image

Danach mit der rechten Maustaste Tasks / Shrink / Database und klicken hier auf OK.

Wie im Screenshot zu sehen ist, hat die Datenbank auf einmal 64% freien Platz … was doch ganz ordentlich ist.

image

Wie alles beim WSUS dauert das verkleinern seine Zeit, danach haben wir aber das Problem für die nächste Zeit behoben.

Vorher:

08.05.2018  05:56    10.652.549.120 SUSDB.mdf

Nachher:

08.05.2018  06:16     3.385.720.832 SUSDB.mdf

Enjoy it, b!

WSUS … The request failed with HTTP status 503

Ich administriere den WSUS sehr gerne über PowerShell, da dass ein hohes Maß an Automation zulässt.

Beim verschieben von Computern in eine von WSUS Gruppe habe ich die folgende Fehlermeldung erhalten.

image

Das Verschieben erfolgt übrigens über den folgenden PowerShell Befehl.

Get-WsusComputer | Add-WsusComputer -TargetGroupName "Update Services Computers"

Diese Fehlermeldung steckt nach meiner Erfahrung auch hinter einer Vielzahl von Problemen wenn die WSUS MMC sich nicht zum WSUS Server verbinden kann. Das Drücken der Reset Server Option bringt hier auch nichts, da das eigentliche Problem in einem gestoppten WsusPool im IIS liegt.

image Ein Start des Application Pools reicht aus um sowohl den PowerShell Befehl als auch die WSUS MMC wieder funktionsfähig zu bekommen.

Das funktioniert sowohl beim WSUS in Windows Server 2012 R2 als auch unter Windows Server 2016.

Enjoy it, b!

WSUS Post Installation Task schlägt fehl

Es wird mal wieder Zeit etwas über den WSUS zu schreiben. Fast alle meiner Small Business Umgebungen laufen inzwischen oder immer noch (kommt drauf an wie man das sehen möchte) auf Windows Server 2012R2 und bekommen damit auch die WSUS Rolle installiert. Früher ist der WSUS mal ein problemlos funktionierendes und wartungsarmes System gewesen, doch zumindest bei mir hat sich diese Rolle des Windows Servers seit dem R2 Release zu einem Problembären entwickelt.

Im Rahmen einer Neuinstallation der WSUS-Rolle (vorher deinstalliert und alles bereinigt) wollte der WSUS Post Installation Task (die Vorbereitung des WSUS nach der Installation) nicht durchlaufen. Der Task brach mit einem Fehler ab und dem Verweis auf das Logfile, welches dazu noch leer war.

C:\Users\administrator\AppData\Local\Temp\tmp9D23.tmp

Nach einigem hin- und her (WSUS Rolle wieder deinstalliert, Verzeichnisse und Datenbank gelöscht, …) bin ich immer wieder in den gleichen Fehler gelaufen.

Neben dem Start des Post Installation Tasks über den Wizard, kann dieser auch über die Kommandozeile initiiert werden. Ein Wechsel in das Programm-Verzeichnis des WSUS zeigte mir aber, dass bei der Installation der Rolle das Tools-Verzeichnis nicht angelegt wurde.

C:\Program Files\Update Services\Tools\wsusutil.exe

Mit dem Fehlen der Tools war auch nicht die WSUSUTIL.EXE vorhanden, welche ebenfalls vom Wizard im Servermanager verwendet wird. Damit war mir auch klar, wieso das Logfile leer war. Das Tools-Verzeichnis habe ich darauf hin, von einer anderen WSUS-Installation kopiert und auf dem Server angelegt, bzw. entpackt.
Danach funktionierte der Aufruf problemlos und der WSUS startete mit dem Dialog zur Konfiguration.

cd "C:\Program Files\Update Services\Tools"

.\wsusutil.exe postinstall SQL_INSTANCE_NAME="localhost" CONTENT_DIR="D:\WSUS"

Enjoy it, b!