Zum Inhalt

Schlagwort: windows

Keine Befehle in der Exchange Management Shell vorhanden

Fehlen der Exchange Verwaltungsshell plötzlich alle Kommandos, also liefert ein

[PS] D:\>get-excommand

CommandType Name Definition

———– —- ———-
Function Get-ExchangeDiagnosticInfo …

nur noch ein Kommando, dann muss die Liste der Kommandos wieder neu gebaut werden. Das geht ganz einfach:

Man löscht den Ordner

C:\Users\username\AppData\Roaming\Microsoft\Exchange\RemotePowershell\domainname

und startet die Powershell neu – schon sind alle Kommandos wieder da.

Leave a Comment

HOWTO: Windows Server 2008/2012 Backups/VSS-Fehler debuggen

Ein schönes Beispiel um zu zeigen, wie man Windows Backup-Fehler generell debuggen kann, gültig für Windows Server 2008 und neuer (entspricht den Client-Betriebssystemen Vista und neuer):

(1) FEHLERBESCHREIBUNG

Log des Sicherungsprogramms meldet:
The backup operation stopped before completing.
Detailed error: ERROR – A Volume Shadow Copy Service operation error has occurred: (0x800423f4)
The writer experienced a non-transient error. If the backup process is retried, the error is likely to reoccur.

Die sog. VSS Writer sammeln Daten von der Festplatte, MSSQL, IIS, Exchange, und so weiter ein und schreiben die jeweiligen Daten(-banken) in einem konsistenten Stand ins Backup, übrigens werden die meistens auch bei Drittanbieter-Software verwendet (Acronis, BackupExec, etc…)

(2) WER IST DER SCHULDIGE?

Infos darüber, welches VSS-Writer-Modul den Fehler erzeugt, findet man in der Konsole mit "VSSADMIN LIST WRITERS"

Writer name: 'SqlServerWriter'
Writer Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
Writer Instance Id: {4fb3be04-8d39-4fc4-9b39-dd6abe6061a9}
State: [8] Failed
Last error: Non-retryable error

Ergo: irgendwas mit SQL.

(3) EIN BISSCHEN GENAUER, BITTE

Die Windows-Ereignisanzeige (am besten schaut man immer zuerst bei den "Administrativen Ereignissen", da bekommt man nur Warnungen und Fehler) sagt zum Zeitpunkt, als das Backup abgebrochen ist:

Source: SQLWRITER
EventID: 8193
SQL writer error: Unexpected error calling routine
IClientVirtualDevice::GetCommand. hr = 0x80770004.

sowie viele dutzende:

Source: MSSQL$MSSQLSERVER2008
EventID: 3041
BACKUP failed to complete the command BACKUP DATABASE MSSQL047.
Check the backup application log for detailed messages.

Ein kurzer Blick nach den beiden Event-IDs und dem Fehlercode 0x80770004 bringt einen dazu, dass es wohl um kaputte Datenbanken geht, die wegen einer Eigenschaft "AutoClose = True" kaputt gehen, gerade auf hektisch befahrenen MSSQL-Servern.

(4) DIE PROBLEMLÖSUNG

Microsoft sagt dazu, es sei "Best Practice", die AutoClose Property abzuschalten. AutoClose bringt den SQL-Server dazu, die Datenbank beim disconnect des letzten Clienst die Daten auf die Festplatte zu schreiben. Verbindet wieder ein Client, wird die DB wieder geöffnet, und wieder geschlossen, und auf, und zu, und BUMM.

siehe:
http://blogs.msdn.com/b/buckwoody/archive/2009/06/24/sql-server-best-practices-autoclose-should-be-off.aspx

Das ist nicht nur anspruchsvoll für die DB, sondern macht auch jegliche Caching-Versuche zunichte. Der Server sollte halt bei deaktiviertem AutoClose nicht hart abgeschalten werden.

Schnell das MSSQLMS (Microsoft SQL Server Management Studio) gestartet, als Administrator eingeloggt, "New Query", und mit folgender Abfrage betroffene Datenbanken gesucht:

SELECT * FROM sys.databases WHERE DATABASEPROPERTYEX (name, 'IsAutoClose') = 1

Die Datenbanken kann man nun mit rechtsklick auf die Datenbank -> Eigenschaften -> Optionen -> AutoClose = false entsprechend konfigurieren.

Manche Datenbanken quittieren das mit einem Fehler 9001, da hilft es die DB offline und online zu nehmen. Die Ursache dafür ist genau der Datenbankdefekt, der durch die angeschaltene AutoClose Option beursacht wurde.

Hint: Microsoft hat ab *irgendeiner* Version (eine neuere als die, an der ich sitze) AutoClose = off direkt in das CREATE DATABASE Statement als Standardwert implementiert. Besser spät als nie.

(5) AUFRÄUMARBEITEN

Hat man alle Datenbanken richtig konfiguriert, werden die kaputten DBs noch repariert. Das kann man sich klicken, schneller geht's aber mit folgendem Query:

SQL-Kung Fu für "ich habe kein Backup aber will alle Datenbanken jetzt sofort reparieren":

MSSQL 2005 und früher:
exec sp_MSforeachDB 'DBCC CHECKDB ("?") WITH ALL_ERRORMSGS, DATA_PURITY'

MSSQL 2008 und später:
exec sp_MSforeachDB 'DBCC CHECKDB ("?") WITH ALL_ERRORMSGS, EXTENDED_LOGICAL_CHECKS, DATA_PURITY'

Danach startet man das Backup und freut sich auf das nächste Problem 🙂

Leave a Comment

Windows Aufgabenplanung – Fehlerwert: 2147943645 oder 2147943726

Code 2147943645 steht für "Benutzer nicht am System angemeldet", und man behebt ihn indem man die Aufgabe bearbeitet und in den Haken "unabhängig von Benutzeranmeldung ausführen" aktiviert.

Für Code 2147943726 war bei mir die Ursache, dass das Kennwort des Benutzers, unter dem der Task lief, geändert wurde; es wurde aber vergessen, die Credentials des Auftrages entsprechend anzupassen. Einfach in den Einstellungen des Tasks den Benutzer erneut auswähen und das aktuelle Kennwort hinterlegen.

Quelle: IMA – Informationen Mal Anders Blog – vielen Dank!

Leave a Comment