Roger Haueter

Modern Workplace Strategist | Microsoft Most Valuable Professional

Automatischen Neustart nach Windows Updates Installation verhindern

Windows XP, Windows Vista und Windows 7 starten nach der manuellen oder der geplanten Installation von Windows Updates den PC neu, um die vorgenommenen Änderungen anzuwenden. Seit Windows 7 haben die Benutzer die Möglichkeit, den Neustart zu verzögern.

Automatischen Neustart druch Windows Update verhindern

  1. Links unten auf Start (resp. das Windows Symbol) klicken, danach geben Sie im Feld "Programme/Dateien durchsuchen" gpedit.msc ein und drücken die Enter-Tase.
  2. Im Editor für lokale Gruppenrichtlinien gehen Sie zu Computerkonfiguration -> Administrative Vorlagen -> Windows-Komponenten ->Windows Update
  3. Doppelklicken Sie Keinen automatischen Neustart für geplante Installationen automatischer Updates durchführen, wenn Benutzer angemeldet sind
  4. Wählen Sie Aktiviert aus und klicken Sie OK
  5. Schliessen Sie den Editor für lokale Gruppenrichtlinien

Benutzer mit Windows XP, Windows Vista oder Windows 7 Home Edition müssen die Änderungen über die Registry vornehmen.

  1. Links unten auf Start (resp. das Windows Symbol) klicken, danach geben Sie im Feld "Programme/Dateien durchsuchen" regedit ein und drücken die Enter-Taste.
  2. Gehen Sie im Registrierungs-Editor zu: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
    Wenn dieser Eintrag noch nicht existiert, dann erstellen Sie ihn wie unten im Bild zu sehen.
  3. Ändern Sie den NoAutoRebootWithLoggedOnUsers DWORD (32-bit) Wert auf 1, um den automatischen Neustart zu verhindern.
    Wenn dieser Wert noch nicht existiert, dann erstellen Sie ihn wie unten im Bild zu sehen.
  4. Schliessen Sie den Registrierungs-Editor.

“An unexpected error has occured” beim Aufrufen einer Web Application

In diesem Artikel beziehe ich mich auf die Meldung "An unexpected error has occured" in Zusammenhang mit dem Erstellen einer neuen Web Application.

Web Applications sollten immer mit einem eigens dafür vorgesehenen Service Account (domain\user) ausgeführt werden, mit normalen User-Rechten im Active Directory als auch lokal auf dem Server.
Wird nun in der Central Administration eine neue Web Application erstellt, dann fügt SharePoint den angegebenen Benutzer in die lokalen Servergruppen "IIS_IUSRS" der SharePoint Server hinzu und prüft nicht, ob dieser die benötigten Rechte hat, um die Web Application korrekt auszuführen. Und hier ist das Problem: Da dieser Benutzer normalerweise keine genügend hohen Rechte besitzt um Änderungen an der GroupPolicy vorzunehmen, kann es vorkommen, dass folgende Fehler beim Aufrufen der Web Application angezeigt werden:
- An unexpected error has occured
- 503 Service unavailable (Application Pool wird gestoppt)

Egal welchen der beiden Fehler Sie erhalten, prüfen Sie in Ihrer Group Policy unter Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignments, ob die Gruppe "IIS_IUSRS" (oder ggf. auch nur der Benutzer unter dem die Web Application läuft) in den folgenden beiden Richtlinien enthalten ist:
- Impersonate a client after authentication
- Log on as a batch job

Ist dies nicht der Fall, dann fügen Sie diese hinzu, führen Sie ein Group Policy Update (gpupdate /force) und einen iisreset auf allen SharePoint Web Front-end Servern durch (alternativ bietet sich auch ein Neustart an).
Nun sollte die Site Collection korrket angezeigt werden. Ist dies nicht der Fall, dann prüfen Sie, ob die angepasste Group Policy auf den Servern angewendet wurde und die Berechtigungen korrekt gesetzt wurden.

Microsoft TechNet Artikel über die benötigten Berechtigungen der einzelnen SharePoint 2010 Benutzerkonten:
http://technet.microsoft.com/de-de/library/cc678863.aspx


Funktionsvergleich der SharePoint 2010 Editionen

Microsoft hat einen Vergleich von SharePoint Foundation, SharePoint Standard und  SharePoint Enterprise online gestellt. Die Funktionen können nebst einer Gesamtübersicht auch nach Kategorien (Sites, Communities, Content, Search, Insights, Composites) verglichen werden. Zudem gibt es zu jeder Funktion eine kurze Beschreibung.

Compare SharePoint 2010 Editions
http://sharepoint.microsoft.com/en-us/buy/Pages/Editions-Comparison.aspx


Erstes kumulatives Updates für SharePoint 2010

Microsoft hat das erste kumulative Update für SharePoint 2010 veröffentlicht. Diese waren bereits für Juni angekündet und wurden mit etwas Verspätung freigegeben.
Anders als bei MOSS 2007 und WSS 3.0 sind die kumulativen Updates nicht als Serverpaket erhältlich, sondern erscheinen in sechs individuellen Paketen.

Technet Artikel zur Installation von Softwareupdates in SharePoint 2010
http://technet.microsoft.com/en-us/library/cc263467.aspx

Update Portal für SharePoint 2010
http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx

June Cumulative Update (CU) für SharePoint Server 2010
KB983497
http://support.microsoft.com/kb/983497

KB2124512 (Search Filters)
http://support.microsoft.com/kb/2124512

KB2182938 (Nur für Japanisch, Chinesisch und Koreanisch)
http://support.microsoft.com/kb/2182938

KB983319 (Search Server)
http://support.microsoft.com/kb/983319

KB2281364
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2281364&kbln=en-us

June Cumulative Update (CU) für SharePoint Foundation 2010
KB2028568
http://support.microsoft.com/kb/2028568


Kerberos in einer SharePoint 2010 Umgebung konfigurieren

Folgendes wird benötigt, um Kerberos in einer SharePoint Umgebung aufzusetzen
- Service Class für die SPNs (HTTP für SharePoint Web Applications, MSSQLSvc für die Standard SQL Server Instanz)
- Hostnamen der Server (FQDN ohne Domainangabe)
- Full Qualified Domain Name (FQDN) für alle Web Applications und Server
- Port Nummern für die SPNs (keine Portangabe für SharePoint Web Applications, Port 1433 für SQL
- Die Domain Benutzerkonten für die SPNs (Service und Application Pool Accounts)

In Active Directory Users and Computers > Computer > Computer Name > Properties > Delegation muss Trust computer for delegation to any service (Kerberos only) aktiviert werden. Für die Benutzer muss in den Eigenschaften (Reiter Account > Account options) Account is trusted for delegation aktiviert werden.

Das muss für folgende Server und User gemacht werden:
- Alle SharePoint Server Computer Accounts
- SQL Server Computer Accounts
- SQL Server Service User Account
- Application Pool User Account

Ein SPN enthält eine Service-Klasse, Hostnamen und manchmal eine Port-Nummer. Es wird empfohlen, sowohl den Hostnamen und FQDN der Web-Anwendungen registrieren, auch wenn nur eine davon verwendet werden soll.

Zum Beispiel:
setspn.exe –A MSSQLSvc/SqlServer:1433 Domain\Account
setspn.exe –A MSSQLSvc/SqlServer.domain.local:1433 Domain\Account

SPN für einen Domänen Account registrieren:
setspn.exe –A HTTP/intranet.domain Domain\Account

Auflisten des SPN für einen Account:
setspn.exe –L DOMAIN\Account

SPN löschen:
setspn.exe –D HTTP/intranet.domain.local DOMAIN\Account

Mehr zu Service Principal Names (SPN): http://support.microsoft.com/kb/929650 oder http://technet.microsoft.com/en-us/library/ms191153.aspx oder http://technet.microsoft.com/en-us/library/ms191153.aspx


Kerberos aktivieren

Central Administration > Application Management > Authentication providers
Web Application auswählen, welche Kerberos nutzen soll
Im Ribbon Authentication Provider anklicken und Negotiate (Kerberos) markieren.
Auf den SharePoint Web Front End Servern iisreset ausführen.

Weitere Informationen zur Kerberos in SharePoint 2010: http://technet.microsoft.com/en-us/library/ee806870.aspx


Kerberos in der SharePoint Umgebung testen

Um zu prüfen, ob Kerberos aktiviert ist, wird am besten das Security Event Log auf erfolgreiche Kerberos Logon Events überprüft. Tauchen Fehler auf, sollte folgendes überprüft werden:
- Datum und Zeit auf allen Servern korrekt gesetzt
- Das Bentutzerkonto ist in der Domain nicht gesperrt
- Der Service oder die Applikation laufen unter dem richtigen Domänenkonto
- Delegation ist für Computer- und Benutzer-Konten aktiviert
- Die SPNs wurden in Active Directory korrekt gesetzt