Eines der Probleme, die das auslösen können ist der SharePoint Timer Service (Windows SharePoint Services Timer). Wenn dieser Dienst nicht gestartet ist, kann es zu diesem Fehler kommen. Bei mir war dies der Fall - leider erscheint aber nach dem Start dieses Dienstes und einem IISRESET immer noch die Fehlermeldung.

Hat jemand dieses Problem schon mal lösen können?

Update: nach einem Restart des Timer Dienstes und einem oder mehreren IISRESETs funktionierte es doch. Hatte wohl übersehen, dass auf der “Convert License” Seite plötzlich “Office SharePoint Server with Enterprise Client Access License” stand - obwohl vorher die Fehlermeldung kam - und den Key nochmal eingegeben: Resultat war natürlich wieder ein Fehler - weil ich schon lizensiert hatte!

This product key cannot be used to convert Office SharePoint Server Trial with Enterprise Client Access License to Office SharePoint Server with Enterprise Client Access License.

Leider stimmt diese Meldung. Ein Wechsel von Enterprise zu Standard ist nicht möglich. Die möglichen Upgrade-Wege sind im Microsoft SharePoint Team Blog notiert: Version to Version Supported Upgrade Paths.

Mögliches Vorgehen in einem solchen Fall: Neuinstallation von SharePoint in Standard-Version. Dann die Inhaltsdatenbanken der neuen Farm hinzufügen. Dieser Weg habe ich bisher aber nicht versucht.

Joel Oleson und Mike Watson schreiben zusammen ein erstes SharePoint 14 Buch für den Verlag O’Reilly.

Ich glaube aber, das Produkt wird unter einer anderen Bezeichnung als “SharePoint 14″ auf den Markt gebracht. Wahrscheinlichere Möglichkeiten wären Microsoft Office SharePoint Server 2009 oder Microsoft Office SharePoint Server 2010. Oder werden wir wirklich schon wieder weg kommen von “MOSS”?

1. Content Types: Contains a definition of a SharePoint content type.
2. Content Type Binding: Actually applies a content type to a document library.
3. Control: Allows you to replace existing controls on the page, such as the search or navigation with your own custom control.
4. Custom Action: You can define custom actions such as add a new menu item in “Site Actions”.
5. Feature/Site Template Association: This allows you to bind a feature to a site template so that the feature is included in new sites based on that template.
6. Field: Contains a field, or column definition that can be reused in multiple lists.
7. Hide Custom Action: Opposite to “Custom Action”, where you want to hide menu items.
8. List Instance: Provisions a SharePoint site with a list which includes specific data.
9. List Template: A list definition or template, which defines a list that can be provisioned to a SharePoint site.
10. Module: Deploys files which are included when provisioning sites. (This is how branding can be deployed via feature).
11. Receiver: Defines an event handler for a list, or document library.
12. Workflow: Defines a workflow for a list, or document library.

Die Liste sollte auch in “plain English” verständlich sein, denke ich.

Basierend auf diesem Artikel habe ich verschiedene Control Adapters geschrieben, die mir in den Webpart-Code hinein zusätzliche class=”meineCSSKlasse” hineinschreiben (zum Beispiel in das rechte TD eines Webpart-Headers). Auch habe ich mit solchen Adapters etliche HTML-Codeschnippsel entfernt, die ich in dem Markup einfach nicht mag.

Die Website (http://createGUID.com) als Bookmark speichern und bei GUID-Bedarf dort eins abholen - schnell und unkompliziert. (GUIDs explained)

   1: <SharepointWebControls:SPSecurityTrimmedControl runat="server" Permissions="ManageWeb">

   2:     This is only visible to users who can manage current web..

   3: </SharepointWebControls:SPSecurityTrimmedControl>

Und einige mehr. Reinschauen lohnt sich auf jeden Fall - auch die Hinweise auf weitere Controls (und auch auf Probleme mit einzelnen Attributen) beachten.

Chris O’Brien: Great controls to be aware of when building SharePoint sites

Neu in Version 1.2:
Nichts. Nur Kompatibilität mit Visual Studio 2008. Funktioniert NICHT mit Visual Studio 2005.

Los, Junge, beeil dich. Hol den Stecken:
VSeWSS 1.2 Download

Ein Beispiel:
Es soll eine Site Directory geführt werden mit allen Projektsites. Beim Erstellen eines Projektsites sollen diverse Metadaten angegeben werden und auch direkt am gleichen Ort die berechtigte Gruppe gewählt werden. Mit der Standardfunktionalität stösst man (immer wieder) schnell an Grenzen.

Probleme sind:
Angabe von Site Directory Metadata in der Siteerstellungsmaske in schlecht gelöst in SharePoint. Für Lookup-Felder werden einfache Textfelder dargestellt, der Benutzer wird in den meisten Fällen falsche Angaben machen. Berechtigungen werden erst auf einer Folgeseite angegeben. Zudem ist man mit dem Standard-Site-Directory recht limitiert.

Lösung:
Site-Verzeichnis als separate benutzerdefinierte Liste führen. Man kann danach alle normalen Listenfunktionen und Webparts verwenden. Lookupfelder gehen und man kann wie sonst überall in SharePoint weitere Spalten hinzufügen. Und hier kommt der EventHandler zum Zug: beim Erstellen eines neuen Eintrags in der Liste, wird anhand der gewählten Daten automatisch eine Website erstellt und (bei Bedarf) darauf die Berechtigungen korrekt eingestellt.

Jetzt eben: wo könnt ihr euch den Einsatz von EventHandlern vorstellen? Oder habt ihr Fragen? Dazu ist der Kommentarbereich offen.