Seit dem 23.02.2010 steht das Cumulative Update Februar 2010 für Windows SharePoint Services 3.0 und  Microsoft Office SharePoint Server 2007 zum download bereit. Artikel vollständig lesen »

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.

Die letzten Tage habe ich damit verbracht, mich mit den Besonderheiten(oder besser absurden Angewohnheiten) von Sharepoint 2007  zu befassen. Speziell mit dem programmatischen Anlegen von Ordnern und Unterordnern in Sharepoint Dokumenten – Bibliotheken beziehungsweise Listen.

Hier meine gesammelten Erfahrungen über das Anlegen von Ordnern in

• Bild- und Dokumentenbibliotheken (Picture- and Documentlibrary)
• Webseiten Bibliotheken (Pages Library)
• Wiederverwendbare Inhalte (Reusable Content)
  

Bild- und Dokumentenbibliotheken (Picture- and Documentlibrary)

Angefangen hat das ganze mit dem Versuch, Unterordner in einer Bild- und Dokumentenbibliothek anzulegen. Hier stellte sich Sharepoint gutmütig. Innerhalb dieser Bibliotheken kann über das Menü (Neu /New) ein Ordner angelegt werden, in welchen später auch Inhalte gespeichert werden können.
Soll das Anlegen der Ordner programmatisch (zum Beispiel über ein Feature) erfolgen,  kann folgender Programmcode verwendet werden.

String folderList = "Bilder";
SPList spList = webContext.Lists[folderList];
String folderUrl = spList.RootFolder.ServerRelativeUrl.ToString();
SPFolderCollection foldersColl = web.GetFolder(folderUrl).SubFolders;
SPFolder newFolder = folders.Add("Unterordner");
spList.Update();

Bis hierher könnte man meinen, Sharepoint bietet dem Entwickler mit seiner API alle Möglichkeiten, Listen zu modifizieren und so zum Beispiel Ordner anzulegen.

Webseiten Bibliotheken (Pages Library)

Ich wurde jedoch eines Besseren belehrt, als ich versuchte, innerhalb der Webseiten Bibliothek (Pages Library) einen Unterordner anzulegen. Anders als in einer Bildbibliothek bietet hier das Menü nicht die Möglichkeit, einen Ordner hinzuzufügen.

Da das Menü fehlte, dachte ich mir, versuche ich es doch einfach per Programmcode. Hierzu kann der obige Code verwendet werden, indem einfach der String für die Liste auf Pages geändert wird.

String folderList = "Pages";

Das Ergebnis sieht wie oben angezeigt aus. Der Unterordner erscheint unterhalb der Webseiten Bibiliothek. Eigentlich das gewünschte Ergebnis … aber dieses Ergbnis hat einen Haken. Unterhalb dieses Ordners können keine Pages angelegt werden und der Unterordner hat auch keinen Menüpunkt innerhalb der GUI für das Anlegen einer Page.

Nach intensiver Recherche fand ich einen Knowledge Article von Microsoft zu diesem Thema.

http://support.microsoft.com/kb/948614/en-us
Daraus geht klar hervor, dass dieses Verhalten von Microsoft nicht unterstützt wird. Schade eigentlich.

Wiederverwendbare Inhalte (Reusable Content)

Der letzte Schritt sollte das Anlegen eines Unterordners unterhalb der Wiederverwendbaren Inhalte Bibliothek (Reusable Content) darstellen.  Da das Menü die Möglichkeit bietet, bequem einen Unterordner in dieser Liste zu erstellen, dachte ich, der Programmcode von oben sollte sehr gut dafür funktionieren … weit gefehlt. Wieder wurde ich eines Besseren belehrt. Der Code bewirkte in dieser Liste rein gar nix.

Nach einer Phase des Debuggens wurde mir klar, wie Sharepoint hier arbeitet. Anstatt einen SPFolder anzulegen, muss hier ein ein neues SPListItem angelegt werden. Der Trick an der Sache ist, diesem SPListItem den gleichen SPContentType zuzuweisen wie Sharepoint ihn verwendet, um einen Ordner anzulegen.

Wir benötigen den ContentType für Folder. Wird dieser ContentType einen SPListItem zugewiesen, erscheint dieses danach auch in der Wiederverwendbaren Inhalte Liste als Ordner und besitzt alle nötigen Menüpunkte. Der passende SPContentType kann wie folgt ermittelt werden:


SPContentTypeId contentId = new SPContentTypeId("0x0120");
SPContentTypeId listCTID = reuseList.ContentTypes.BestMatch(contentId);
SPContentType cType = reuseList.ContentTypes[listCTID];
List contentTypes = new List();
contentTypes.Add(cType);

Das Ganze habe ich anschließend in eine generische Methode verpackt, welche wie folgt aussieht:

Diese Methode legt nun ein SPListItem an, welches den Content Type Folder besitzt und auch entsprechend in der Liste angezeigt wird. Da der Ordner im Verzeichnisbaum jedoch nicht derselbe ist wie in der Liste angezeigt, muss  dieser noch umbenannt werden.  Anschließend kann dieser Ordner genauso verwendet werden, als ob er über das grafische Menü angelegt worden wäre. War doch ganz einfach… – oder?
Zum besseren Kopieren hier das Ganze nochmal als Text:

internal static void SubFolder2ReusableList(SPList reuseList, string reusableFolder)
 {
 reuseList.ContentTypesEnabled = true;
 //get the content type for the folder
 SPContentTypeId contentId = new SPContentTypeId("0x0120");
 SPContentTypeId listCTID = reuseList.ContentTypes.BestMatch(contentId);
 SPContentType cType = reuseList.ContentTypes[listCTID];
 List<SPContentType> contentTypes = new List<SPContentType>();
 contentTypes.Add(cType);

 SPListItem newListItem = reuseList.Items.Add();

 newListItem[SPBuiltInFieldId.ContentTypeId] = cType.Id;
 newListItem[SPBuiltInFieldId.Title] = reusableFolder + "_tmp";
 newListItem.Update();
 reuseList.Update();

 //get the parent folder of the SPListItem which is resident in the left tree
 //its not the same folder as listed in die detail list on the right
 using (SPWeb webContext = reuseList.ParentWeb)
 {
 SPFolder reuseFolder = webContext.GetFolder(newListItem.Url);
 try
 {
 //try to rename the folder on the left
 reuseFolder.MoveTo(reuseList.RootFolder.ServerRelativeUrl + "/" + reusableFolder);
 }
 catch (SPException)
 {
 //if the folder already exist delete it
 SPFolder toDeleteFolder = webContext.GetFolder(reuseList.RootFolder.ServerRelativeUrl + "/" + reusableFolder);
 toDeleteFolder.Delete();
 reuseFolder.MoveTo(reuseList.RootFolder.ServerRelativeUrl + "/" + reusableFolder);

 }
 //rename the _tmp SPListitem to his final name
 newListItem[SPBuiltInFieldId.Title] = reusableFolder;
 newListItem.Update();
 }
 }

Das Service Pack 2 ist nun für Windows SharePoint Services 3.0 und für die 2007er Office Server Familie verfügbar:

• Windows SharePoint Services 3.0 Service Pack 2
• Windows SharePoint Services 3.0 Language Pack Service Pack 2 (x86)
• Windows SharePoint Services 3.0 Language Pack Service Pack 2 (x64)

• Microsoft Office Servers Service Pack 2
• 2007 Microsoft Office Servers Language Pack Service Pack 2 (x86)
• 2007 Microsoft Office Servers Language Pack Service Pack 2 (x64)

Eine Übersicht, welche Punkte geändert wurden, findet sich in folgenden Dokumenten. Zu den Änderungen an WSS und MOSS kommen hier noch Änderungen an Office 2007 Desktop Anwendungen (wie SharePoint Designer):

• Windows SharePoint Services 3.0 Service Pack 2 Changes
• 2007 Office Servers Service Pack 2 Changes
• 2007 Office Desktop Applications Service Pack 2 Changes

Da ich gerade einige Zeit in Grundlagenforschung (in Form von Googlen und viiiel Ausprobieren…) zum Thema Site Variations investiert habe, hier meine gesammelten Erkenntnisse am Stück:

Der MOSS bietet die Möglichkeit, sogenannte Site Variations anzulegen. Diese sind (nicht nur, aber vor allem) eine Grundlage für mehrsprachige Systeme.

Site Variations sind standardmäßig deaktiviert. Zur Aktivierung geht man wie folgt vor:

1. -> Site Settings -> Modify All Site Settings aus dem Site Actions Menü auswählen
2. Auf der Site Settings Seite den Link Variations unter der Gruppe Site Collection Administration auswählen

Standardeinstellungen für Variations

Wenn die Standardeinstellungen für Variations (s. Screenshot) verwendet werden, gilt folgendes:

• Automatic Creation
  • Wenn eine Site oder Page in der Quellvariation erzeugt und dort publiziert wird, wird sie automatisch in jeder Zielvariation erzeugt und ist dort für Administratoren und Approver sichtbar
    • Für normale Nutzer ist sie in einer Zielvariation per Default nicht sichtbar, es kommt “Access denied”, wenn man direkt auf die Url geht.
    • Damit sie in einer Zielvariation auch für normale Nutzer sichtbar ist, muss sie noch von einem Approver oder Administrator in der Zielvariation publiziert werden.
• Recreate Deleted Target Page
  • Wenn in einer Zielvariation eine Sites oder Seite gelöscht wird, wird diese automatisch in der Zielvariation erneut erstellt, sobald in der Quellvariation eine Änderung an der Site bzw. Seite vorgenommen und publiziert wurde.
  • Sie ist dann für Administratoren und Approver sichtbar und muss in der Zielvariation publiziert werden, damit sie für alle Nutzer sichtbar ist.
• Update Target Page Web Parts
  • Wenn in einer Seite in der Quellvariation Webparts hinzugefügt oder gelöscht oder Eigenschaften oder Content (!) geändert werden und die Änderung publiziert wird, wird die Änderung automatisch in jeder Zielvariation angewendet und ist dort für Administratoren und Approver sichtbar.
    • Evtl. in einer Zielvariation vorgenommene Änderung (insbesondere geänderter Content, z.B. übersetzter Text in einem Content Editor Webpart oder im bei Verwendung von Page Layouts verfügbaren Content Editor Control direkt auf der Seite) wird durch die aktuelle Änderung gnadenlos überschrieben!
    • Für normale Nutzer ist die Änderung in einer Zielvariation per Default nicht sichtbar, es wird weiterhin die bis dahin gültige Version angezeigt.
    • Damit die Änderung in einer Zielvariation auch für normale Nutzer sichtbar wird, muss sie noch von einem Approver oder Administrator in der Zielvariation publiziert werden.
  • Es ist möglich, dass ein Approver in einer Zielvariation unabhängig von der Quellvariation Änderungen vornimmt (neue Seite, Änderungen an Webparts, Content) und diese Änderungen durch Publizieren für alle Nutzer dieser Variation sichtbar macht.
    • Man sollte sich aber dabei dessen bewusst sein, dass diese Änderungen (zumindest für alle Approver und Administratoren) in der Standardeinstellung durch Anpassungen an der Quellvariation wieder überschrieben werden.

Im Folgenden wird beschrieben, wie man an den Standardeinstellungen schrauben kann und was genau das Ändern jeder einzelnen Einstellung bewirkt.

Gelöschte Seiten nicht neu anlegen

Die Einstellung „Recreate Deleted Target Page” kann jederzeit geändert werden. Eine Änderung der Einstellung wirkt sich auf alle zukünftigen Anpassungen an Seiten aus.

Wenn die Option “Do not recreate a new target page when the source page is republished” ausgewählt ist, gilt folgendes:

• Wenn in einer Zielvariation eine Sites oder Seite gelöscht wird, wird diese nicht erneut in der Zielvariation erneut erstellt, wenn in der Quellvariation eine Änderung an der Site bzw. Seite vorgenommen und publiziert wurde.
• Wenn die Option wieder geändert wird auf “Recreate a new target page when the source page is republished”, dann wird eine in einer Zielvariation gelöschte Seite nach der nächsten Anpassung der Seite in der Quellvariation und Publikation auch in der Zielvariation erneut erstellt.

Webpart-Änderungen nicht anwenden

Die Einstellung „Update Target Page WebParts” kann jederzeit geändert werden. Eine Änderung der Einstellung wirkt sich auf alle zukünftigen Anpassungen an Seiten aus.

Wenn die Option “Do not update Web Part changes to target pages when variation source page update is propagated” ausgewählt ist, gilt folgendes:

• Wenn in einer Seite in der Quellvariation Webparts hinzugefügt oder gelöscht oder Eigenschaften geändert werden und die Änderung publiziert wird, wird die Änderung nicht in den Zielvariationen angewendet.
• Wenn in einer Seite in der Quellvariation Content direkt (nicht in einem Webpart) geändert wird (z.B. Textbausteine oder Text in einem Content Editor) und die Änderung publiziert wird, wird die Änderung trotzdem automatisch in jeder Zielvariation angewendet und ist dort für Administratoren und Approver sichtbar. Evtl. gleichzeitig oder vorher vorgenommene Änderungen an Webparts werden trotzdem nicht angewendet.
• Alle Aussagen zur Erstellung von Seiten und Sites gelten wie bei den Standardeinstellungen beschrieben. Insbesondere gilt:
  • Wenn eine Seite in der Quellvariation erstellt und vor dem ersten Publizieren Webparts hinzugefügt und konfiguriert werden (z.B. ein Content Editor Webpart mit eingefügtem Inhalt in der Quellsprache), dann wird die komplette Seite incl. aller Webparts/Inhalte beim Publizieren in der Zielvariation erzeugt.
  • Wenn nach dem ersten Publizieren Änderungen bzgl. Webparts vorgenommen werden, werden diese nicht mehr angewendet.
• Wenn die Option geändert wird auf “Update Web Part changes to target pages when variation source page update is propagated”, dann werden nach der nächsten Anpassung einer Seite in der Quellvariation und Publikation auch Änderungen in der Zielvariation angewendet, die vorgenommen wurden, während die Option auf „Nicht anwenden“ eingestellt war.

Variation Labels

Den Abschluss meines kleinen Exkurses sollen die folgenden Erläuterungen zu Variation Labels bilden:

• Ein Variation Label entspricht einer Variation, also z.B. einer Sprache.
• Quell- und Zielvariationen
  • Es gibt genau eine Quellvariation und n Zielvariationen.
  • Die Rollen als Quell- und Zielvariation können nicht nachträglich getauscht werden!
• Genehmigungsworkflow
  • Beim Erstellen der Quellvariation muss ausgewählt werden, ob eine Publishing Site mit oder ohne Workflow als Template verwendet werden soll. Diese Einstellung ist nicht nachträglich änderbar.
  • Es ist möglich, eine Publishing Site ohne Workflow auszuwählen und manuell den MOSS-Standard-Approval-Workflow oder einen angepassten Workflow in der Pages-Dokumentenbibliothek zu aktivieren.
  • Wenn ein Genehmigungsworkflow aktiviert ist, werden Änderungen in der Quellvariation beim Publizieren nicht unmittelbar in der Zielvariation angewendet, sondern der Genehmigungsworkflow startet und erst wenn dieser erfolgreich beendet wurde, werden (abhängig von den Grundeinstellungen für Variationen) die Änderungen in der Zielvariation angewendet.
• Hierarchien erzeugen
  • Das Erstellen der Hierarchie erzeugt die Infrastruktur (Sites und Seiten) für die einzelnen Variationen. Bevor eine Hierarchie erstellt werden kann, müssen zumindest eine Quellvariation und eine Zielvariation vorhanden sein.
  • Es können nachträglich weitere Zielvariationen hinzugefügt werden. Damit diese physisch angelegt werden, muss die Hierarchie erneut erstellt werden.