Dieser Artikel beschäftigt sich mit der Fragestellung, wie vorgegangen werden kann, wenn Daten aus einem beliebigen System oder einer Datenquelle in MS Dynamics CRM importiert werden sollen.

Dabei sind verschiedenste Vorbereitungen zu treffen, und man sollte nicht zu hastig dabei vorgehen, sondern jeden Schritt überprüfen und mit Testdaten verifizieren, um zu vermeiden im Nachhinein sehr viel manuelle Arbeit leisten zu müssen, oder unvollständige oder inkonsistente Daten im System vorzufinden.

Inhalte:

·         Analyse der vorhandenen Daten und Zuordnung zu den CRM Entitäten

·         Aufbereitung von Daten

·         Typische Fallbeispiele

Analyse und Zuordnung von Daten

In den wenigsten Fällen wird ein CRM-System in Betrieb genommen, ohne dass es bereits Daten gibt, die sich mit Kunden, Personen, Angeboten, Aufträgen, Rechnungen und anderen Daten beschäftigen. Zumeist sind schon Daten vorhanden, die in Form von Listen, Datenbanken, Ordnerstrukturen oder Tabellen vorliegen.

In MS Dynamics CRM werden diese Daten/Informationen in Form der Entitäten (Entitities) abgebildet. Gleichzeitig sind im CRM die vertriebsüblichen Prozesse vorkonzipiert. Man sollte sich vorab also darüber klar werden, wie CRM mit dem Vertriebsprozess umgeht. Dies ist für jemanden, der sich im vertrieblichen Umfeld auskennt, keine große Herausforderung. Für die IT-lastigen Menschen jedoch, die damit beauftragt werden, ein CRM-System zu administrieren und mit Daten zu befüllen, ist dies manchmal jedoch durchaus zunächst ein neue Bereich, in den man sich einarbeiten muss. Man sollte sich also durchaus nicht scheuen, sich beratende Unterstützung durch einen “Vertriebler” hinzu zu ziehen.

TIP: Ziehen Sie einen fachlichen Ansprechpartner aus dem Vertrieb in allen Phasen des Datenimports hinzu!

Der Vertriebsprozess im CRM in Kürze

Kurz zusammengefasst und nur in den wichtigsten Prozess-Teilen genannt, hier der Vertriebsprozess, wie er durch MS-CRM “gedacht” ist:

·         Leads

·         Sind die klassischen “Interessenten” im Vertriebsprozess. Sie stellen relativ unspezifische Interessenten an Produkten oder Leistungen dar. Hierbei steht im Vordergrund, dass Leads im Rahmen des Vertriebsprozesses noch unvollständige Informationen enthalten. So mag bei einem Lead zum Beispiel noch unklar sein, an welchen produkt genau Interesse besteht, oder ob der Ansprechpartner, der ein Interesse geäußert hat, auch der richtige Ansprechpartner für den weiteren Vertriebsprozess ist. Eventuell ist auch noch gar kein namentlicher Ansprechpartner bekannt.

·         Firmen / Accounts

·         Hier sind die Firmen-Stanndaten hnterlegt, die Basis des weiteren Vertriebsprozesses sind. Firmen können eine Vielzahl von Detailinformationen enthalten. Verschiedenen Adressen (Rechnungsadresse, Lieferadresse, Hauptanschrift, etc.) Weiterhin wichtige Informationen, um Firmen zu segmentieren, wie Mitarbeiteranzahl, Umsatz, Branche, Beziehung zu anderen Firmen und regionale Lage, um nur einige zu nennen.

·         Kontakte / Contacts

·         Ebenso, wie die Firmeninformationen enthalten die Kontakte Personen-Informationen mit vielen Details zu den Ansprechpartnern. Dazu gehören beispielweise: zugehörigkeit zu Firma, Abteilung, Verantwortungsbereich, Adresse, Beziehung zu anderen Personen, Geburtstag und vieles mehr.

·         Verkaufschancen / Opportunities

·         Ein Lead wird im besten Falle zu einer Verkaufschance qualifiziert. In der Verkaufschance werden die Rahmeninformationen zum Verkauf und dem potentiellen Umsatz festgehalten. Wie hoch die Wahrscheinlichkeit eines erfolgreichen Verkaufs ist, ist die wesentlichen Information der Verkaufschance.

·         Angebote / Quotes

·         Angebote an Interessenten enthalten Angaben zu den angebotenen Produkten, Rabatte und andere Angebotskonditionen.

·         Bestellungen / Orders

·         Bestellungen von Kunden enthalten Angaben zu den verkauften Produkten, Rabatte und andere Konditionen. Lieferadressen, Rechnungsadressen und die Bestellabwicklung finden hier ihren Platz.

·         Rechnungen / Invoices

·         Aus den Bestellungen werden Rechnungen erzeugt, zu denen Zahlungen nachverfolgt werden.

·         Aktivitäten / Activities

·         Aktivitäten können an benahme jeder Stelle des Verkaufsprozesses entstehen. Sie stellen typische Kontaktaufnahmen mit dem Interessenten / Kunden und die üblichen Wiedervorlagen des Vertriebs dar. So kann lückenlos nachverfolgt werden, wer, wann und welcher Form Kontakt mit dem Interessenten / Kunden hatte, und natürlich auch, was dabei vereinbart und besprochen wurde.

Zusammenfassung:

Ein Lead wird qualifiziert. Dabei entstehen Aktivitäten (Anrufe, Mails, Fax). Es werden Informationen gesammelt (Firma, Kontakt, Produktinteresse), die zu einer Verkaufschance führen.

Die Verkaufschance wird nachverfolgt (weitere Aktivitäten) und verfeinert und führen zur Abgabe eines Angebots. Das Angebot wird verfeinert (verhandelt), was zu Änderungen am Angebot und an der Verkaufschance führt. Die Verkaufschance wird entweder im Erfolgsfalle zu einem Auftrag, oder wird als nicht gewonnen dann geschlossen.

Aus dem Auftrag wird eine Auftragsbestätigung erzeugt, sowie eventuell eine Lieferung (Lieferschein) nachverfolgt. Sobald der Auftrag abgewickelt wurde, wird eine Rechnung erzeugt, zu der ein Zahlungseingang erfasst wird.

Für diesen Standard-Vertriebsablauf liefern noch weitere Entitäten Informationen hinzu:

Produkte und Leistungen werden im Produktkatalog und Preislisten geführt.
In der Auftragsabwicklung entstehen eventuell Beschwerden und Kundendokumente.
Eine Abwicklung von Dienstleistungen, Service-Verträgen etc. ist ebenfalls möglich, hier aber nicht beschrieben.

Analyse der vorhandenen Daten

Der eigentlichen Datenanalyse sollte zunächst die Prüfung voran gehen, ob der bisherige Vertriebsprozess dem MS-CRM Vertriebsprozess entspricht. Meist wird zumindest ein gewisser Abdeckungsgrad erreicht werden können. In beinahe allen Fällen werden sich jedoch Unterschiede herausstellen. Somit steht am Anfang die Fragestellung, ob der Vertriebsprozess angepasst werden muss, oder ob der MS-CRM-Prozess angepasst wird.

Sofern der CRM-Prozess angepasst werden muss, wird dies Thema einer anderen Artikels werden. Gehen wir an dieser Stelle davon aus, dass eine Einigung zur Abbildung des Prozesses auf Entitäten des CRM erzielt werden konnte (mit oder ohne Anpassung des CRM).

Mapping der vorhandenen Daten auf Entitäten

Vorhandenen Datenquellen werden nur in den seltensten Fällen genau den Entitäten des MS-CRM entsprechen. Meist werden jedoch zunächst die einzelnen Datenquellen mit ihren einzelnen Informationsbestandteilen den CRM-Entitäten zugeordnet werden müssen. Nehmen wir dazu ein Fallbeispiel unter die Lupe:

Vorhandene Datenquellen:

Firmendaten:

ID                                                  (Eindeutige ID, Zahl)
FIRMA1                                       (Firmenname, Text)
FIRMA2                                       (Firmenname2, Text)
STRASSE                                     (Straße + Hausnummer, Text)
LAND                                           (Land, Text)
PLZ                                                (Postleitzahl, Text)
ORT                                              (Ort, Text)
NAME                                          (Ansprechpartner Nachname, Text)
VORNAME                                 (Ansprechpartner Vorname, Text)
ANREDE                                      (Anrede, Auswahlfeld: Firma, Herr, Frau)
PRODUKT                                   (Produktinteresse, Text)
BERATER                                     (Zuständiger Vertriebsmitarbeiter, Auswahlfeld)
STATUS                                       (Bearbeitungsstatus, Auswahlfeld)
NOTIZEN                                    (Anmerkungen, Memo)
WV                                              (Wiedervorlagedatum, Datum kurz)
DOKUMENT1                            (Dateianlage)
DOKUMENT2                            (Dateianlage)
DOKUMENT3                            (Dateianlage)
EMAIL                                          (E-Mail Adresse der Firma/AP, Text)
ANSPRECHPARTNER2           (Zweiter Ansprechpartner, Text)

Anfragen:

ID                                                  (Eindeutige ID, Zahl)
FIRMA                                         (Firmenname, Text)
ANSPRECHPARTNER              (Ansprechpartner, Text)
ANFRAGETEXT                         (Text der Anfrage, Memo)
NOTIZEN                                    (Anmerkungen, Memo)
STATUS                                       (Bearbeitungsstatus, Auswahlfeld: Neu, In Bearbeitung, Angebot)

Angebote:

ID                                                  (Eindeutige ID, Zahl)
FIRMA                                         (Firmenname, Text)
NOTIZEN                                    (Anmerkungen, Memo)
ANSPRECHPARTNER              (Ansprechpartner, Text)
BETRAG                                      (Angebotsbetrag, Währung)
BEWERTUNG                            (Realisierungswahrscheinlichkeit, Zahl)
WV                                              (Wiedervorlagedatum, Datum kurz)
Dokument 1-N                         (Dateianlagen, Angebotsunterlagen und anderes)

Obwohl die Datenquellen überschaubar sind, so wird doch auf den ersten Blick klar, dass hier die Struktur deutlich einfacher ist, als dies im CRM der Fall ist. In den Ausgangsdaten werden verschiedenen Entitäten, wie sie im CRM vorhanden sind, vermischt.

So sind schon in den Firmendaten der Datenquelle mehrere Entitäten aus dem CRM in einer einzigen Datenquelle enthalten: Firmen (Accounts), Adressen, Kontakte (Contacts), Aktivitäten (Activities), Notizen (Notes), Dokumente (Documents)

Dies führt zu einem Mapping der Datenquelle Firmendaten:

Bereits an dieser Stelle wird klar, dass eine entsprechende Aufbereitung der Daten aus der Datenquelle erforderlich ist. Wie diese Aufbereitung erfolgen muss, hängt jedoch davon ab, wie die Ausgangsdaten zu interpretieren sind, und ob und inwieweit diese Interpretation maschinell durchgeführt werden kann.

Hier einige Beispiele:

·         Sind die Felder FIRMA1 und FIRMA2 immer gefüllt?

o   Nein: Dann stellt der Datensatz nur einen Kontakt dar?

o   Ja: Gibt es Kontakte ohne Firma?

·         Wohin gehören STRASSE, PLZ, LAND, ORT?

o   Zum Kontakt?

§  Wie sind dann Firmen mit mehr als einer Adresse bisher in den Daten gepflegt? Duplikate bei FIRMA1, FIRMA2?

o   Zur Firma?

§  Wie sind dann Firmen mit mehr als einer Adresse bisher in den Daten gepflegt? Duplikate bei FIRMA1, FIRMA2?

·         Ergibt sich aus PRODUKT ein eindeutiger Produktkatalog?

o   Nicht anzunehmen, da reines Textfeld. Produkte werden höchstwahrscheinlich Schreibfehler und Unterschiede bei Bezeichnung enthalten (Beispiel: „Milch 1 Ltr“ meint das gleiche Produkt wie „1 Liter Vollmilch“ in einem Textfeld)

·         Handelt es sich beim Feld STATUS um einen Status zur Firma, zum Kontakt, oder zur letzten durchgeführten Aktivität, oder zu keinem der genannten?

·         Sind die NOTIZEN Notizen zum Kontakt, zur Firma oder zur letzten Aktivität?

·         Gehören die Dokumente zum Kontakt oder zur Firma?

·         Ist die E-MAIL-Adresse die Adresse des Kontakts? Oder der Firma?

·         Wie kann das Feld ANSPRECHPARTNER2 interpretiert werden? (Format: „Vorname Nachname“, „Vorname, Nachname“, „Anrede Vorname Nachname“, oder beliebige Variationen?)

·         Wenn das Feld WV als Fälligkeitsdatum einer Aktivität gewertet wird, um welche Art von Aktivität soll es sich nach dem Import handeln? (Aufgabe, Telefonanruf, Mail, etc.)

Bei Betrachtung der weiteren Datenquellen stellen sich Fragen wie:

• Sind die Ausgangsdaten aus FIRMA (Anfrage, Angebot) eindeutig den Daten aus FIRMA1 und FIRMA2 (Firmendaten) zuzuordnen?
• Sind die Ausgangsdaten aus Ansprechpartner (Anfrage, Angebot) eindeutig den Daten aus NAME und VORNAME (Firmendaten) zuzuordnen?

Von den Antworten und/oder Beschlüssen zu den vorstehenden Fragen erfolgt dann ein erweitertes Mapping, welches dann auch schon konkrete Hinweise gibt, wie die Ausgangsdaten aufzubereiten sind.

Weiter geht es in Kürze, in einem weiteren Artikel, zur Aufbereitung der Ausgangsdaten.

(more…)

(more…)

Project Server 2010

1            Project Server Web Application

PWA. Häufig auch als Project Server Web Access bezeichnet.

Diese Web-Anwendung basiert auf der MS-SharePoint-Technologie und ist als solche in die MS-SharePoint-Foundation integriert.

1.1     Was ist das?

PWA ist ein Teil des Project-Server 2010.

Während der Project Server 2010 selbst aus einer Vielzahl von Komponenten besteht, die unter anderem dafür sorgen, dass Workflows abgearbeitet werden können, Berichte generiert werden, und viele andere Funktionen automatisiert ausgeführt werden, ist die PWA eine Browser basierte Oberfläche, die Administration und vereinfachte Erfassung von Projektdaten ermöglicht.

Die Komplexität einer vollumfänglichen Projektplanung- und Steuerungs-Umgebung, wie in der Client-Software MS-Project 2010, wird durch diese Web-Oberfläche in einzelne Funktionsbereiche aufgebrochen.

So benötigt nicht jeder Projektbeteiligte eine Project 2010 Client Installation. Gleichzeitig kann der Projektmanager von täglichen Pflegeaufgaben der Vorgänge seines Projekt entlastet werden.

Daten zu Vorgängen können beispielsweise durch die Projektmitarbeiter über die PWA erfasst und gepflegt werden. Angaben zu Vorgangsfortschritt und aktuellen Arbeitszeiten können vereinfacht erfasst und an das Projekt zurückgemeldet werden.

1.2     Wer benutzt PWA?

Die Project Server Web Application wird durch mehere Personengruppen in mit unterschiedlicherAusrichtung genutzt.

●         Administratoren

●         Projektmanager

●         Portfolio Manager

●         Projektmitarbeiter

1.2.1              Administratoren

Admins sorgen für die Konfiguration des Project-Servers. Über die PWA konfigurieren sie Sicherheitseinstellungen, Basis-Einstellungen zu Fiskal-Voreinstellungen, Konfigurieren Workflows und Erstellen und Verwalten die Richtlinien zur operativen Steuerung der Projekte.

1.2.2              Projektmitarbeiter

Projektmitarbeiter oder Projekt-Team-Mitglieder, sind üblicherweise die Personen in einem Projekt, denen einzelne Vorgänge zugeordnet werden.

Sie meldem dem Projektmanager Daten zu den Ihnen zugeordneten Aufgaben/Vorgängen zurück.

Sie aktualisieren den Fortschritt von Vorgängen, erfassen ihre Projekt-Arbetszeiten und informieren sich zu Zeitplänen, Problemstellungen und Kritischen Vorgängen.

1.2.3              Projektmanager

Sie erstellen neue Vorgänge, ordnen diese Vorgänge den Team-Mitgliedern zu, genehmigen Arbeitszeiten und verfolgen und reprten den Fortschritt von Projektvorgängen.

1.2.4              Portfoliomanager

Sie sorgen via PWA für den Durchlauf von Projektanträgen durch die einzelnen Arbeitsschritte bis zum Projekt.

Sie überwachen die Projektarten und stellen sicher, dass innerhalb der Projekte Synergien genutzt werden können.

Gleichzeitg prüfen sie die Erfolgsfaktoren, die ein ein erfolgreiches Projekt ausmachen.

1.3     Wie ist PWA aufgebaut?

Die Oberfläche ist in drei Teile aufgeteilt:

●         Das Menüband

●         Der Inhaltsbereich

●         Die Schnellstart-Leiste

1.3.1              Menüband

Das Menüband ist, ähnlich wie in der MS-Office Version 2010 /2007, aufgebaut und bietet Kontext abhängig die Bearbeitungsfunktionen, mit denen der Benutzer den Inhalt bearbeiten kann.

1.3.2              Schnellstart-Leiste

Bietet schnellen Zugriff auf die Informations- und Funktionsbereiche im PWA.

Projekte

1.3.2.1       Project Center

Bietet im Inhalts-Bereich eine Übersicht über alle Projekte, auf die der aktuelle Benutzer mindestens Lese-Rechte hat.

Hier können z.B. Projektmanager Ihre Projekte aufrufen und in Projekt-Professional 2010 bearbeiten.

1.3.2.2       Genehmigungscenter

Hier werden alle aktualisierten Vorgänge angezeigt, die von dem / den Projektmanager(n) genehmigt werden müssen.

Hat also ein Teammitglied zum Beispiel den Status eines Vorgangs geändert (z.B. Arbeitsfortschritt aktualisiert), so wird dies zur Genehmigung eingereicht und kann hier vom Projektmanager bearbeitet werden.

Auch weitere genehmigungspflichtige Aktionen werden hier aufgeführt und dem angemeldeten Benutzer dargestellt.

Workflow-genehmigungen

Hierfindet der aktuell angemeldete Benutzer alle Aufgaben, die aus Project-Server Workflows für ihn anstehen.

So also zum Beispiel eine Aufgabe ein neues Projekt zu genehmigen.

1.3.2.3       Vorgänge

Sofern der derzeit angemeldete Benutzer in Projekten als Ressource zu einem oder mehreren Vorgängen zugeordnet ist, so kann er hier eine Übersicht aufrufen.

Hier kann er ebenfalls Aktualisierungen zu seinen Vorgängen vornehmen, wenn er dazu berechtigt ist, oder Vorgänge Kollegen zuordnen, um z.B. deren Mitarbeit daran anzufordern.

1.3.2.4       Arbeitszeittabelle

Es können administrativ sogenannte Arbeitszeittabellen angelegt werden, mit denen alle Projektbeteiligten ihre Arbeitszeiten am Projekt erfassen können.

Dies kann zum Beispiel dazu genutzt werden sehr genau die einzelnen Arbeitsaufwände an den Projektvorgängen zu erfassen und abzurechnen.

In dieser Ansicht findet der aktuell angemeldete Benutzer seine Arbeitszeittabellen, in denen er für die ihm zugeordneten Vorgänge die Arbeitszeiten erfassen kann.

Auch administrative Zeit, die er für die Projekte investiert hat, die jedoch keinem Vorgang zugeordnet werden können, kann er hier erfassen.

1.3.2.5       Probleme und Risiken

Zu jedem Unternehmens-Projekt im Project-Server wird eine eigene WebSite erstellt, auf der Informationen abgelegt werden können, die nicht in der Projektdatei selbst Platz finden oder nicht unmittelbar einem Vorgang zugeordnet werden können.

Dazu zählen beispielsweise Projektdokumente und auch Probleme oder identifizierte Projektrisiken. Gleichzeitig bietet die WebSite eine Arbeitsplattform für die Projektmitglieder. Auf dieser Projekt-WebSite werden auch SharePoint-Aufgabenlisten erstellt, die sich mit den Projekt-Probelem und Risiken befassen.

Ist dem Benutzer eine solche Aufgabe zugeordnet, so kann er sie in diesem Abschnitt des PWA sehen und per Klick auf die Projektsite wechseln.

1.3.2.6       Ressourcencenter

Im Ressourcencenter werden alle Projektressourcen (im wesentlichen Personen) zentral verwaltet. Sie können den Unternehmens-Projekten zugeordnet werden, damit alle Projekte die gleichen Ressourcen verwenden und somit auch die Auslastung und Verfügbarkeit der Ressourcen zentral überwacht werden kann.

1.3.2.7       Statusberichte

Statusberichte können von den Projektmanagern angefordert werden. Sie dienen dazu, neben den Fortschritts-und Aufwandsdaten der Vorgänge, weitere Statusdaten von den Projektmmitgliedern anzufragen.

Diese können sogar automatisiert werden, so dass beispielsweise wöchentlich automatisch ein Statusbericht zu den wichtigsten Projekteckdaten abgefordert werden kann.

Strategie

1.3.2.8       Faktorbibliothek

Jedes Projekt in zuzuordnenden Abteilungen des Unternehmens kann vergleichend mit  betriebswirtschaftlichen Faktoren gemessen werden. Die Auswirkungsbewertung beschreibt, wie groß der Beitrag eines bestimmten Projekts zum betriebswirtschaftlichen Faktor ist.

Hier werden diese Faktoren beschrieben. Es handelt sich um rein beschreibende Funktionen.

1.3.2.9       Faktorpriorisierung

Jeder Faktor wird im Vergleich mit jedem anderen Faktor bewertet, um die relative Wichtigkeit der Faktoren zu bestimmen.

Portfolioanalysen

Dient der Auswertung von Faktoreneinfluss und der Priorisierung von Projekten.

Dies kann entscheidend für die Rangfolge der Ressourcenzuordnung sein.

1.3.2.10   Business Intelligence

Ein wichtiger Punkt zur Unterstützung des Projektcontrolling sind die Berichte und Berichtsergebnisse zu den Projekten.

Im Business Intelligence Center können Scorecards, Statuslisten, Excel-Service Arbeitsmappen und Projekt-Dashboards erstellt werden.

Einstellungen

1.3.2.11   Persönliche Einstellungen

Der Benutzer verwaltet hier seine Benachrichtigungen, die als Alerts vom Project-Server versendet werden können, sowie Stellvertreterregelungen um während seiner Abwesenheit beispielsweise Arbeitszeitgenehmigungen durch einen Vertreter ausführen zu lassen.

1.3.2.12   Servereinstellungen

Die ist die Domäne der Administratoren, die hier alle wichtigen Servereinstellungen konfigurieren und überwachen können.

1.3.2.13   Arbeitszeit-Tabellen verwalten

Hier hat der Benutzer Zugriff auf alle seine Arbeitszeittabellen und kann ggf. auch zurückliegende Arbeitszeittabellen nochmals einsehen.

Bibliotheken

1.3.2.14   Freigegebene Dokumente

Eine allgemeine Dokumentenablage für Dokumente zum Project-Server selbst.

1.3.3              Inhalts-Bereich

Anhand der MindMap-Grafik kann die Migration schrittweise abgearbeitet werden. Die beigefügten Dokumente können sowohl als Checkliste, als auch als Dokumentationsgrundlage für eine Migration verwendet werden.

Mindmap Migration MOSS 2007 -> SP 2010

Open Office Dokument

Word Dokument

Die beiden Dokumente liegen als ZIP-Dateien vor.

Die Bilddatei im Browser öffnen und mit der Zoom-Funktion (STRG-Mausrad) auf die gewünschte Ansichtsgröße skalieren.

Backup aller SiteCollections einer Web-Application und Export aller einzelnen Unterwebsites der SiteCollection.

Zweck:

Schnelles wieder herstellen von einzelnen Webseiten und SiteCollections wird damit möglich. Es muss nicht umständlich in eine andere Datenbank wieder hergestellt werden, um von dort auf die benötigten Webseiten zu exportieren und dann wieder in die produktive Umgebung zu importieren.

Dazu wird ein Powershell-Script verwendet, welches auch in die Schedules-Tasks unter Windows-Server eingebunden werden kann:

# Das Script erwartet 2 Argumente beim Aufruf
# .\backup.ps1 <WebApplicationUrl> <PfadZumBackUpVerzeichnis>

# Einlesen des Powershell-Snapin für Microsoft Office SharePoint, wenn es nicht schon geladen ist
#
if ( (Get-PSSnapin -Name ‘Microsoft.SharePoint.PowerShell’ -ErrorAction SilentlyContinue) -eq $null) {
Add-PSSnapin -Name ‘Microsoft.SharePoint.PowerShell’
}

# Übernehmen des Kommandozeilen-Arguments für die Web-Application[0] und den Backup-Pfad[1]
#
$siteUrl = $args[0]
$pfad = $args[1]

# Instanziieren des Web-Application Objekts
#
$rootSite = New-Object Microsoft.SharePoint.SPSite($siteUrl)
$spWebApp = $rootSite.WebApplication

# Durchlaufen aller SiteCollections in der Web-Application und Anlegen eines Backups mit dem Namen
# der obersten Website der SiteCollection (.bak) im Pfad, der als zweites Argument an das Script übergeben wurde

foreach($site in $spWebApp.Sites)
{ 
 $web = $site.OpenWeb()
 $Datei =$pfad + $web.Title + “.bak” # erhaschen des Titels der Website auf oberster Ebene der SiteCollection
 write-host $Datei
 Backup-SPsite -Identity $site.url -Path $Datei –Force

 # Durchlaufen aller Webseiten der Site-Collection und Export dieser Webseiten
 #
 foreach($website in $site.Allwebs)
 {
  # Der Name der exportierten Webseite wird zusammengesetz aus <<Name der SiteCollection>-<Name der Website>>.exp
  #
  $Datei = $pfad + $web.Title + “-” + $website.Title + “.exp” # erhaschen des Titels der Website die als nächtes exportiert wird
  Export-SPweb -Identity $website.url -Path $Datei
 }
 $site.dispose()
}

# Anmerkungen
# Aufruf des Scripts:
# Vom CMD-Prompt oder aus einem Scheduled Task: powershell <pfad>\backup.ps1 <WebApplicationUrl> <PfadZumBackUpVerzeichnis>
#
# Wiederherstellen von SiteCollections
# Restore-SPSite –Identity http://servername/your/directory -Path <Pfad>\NameDerBackupDatei.bak –Force
#
# Wiederherstellen von WebSites
# Import-SPWeb –Identity http://servername/your/directory -Path <pfad>\NameDerBackupDatei.exp –Force -IncludeUserSecurity

Vorab sei jedoch erwähnt, dass dieses Vorgehen nicht von Microsoft unterstützt wird, da es eine direkte Manipulation der Datenbank beinhaltet. Ich empfehle dies auch in Produktivumgebungen nicht zu tun, da eventuelle Support-Ansprüche an Microsoft verloren gehen könnten.

Leider ist es nicht möglich die SharePoint-Zentraladministration (SP2010 und MOSS 2007) nachträglich mit unterstützter Funktionalität auf eine andere Sprache umzustellen. Dennoch ist dies mit Hilfe einer kleinen Manipulation machbar.

(more…)

Beziehungen zwischen Listen (Relationen)

In den vorangegangenen SharePoint Versionen gab es echte Relationen zwischen verschiedenen Listen einer Webseite nicht, oder nur in der Form, dass aus einer Liste Nachschlagespalten auf eine andere Liste erstellt werden konnten.

In SharePoint 2010 kommt nun eine „echte“ Beziehung zwischen Listen zu Stande, wenn eine Nachschlagespalte auf eine andere Liste erstellt wird. Durch die Herstellung einer Beziehung zwischen Listen kann gleichzeitig eine referentielle Integritätsprüfung konfiguriert werden, die dafür sorgt, dass abhängige Listeneinträge in untergeordneten Listen gelöscht werden, wenn der übergeordnete Listeneintrag gelöscht wird.

Dies sorgt für deutlich mehr Konsistenz in miteinander verbundenen Listen und kann dazu genutzt werden tatsächlich Abhängigkeiten darzustellen.

Beispiel:

Verbundene Listen sollen dazu genutzt werden, ein Projekt mit Sammelvorgängen und Untervorgängen darzustellen. Dazu wird eine Aufgaben-Liste mit einer zweiten Liste über ein Nachschlagefeld verknüpft.

Abbildung 8 und 9:
Konfiguration verknüpfter Listen über ein Nachschlagefeld mit Löschweitergabe

n diesem Beispiel werden die Listen über eine neu angelegte Spalte namens „Vorgang“ verknüpft. Somit ist die Liste Unteraufgaben mit den Projektaufgaben verbunden und wenn eine Projektaufgabe gelöscht wird, so werden alle auf sie bezogenen Unteraufgaben ebenfalls gelöscht.

In einer Collaboration-Umgebung kommt es schnell dazu, dass Listen sehr schnell wachsen und schon sehr bald viele Einträge (Listenelemente) beinhalten. In bisherigen Versionen des SharePoint gab es hier gewisse Einschränkungen und Empfehlungen von Seiten Microsoft, wie mit Listen mit mehreren Tausend Einträgen umgegangen werden sollte. Schnell stieß man hier auf Performance Einschränkungen oder Empfehlungen, die dann eine umfangreiche Ordnerstruktur vorsehen mussten, um große Listen performant und bedienbar zu halten.

Um dies zu vermeiden, wurden Konfigurationseinstellungen auf Web-Anwendungsebene neu hinzugefügt, die es dem Administrator ermöglichen zum Beispiel das Aufrufen von Listenansichten, die mehr als eine definierte Anzahl von Elementen enthalten, zu verhindern. Damit werden von vorn herein Performance-Probleme und übermäßige Ressourcen Belastung der Server und Datenbank verhindert.

Auch für Entwickler interessant

Auch das Objektmodell bietet dem SharePoint-Entwickler an dieser Stelle neue Methoden, die der Entstehung von Ressourcen-Problemen vorbeugen. Hier wurden Methoden auf Listen und Bibliotheksebene hinzugefügt, die bisherige bekannte Methoden ersetzen und speziell für das Handling von großen Listen gedacht sind. Hierzu zählen:

• SPList.ItemCount

• SPList.AddItem

• SPList.GetItemByID

und weitere mehr.

Abbildung 7:
Ressourcen-Steuerung für große Listen in der Zentraladministration für eine Web-Anwendung