NTFRS – Fehler 13561 JRNL_WRAP_ERROR

ntfrs_event13561

Dieser Fehler kann mittels Übergabe eines Parameters an den NTFRS-Dämon behoben werden. Dazu muss in der Registry folgender Wert hinterlegt werden:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NtFrs\Parameters

ntfrs_registry_wrap_journal_restore

Hier wird ein DWORD mit dem Namen Enable Journal Wrap Automatic Restore angelegt. Der Wert 1 bedeutet, dass der Restore ausgeführt werden soll, der Wert 0 das Gegenteil.

Nach Änderung des Wertes muss der Dateireplikationsdienst neu gestartet werden:

net stop ntfrs && net start ntfrs

 

Exchange Management-Tools deinstallieren

Heute musste ich feststellen, dass die Exchange-Management-Tools nicht auf dem herkömmlichen weg über Systemsteuerung – Software deinstalliert werden können. Man kann das Exchange-Setup auf diesem Wege aufrufen, aber die Deinstallationsroutine besteht darauf, dass Serverrollen zur Entfernung markiert werden.

Nimmt man den Weg über die CMD glückt die Deinstallation allerdings:

C:\Program Files\Microsoft\Exchange Server\Bin>Setup.com /m:uninstall /roles:MT

Willkommen bei der unbeaufsichtigten Installation von Microsoft Exchange Server
2007

Das Exchange-Setup wird vorbereitet.

Die folgenden Serverfunktionen werden entfernt
    ManagementTools

Die Voraussetzungen für Microsoft Exchange Server werden überprüft


Konfigurieren von Microsoft Exchange Server

    Exchange ManagementTools         ......................... ABGESCHLOSSEN
    Die Exchange-Dateien werden entfernt.
    Status                           ......................... ABGESCHLOSSEN

Der Installationsvorgang von Microsoft Exchange Server wurde erfolgreich abgesch
lossen.

C:\Program Files\Microsoft\Exchange Server\Bin>

Server 2008 Terminal-Server und Outlook 2013

Installiert man auf einem Server 2008 (R2) Office 2013 inklusive Outlook, dann durchläuft Outlook bei jedem Starten folgenden Installer – Microsoft Office 64-Bit Components 2013:

windows2008_ts_outlook_64_components

Hier sind verletzte Abhängigkeiten das Problem. Es fehlt der Rollendienst „Windows Search“ der Dateidienste-Rolle. Dieser kann über den Server-Manager hinzugefügt werden:

windows_search_rollendienst

Es muss nicht zwangsläufig eines der Laufwerke zur Indizierung angegeben werden:

windows_search_rollendienst-2

WSUS-Client: Fehler 800B0001

Auf älteren WSUS-Servern werden Clients mit den Betriebssystemen Windows Server 2012 / Windows 8 oder neuer nicht erkannt.

WSUS_Client_Error_800B0001

Folgende Patches sind zu installieren und der WSUS ist neu zu starten:

1. KB2720211

http://support.microsoft.com/kb/2720211/de

Download 64-Bit:
http://www.microsoft.com/de-de/download/details.aspx?id=29999

2. KB2734608

Evaluierungsversion konvertieren

Möchte man eine Testversion von Windows Server 2012 länger benutzen, dann muss diese konvertiert werden.

Zur Ausführung der folgenden Befehle benötigen wir eine Administrator-CMD (elevated command prompt).

Aktuelle Installation anzeigen lassen:

C:\Users\administrator>DISM /online /Get-CurrentEdition

Tool zur Imageverwaltung für die Bereitstellung
Version: 6.3.9600.17031

Abbildversion: 6.3.9600.17031

Aktuelle Edition:

Aktuelle Edition : ServerStandardEval

Der Vorgang wurde erfolgreich beendet.

Konvertierung; es muss der Key der gewünschten Version angegeben werden, zu der konvertiert werden soll:

DISM /online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula

Es folgt folgende Bestätigung und Aufforderung zum Neustart des Systems:

Tool zur Imageverwaltung für die Bereitstellung
Version: 6.3.9600.17031

Abbildversion: 6.3.9600.17031

Komponentenaktualisierung wird gestartet...
Product Key-Installation wird gestartet...
Product Key-Installation ist abgeschlossen.

Paket "Microsoft-Windows-ServerStandardEvalEdition~31bf3856ad364e35~amd64~~6.3.9
600.16384" wird entfernt
[==========================100.0%==========================]
Komponentenaktualisierung ist abgeschlossen.

Editionsspezifische Einstellungen werden angewendet...
Das Anwenden der editionsspezifische Einstellungen ist abgeschlossen.

Der Vorgang wurde erfolgreich beendet.
Zum Abschließen dieses Vorgangs muss Windows neu gestartet werden.
Möchten Sie den Computer jetzt neu starten? (Y/N)

Exchange: Nachrichtenverfolgung anpassen

Generell kann über die Exchange-Management-Shell angepasst werden, wie viel, wie lange und was die Nachrichtenverfolgung nachhält. Zumindest gilt das für Exchange 2010 und 2013 – 2007 habe ich nicht getestet.

Dieser eine Befehl steuert dies:

Set-TransportService <ServerIdentity> -MessageTrackingLogEnabled <$true | $false> -MessageTrackingLogMaxAge <dd.hh:mm:ss> -MessageTrackingLogMaxDirectorySize <Size> -MessageTrackingLogMaxFileSize <Size> -MessageTrackingLogPath <LocalFilePath> -MessageTrackingLogSubjectLoggingEnabled <$true|$false>

Interessant zu wissen ist, dass mit -MessageTrackingLogMaxAge 00:00:00 die Vorhaltezeit auf unendlich gesetzt wird. Trotzdem greifen aber die Maxima der Logfile-Größen. Diese sollten ebenfalls angepasst werden, wenn eine unendliche Speicherung dieser Daten angestrebt wird.

Mit folgendem Befehl kann überprüft werden, welche Werte gesetzt worden sind:

Get-TransportService <ServerIdentity> | Format-List MessageTrackingLog*

Verdächtiges Update auf WSUS

Manchmal macht Microsoft auch einen Fehler. 😉 Dieser hat zumindestens meine Kollegen und mich ziemlich ins Grübeln gebracht. Denn durch das versehentlich veröffentlichte Testupdate ist uns bewusst geworden, dass die Microsoft Update Server eine Waffe sind. Dies gälte zumindest, wenn bösartiger Code über diese verteilt werden würde.

Am 01.10.2015 haben wir gedacht, dies wäre geschehen. Folgendes Bild bot sich auf der WSUS-Konsole:

wsus_komisches_update

Gott sei dank, die Befürchtungen waren unbegründet. Das Update mit dem Namen gYxseNjwafVPfgsoHnzLblmmAxZUiOnGcchqEAEwjyxwjUIfpXfJQcdLapTmFaqHGCFsdvpLarmPJLOZYMEILGNIPwNOgEazuBVJcyVjBRL hat Microsoft bereits wieder aus der Verteilung entfernt.

Nähere Infos auch unter http://www.zdnet.com/article/microsoft-accidentally-issued-a-test-windows-update-patch/

Windows Update Reset

Es kommt öfters mal vor, dass Windows Update sich verhakt. Mit diesem kleinen Batchfile wird der Update-Mechanismus auf Null gesetzt:

net stop wuauserv
cd %systemroot%
ren SoftwareDistribution SoftwareDistribution.old
net start wuauserv

pause

Fehler beim Domänenbeitritt

Letztens bin ich von einem Kunden mit folgender Fehlermeldung konfrontiert worden:

fehler_beim_domainbeitritt

„Die maximale Anzahl der Computerkonten, die in dieser Domäne erstellt werden können, wurde überschritten.“

Wenn man sich überlegt, in welchem Kontext der Fehler zu betrachten ist, kommt Licht ins Dunkel:

Hier wurde versucht mit einem normalen Domänen-Benutzer, kein Domänen-Administrator, ein Computer in die Domäne zu heben. Dies ist sogar möglich. Damit mit dieser Funktion kein Missbrauch getrieben wird, hat Microsoft die Anzahl der erstellbaren Computerkonten auf 10 Stück begrenzt. Quelle: https://support.microsoft.com/en-us/kb/251335

Domänen-Administratoren unterliegen natürlich nicht dieser Beschränkung.

Exchange Datenbank verschieben

In der Regel möchte man die Exchange-Datenbanken auf einer eigenen Partition oder LUN auf dem Exchange-Server laufen lassen oder einfach auf andere Festplatten verschieben.

So wird es gemacht…

Über die Powershell

Mittels des folgenden Befehls wird die angegebene Datenbank sowie deren Logfiles verschoben:

[PS] Move-DatabasePath -Identity "Mailbox Database 0695288994" -EdbFilePath "D:\ExchangeDB\Mailbox\Mailbox Database 0695288994\Mailbox Database 0695288994.edb" –LogFolderpath "D:\ExchangeDB\Mailbox"

Bestätigung
Möchten Sie diese Aktion wirklich ausführen?
Der Datenbankpfad 'Mailbox Database 0695288994' wird verschoben.
[J] Ja  [A] Ja, alle  [N] Nein  [K] Nein, keine  [?] Hilfe (Standard ist "J"): J

Bestätigt man nun mit J wird die Bereitstellung der Datenbank sofort aufgehoben!

Mit folgendem Befehl kann abgefragt werden, on die Datenbank nach Verschiebnung wieder erfolgreich gemountet worden ist:

[PS] Get-MailboxDatabase "DatabaseName" | FL Name,*Path*