Aus dem Alltag: Die Explorer Ansicht verlangt ein Login


Problem

Wenn Sie auf einem Windows Vista, 7 oder 2008 und 2008 R2 Server eine SharePoint Bibliothek in der Explorer Ansicht öffnen wollen, erscheint immer das Login Fenster und fragt nach einer erneuten Authentifizierung, obwohl Sie bereits mit einem berechtigten Benutzer angemeldet sind.

image

image

Voraussetzung für die Explorer Ansicht auf einem 2008 oder 2008 R2 Server ist auch die Desktop Experience, welche als Feature eingeschaltet werden muss. Ohne diese Einstellung werden gar keine Credentials abgefragt. Es geht zwar in diesem Blogpost nicht direkt darum, doch damit keine Missverständnisse entstehen auch noch kurz die Anleitung dazu:

  1. Server Manager öffnen
  2. Auf der linken Seite Features anklicken
  3. Rechts auf Add Feature klicken
    image
  4. Feature “Desktop Experience” hinzufügen
    image

Ursache

Seit Vista bzw. Windows Server 2008 werden bei WebDav die Authentifizierungsinformationen (Credentials) nur an Hostnamen übermittelt, welche keine Punkte im Hostnamen haben. Man geht davon aus, dass innerhalb eines Netzwerkes nicht mit fully qualified domain Namen gearbeitet wird, was nicht immer der Fall ist. Wenn Sie also mit http://mywebsite arbeiten, dann erscheint das Problem nicht. Wenn Sie hingegen mit http://mywebsite.mydomain.ch arbeiten, dann erscheint das Problem.

Lösung

Es gibt nun für dieses Szenario zwei Lösungen:

A: Fügen Sie eine Registry Anpassung durch

In diesem Szenario bestimmen Sie, an welche fully qualified Domain Names WebDav die Credentials mitgeben soll. Achtung: Diese Lösung schliesst Änderungen in der Registry ein, bitte lassen Sie sich ggf. von einem Fachmann beraten, die Anpassungen machen Sie auf eigene Verantwortung. Die Anpassung muss auf jeder Maschine vorgenommen werden, auf welcher Sie über FQDN WebDav machen wollen.

  1. Klicken Sie auf start und geben Sie “regedit” ein
  2. Navigieren Sie zum Knoten HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
  3. Klicken Sie mit der rechten Maustaste in das Feld mit den Einträgen und klicken Sie auf Neu und dann auf Multi Value
    image
  4. Geben Sie den Wert “AuthForwardServerList” ein und drücken Sie auf Enter
  5. öffnen Sie den Schlüssel mit einem Doppelklick und geben Sie in das Feld alle fully qualified Domain Names ein, auf welche Sie WebDav automatisch öffnen lassen wollen und klicken Sie auf OK
    image
  6. Restarten Sie den Server bzw. den Client auf welchem Sie den Eintrag vorgenommen haben

 

B: Benutzen Sie firmenintern nur einfache Hosteinträge

In diesem Szenario verwenden Sie für interne Aufgaben lediglich die Hostadresse, also http://mywebsite Wollen Sie zu einer fully qualified Adresse eine Hostadresse hinzufügen, so können Sie einen alternativen Zugriffspfad definieren. Tun Sie dies wie folgt:

  1. Öffnen Sie die Zentraladministration
  2. Navigieren Sie zu “Manage web applications”image
  3. Wählen Sie die Webapplikation aus, welche Sie gerne anpassen würden und klicken Sie “Extend”
    image
  4. Geben Sie die Angaben ein, welche für Ihre Webapplikation zutreffen, stellen Sie sicher, dass Sie im Feld “Hostheader” nur “mywebsite” eingeben, ohne http://, das wird später automatisch hinzugefügt. Wählen Sie Port 80 aus, wählen Sie die Authentifizierung (NTLM / Kerberos) und klicken Sie auf OK

Aus dem Alltag: 503 Service Unavailable in der Central Administration


Problem:

Nachdem ich bei einem Kunden erfolgreich SQL Server 2008 R2 und SharePoint Server 2010 installiert hatte, erhielt ich beim erstmaligen Öffnen der Central Administration (Zentraladministration) den folgenden Fehler:

Service Unavailable

——————————————————————————-

HTTP Error 503. The service is unavailable.

 

Die Kontrolle im Windows Log ergab folgende drei Einträge:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5021
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
The identity of application pool SharePoint Central Administration v4 is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request.  If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5057
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
Application pool SharePoint Central Administration v4 has been disabled. Windows Process Activation Service (WAS) did not create a worker process to serve the application pool because the application pool identity is invalid.

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5059
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
Application pool SharePoint Central Administration v4 has been disabled. Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.

Grund:

Wie aus den Log Einträgen ersichtlich wird, fehlt dem Application Pool Account die folgende Berechtigung “Logon as a batch job”, welche in den Security Policies definiert werden können. In unserem Fall war diese Einstellung von einer überliegenden Policy auf unser System publiziert worden. Diese Berechtigung wird benötigt, damit der Windows Process Activation Service dem entsprechenden Application Pool einen Worker Process zuordnen kann.

Lösung:

  1. Kontrollieren Sie, ob die “Logon as a batch job” Policy von einer höheren Instanz gesteuert wird.
    1. Klicken Sie auf Start –> ausführen
    2. Geben Sie “secpol.msc” ein und drücken Sie Enter
    3. Navigieren Sie zu Local Policies –> User Rights Assignment –> Log on as a batch job
      image
  2. Ist die “Logon as a batch job” Policy nicht übersteuert, kontrollieren Sie ob IIS_IUSRS berechtigt sind. Wenn nicht, vergeben Sie diese.
  3. Ist die Policy übersteuert (sie können lokal keine Änderungen vornehmen), so bearbeiten Sie die entsprechend übergeordnete Policy:
    1. Erstellen Sie eine Active Directory Gruppe, welcher Sie alle Application Pool User von SharePoint zuordnen (inkl. dem Service User für die Service Applications (SharePoint 2010) oder dem Shared Services Provider (SharePoint 2007) und dem Farm User für die Central Administration)
    2. Fügen Sie die Active Directory Gruppe der die Policy “Logon as a batch job” hinzu

So long, Samuel Zürcher