christian-heim.de

Peoplepicker findet keine Active Directory User

16. März 2010

Installiert man SharePoint auf Windows 2008 R2 Systemen, kann es zu einem seltsamen Verhalten des Peoplepickers kommen:

Problembeschreibung:
Auf einem SharePoint System können per Peoplepicker keine User aus dem AD gefunden werden. Lediglich User, die schon mal mit der Sitecollection gearbeitet haben können gefunden werden.

Das Problem wird vom Betriebssystem hervorgerufen und kann sich deshalb auch in anderen Anwendungen beim Auflösen von AD Usernamen auftreten (z.B. SQL Server).

Folgende Fehlermeldungen können dabei auftreten:

The trust relationship between this workstation and the primary domain failed.

Betrifft:
Das Problem betrifft nur Windows 2008 Server R2 oder Windows 7 Systeme.

Problemlösung:
Durch Installation des Hotfixes KB976494 wird das Problem gelöst.

Migrierte Email-Aktivierte Listen empfangen nach Database Attach keine Mails mehr

21. Februar 2010

stsadm.exe

Thema dieses Beitrags:
Wichtiger Hinweis zur Verwendung von STSADM -o ADDCONTENTDB

Letzte Woche führte ich bei einem Kunden eine Migration/Datenumzug einer produktiven SharePoint Umgebung auf eine neue große Farm durch. Durch das Kopieren aller Inhaltsdatenbanken auf den SQL Cluster der neuen Farm und Anhängen dieser an die neue Webapplication wurden 85 Sitecollections mit 100 GB Daten in 32 Datenbanken umgezogen.

Durch gute Vorausplanung und einer Testmigration wurde sichergestellt, dass alle Inhalte einwandfrei migriert werden können. Ein sehr detaillierter Ablaufplan/Checkliste half mir bei der Arbeit. Ein wichtiger Punkt dieser Liste war das Prüfen bestehender Email Aktivierter SharePoint Listen. Auf dem alten System existierten über 100 Listen, die Emails empfangen. Ich checkte vor dem Umzug auf der alten Umgebung in der SharePoint_Config Datenbank (Tabelle dbo.EmailEnabledLists), wieviele Email-Aliase insgesamt vergeben wurden. So erhielt ich eine genau Übersicht der Listen mit Emailadressen.

Nach dem erfolgreichen Umkopieren der Datenbanken auf die neue Umgebung und dem Anhängen per STSADM -o ADDCONTENTDB musste geprüft werden, ob all diese Email Aktivierten Listen in der SharePoint_Config Datenbank der neuen Farm eingetragen wurden.
Das war der Punkt, an dem ich kurz erschrak, denn es waren keine Einträge zu finden.

Ganz offensichtlich werden durch einen Datenbank Attach bestehende Listen mit Emailadressen nicht in die ConfigDB propagiert.
Ich fand jedoch heraus, dass sich dieses Problem durch einen weiteren STSADM Befehl korrigieren lässt:

STSADM -o REFRESHDMS -url http://webapplication.domain.com
Dokumentation der REFRESHDMS Operation

Der Befehl prüft alle existierende Listen ab und trägt vorhandene Emailadressen in die dbo.EmailEnabledLists der SharePoint_Config. Nachdem ich den Befehl auf die betroffene Webapplication abgesetzt hatte, waren alle Email-Aliase und dazugehörigen List-IDs ordnungsgemäß registriert. Inhalte konnten danach mit Hilfe von Testmails ohne Probleme in diese Listen veröffentlicht werden.

Fazit:
Nach einem Anhängen von Datenbanken mit STSADM -o ADDCONTENTDB sollte mit STSADM -o REFRESHDMS die dbo.EMailEnabledLists aktualisiert werden!

Verwaiste Benutzer aus SharePoint Sitecollections löschen

1. Februar 2010

Auf vielen SharePoint Systemen werden Benutzer direkt in SharePoint Sitecollections (SC) berechtigt, statt über Active Directory Gruppen. Werden solche Active Directory Userkonten gelöscht (weil ein Mitarbeiter das Unternehmen verlässt), bleiben Berechtigungen erhalten und Namen von Usern stehen noch in den Berechtigungen dieser Sitecollections, obwohl sie schon lange nicht mehr im Unternehmen sind. So kann es passieren, dass sehr viele verwaiste/nicht mehr existierende Useraccounts in Site-Strukturen bestehen bleiben. Daran stören sich (verständlicherweise) viele unserer Kunden.

Für dieses Problem gibt es ein freies Kommandozeilentool, welches sich genau diesem Problem annimmt. SharePoint Orphaned Users Cleanup 1.3 ermittelt orphane Userkonten und entfernt sie automatisch auf Wunsch, samt eventuell gesetzter Alerts. Dies kann auch rekursiv erfolgen, wenn Berechtigungen unterbrochen wurden und z.B. auf Listen individuell vergeben wurden.

Weitere Informationen & Download:
SharePoint Orphaned Users Cleanup 1.3
http://landofsharepoint.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22242

STSADM preparetomove Operation nicht mehr verwenden

20. Januar 2010

stsadm.exe

Der preparetomove STSADM-Befehl wurde ursprünglich eingeführt, um Content-Datenbanken auf einen Umzug (zum Beispiel auf eine andere SharePoint Farm) vorzubereiten. Dies war ein wichtiger vorzunehmender Vorgang, den man entweder vor dem Umzug oder aber nachträglich nach dem Umzug ausführen musste.
Preparetomove: Stsadm operation (Office SharePoint Server)

Dieses Vorgehen muss seit der Einführung des SharePoint Infrastruktur Updates (15 Juli 2008, SharePoint Build 12.0.0.6318) nicht mehr beachtet werden. Das preparetomove Kommando wird daher jetzt obsolet und soll nicht mehr verwendet werden.

Quelle: Deploy software updates for Office SharePoint Server 2007
Dort heisst es: “If you have installed the Infrastructure Update or later, you must not run preparetomove.”

Man stößt im Internet immer wieder auf Artikel, die sogar beschreiben, dass durch die Verwendung des Befehls auf Systeme mit Infrastruktur Update oder höher Probleme hervorgerufen werden können.
(z. Bsp. http://blogs.msdn.com/toddca/archive/2009/01/30/preparetomove-away-from-running-this-command.aspx)

Hosts Datei auf SharePoint Index Server verschwunden

26. November 2009

Bei der Installation einer Multi-Server Farm bei einem Kunden hatte ich gestern auf dem MOSS Index-Server das folgende Kuriosum.
Die Topologie der Farm war wie folgt:

2 Webfrontend-Server für Userrequests (load-balanced)
1 Index-Server für die Suche
1 dedizierter Webfrontendserver für die Suchanfragen des Indexservers
SQL-Server 2008 Cluster mit zwei Nodes

Betriebssysteme aller Server: Windows Server 2008 R2
Versionsstand SharePoint: MOSS 2007 SP2 plus Kumulatives Update Package vom Oktober 2009

Problembeschreibung:

Im Application Eventlog des Index-Servers wurde Ereignis 6482 protokolliert (alle 2 Minuten):

Log Name: Application
Source: Office SharePoint Server
Date: 25.11.2009 09:49:16
Event ID: 6482
Task Category: Office Server Shared Services
Description: Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (3f663847-13a5-4174-b509-15ec477d67f3).
Reason: Access to the path ‘C:\Windows\system32\drivers\etc\HOSTS’ is denied.

Techinal Support Details:
System.UnauthorizedAccessException: Access to the path ‘C:\Windows\system32\drivers\etc\HOSTS’ is denied. (…)

Bei der Kontrolle der Hosts Datei musste ich mit Schrecken feststellen, dass es diese nicht mehr gibt …
Die Ursache des Problems ist folgende:

In der Konfiguration der Office SharePoint Search des Index-Servers wurde angegeben, dass der für die Suche dedizierte Webfrontend-Server benutzt werden soll. SharePoint versucht dann, die Hosts Datei des Index-Servers neu anzulegen, mit neuen Einträgen (alle SharePoint Webanwendungs-URLs werden auf den Wunsch-WFE Server umgelenkt):

Auslesen der bestehenden Hosts Datei
Sichern der bestehenden Hosts Datei nach %commonprogramfiles%\Microsoft Shared\Web Server Extensions\12\Log
Löschen der Hosts Datei
Erstellen einer neuen Hosts Datei

Nun kann es unter Windows 2008 R2 offensichtlich vorkommen, dass aufgrund fehlender Berechtigungen, die Hosts Datei zwar gelöscht, aber nicht neu angelegt werden kann. Dann kommt es zum oben beschriebenen Problem.

Lösung des Problems:

Wiederherstellen der gesicherten Hosts Datei von %commonprogramfiles%\Microsoft Shared\Web Server Extensions\12\Log
bzw.
Erstellen einer neuen Hosts Datei von Hand.
Setzen zusätzlicher Berechtigungen auf den Ordner C:\Windows\System32\Drivers\etc :

Lokale Gruppe %COMPUTERNAME%\WSS_ADMIN_WPG bekommt folgende Rechte