Schwerpunkt DienstprogrammeAktualisierungstoolkit für SharePoint-Websites und -Vorlagen

Luis Câmara Manoel and Peter Skjøtt Larsen

Laden Sie den Code für diesen Artikel herunter: Upgrade Toolkit for Windows SharePoint Services Sites and Templates (699KB)

Seit der Veröffentlichung von Windows SharePoint Services (WSS) 3.0 sehen sich viele Administratoren der Aufgabe gegenüber, ihre bereits vorhandenen Websites und Daten für WSS 2.0 auf die neuen WSS 3.0-Umgebungen zu aktualisieren. Obwohl WSS 3.0 umfangreiche Tools bereitstellt, mit denen die Websitedaten angemessen migriert und die

Websitestruktur aktualisiert werden kann, fallen beim Aktualisieren von benutzerdefinierten Websites oder Websitevorlagen möglicherweise zusätzliche Arbeiten an.

Außerdem sind möglicherweise zusätzliche Arbeiten notwendig, um die Struktur benutzerdefinierter Websites oder Websitevorlagen zu aktualisieren. Glücklicherweise hat das Microsoft® Solution Accelerator Team das Aktualisierungstoolkit für Websites und Vorlagen von Windows® SharePoint® Services veröffentlicht, in dem Anleitungen und Tools für diese Verfahren enthalten sind (siehe Randleiste „WSS-Ressourcen“). In dieser Rubrik werden Herausforderungen und Lösungen im Zusammenhang mit der Aktualisierung von benutzerdefinierten Websites auf eine WSS 3.0-Umgebung erörtert. Informieren Sie sich zunächst in der Randleiste „WSS-Terminologie“ über einige Definitionen und allgemeine Begriffe.

Der Aktualisierungsprozess

Weshalb sollten Sie eine Aktualisierung vornehmen? In WSS 3.0 gibt es eine Reihe neuer Features, die eine Aktualisierung für die Betreiber der Website unumgänglich machen:

• Ein Papierkorb, mit dem versehentlich gelöschte Dokumente wieder hergestellt werden können.
• Sicherheitsmechanismen auf Ordnerebene, mit deren Hilfe Websiteadministratoren steuern können, welche Personen bzw. Gruppen Zugriff auf Ordner haben.
• Versenden von E-Mails an Listen, wodurch beispielsweise Blogbeitragslisten einer SharePoint-Website Inhalte via E-Mail empfangen können.
• Eine Schaltfläche „Websiteaktionen“, mit der Benutzer auf einfache Weise Websites und Webseiten erstellen, Seiten bearbeiten und Websiteeinstellungen verwalten können.
• Als Breadcrumbs bezeichnete Steuerelemente, die sofort Navigationskontext für den Benutzer bereitstellen.
• Mobile Ansichten, mit denen Benutzer mobiler Geräte eine praktische Offlinesynchronisierung vornehmen können.
• RSS-Feeds, mit denen RSS-fähige Programme wie Internet Explorer 7.0 und Outlook® 2007 Informationen aus Listen abrufen können.
• Versionsverwaltung in Dokumentbibliotheken, durch die eine gewisse Versionsverwaltung und Kontrolle für das Auschecken von Dokumenten vor der Bearbeitung möglich ist.

Da der Aktualisierungsprozess für Websites und Vorlagen von bestimmten Schritten vor und nach der Aktualisierung des eigentlichen Servers auf WSS  3.0 abhängt (siehe Abbildung 1), stellt das Festlegen der Anforderungen für die Aktualisierung von Websites und Vorlagen einen wichtigen Schritt in der Gesamtstrategie für die Aktualisierung auf WSS 3.0 dar. Websitebesitzer und Servermanager sollten gemeinsam festlegen, welche Websites und Vorlagen in eine WSS 3.0 instanziiert und aktualisiert werden sollten. Nach der Auswahl dieser benutzerdefinierten Websites kann mit der Aktualisierung begonnen werden.

Abbildung 1** Workflow für die Aktualisierung von Websites und Vorlagen von WSS **(Klicken Sie zum Vergrößern auf das Bild)

Erkennen benutzerdefinierter Websitevorlagen

Wie lässt sich ermitteln, ob die Websites angepasst wurden? WSS 3.0 stellt ein Tool zum Ausführen eines Scans vor der Aktualisierung zur Verfügung, das für die gesamte Farm einen Bericht über die an Websitevorlagen vorgenommenen Änderungen erzeugt. Sie sollten dieses Tool vor Beginn der Migration ausführen, um festzustellen, welche Websitevorlagen besondere Aufmerksamkeit erfordern.

Das Tool liefert einen Bericht im XML-Format (siehe Abbildung 2). Das Element „unghostedPage“ zeigt an, dass eine Website angepasst wurde.

Figure 2 Bericht des Tools zum Ausführen eines Scans vor der Aktualisierung über die an Websitevorlagen vorgenommenen Änderungen

<?xml version=”1.0” encoding=”utf-8”?>
<summary>
  <sites>
    <site url=”http://mscc-shr-v3-01” storage=”172767226”>
      <webs>
        <web url=”http://mscc-shr-v3-01/Board of Directors-Basic”>
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/default.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/EditForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/Upload.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/WebFldr.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and 
                Business Planning/Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and 
                Business Planning/Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and 
                Business Planning/Forms/EditForm.aspx” />

Benutzerspezifische Websitedefinitionen

Es ist anzunehmen, dass die meisten angepassten WSS 2.0-Websites, die zu aktualisieren sind, aus Vorlagen auf der Basis von Standardwebsitedefinitionen von WSS erstellt wurden. Es ist jedoch möglich, dass einige der angepassten Websitevorlagen anhand benutzerspezifischer Websitedefinitionen erstellt wurden. Dies kann der Fall sein, wenn Entwickler in Ihrer Organisation benutzerspezifische Websitedefinitionen erstellt haben, oder wenn Sie Anwendungen von Drittanbietern oder auf benutzerspezifischen Websitedefinitionen basierende Vorlagen erworben haben. In dieser Rubrik wird lediglich das Szenario für Standardwebsitedefinitionen behandelt. Weitere Informationen zum Szenario für benutzerdefinierte Websitevorlagen finden Sie in der Randleiste „WSS-Ressourcen“.

Wenn Sie sich davon überzeugt haben, dass die STP-Dateien und Websites tatsächlich auf der Basis von Standardwebsitedefinitionen erstellt wurden, d. h. dass in WSS 3.0 aktualisierte Websitedefinitionen vorhanden sind, können Sie mit dem Installieren und Instanziieren der Websites fortfahren.

Um bestimmte Websitevorlagen von WSS 2.0 zu aktualisieren, müssen Sie die Vorlagen zunächst auf einem WSS 2.0-Server installieren (siehe Phase 1 in Abbildung 1). Anschließend nehmen Sie auf Grundlage der einzelnen installierten Vorlagen die Websiteerstellung vor.

Der Solution Accelerator stellt einen Satz an Skripts bereit, in denen Stsadm.exe-Befehle wirksam eingesetzt werden. Dies sorgt dafür dass der Installationsprozess mehrerer STP-Dateien, das Instanziieren mehrerer Websites und das Bereinigen des Servers von temporären Dateien nach Abschluss des Aktualisierungsprozesses optimiert werden (Einzelheiten finden Sie in der Randleiste „Lösungsskripts“). Stsadm.exe ist eine Befehlszeilenanwendung, die einen vollständigen Satz an WSS-Vorgängen zum Verwalten von SharePoint-Servern und SharePoint-Websites bereitstellt. Mithilfe der Lösungsskripts können Sie diesen Prozess automatisieren, indem Sie Installation und Instanziierung als Batch ausführen oder diese Aufgaben nacheinander vornehmen. Die Zeitersparnis kann beträchtlich sein, besonders, wenn eine Vielzahl an STP-Dateien zu installieren und viele Websites zu instanziieren sind.

Lösungsskripts

Im Prozess für die Installation und das Anlegen der Website werden zwei Skripts verwendet, die Stsadm.exe ausführen:

• MigInstStp.cmd installiert mithilfe der addtemplate-Operation von Stsadm.exe die Websitevorlagen. Diese Operation hat die Parameter _SOURCEFILELOCATION, _SOURCEFILENAME und _FILETITLE.
• MigMakeSite_1.cmd erstellt die neuen Websites. MigMakeSite_1.cmd führt die createweb-Operation von Stsadm.exe aus. Diese Operation hat die Parameter _SERVERURL, _SITENAME, _SITETEMPLATENAME und _SITETITLE.

Führen Sie diese Skripts auf dem lokalen WSS 2.0-Server mit Zugriff auf den Speicherort der Websitevorlagendateien (.stp) aus. Um diese Skripts ausführen zu können, müssen Sie Mitglied der lokalen Administratorengruppe auf dem Server oder Mitglied der WSS-Administratorengruppe mit Berechtigungen für das Anlegen von Websites sein. Im Handbuch zum Aktualisierungstoolkit für Websites und Vorlagen von Windows SharePoint Services finden Sie eine ausführliche Anleitung, wie Sie diese Skripts optimal nutzen können. Wenn die STP-Dateien installiert und die Websites instanziiert wurden, können Sie mit der Aktualisierung des Servers fortfahren. Eine detaillierte Beschreibung der Ansätze für eine Aktualisierung auf WSS 3.0 finden Sie unter „Aktualisieren auf Windows SharePoint Services 3.0“ (siehe Link in der Randleiste „WSS-Ressourcen“).

WSS-Terminologie

Windows SharePoint Services nutzt seine eigene, spezifische Terminologie. Hier ist ein kurzes Glossar gebräuchlicher Begriffe.

Websitedefinition Hierbei handelt es sich um einen Satz an Dateien, durch die eine bestimmte Art von Websites definiert wird. Zu einer Websitedefinition gehören die Dateien XML, ASPX, ASCX und Masterseite sowie Listenvorlagen- und Inhaltsdateien, die in einem speziellen Ordner auf dem Front-End-Webserver gespeichert sind. WSS verfügt über einen Satz gebrauchsfertiger Standardwebsitedefinitionen, z. B. „Team Site“, „Blank Site“ und „Document Workspace“. Zu Anfang sind dies die einzigen Websitevorlagen, die im Websitevorlagenkatalog gespeichert sind und unter „Neue SharePoint-Website“ in der Liste zur Vorlagenauswahl zur Verfügung stehen.

In Websitevorlagen der Art Websitevorlage ist festgelegt, wie eine SharePoint-Website zu instanziieren ist. Um eine neue SharePoint-Website zu erstellen, müssen Sie eine Websitevorlage auswählen, auf der die Website basieren soll. So können Sie z. B. eine neue Website mit dem Namen „Vorstand“ erstellen, die auf der standardmäßigen „Blank Site“-Vorlage basiert. Anschließend können Sie Listen, Bibliotheken, Webparts und andere Anpassungen zur instanziierten Website hinzufügen. Um anderen diese Anpassungen verfügbar zu machen, speichern Sie diese Website anschließend als Vorlage mit dem Namen „Vorstand“. Die Website basiert auf der Websitedefinition „Blank Site“. WSS speichert die angepasste Websitevorlage als STP-Datei (Websitevorlage), platziert sie in den Websitevorlagenkatalog und zeigt sie auf der Seite „Neue SharePoint-Website“ in der Liste „Vorlage auswählen“ an, damit Benutzer später auf der Basis dieser Website neue Websites erstellen können. Websitevorlagen enthalten eine Reihe von Websitekonfigurationsdateien wie XML, ASPX, Bilder und andere, die anschließend in eine einzige STP-Datei komprimiert werden. (STP-Dateien funktionieren ähnlich wie CAB-Dateien.) Die wichtigste dieser Dateien ist Manifest.xml. Sie enthält wichtige Informationen wie Websitestruktur, Websitenavigation, Listen und Bibliotheken, Standort von Webparts, Definitionen benutzerdefinierter Listen sowie die Websitedefinition, auf der die angepasste Websitevorlage basiert.

Anwendungsvorlage. Hierbei handelt es sich um Websitevorlagen von Windows SharePoint Services, die zur Abwicklung bestimmter Geschäftsprozesse oder Aufgaben entwickelt wurden. Diese Vorlagen werden von Microsoft veröffentlicht und stehen für WSS-Kunden kostenlos als Download zur Verfügung.

Angepasste Website. Hierbei handelt es sich um eine SharePoint-Website mit einer geänderten Benutzeroberfläche.

Masterseite Die Masterseite ist ein Bereich, in dem Informationen zum Standardlayout, z. B. Banner, Navigationsteuerelemente und andere Menüs gespeichert werden können, um über die gesamte Website hinweg eine konsistente Oberfläche zu erzielen.

Duplizierte Seiten. Dies sind Seiten, deren Inhalt nicht in der WSS-Inhaltsdatenbank gespeichert ist, sondern aus einer Websitedefinitionsdatei gelesen wird. Duplizierte Seiten wurden nicht angepasst.

Nicht duplizierte Seiten. Hierbei handelt es sich um Seiten, die durch die Websitedefinitionsdatei geändert wurden und deren Inhalt in der WSS-Inhaltsdatenbank gespeichert ist.

Websiteüberprüfung nach der Serveraktualisierung

Nun sind Sie bei Phase 2 im Aktualisierungsworkflow angelangt (siehe nochmals Abbildung 1). In dieser Phase der Aktualisierung von Website und Vorlagen sind folgende Schritte auszuführen:

1. Öffnen und Überprüfen der aktualisierten Websites.
2. Anwenden der Standardmasterseite.
3. Beheben von Problemen mit Features und Layout der neuen Websites.
4. Speichern der korrigierten Websites als neue Websitevorlagen von WSS 3.0.
5. Erneute Bereitstellung der neuen WSS 3.0-Websitevorlagen auf dem Server.
6. Erstellen von Websites anhand der erneut bereitgestellten Websitevorlagen.
7. Öffnen der neuen Websites und Überprüfung, ob sich die Websites wie erwartet verhalten.
8. Initiieren des Bereinigungsprozesses.

Zurücksetzen auf die Websitedefinition

Wenn Sie die aktualisierte Website erstmalig öffnen, werden Sie feststellen, dass sie immer noch wie eine WSS 2.0-Website aussieht. Um der Website das Erscheinungsbild einer WSS 3.0-Website zu geben, müssen Sie zunächst auf die Websitedefinition in der neuen WSS 3.0-Website zurücksetzen. Dadurch werden nahezu alle Layoutprobleme behoben, und es gehen keinerlei Anpassungen von Webparts verloren, vorausgesetzt, dass sich diese Webparts bereits in einer auf der Websitedefinitionsseite vorhandenen Webpartzone befinden. Durch diese Aktion wird außerdem die Standardmasterseite für alle Seiten der Website übernommen.

Eine Masterseite ist, wie der Name schon sagt, ein Bereich, in dem Informationen zum Standardlayout, z. B. Banner, Navigationsteuerelemente und andere Menüs gespeichert werden können, um für ein konsistentes Erscheinungsbild zu sorgen. Auf diese Weise können Sie Änderungen am Entwurf an der Masterseite vornehmen und diese Änderungen für die gesamte Website übernehmen. Durch das Anwenden von Masterseiten wird die gesamte systemeigene Funktionalität von WSS 3.0 für die aktualisierten Websites aktiviert.

Obwohl die Website jetzt wie eine native WSS 3.0 aussehen und funktionieren sollte, finden sich wahrscheinlich noch einige Problembereiche, z. B. Diskussionsrunden, angepasste Webparts, Hyperlinks und Themen.

Beheben von Problemen

In aktualisierten und angepassten Websitevorlagen kann eine Reihe von Problemen auftreten. Hier sind einige der häufigsten Probleme und ein paar einfache Ideen zur Behebung dieser Probleme aufgeführt.

Auf eine Website wird immer noch das Standardstylesheet von WSS 2.0 angewendet. Entfernen Sie im SharePoint Designer das alte Stylesheet.

Webparts fehlen oder befinden sich am falschen Ort. Verschieben Sie mithilfe von SharePoint Designer Webparts, bzw. fügen Sie Webparts ein.

Webparts funktionieren nicht korrekt. Entfernen Sie Webparts, die nicht mit WSS 3.0 kompatibel sind, und kontaktieren Sie den Webpart-Entwickler, um in Erfahrung zu bringen, ob entsprechende Webparts für WSS 3.0-Umgebungen erstellt wurden.

Angepasste Listen und Bibliotheken erscheinen nicht korrekt. Speichern Sie die vorhandenen Daten. Erstellen Sie anschließend die angepasste Liste bzw. Bibliothek neu, und importieren Sie die gespeicherten Daten.

Aktivierte Features von WSS 3.0 sind nicht verfügbar. Funktionen für die Teamzusammenarbeit müssen möglicherweise unter Websitefeatures aktiviert werden.

Hyperlinks funktionieren nicht mehr. Hartcodierte Hyperlinks müssen möglicherweise manuell aktualisiert werden.

Das Thema wurde geändert. Übernehmen Sie das entsprechende WSS-Thema.

Fast fertig

Der Prozess ist nun fast abgeschlossen, und alle Probleme sind behoben. Es ist an der Zeit, eine letzte Websiteüberprüfung vorzunehmen. Sie sollten die korrigierten Websites als WSS 3.0-Websitevorlagen speichern, eine Neuinstallation der STP-Datei und eine Instanziierung der Website vornehmen (Sie können auch hierbei die praktischen Skripts nutzen) und schließlich die Website öffnen und überprüfen, ob alle Probleme behoben wurden und die aktualisierten Websites und STP-Dateien für eine Weiterverteilung in der Arbeitsumgebung bereit sind.

Alternativen zu einer Aktualisierung

Das Aktualisieren von Vorlagen mithilfe der hier erläuterten automatischen Tools und Prozesse ist möglicherweise nicht in jedem Fall die günstigste Vorgehensweise. Wenn Sie sehr spezielle Vorlagen von Drittanbietern verwenden, ist es u. U. äußerst schwierig oder gar unmöglich, die Vorlagen selbst zu aktualisieren, und es ist oft besser, auf eine neue Version der Vorlage zu warten. In anderen Fällen ist das Erstellen einer brandneuen Vorlage in WSS 3.0 und ein anschließendes Implementieren der Features der früheren Vorlage die bessere Entscheidung.

Anwendungsvorlagen

Es gibt einen Satz von Microsoft entwickelter Anwendungsvorlagen, die für WSS 2.0 und für WSS 3.0 verfügbar sind. Der neue Satz für WSS  3.0 umfasst aktualisierte Versionen einiger Anwendungsvorlagen aus WSS 2.0. Wenn Sie eine dieser Vorlagen verwendet haben, können Sie die aktualisierte Version für WSS 3.0 in Ihre WSS 3.0-Umgebung hochladen.

Falls Sie eine der Anwendungsvorlagen von WSS 2.0 verwendet haben, für die keine aktualisierte Version für WSS 3.0 zur Verfügung steht, stellt Ihnen der Solution Accelerator einen Satz von Anwendungsvorlagen aus WSS 2.0 bereit, die für die Verwendung in einer WSS 3.0-Umgebung aktualisiert wurden.

Zusammenfassung

Das Aktualisierungstoolkit für Websites und Vorlagen von Windows SharePoint Services ist für das Weiterverwenden von Vorlagen, Websites und Anpassungen aus der Version 2.0 in einer 3.0-Umgebung äußerst nützlich. Weitere Information zu diesem Thema und das Toolkit selbst finden Sie auf den in der Randleiste „WSS-Ressourcen“ angegebenen Websites.

Wir möchten Betty Houser für ihre wertvollen Beiträge zu dieser Rubrik und zum Solution Accelerator danken.

WSS-Ressourcen

• Tool zum Ausführen eines Scans vor der Aktualisierung
• Aktualisierungstoolkit für Windows SharePoint Services-Websites und -Vorlagen
• Aktualisieren auf Windows SharePoint Services Version 3.0 (Windows SharePoint Services 3.0 – Technische Bibliothek)
• Bereitstellen von Aktualisierungsdefinitionsdateien und neuen Websitedefinitionen

Luis Câmara Manoel ist Programmmanager in der Microsoft Solution Accelerator Group. Er arbeitet seit einem Jahr bei Microsoft. Davor war er als Projektleiter und Programmmanager bei Novell Inc. und bei Volera in Provo, Utah, tätig. Sie können ihn unter luiscam@microsoft.com erreichen.

Peter Skjøtt Larsen ist Produktmanager in der Microsoft Solution Accelerator-Gruppe. Er arbeitet seit mehr als fünf Jahren in Entwicklung und Marketing. Davor entwickelte er Client- und Serversoftware für die Branchen Finanzwesen, Ingenieurwesen und Telekommunikation. Sie können ihn unter petela@microsoft.com erreichen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.