Durch die Integration von PowerShell in SharePoint 2010 geht Microsoft endlich einen Weg in die richtige Richtung. Schon im Beta Status sind sehr viele STSADM Befehle entfernt und nur sehr wenige hinzugefügt wurden. Ungefähr 20 Befehle wurden entfernt und nur 6 hinzugefügt. Dies ist einfach nachzuvollziehen in dem

stsadm -help

jeweils auf einem Sharepoint 2007 System und auf einem Sharepoint 2010 System ausgeführt und anschließend die Ausgabe verglichen wird. Ich finde diesen Weg richtig cool. Wahrscheinlich weil ich mich mit STSADM nie so richtig anfreunden konnte.

PowerShell eröffnet dem geneigten Administrator oder Entwickler jetzt vollkommen neue Ansätze Sharepoint zu administrieren.

Jeder Entwickler , welcher mit dem Sharepoint Objekt Modell schon etwas vertraut ist, wird vermutlich wissen, dass Instanzen von SPSite, SPWeb oder im allgemeinen alle Klassen welche IDisposable implemtieren, sehr viele Ressourcen verbrauchen können. Gleich zum Start hat das Sharepoint Team nun zwei CMDLETS entwickelt welche den Umgang mit Disposable Objekten vereinfachen sollen und uns das Leben erleichtern.

Start-SPAssigment

Stop-SPAssigment

Es gibt drei Levels des Assignments.

• No Assignment
• Simple Assignment
• Advanced Assignment

No Assignment

Diesen Weg sollte jeder kennen. Es wird ein SPWeb Objekt erstellt, welches verarbeitet aber nicht mehr disposed wird.

$web = Get-SPWeb "http://localhost"
$web.Title = "Hallo SharePoint Usergroup"
$web.Update()

Simple Assignment

Beim “simple assignment” werden alle Objekte dem “global assignment store” zugewiesen. Der Aufruf erfolgt per

Start-SPAssignment -Global

Das “Disposen” aller Objekte erfolgt beim Aufruf von

Stop-SPAssignment

Start-SPAssignment -Global
$web = Get-SPWeb "http://localhost"
$web.Title = "Hallo SharePoint Usergroup"
$web.Update()
Stop-SPAssignment -Global

Advanced Assignment

Beim “advanced assignment” werden alle Objekte einem “named store” zugewießen. Das “Disposen” erfolgt durch den Aufruf von Stop-SPAssignment  -Bezeichner

$gc = Start-SPAssignment
$site = $gc | Get-SPSite "http://localhost"
$site.Allwebs
$gc | Stop-SPAssignment

Zu beachten wäre noch dass beim Schließen der PowerShell alle Objekte “disposed” werden.

Heute habe ich versucht, über ein Nutzerinterface (GUI) eine Site Collection (Websitesammlung) anzulegen, welche über eine eigene Url erreichbar ist (Host Named Site Collection). Wie erwartet ging dies nicht ohne jegliche Komplikationen über die Bühne.

Um eine Host Named Site Collection anzulegen, stehen dem Entwickler zwei Varianten zur Verfügung. Die erste und von mir bevorzugte ist die programmatische:

Mit der folgenden Methode (z.B. in einer Konsolenanwendung) kann eine Host Named Site Collection angelegt werden:

void createHostNamedSC(string siteUrl,string siteName,string siteDescription)
{
SPWebApplication webApp = SPWebApplication.Lookup(new Uri(SPContext.Current.Web.Url));
SPSiteCollection sites = webApp.Sites;
SPSite Site = null;
Site = sites.Add(siteUrl, siteName, siteDescription, 1033, “STS#0″, “Domain\\Administrator”, “Owner_Display_Name”, “Owner_Email”, “Domain\\Administrator”, “Secondary_Owner_Display_Name”, “Secondary_Owner_Email”, true);
}

Die zweite Variante wird über stsadm realisiert:
Dazu wird in der Console folgender Aufruf gestartet:

stsadm.exe -o createsite
-url http://hnsc.webapplication.com
-ownerlogin Domain\Administrator
-owneremail Administrator@webapplication.com
-hhurl http://www.webapplication.com

Die Webapplication stellt dabei der Eintrag hinter -hhurl (http://www.webapplication.com) dar.
Unter -url wird die gewünschte URL der neuen Site Collection angegeben.

Hat man sich für eine der beiden Methoden entschieden und diese ausgeführt, müssen noch die Hostheader für die Webapplikation angepasst werden. Das Hinzufügen der Hostheader kann einerseits über die Sharepoint Zentral-Administration erfolgen oder aber über den Internet Information Services (IIS) Manager.
Ich habe mich dabei für die Einstellung innerhalb des IIS entschieden.

Dazu öffnet man den IIS Manager und öffnet über das Kontext-Menü die Einstellungen (Properties) der Webapplikation.

• Anschließend wählt man Advanced
• Menüpunkt Add wählen
• Als letzter Schritt muss der Port und die Domain noch eingetragen werden
• Alles bestätigen und einen IIS Reset durchführen (ggf. host Datei Domain eintragen)

Nach diesen Schritten sollte die eben erstelle Site Collection unter ihrer Domain aufrufbar sein.

Nachdem ich diese Schritte alle erfolgreich ausgeführt hatte, versuchte ich mich nun an meiner neuen Host Named Site Collection anzumelden. Obwohl ich augenscheinlich alle Credentials ordnungsgemäß eingegeben hatte, bekam ich folgende Seite zu sehen:

HTTP 401.1 – Nicht autorisiert: Fehler bei der Anmeldung

Nachdem ich schon fast anfangen wollte, mir die Haare auszureißen, fand ich eine Bugbeschreibung von Microsoft unter

Fehler 401.1 beim Aufrufen einer Website

Update:

Spencer Harbar weißt auf seinem Blog, in einen interessanten Artikel,  darauf hin, dass dieser Bugfix nicht auf Produktiv – Maschinen eingesetzt werden sollte. Für den externen Zugriff auf die Site Collection tritt dieses Problem in der Regel nicht auf. Deshalb richtet sich dieser Fix nur an Entwickler welche auf der selben Maschine mit mehr als einer Host Named Site Collection arbeiten.

Laut Microsoft tritt dieser Fehler nur auf, wenn die Website integrierte Authentifizierung verwendet und ihr Name der lokalen Loopbackadresse zugeordnet ist. Wenn dann noch Windows Server 2003 mit SP1 installiert ist, schlägt der Fehlerteufel zu. Demnach schlägt die Authentifizierung fehl, wenn der Domänenname oder der benutzerdefinierte Hostheader nicht mit dem lokalen Computernamen übereinstimmen.

Um den Bug zu beheben, müssen folgende Schritte ausgeführt werden.

• Registry Editor öffnen mit “regedit”
• Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa suchen
• auf LSA mit rechter Maustaste drücken ->Neu->DWORD
• Name DisableLoopbackCheck vergeben und Wert 1 eintragen
• Computer neu starten

Nach dem Neustart war ich in der Lage, die Site Collection unter ihrer Domain aufzurufen.

Das Programm STSADM ist ein sehr nützliches Tool für häufig wiederkehrende Aufgaben auf einem Sharepoint-Server. Einer der großen Vorteile ist es, dass man diese Aufgaben per Kommandozeile und damit z.B. per Batch abarbeiten kann.

An manchen Stellen kommt aber auch der dieses Programm an seine Grenzen. Glücklicherweise kann der beherzte Entwickler hier selbst eingreifen und sich eigene Erweiterungen schreiben, die genau den Bedarfsfall abbilden, der gerade vorliegt.

Die Entwicklung einer eigenen Erweiterung ist gar nicht so kompliziert, wie es sich anhört. Dazu sind folgende Schritte notwendig:

Zunächst erstellt man sich ein neues DLL-Projekt und verlinkt die Microsoft.Sharepoint-Assembly. Jede Klasse, die das ISPStsadmCommand-Interface implementiert, kann als Erweiterung fungieren.

Das Interface beinhaltet 2 Funktionen. Einerseits GetHelpMessage – diese Funktion wird dann aufgerufen, wenn man stsadm -help <befehl> aufruft; andererseits  Run – diese Funktion wird aufgerufen, wenn man stsadm -o <befehl> in der Kommandozeile eingibt.

Beide Methoden beinhalten einen Parameter command. Dieser beinhaltet zur Ausführungszeit den Befehl – vermutlich aus dem Grund, da eine implementierende Klasse auf mehrere Befehle gemappt werden kann. Das Mapping selbst ist recht einfach. Dazu erzeugt man sich eine neue XML-Datei mit dem Namen stsadmcommands.<eigenername>.xml, die später unter “Gemeinsame Dateien\Microsoft Shared\web server extensions\12\CONFIG” abgelegt wird.

Im Beispiel wird das command copynewfiles auf die eben erstellte Klasse CopyFiles gemappt.

Nachdem die DLL nun in den GAC deployed ist, kann der Aufruf erfolgen.