Das Tool hat den Namen SPContentDBManager und erlaubt die Verwaltung der eingebundenen Content Datenbanken in SharePoint 2007. Gerade bei einer großen Anzahl von Content Datenbanken, fällt die Verwaltung durchaus leichter aus.

Folgende Funktionen sind bereits implementiert:
- Content Datenbanken im Bulk in den Status “disabled” versetzen
- Content Datenbanken im Bulk in den Status “online” versetzen

Features in der nächsten Version:
- Lösen und anbinden von Contentdatenbanken
- Das Limit der SiteCollection und Warnungen verwalten

Links: http://spcontentdbmanager.codeplex.com/

Neuerungen und Verbesserungen:

• Verbesserte Unterstützung für Internet Explorer 9.
• Papierkorb: Sie können eine gelöschte Websitesammlung oder Website wiederherstellen.
• Remote Backup Systems (RBS) und flaches Kopieren können die Ausfallzeiten verringern und die Effizienz steigern, indem die Zeiger auf die Datenbanken und nicht die Datenbanken selbst verschoben werden.
• Mithilfe der verbesserten Speicherverwaltungsfunktion in den Websiteeinstellungen können Sie sehen, welche Ordner wertvollen Speicherplatz belegen.
• Unterstützung für Microsoft SQL Server 2011
• Ein robusterer Search-Host-Verteilungsdienst verbessert Fehlerbehebung und Leistung während der Suchdurchforstung.
• Stellt Sicherungs- und Wiederherstellungsfunktionen zum Wiederherstellen gelöschter Websitesammlungen und Websites bereit.

Hier findet ihr das ServicePack 1 zum Download:

Was wird benötigt?

• Microsoft Project 2010 Professional
• SharePoint Server oder Foundation 2010 mit einer Aufgabenliste

Nun erstellt man wie gewohnt in Project 2010 einen Zeitplan und Aufgabenplan. Wie dies im Detail funktioniert möchte ich hier nicht näher erläutern. So z.B. könnte ein kleiner Aufgabenplan aussehen:

Wichtig hierbei ist, dass den Aufgaben Ressourcen (Personen) zugeordnet werden, damit die Aufgaben von SharePoint später korrekt zugewiesen werden können.

Das Veröffentlichen der Aufgaben funktioniert wie folgt: Über Datei –> Speichern und Senden –>Mit Aufgabenliste synchronisieren gibt man eine SharePoint Site an und wählt eine Aufgabenliste aus. Über den Button synchronisieren werden die Aufgaben aus Microsoft Project 2010 mit SharePoint 2010 synchronisiert.

Das sieht in SharePoint dann wie folgt aus:

Setzt man nun eine neue Ansicht von Typ Balkendiagramm (Gantt) auf, sieht da Ansicht in SharePoint plötzlich wie in Microsoft Projekt 2010 aus. Somit kann man die Aufgaben wesentlich besser in einer zeitlichen Abfolge betrachten.

Eines der wichtigsten Features ist in meinen Augen jedoch die Synchronisation in beide Richtungen. Was würde es einen Projektleiter nutzen, wenn er immer nur seine Aufgaben anderen zuweisen kann aber nie ein Feedback in sein Microsoft Project Diagramm zurückbekommt, ob die Aufgaben durch die Projektteilnehmer bereits erledigt wurden.

Hierzu muss der Projektmanager in Microsoft Project 2010 denselben Weg der Synchronisierung gehen. Also auch über Datei –> Speichern und Senden –>Mit Aufgabenliste synchronisieren. Sollte es Konflikte geben, so werden diese angezeigt.

Diese Wege haben alle etwas gemeinsam, sie funktionieren nur gut, solange man in etwa lokalisieren kann wo der Fehler auftreten wird. Ist man sich darüber jedoch nicht im Klaren erhält, man im Fall einer Exception nur die Standardausgabe in der Workflow History “Fehler im Workflow [NAME]”.

Die Workflow Foundation bietet jedoch die Möglichkeit diesen Standard FaultHandler zu überschreiben und eine eigene Implementierung zu hinterlegen. Somit ist es möglich die Informationen der Fehlerausgabe selbst zu definieren und zu skalieren.

Dazu muss als ersten in der Codeansicht die Funktion HandleFault überschrieben werden. Wie dies in einem konkreten Beispiel aussehen könnte, ist in dem Codesnippet zu erkennen.

Dies funktioniert jedoch nur solange wie das Zielsystem dieselbe Sprache installiert hat wie das Quellsystem. Um die Listendefinition nun trotzdem in einem anderssprachigen Zielsystem verfügbar zu machen, werde ich euch hier einen Workaround vorstellen.

Die STP Datei ist im Prinzip nichts anderes als eine CAB Datei, welche ja im Windows Explorer einfach entpackt werden kann.

1. Benennt eure *.STP einfach in eine *.CAB Datei um
2. Extrahiert alle Dateien aus der CAB Datei
3. Öffnet die manifest.xml in einem Texteditor (z.B. Notepad++)
4. Ersetzt alle Ländercodes durch den gewünschten Ländercode. Der Code 1033 steht für Englisch und der Code 1031 steht für Deutsch.
5. Handelt es sich um ein Site-Template so solltet ihr zusätzlich auch en-us durch de-de ersetzen
6. Speichert alle Änderungen und schließt die manifest.xml
7. Nun müsst ihr eine neue CAB Datei erzeugen, welche alle Dateien aus der alten CAB Datei inkl. der neuen manifest.xml enthält. Hierfür empfehle ich das Tool SimplyZip zu benutzen.
8. Nun müsst ihr die Datei nur noch von *.CAB und *.STP umbenennen und in das Zielsystem importieren und schon steht euch die Listendefinition in der gewünschten Sprache zur Verfügung.

Unter dem Motto Building & Connecting Know-how finden die große SharePoint konferenz sowie die VSone – nur wenige Meter von der Microsoft Zentrale Deutschland entfernt – in München statt. Das neue Designhotel Dolce Munich stellt dabei einen perfekten Ort für Konferenz, Networking, Business Forum sowie Fachausstellung dar. Erleben Sie auf 10 parallelen Vortragsreihen mehr als 120 Sessions zu allen Top-Themen rund um aktuelle Microsoft-Technologien – von SharePoint und ECM über SQL Server, Business Intelligence, Visual Studio, .NET, Silverlight, Windows Azure und Co. bis hin zu User Interface & Design.

Infos und Anmeldung unter www.SharePointKonferenz.de

Achtung: Für die Visio Services benötigt man die Enterprise Lizenz des SharePoint Servers 2010

Ist die Visualisierung von Workflows in SharePoint 2010 erst einmal eingerichtet so findet man folgende Visualisierung des Workflows in dem jeweiligen Workflow Status.

Wie Aktiviert man die Visualisierung der Workflows?

1. Öffnen der Central Administration (CA) und unter “Manage Services on server” den Dienst “Visio Graphics Services” starten
2. Danach öffnet man in der CA den Bereich “Manage Web Applications” und schaut nach ob der “Visio Graphics Service” zur Verfügung steht und gestartet ist.
   Steht der “Vision Graphics Service” nicht zur Verfügung, so muss man einen neuen “Visio Graphics Service” anlegen.
3. In den Farm Features muss das Feature “Visio Web Access” gestartet werden
4. Danach sollte sowohl in den Site Collection Features, wie auch in den Site Features, das Feature “SharePoint Server Enterprise Site (Collection) features” aktiviert werden.
5. Zu beachten ist lediglich noch, das in den Einstellungen des Workflows, welcher durch den SharePoint Designer veröffentlicht wird, die Option “Show workflow visualization on status page” aktiviert ist. (Siehe Bild)

   

In meinen Ziellisten existierten jedoch unzählige Event Receiver welche diverse Dinge taten wenn Listeneinträge erzeugt bzw. gelöscht werden. Zum Beispiel wurden Emails und Termine versendet oder Einträge in anderen Listen erzeugt.

Mein Migrationsworkflow (stark vereinfacht) ist im Bild rechts zu erkennen. Hier wurde zuerst die Quell- und die Zielliste geladen. Danach sicherte der Event Manager alle Eventdefinitionen für die Zielliste und löschte diese anschließend aus der Zielliste. Danach wurde die Zielliste gelöscht und neu erstellt, dies ist nötig da ich die ID’s der Listeneinträge aus dem alten System mit übernehmen musste. Jetzt wird jeder Listeneintrag einzeln aus der Liste selektiert und transformiert. Danach wird er in der Zielliste gespeichert. Ganz zum Schluss werden die Eventdefinitionen, welche wir am Anfang gesichert haben, wieder an die Zielliste angehangen.

Ich möchte mich in diesem Beitrag jedoch nur auf die Verwaltung der Event-definitionen stützen und den Rest außen vor lassen. Da es leider keine Deactivate bzw. Activate Funktion in der SPEventReceiversDefinitionCollection gibt, war ich gezwungen mir ein Workaround zu bauen.

Als erstes habe ich mir eine Klasse gebaut, welches die wichtigsten Daten des Event Receivers hält und eine Möglichkeit bietet diese am Ende auch zu speichern. Die Klasse seht ihr im unteren Screenshot.

Den Inhalt dieses Objekts vom Typ EventDefinition wird aus der jeweiligen SharePoint Liste ausgelesen. Dazu gibt es in der SPList Klasse die Property “EventReceivers” vom Typ SPEventReceiversDefinitionCollection, welche alle Eventdefinitionen für die SharePoint Liste zurück gibt.

Damit ich die Properties vom SPEventReceiversDefinition Objekt nicht jedes Mal von Hand zuweisen muss, habe ich mir einen expliziten Operator geschrieben, der das konvertieren übernimmt.

Nun kommen wir zu der Klasse EventManager. Dieser sorgt dafür, dass die Event Definitionen aus der Zielliste entfernt und nach dem Import der Daten wieder eingefügt wird. Die Klasse hat folgendes Schema:

Die Event Receiver Definitionen werden dem EventManager beim Erstellen über den Konstruktor übergeben. Dieser fügt sie dann in die Liste Events ein.
Die Funktion DeleteEvents sorgt dafür, dass die Eventdefinitionen aus der SharePoint Liste, welche man übergibt, entfernt werden.

Hingegen ist die Funktion AddEvents dafür verantwortlich, das die Events wieder an die Zielliste angehangen werden. Hierfür muss man die Zielliste der Funktion übergeben. Die Eventdefinitionen selbst befinden sich in der Liste Events, welche durch den Konstruktor gefüllt wurde. In der Funktion AddEvents wird die Funktion Save aufgerufen, welche Die Aufgabe hat jede einzelne Definition wieder in ein Objekt vom Typ SPEventReceiverDefinition umzuwandeln und in der Zielliste zu speichern.

Problem:

Ich musste heute in meiner SharePoint Entwicklungsumgebung den Servernamen anpassen. Das ist prinzipiell nicht kompliziert, nur muss bei Windows SharePoint Services bzw. SharePoint Server auf einiges geachtet werden, damit er danach weiterhin fehlerfrei läuft.

Lösung:

1. Umbenennen des Servers geschieht über die Eigenschaften des Arbeitsplatzes. Nachdem umbenennen muss der Rechner neu gestartet werden.
2. Wenn der Servername geändert ist, wird die Änderung leider nicht im SQL Server übernommen. Wir müssen uns also mit dem SQL Server verbinden und den Servernamen per T-SQL anpassen. Sich mit dem SQL Server der WSS 3.0 zu verbinden, funktioniert leider nur über NAMED PIPES.

   Servername (WSS 3.0):        \\.\pipe\mssql$microsoft##ssee\sql\query
   Servername (SP 2010):        \\.\pipe\mssql$sharepoint\sql\query

   In beiden Fällen sollten ihr als Authentifizierungsmodus die Windows Authentifizierung wählen!

   Wie der Servername geändert werden kann, erfahrt ihr in einem etwas älteren Blog Post von mir:
   SQL Server 2008: Tatsächlichen Servernamen ändern

3. Als nächstes öffnen wir die Eingabeaufforderung um den Servernamen in den SharePoint Services anzupassen.

   cd c:\program files\common files\microsoft shared\web server extensions\12\bin
   stsadm -o renameserver -oldservername [alter Servername] -newservername [neuer Servername]
   

4. Der letzte Schritt wäre die bestehenden Webanwendungen im SharePoint Server anzupassen. Dort werden wir Adressen unter denen die Seiten gefunden werden anpassen. Wir öffnen dazu die SharePoint Zentral-administration (Wichtig: Beim öffnen nicht über den Fehler wundern. Ihr müsst den neuen Servernamen in der URL benutzen!), begeben uns unter Vorgänge in die Einstellungen der Alternativen Zugriffszuordnungen (Alternate Access Mappings) und passen dort in allen Einträgen den Servernamen entsprechend an.

   

Szenario:

Mein Kollege hatte in einem Projekt die Anforderung, Abfragen welche über das Entity Framework auf eine Datenbank ausgeführt werden nur über Stored Procedures zu erlauben. Das bedeutet, eine direkte Abfrage über den ObjectContext mit Zugriff auf die EntitySets soll nicht möglich sein (siehe Bild unten).

Lösung:

Als erstes werde ich eine Stored Procedure im SQL Server anlegen, welche mir alle Kunden selektiert, die in einer bestimmten Stadt wohnen.

Danach werde ich mein Entity Data Model aktualisieren und die Stored Procedure hinzufügen. Damit steht die Stored Procedure jedoch noch nicht im ObjectContext zum Aufruf zur Verfügung. Die Stored Procedure muss nun vom Store Model in das Conceptual Model importiert werden. Dazu öffnet man das Model Browser Fenster, begibt sich in den Store Bereich und wählt unter Stored Procedures die gewünschte Stored Procedure aus. Mit einem Rechtsklick auf die ausgewählte Stored Procedure, öffnet sich ein Kontextmenu wo man den Eintrag Add Function Import auswählt. Jetzt muss noch ein Funktionsname und ein Rückgabewert gewählt werden.

Nun steht die Stored Procedure im ObjectContext zum Aufruf zur Verfügung. Jetzt müssen wir nur noch dafür sorgen, dass die EntitySets, welche nicht über den ObjectContext aufrufbar sein sollen, verschwinden. Dazu begeben wir uns wieder in den Model Browser und schauen uns den Bereich EntityContainer –> Entity Sets näher an. Hier wählen wir nun das gewünschte EntitySet aus. Nun können wir in den Eigenschaften den Getter Zugrifflevel definieren. Hier wählen wir Private aus.

Jetzt stehen uns im ObjectContext die EntitySets, welche wir auf Private gesetzt haben, nicht mehr für Abfragen zu Verfügung. Die Abfrage ist somit nur noch über die vorgegeben Stored Procedures möglich.

Fazit:

Zugegeben ist dieses Szenario eher selten in dieser extremen Form anzutreffen. Aber z.B. in besagten Projekt geht es leider nicht anders und so sollen andere Entwickler, gar nicht erst auf die Idee kommen die Abfragen auf die EntitySets direkt auszuführen. Mit dieser Lösung wird uns nur ein Weg zur Abfrage von Daten, für die Tabelle Customer, zur Verfügung gestellt.