Angesichts des näher rücken­den Support-Endes für Windows Server 2008 (R2) und SQL Server 2008 (R2) bietet Microsoft zwei Optionen an, mit denen sich das Betriebs­system und die Daten­bank darüber hinaus nutzen lassen. Anwender können Extended Security Updates beziehen oder die Server nach Azure zu migrieren.

Zu den Wartungs­aufgaben für die Update Services gehört neben dem regel­mäßigen Rein­dexieren auch das Sichern der Daten­bank. Ist diese nämlich beschädigt, dann kann der WSUS-Server keine Updates mehr bereit­stellen. Für solche spezi­fischen Backup-Aufgaben eignet sich das Bord­mittel Windows Server Sicherung.

Zu den regel­mäßigen Wartungs­arbeiten an den Windows Server Update Services (WSUS) gehört die Neu­indexierung der Daten­bank. Setzt man die interne Windows-Datenbank (WID) ein, dann muss diese Tätigkeit lokal erfolgen. Am einfach­sten ist es daher, zu diesem Zweck eine geplante Auf­gabe mit PowerShell zu erstellen.

Nakivo gab die Version 7.4 von Backup & Repli­cation frei. Obwohl es sich dabei nur um ein Minor Release handelt, bringt es gleich mehrere interes­sante Neuerungen. Dazu zählt ein verein­fachtes DR von virtu­ellen Maschinen, erwei­terte Unter­stützung für SQL Server sowie eine flexi­blere Nutzung des Netz­werks.

Die eigent­liche Instal­lation der WSUS-Rolle geht flott über die Bühne. Bevor man aber damit los­legt, sollte man den gesamten Ein­satz von WSUS planen. Dabei ist etwa zu klären, wo man Updates speichert und wie sie an welche Clients gelan­gen. Zu­dem stellt sich die Frage, ob man WSUS zentral oder dezen­tral verwalten möchte.

Dieser Beitrag be­schreibt die Vorarbeiten für das Setup des Virtual Machine Manager (SCVMM). Dazu zählen das An­legen eines AD-Kontos, eines SPN und eines Distri­buted Key Manage­ment Containers sowie die Instal­lation diverser Tools. Manche Maß­nahmen sind nur für eine hoch­verfügbare Konfigu­ration nötig.

Bei einer Database Availabilty Group (DAG) kann die Daten­sicherung oder die Migration einer Exchange-VM einen Daten­bank-Failover aus­lösen. Tritt dies öfters auf, dann empfiehlt es sich, die Schwell­werte, welche ein Schwenken der DAG auslösen, manu­ell anzu­passen.

Es kommt immer wieder mal vor, dass in Exchange Daten­banken und Log­dateien auf andere Lauf­werke umge­zogen werden müssen. Häufig sind dafür Ressourcen­engpässe verant­wortlich. Das Vor­gehen unter­scheidet sich, je nach­dem ob eine Daten­bank zu einer Database Availability Group (DAG) gehört oder nicht.

Nach­dem man die Voraus­setzungen für eine Data­base Availa­bility Group ge­schaf­fen hat, indem man das Netz­werk ein­richtet, einen File-Server bereit­stellt und ein Computer-Konto für die DAG anlegt, kann man nun die hoch­verfügbare Daten­bank­gruppe konfi­gurieren.

Die Data­base Availa­bility Group (DAG) ist eine Hoch­verfüg­bar­keits- und Daten­wieder­her­stel­lungs­funktion von Exchange. Diese An­lei­tung beschreibt, wie man dafür das Netz­werk konfi­gu­riert, den erfor­der­lichen File-Server ein­richtet und ein Konto für die DAG im Active Directory erstellt.