Das eigene Attribut

Wir haben wie unter [1] unser eigenes Attribut Matrikelnummer erzeugt.

Advanced Find

Die erweiterte Suche in Active Directory Benutzer und Computer kann ein recht hilfreiches Tool sein, um nach bestimmten Kriterien zu suchen. Manuell angelegte Attribute werden hier in der Regel nicht berücksichtigt.

Mit folgendem Trick werden auch diese Attribute durchsucht:

• Öffnen der adsiedit.msc
• Navigiere zum Pfad
  deutsch:  Configuration -> CN=Configuration,DC=DOMAIN,DC=LOCAL -> CN=DisplaySpecifiers -> CN=407
  englisch:  Configuration -> CN=Configuration,DC=DOMAIN,DC=LOCAL -> CN=DisplaySpecifiers -> CN=409
• Ein Doppelklick auf CN=user-Display öffnet die Eigenschaften
• Nun attributeDisplayNames auswählen und bearbeiten drücken
• Hier tragen wir nun folgendes ein:

Das Ergebnis

Nach dem Eintrag lässt sich nun das Attribut über Advanced Find finden:

Das Was

Die Mitglieder unserer AD-Gruppe Subdomain-Mailbox-Verwaltung sollen folgendes in der Subdomäne sub.test.local administrieren können:

• Erstellen / Bearbeiten von Mailboxen
• Erstellen / Bearbeiten von MailContacts
• Erstellen / Bearbeiten / Löschen von DistributionGroups

Hierzu erstellen wir uns eigene ManagementRoles, die von vorhandenen Roles erben:

New-ManagementRole -Parent “Mail Recipient Creation” -Name “Restricted Mail Recipient Creation”

New-ManagementRole -Parent “Distribution Groups” -Name “Restricted Distribution Groups”

Nun müssen wir die Rechte, die nicht vergeben wollen sollten, aus den gerade erstellten Gruppen entfernen:

Remove-ManagementRoleEntry “Restricted Mail Recipient Creation\Remove-Mailbox”

Remove-ManagementRoleEntry “Restricted Mail Recipient Creation\Remove-MailContact”

Remove-ManagementRoleEntry “Restricted Distribution Groups\Remove-DistributionGroup”

Weitere Infos zu ManagementRoles, die unter Exchange 2010 bereits existieren, finden Sie unter [2].

Das Wer

Wie in Teil1 erstellen wir auch hier eine RoleGroup mit den entsprechenden Rollen:

New-RoleGroup “sub Mailbox Management RoleGroup” -Roles “Restricted Mail Recipient Creation”, “Restricted Distribution Groups”

und fügen die gewünschten Mitglieder hinzu:

Add-RoleGroupMember “sub Admin RoleGroup” -Member Subdomain-Mailbox-Verwaltung

Das Wo

Die Rechte der RoleBased-Access-Control können, wie in Teil1 [1] beschrieben, auf bestimmte Rechner eingeschränkt werden. In diesem Beispiel wollen wir aber zusätzlich das Erstellen von Mailboxen, MailContacts und DistributionGroups nur in der OU Verwaltung zulassen. Aus diesem Grund erstellen wir einen neuen Scope Sub Scope Recipients:

New-ManagementScope -Name “Sub Scope Recipients” – RecipientRoot sub.test.local/Verwaltung -RecipientRestrictionFilter {(RecipientType -eq “UserMailbox”) -or (RecipientType -eq “MailUser”) -or (RecipientType -eq “MailContact”) -or (RecipientType -eq “MailUniversalSecurityGroup”) -or (RecipientType -eq “MailUniversalDistributionGroup”) -or (RecipientType -eq “DynamicDistributionGroup”)}

Im letzten Schritt bringen wir die RoleGroup mit dem Scope zusammen:

Get-ManagementroleAssignment -RoleAssignee Subdomain-Mailbox-Verwaltung | Set-ManagementRoleAssignment -CustomRecipientWriteScope “Sub Scope Recipients”

[1] http://infrablog.escde.net/2012/02/01/exchange-2010-verwaltung-in-der-subdomane-teil1/
[2] http://technet.microsoft.com/en-us/library/dd638077.aspx

Es wird manchmal das Verhalten beobachtet, dass die neu erstellten Blogeinträge anderer Nutzer trotz Aktivierung in den Newsfeed-Settings nicht angezeigt werden.

Zur Aktualisierung bzw. generell zur Darstellung der Elemente im Newsfeed muss ein Job gestartet bzw. konfiguriert werden. Es handelt sich hierbei um “User Profile Service Application – Activity Feed Job”. Die Aktivierung und regelmäßige Ausführung kann unter Central Administration -> Monitoring -> Timer Jobs -> Review Timer Jobs vorgenommen werden [1].

Hierbei ist auffällig, dass Kommentare und Notizen der Kollegen angezeigt wurden, jedoch die neuerstellten Blogeinträge nicht vorzufinden waren. Als Ursache hierfür wurde der Search-Crawler ausfindig gemacht, dessen Frequenz zu niedrig eingestellt war. Der Search-Crawler ist für die Indizierung neuerstellter Inhalte, somit auch der Blogbeiträge, verantwortlich. Die Einstellungen hierzu finden sich unter Central Administration -> Application Management -> Manage Service Applications -> Search Service Application. Unter Content Sources lässt sich der Schedule sowohl für den vollständigen als auch für das inkrementellen Crawl für eine bestimmte Source definieren. Das inkrementelle Crawl sollte mehrfach täglich laufen, sodass neu erstellte Inhalte den Benutzern im Newsfeed angezeigt werden.

Weiterführende Links:

• http://technet.microsoft.com/en-us/library/hh344225.aspx  – Verify that the Activity Feed Timer Job is enabled (SharePoint Server 2010)

Die Funktion zum Starten des Task-Managers kann durch das Setzen eines Registry-Keys deaktiviert werden. Hierzu muss unter

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System

der Wert des DWORD-Eintrags DisableTaksMgr auf 1 geändert werden. Sofern das Verzeichnis und/oder der DWORD-Eintrag noch nicht existiert, muss der Eintrag noch erstellt werden. Durch die Änderung in der Registry wird im Windows Security Screen der Eintrag Task-Manager ausgeblendet (oder es erscheint die Meldung, dass der Task-Manager deaktiviert wurde), allerdings bleiben noch weitere Optionen, wie z.B. Benutzer wechseln oder Benutzer abmelden:

Wenn alle Optionen auf dem Security Screen deaktivieren werden, erscheint dieser leer, wodurch der nächste Nutzer möglicherweise irritiert wird. In 32-bit Versionen von Windows XP und Windows Vista ließ sich der Zugriff auf das System in gewissem Maß anhand des Steady-State Tools verhindern. Allerdings wird dieses Tool von Windows 7 leider nicht mehr unterstützt.

Tasten deaktivieren

Eine Möglichkeit alle Tastenkombinationen zu unterbinden ist das komplette Deaktivieren einzelner Tasten, wie z.B. die Windows-Tasten, STRG, ALT, DEL, F10, sowie die Kontextmenü-Taste. Hierzu muss in der Registry unter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout

den Wert des Eintrags Keyboard Layout geändert werden. Am Einfachsten geht dies über ein Reg-File mit folgendem Inhalt:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,09,00,00,00,00,00,5b,e0,00,00,5c,e0,00,00,5d,e0,00,00,44,00,00,00,1d,00,00,00,38,00,00,00,1d,e0,00,00,38,e0,00,00,00,00

Dieser Text wird in einen Texteditor kopiert und die Datei mit beliebigem Name sowie der Dateiendung „.reg“ abgespeichert und anschließend ausgeführt. Durch den Vorgang wird der Inhalt der Scancode Map überschrieben und damit die Tasten Windows-Taste, STRG, ALT, DEL, F10, sowie die Kontextmenü-Taste deaktiviert.

Die Funktionsweise (Hinweis: alle Werte sind hexadezimal):
Der Wert 09 nach den ersten 16 Nullen definiert die Anzahl der Tasten-Mappings. Dies sind in unserem Fall 9. Anschließend kommen 10 Nullen bis die eigentlichen Mappings beginnen. Hierbei bedeutet „5b e0 00 00“ das Deaktivieren der linken Windows-Taste. Im Folgenden werden alle verwendeten Mappings aufgelistet:

5b e0 – linke Windows-Taste
5c e0 – rechte Windows-Taste
5d e0 – Kontextmenü-Taste
44 00 – F10
1d 00 – linke Strg-Taste
38 00 – linke Alt-Taste
1d e0 – rechte Strg-Taste
38 e0 – rechte Alt-Taste

ACHTUNG:
Das systemweite Deaktivieren der Tasten STRG, ALT und ENTF führt dazu, dass diese Tasten auch beim Anmeldebildschirm nicht funktionieren. Somit lässt sich die Sichere Anmeldung mit STRG+ALT+ENTF nicht verwenden, die daher unbedingt vorher über die Benutzerkontensteuerung deaktiviert werden muss, weil sich der Nutzer sonst vom Zugriff auf das System ausschließt:

Start –> Ausführen –> „netplwiz“ –> Erweitert und Haken bei Strg+Alt+Entf drücken ist für die Anmeldung erforderlich entfernen

Weiterführende Links:

• http://support.microsoft.com/kb/126449 - Windows Shortcuts
• http://technet.microsoft.com/de-de/library/gg176676(WS.10).aspx - Steady State
• http://msdn.microsoft.com/de-de/windows/hardware/gg463447 – Scancode Mapping

Sicherheitshinweis: Bitte beachten Sie, dass Änderungen an der Registry einen tieferen Eingriff in das System darstellen und die fehlerhafte Bearbeitung der Registry zu gravierenden Problemen führen kann. Daher sollten Sie vor der Bearbeitung der Registry stets ein Backup der Registry durchführen. Wie Sie ein Registry-Backup erstellen können, wird in Sichern der Registry beschrieben.

Seit Exchange 2010 gibt es die sogenannte Role-Based-Access-Control (RBAC). Hiermit lassen sich die Berechtigungen des Exchange Administrators einer Subdomänen einschränken, die im Folgenden erklärt werden:

Das Was

Die Mitglieder unserer AD-Gruppe Subdomain-Admins sollen folgendes in der Subdomäne sub.test.local können:

• Server Management
• Recipient Management allerdings ohne den Befehl Remove-OwaMailboxPolicy
• View-Only Organization Management

Weitere Informationen zu diesen RoleGroups finden Sie unter [1].

Um die vorhanden RoleGroups nicht zu beschädigen oder einzuschränken, erstellen wir alle 3 RoleGroups neu:

$RoleGroup = Get-RoleGroup “Server Management”
New-RoleGroup “Subdomain Server Management” -Roles $RoleGroup.Roles

$RoleGroup = Get-RoleGroup “View-Only Organization Management”
New-RoleGroup “Subdomain View-Only Organization Management” -Roles $RoleGroup.Roles

Für die angepasste Rolle RecipientManagement wird das ganze etwas komplizierter. Da der Befehl Remove-OwaMailboxPolicy in den Rollen Mail Recipients und Recipient Policies enthalten ist, die beide ein Teil von Recipient Management sind, müssen wir das Ganze anpassen. Hierzu erstellen wir uns Kopien der entsprechenden Rollen:

New-Managementrole -Parent “Mail Recipients” -Name “Restricted Mail Recipients”

New-ManagementRole -Parent “Recipient Policies” -Name “Restricted Recipient Policies”

Nun müssen wir den unerwünschten Befehl entfernen:

Remove-ManagementRoleEntry “Restricted Mail Recipients\Remove-OwaMailboxPolicy”

Remove-ManagementRoleEntry “Restricted Recipient Policies\Remove-OwaMailboxPolicy”

Diese und alle anderen Rollen, die wir benötigen fügen wir nun zu einer RoleGroup Restricted Recipient Management zusammen:

New-RoleGroup “Restricted Recipient Management” -Roles “Distribution Groups”, “Mail Enabled Public Folders”, “Mail Recipient Creation”, “Message Tracking Migration”, “Move Mailboxes”, “Restricted Mail Recipients”, “Restricted Recipient Policies”

Weitere Infos zu ManagementRoles, die unter Exchange 2010 bereits existieren, finden Sie unter [2].

Das Wer

Jetzt müssen die gewünschten Mitglieder noch den RoleGroups hinzufügen werden. In unserem Fall die Gruppe Subdomain-Admins:

Add-RoleGroupMember”Subdomain Server Management” -Member Subdomain-Admins

Add-RoleGroupMember “Subdomain Recipient Management” -Member Subdomain-Admins

Add-RoleGroupMember “Subdomain View-Only Organization Management” -Member Subdomain-Admins

Das Wo

Die Rechte, die über RoleBased-Access-Control vergeben werden, können am einfachsten durch einen eigenen Scope auf bestimmte Bereiche einschränken. In unserem Fall müssen wir also die Subdomäne zu einem neuen Sub Scope zusammenfassen. Dies geht am einfachsten über den FQDN der beteiligten Server:

New-ManagementScope -Name “Sub Scope” -ServerRestrictionfilter {FQDN -like “*.sub.test.local*”}

Nun werden die zuvor erstellten RoleGroups dem Scope zugeordnet:

Get-ManagementRoleAssignment -RoleAssignee “Subdomain Server Management” | Set-ManagementRoleAssignment  -CustomConfigWriteScope “Sub Scope”

Get-ManagementRoleAssignment -RoleAssignee “Subdomain Recipient Management” | Set-ManagementRoleAssignment -CustomConfigWriteScope “Sub Scope”

Get-ManagementRoleAssignment -RoleAssignee “Subdomain View-Only Organization Management” | Set-ManagementRoleAssignment -CustomConfigWriteScope “Sub Scope”

Nach den durchgeführten Änderungen hat jedes Mitglied der Gruppe SubdomainAdmins alle nötigen Berechtigungen um den Exchange innerhalb der Subdomain, wie gewünscht, zu verwalten.

[1] http://technet.microsoft.com/en-us/library/dd351266.aspx
[2] http://technet.microsoft.com/en-us/library/dd638077.aspx

Genau das werde ich im Folgenden erklären:

Das versteckte Attribut

Durch das Verstecken des Attributs MyAttribut wird aus

diese LDAP-Anzeige:

Visible again

Um das Attribut für eine Gruppe Visible wieder sichtbar zu machen, muss der Administrator wie folgt vorgehen:

• ldp.exe öffnen
• über Connection -> Bind… sich mit einem Administrator-Account zum AD verbinden
• über View -> Tree das AD öffnen
• Ein Rechtsklick auf die oberste Ebene -> Advanced -> Security Descriptor öffnet das benötigte Fenster

Hier muss folgendes über Add ACE eintragen werden:

• Trustee:  DOMAIN\Visible
• ACE type: Allow
• Access mask: Control access
• ACE flags: Inherit
• Object type: MyAttribute

Durch das Bestätigen des Dialogs werden die Rechte entsprechend geändert, so dass die Mitglieder der Gruppe Visible das Attribut MyAttribut lesen können, obwohl es als confidential deklariert wurde.

Aber was ist die Cloud nun? Wie kann ich sie zu meinem Vorteil nutzen? Diese Fragen möchte ich im folgenden Artikel klären.

Eine Begriffsdefinition

Wer sich näher mit dem Thema Cloud auseinandersetzt, wird schnell darauf stoßen, dass es um Virtualisierung von Computersystemen geht. Virtualisierung kennen wir aber nun schon recht lange. Wo ist denn nun das fundamental neue Konzept, das eine eigene Marketing-Kampagne rechtfertigt?

Die Schwierigkeit daran, den Begriff Cloud zu definieren ist, dass hier eher versucht wird eine Idee zu benennen. Ein Beispiel: Wenn ich vor einem Computer stehe kann ich, nicht feststellen, ob es sich um einen Server- oder einen Client-PC handelt,  ohne mit ihm zu arbeiten. Der Unterschied liegt darin, dass der Server Dienste für Clients bereitstellt. Ähnlich stellt sich die Situation mit der Cloud dar. Sie ist Virtualisierung mit “ein bisschen mehr”.

Die Cloud vereint Virtualisierung mit (teilweise automatisiertem) Energie- und Ressourcenmanagement und erweiterter Ausfallsicherheit. Dadurch, dass nahezu alle Systeme virtualisiert sind, ist für den Klienten gar nicht wichtig, auf welcher Hardware er tatsächlich arbeitet. So können zum Beispiel bei geringer Last automatisch die benötigten Systeme auf wenigen physikalischen Maschinen zusammengefasst und der Rest ausgeschaltet werden.

Ist Cloud gleich Cloud?

Leider auch verfehltem Marketing geschuldet ist die Wahrnehmung, dass eine Cloud generell außerhalb des eigenen Rechenzentrums bestehen muss. Hier wird unterschieden zwischen der Private Cloud (oder in Microsoft-Terminologie die Hyper-V Cloud) und der Public Cloud. Bei der Public Cloud stehen die physikalischen Maschinen dabei in einem fremden Rechenzentrum, während die Private Cloud alleine im eigenen Haus arbeitet.

Welche Vorteile hat die Public Cloud?

Die Public Cloud nimmt dem IT-Administrator die Arbeit ab, Hardware beschaffen oder warten zu müssen. Er kann sich komplett auf die Administration der Software konzentrieren. Auch für Dienste, bei denen seltene, aber große Lastspitzen zu erwarten sind, ist die Public Cloud sinnvoll.

Ein fiktives Beispiel aus Sicht des KIT: Zu Beginn jedes Semesters müssen sich alle Studenten zu Seminaren anmelden. Die Anmeldung wird für alle Seminare gleichzeitig freigeschaltet und wer sich zu spät meldet bekommt häufig keinen Platz in den beliebten Seminaren. Um die Last abzufangen, muss das System auf ausreichend starker Hardware betrieben werden. Allerdings sprechen wir hier nur von wenigen Tagen im Jahr, in denen der Service überhaupt verwendet wird. Eine Public Cloud versetzt mich nun in die Lage, bei hoher Last weitere Rechenleistung hinzuzubuchen. Dadurch entstehen nicht das ganze Jahr unnötige Kosten.

Der größte Kritikpunkt an der Public Cloud sind generell Sicherheitsbedenken. Oft hört man davon, dass interne Daten nicht “in die Cloud” sollten. Die Sorge ist sicher nicht ganz unberechtigt. Die Daten liegen nicht mehr im eigenen Haus und können nicht unmittelbar kontrolliert werden. Bei einem seriösen Anbieter hält sich das tatsächliche Risiko allerdings in Grenzen. Es ist auch in der Public Cloud möglich (und sinnvoll) die eigenen Server mit Sicherheitssoftware auszustatten. Zusätzlich werden größere Rechenzentren von Fachkräften gesichert, die oft mehr Erfahrung mit der Materie haben, als die eigenen Administratoren.

Wir haben ein Rechenzentrum. Kann ich von der Cloud profitieren?

Abgesehen davon, Public Cloud und Private Cloud zu kombinieren, sollte jedes Rechenzentrum generell über den Aufbau einer Private Cloud nachdenken.

Speziell aus Sicht unserer Kunden, also Hochschulen, gibt es immer wieder Szenarien, die eine Private Cloud nahelegen. In der Regel hat nicht nur jede Fakultät, sondern sogar jedes Institut eine eigene Infrastruktur. Diese beinhaltet nicht nur Dienste wie Exchange oder File Server, die ohnehin in ein Rechenzentrum ausgelagert werden sollten, sondern gerade im Bereich Informatik auch viele starke Rechner für wissenschaftliche Berechnungen.
Diese Systeme werden nicht durchgängig benötigt, werden aber trotzdem für viel Geld angeschafft. Eleganter wäre hier der Weg in die Private Cloud. Der User kann beispielsweise über eine SharePoint-Seite ein Testsystem mit bestimmter Leistung anfordern. Es wird ein passendes Gastsystem gesucht und eine virtuelle Maschine eingerichtet. Nach einer gesetzten Zeit wird, wenn der User nicht widerspricht, die Maschine gelöscht und die Ressourcen freigegeben. Ein ähnliches Vorgehen ist auch für Software (z.B. Teile des Office Pakets, Adobe Reader, diverse Media Player, …) möglich. Das spart Lizenzen und hält die Client-Computer sauber. Letzteres Szenario bietet sich beispielsweise für Poolräume von Rechenzentren an.

Fazit

Man sollte sich nicht durch das Marketing der Cloud abschrecken lassen. Das Konzept bietet in seinen verschiedenen Ausprägungen viele Möglichkeiten. Generelle Virtualisierung der meisten Systeme empfiehlt sich ohnehin. Diese virtuellen Maschinen lassen sich gut über Microsofts System Center Virtual Machine Manager (SCVMM) verwalten. Damit ist die Grundlage für die Hyper-V Cloud bereits gesetzt. Ob darüber hinaus Cloud-Funktionen eingesetzt werden, muss jedes Rechenzentrum für sich entscheiden. Aus meiner Sicht können die meisten Anwender von einer Cloud allerdings nur gewinnen.

Stellen Sie sich nun folgendes Szenario vor: Sie setzen einen Server 2008 R2 in Hyper-V auf und konfigurieren Dynamic Memory:

Nach der Installation des Betriebssystems kommt nun die Überraschung: Der Server läuft nur mit dem Startup-RAM, in diesem Fall 512MB:

Mit exakt diesem Problem sah ich mich neulich konfrontiert. Zunächst habe ich versucht die Integration Tools erneut zu installieren um sicherzustellen, dass die neueste Version vorhanden ist. Auch dieses Vorgehen hat jedoch keinen Erfolg gebracht. Nach einiger Recherche habe ich in der TechNet im Artikel Hyper-V Dynamic Memory Configuration Guide die Lösung gefunden. Wenn es sich, wie in meinem Fall um einen Server 2008 R2 Standard handelt, so muss auch auf dem Gast-System SP1 für Server 2008 R2 installiert sein. Für alle Server 2003 und Server 2008 Versionen sowie für Server 2008 R2 Enterprise oder Datacenter genügt ein Update der Integration Tools.

Nach der Installation von SP1 funktionierte dann auch Dynamic Memory wie gewünscht:

Die einfache Antwort lautet in diesem Fall Mailbox Storage Quotas.

Was sind überhaupt Mailbox Storage Quotas und was kann ich mit ihnen einstellen?

Mailbox Storage Quotas sind grundsätzlich ein Speicherplatz-Limit für Exchange Postfächer. Darüber hinaus lässt sich einstellen, wie sich der Exchange Server verhält, sobald das eingestellte Limit erreicht wurde. Dafür gibt es folgende Optionen:

• Ab welcher Größe wird gewarnt, dass das Postfach zu groß wird.
• Ab welcher Größe wird das Senden neuer E-Mails verhindert.
• Ab welcher Größe wird das Senden und Empfangen von E-Mails verboten.

Die Einstellungen lassen sich für einzelne Mailboxen oder für eine ganze Datenbank vornehmen. Wenn ein Quota für eine Datenbank festgelegt wird, gilt es für alle Postfächer, die sich darin befinden, und kein eigenes Quota eingestellt haben.

Wie werden Mailbox Storage Quotas konfiguriert?

Grundsätzlich können die Mailbox Storage Qutas in der Exchange Management Console (EMC) oder über die Exchange Management Shell eingestellt werden.

In der EMC werden die Limits für die gesamte Datenbank wie folgt eingestellt:

1. Organization Configuration
2. Mailbox > Reiter “Database Management”
3. Eigenschaften der gewünschten Mailbox
4. Limits

Für einzelne User funktioniert die Einstellung wie folgt:

1. Recipient Configuration
2. Mailbox
3. Eigenschaften eines Users
4. Mailbox Settings
5. Storage Quotas

Darüber hinaus lassen sich diese Einstellungen auch über die Shell vornehmen. Dazu verwenden Sie folgende Befehle:

Set-Mailbox -Identity jsmith@contoso.com -IssueWarningQuota 209715200 -ProhibitSendQuota 262144000 -ProhibitSendReceiveQuota 293601280 -UseDatabaseQuotaDefaults $false

Dieser Code Ausschnitt setzt die Quotas für das Postfach jsmith@contoso.com. Außerdem wird nun das persönliche Quota und nicht mehr das allgemeine Datenbank Quota angewandt. Genauso lässt sich als Identity der Name einer Mailbox in der Form “Mailboxname” angeben (inklusive Hochkommata), wobei das UseDatabaseQuotaDefaults Argument entfällt und die übrigen Befehle identisch bleiben.

Zuerst wird das Service Pack installiert und anschließend der Server neu gestartet. Lässt man den Server nun laufen sieht das Eventlog bald wie im folgenden Bild aus:

Ein Blick in die Zentraladministration unter Upgrade and Migration -> Review database status zeigt für alle Datenbanken folgende Meldung:

Dieses Datenbank Upgrade kann über die PowerShell oder einfacher noch über den SharePoint 2010 Products Configuration Wizard vorgenommen werden. Dieser muss mit einem Account gestartet werden, der sowohl administrative Rechte auf dem SharePoint Server, als auch Schreibzugriff auf die Datenbank besitzt.

Möglicher Weise schlägt das Datenbank Upgrade für eine oder mehrere Datenbanken fehl. Das ist grundsätzlich kein Problem. Unter Upgrade and Migration -> Check upgrade status in der Zentraladministration lässt sich der Status des aktuellen Upgrades einsehen. Dort ist auch der Pfad zum passenden Logfile angegeben. In unserem Fall ist das Upgrade bei zwei Datenbanken fehlgeschlagen. Eine aussagekräftige Fehlermeldung gab es nicht. Nur den Hinweis es noch einmal zu versuchen. Ein zweiter Durlauf des Configuration Wizard brachte dann den gewünschten Erfolg.

Je nach Leistung des Servers und Größe der Datenbanken sollte für den ganzen Vorgang etwa eine Stunde eingeschränkte Erreichbarkeit für den SharePoint Server eingeplant werden.