Problem
Nach einem Restore eines DCs aus einem Snapshot oder ähnlichen Wiederherstellungsvorgängen wird im Eventlog folgender Eintrag protokolliert:
Ereignistyp: Fehler
Ereignis Quelle: NTDS Allgemein
Ereigniskategorie: Steuerung
Ereignis-ID: 2103
Beschreibung: Die Active Directory-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt. Active Directory können Benutzer anmelden, während das Problem weiterhin besteht. Als Ergebnis wurde der Netlogon-Dienst angehalten. Benutzer Aktion Siehe vorherige Ereignisprotokolle Einzelheiten. Weitere Informationen finden Sie im Hilfe- und Supportcenter unter http://support.microsoft.com.
Wenn man eine manuelle Replikation unter AD Standort und Dienste durchführt erhält man die Fehlermeldung:
Der Quellserver nimmt keine Replikationsanforderung entgegen
Lösung
Durch die "unspupportete" Wiederherstellung der AD Datenbank wird diese als "not writeable" gesetzt und es ist keine Replikation möglich. Mit folgendem Workaround kann man die Replikation wieder ans laufen bekommen...
• HKLM\System\CurrentControlSet\Services\NTDS\Parameters
?“Dsa Not Writable” von 4 auf 0 setzen
?REG_DWORD “Ignore USN Rollback” anlegen und auf 0 setzen (Damit wird ein erneutes Auftreten des Fehlers unterdrückt)
WSUS 3.0 Migration von Windows Server 2003 auf Windows Server 2008 (R2)
Auf dem alten Server
1.) WSUS API Samples and Tools downloaden: WSUS API Samples and Tools (Sie finden die Installationsdatei auch am Ende des Artikels)
2.) In den Ordner C:\Program Files\Update Services 3.0 API Samples and Tools\WsusMigrate\WsusMigrationExport wechseln
3.) Ausführen von wsusmigrationexport.exe settings.xml
4.) Die MSDE Instanz stoppen, Update Dienst stoppen
5.) WSUS Verzeichnisse sichern (z.B.: NTBACKUP) Achtung: Nur Windows Server 2008 unterstuetzt das separat herunterzuladende Windows NT Restore Utility (NTBACKUP read only). Windows Server 2008 R2 unterstuetzt das nicht mehr
Auf dem neuen Server
1.) WSUS 3.0 SP2 ueber den Servermanager installieren (Rolle hinzufügen) (inkl. WMDE)
2.) Erstkonfigurationsassistent nicht ausführen
3.) WSUS Dienst und MSDE Dienst stoppen
4.) WSUS Verzeichnisse zurückkopieren (inkl. WSUS DB)
5.) In den Ordner C:\Program Files\Update Services 3.0 API Samples and Tools\WsusMigrate\WsusMigrationImport wechseln
6.) Ausführen von wsusmigrationimport.exe settings.xml All None
Danach ist die alte WSUS Konfiguration inkl. aller Updates verfügbar!
ACHTUNG: Anschliessend in den GPO-Einstellungen noch den Pfad zum WSUS Server anpassen!
Hier gibt es den "Hardcore-Button" Force Patching. Damit wird die Verbindung erzwungen!
Folgende Vorgehensweise hat bis jetzt immer zum Erfolg geführt:
- Reset Client ID
Erstellt eine neue WSUS-Client-ID für den Rechner und schreibt diese unter HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate
- Force Patching
Hier werden ein paar Registry-Keys gesetzt. Dadurch wird die Kommunikation zwischen WSUS-Server und Client erzwungen.
- Report now
Hiermit wird der aktuelle Statusbericht an den Server gesendet – z.B. installierte Patches, OS etc.
Die heruntergeladenen Updatefiles nehmen beim WSUS schnell ein paar Gigabytes mehr in Anspruch als ursprünglich eingeplant.
Wie verschiebt man nun die Content-Datenbank des WSUS 3 Servers auf ein neues, größeres Laufwerk?
Lösung:
Dies ist mit dem WSUSUTIL möglich:
Neben anderen Optionen zur Wartung des WSUS-Servers bietet das Utility WSUSUTIL.EXE (im Pfad %drive%\Program Files\Update Services\Tools) den Parameter movecontent.
Mit WSUSUTIL movecontent [Pfad zum Zielverzeichniss] [logfile] werden sämtliche heruntergeladenen Updates auf das neue Laufwerk verschoben, und der WSUS-Server für den neuen Contentpfad konfiguriert.
Das Logfile nach erfolgter Aktion sollte so aussehen:
2007-05-11T12:53:43 Successfully stopped WsusService.
2007-05-11T12:53:43 Beginning content file location change to e:\wsus
2007-05-11T12:57:58 Successfully copied content files.
2007-05-11T12:57:58 Successfully copied application files.
2007-05-11T12:57:59 Successfully changed WUS configuration.
2007-05-11T12:58:00 Successfully changed IIS virtual directory path.
2007-05-11T12:58:00 Successfully removed existing local content network shares.
2007-05-11T12:58:00 Successfully created local content network shares.
2007-05-11T12:58:00 Successfully changed registry value for content store directory.
2007-05-11T12:58:00 Successfully changed content file location.
2007-05-11T12:58:02 Successfully started WsusService.
2007-05-11T12:58:02 Content integrity check and repair...
2007-05-11T12:58:02 Initiated content integrity check and repair.
Es lassen sich keine Seiten mehr vom IIS anzeigen. Telnet auf Port 80 ist aber erfolgreich!
Lösung:
Als erstes sollte die Httperr.log im Verzeichnis c:\windows\system32\logfiles\httperr und der KB-Artikel KB934878 von Microsoft "Users receive a "The page cannot be displayed" error message, and "Connections_refused" entries are logged in the Httperr.log file on a server that is running Windows Server 2003, Exchange 2003, and IIS 6.0"abgearbeitet werden.
Manchmal ist man leider gezwungen einen Windows Server 2003 mit IIS und ASP aufzusetzen.
Fast immer hat man aber das Problem, dass ASP.NET v2.0.50727 im Web Services Extension Manager im IIS Manager auftaucht.
Vorallem dann, wenn .Net bereits installiert ist und der IIS erste nachinstalliert wird.
Lösung:
Der einfachste Weg ist es, das .NET Framework neuzuinstallieren. Doch das ist sehr unsauber und wird eindeutig nicht empfohlen. Die schnellste und meiner Meinung nach beste Möglichkeit ist es, eine CMD zu öffnen und in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 bzw C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727 (für 64bit Systeme) zu wechseln. Dort führt man einfach den folgenden Befehl aus: aspnet_regiis.exe – i
Danach taucht ASP.NET v2.0.50727 im Web Services Extension Manager auf und kann einfach aktiviert werden.
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”