langsames Backup der Exchange-Datenbanken zwischen 0 Uhr und 6 Uhr

Problem:
Die Sicherung der Exchange-Datenbanken dauert extrem lange. Die Sicherung findet zwischen 0 Uhr und 6 Uhr früh statt.

Ursache:
Der Wartungsintervall der Exchange-Datenbank läuft zeitgleich mit der Sicherung.

Lösung:
Entweder Sie verschieben den Zeitpunkt der Datensicherung des Exchangeservers (Ressourcenreihenfolge), oder Sie ändern die Uhrzeit des Wartungsintervalls.
Dieses ist zu ändern im Systemmanager - erste Organisation - Server - Servername - erste Speichergruppe - Postfachspeicher - Eigenschaften - Datenbank
Hier kann die Uhrzeit bzw. der Zeitraum des Wartungsintervalls eingestellt werden.

ACHTUNG: Nach der Änderung des Wartungsintervalls muß der Exchnage Information Dienst neu neu gestartet werden, sonst wird die Änderung nicht übernommen!


Backup Information Store mit AOFO schlägt fehl

Problem:
Bei der Sicherung mit Advanced Open File Option kommt es zur folgender Fehlermeldung:

Sichern- SERVER\BKUPEXEC AOFO: Initialisierung fehlgeschlagen: "Microsoft Information Store". Advanced Open File Option verwendet: Microsoft Volume Shadow Copy Service (VSS).
Fehler im Schnappschuß-Provider (0xE00084AF): Das Verzeichnis bzw. die Datei wurde nicht gefunden, oder der Zugriff ist nicht möglich.
Ausführliche Angaben finden Sie in der Windows-Ereignisanzeige.


Wenn man die AOFO abschaltet, dann wird zwar der Information Store wieder gesichert, aber geöffnete Dateien werden übersprungen.

Ursache:
Default ist der Exchange Writer für die VSS-Sicherung des Information Stores abgeschaltet. Dadurch kommt es zu der genannten Fehlermledung, da Backup Exec versucht den IS mittels VSS zu sichern.

Lösung:
Man kann den "Exchange Writer" aktivieren in dem man folgenden Microsoft KB-Artikel 838183 befolgt:

- Click Start, click Run, type regedit, and then click OK.
- Locate and then double-click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
- Double-click the "Disable Exchange Writer" value.
- In the Value data text box, change the value from 1 to 0, and then click OK.
- Quit Registry Editor.
- Click Start, point to Administrative Tools, and then click Services.
- Stop and then restart the Microsoft Exchange Information Store service.

Link: Microsoft Article ID: 838183

Das Problem wird in der Symatec KB aufgeführt und erklärt.
Link: Symantec Document ID: 275234

Enabling or Disabling the Debug logging

Enabling or Disabling the Debug logging

Follow the steps below to enable-disable Debug logging from the Beutility:

1. From Windows Explorer, go to the Program files\Symantec\Backup Exec folder and open Beutility.exe

2. Right-click on the server name and select Enable Debug Logs.

3. Select Enable Debug Logs to activate Backup Exec debug routines for a variety of Backup Exec services. In addition to activating the debug feature, debug log files are created and stored on a media server hard drive.
Note In a default installation, Backup Exec log files reside in the Logs directory, in the following path :
drive letter>\Program Files\Symantec\Backup Exec\Logs.

4. Selecting Enable debug log for Job Engine and Remote Agent service activates the log required to debug both the Backup Exec Job Engine and Remote Agent services.

5. Selecting Engine NDMP debug level sets the level of Engine NDMP debug details that are logged.

6. Remote Agent NDMP debug level sets the level of Remote Agent debug details that are logged.
Either of the 3 Choices can be included in the debug logging :
Log NDMP errors only, Log flow messages and Verbose Logging.
Selecting Log NDMP errors only gives general information and errors that are generated.
Selecting Log flow messages includes both a higher level overview of the activity occurring, and the NDMP errors that are generated.
Verbose Logging offers even more information and should only be used with VERITAS Technical Support guidance.


7. Deselect "Enable debug log for Job Engine and Remote Agent service" to disable the debug logging.

Note: Enable Debug Logs should only be used when specific information is needed about your Backup Exec installation in order to diagnose issues. Activating debug logging will greatly impact media server performance.

Quelle: Symantec Document ID: 274875

Client meldet sich nicht mehr bei WSUS Server

Problem:

Bestimmte Clients melden sich nicht mehr beim WSUS-Server bzw. holen sich keine Updates mehr

Lösung:

Folgende Vorgehensweise für einen Reset der Verbindung:

- regedit HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
- PingID, SUSClientID und AccountDomainSID löschen
- wuauserv Dienst durchstarten (Automatische Updates)
- wuauclt.exe /resetauthorization /detectnow
- wuauclt.exe /reportnow
- eventuell reboot des Clients


Nach ca. 10 Minuten sollte der Client sich wieder melden.

Sollte das alles nicht zum Erfolg führen, dann holft der WSUSHelper:

Download: http://web318.server168.star-server.info/node/116

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.
Kategorien: WSUS
Tags für diesen Artikel:

WSUS Content-Files verschieben

Problem:

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.


Quelle: http://www.admins-tipps.de/Microsoft/Win...verschieben.htm
Kategorien: WSUS
Tags für diesen Artikel:

keine Website wird mehr angezeigt - "Die Seite kann nicht angezeigt werden"

Problem:

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.

Link: Microsoft Artikel-ID: 934878

Dann bitte die Verzeichnis-Sicherheit der einzelnen Websites nochmal überprüfen...gerade bei OWA.

Link: Standard-Verzeichnis-Rechte IIS für OWA
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)