Einrichten von Webtests und Loadtest für SharePoint Anwendungen in Visual Studio Team System 2008.

Verbindung zur Datenbank als Load Test Repository.

Hier verlässt man zunächst die VS Oberfläche und begibt sich in die Konsole.  Ich nehme mal  an, es ist ein SQL Server (in meinem Fall SQL Express auf der gleichem Maschine) vorhanden.

Dann einfach VS Command Prompt (über das Startmenü) öffnen und ein CD in folgendes Verzeichnis machen:
c:\program files\microsoft visual studio 9.0\common7\ide

Anschließend folgendes Kommando ausführen (evtl. SQL Instanz anpassen):

SQLCMD /S localhost\sqlexpress /i loadtestresultsrepository.sql

Siehe dazu im Übrigen auch :
http://msdn2.microsoft.com/en-us/library/ms182600.aspx

Nun zurück im VS 2008 die Datenbankconnection prüfen unter:

Und

Webtest aufzeichnen

Dann wollen wir den Webtest mal aufzeichnen. Das geht meines Wissens nach übrigens nur mit IE.

Den Test ordentlich benennen, wir ordnen ihn später einem Szenario zu.

Der Webtestrecorder ist ein IE Addon. Deshalb wohl die Einschränkung auf diesen Browser.

Der Pause Button macht sich gut, wenn man während des Aufzeichnens vergessen hat, was man machen wollte. Er unterbricht hoffentlich auch die Think Time, die mit aufgezeichnet werden kann.

Ende der Aufzeichnung. Man kann sich die augezeichneten Schritte im nachhinein noch einmal ansehen.

Run Settings einstellen

Die Run Settings erhalten, wir in dem wir über Test > New Test einen Load Test hinzufügen. Wir möchten ja die Last messen.

In den Run Settings stellen wir grob ein, welche Maschinen getestet werden und was darauf. Hier hängen wir unseren Webfrontend Server rein, auf dem die SharePoint Anwendung läuft. Der Rechner wird an seinem Namen erkannt. Der TFS-Eval hostet das VS2008 mit seiner Datenbank, beide befinden sich in der gleichen Domäne.

In den Eigenschaften des Tests sind u.a. die Test Iterations wichtig und Use Test Iterations. Unser Test soll nach der vorgegebenen Zeit beendet werden.

Szenario erstellen

Nun erstellen wir ein Szenario. Hier legen wir u.a. fest, ob unsere Benutzer zwischen den Klicks denken sollen, die Think Time.

Das Load Pattern legt fest, ob fest immer eine bestimmte Anzahl nutzer gleichzeitg den Test durchführen soll, oder ob die Anzahl der Benutzer ansteigt (Step Load).

In diesem Schritt fügen wir nun unseren Webtest hinzu.

Und ein bunter Mix aus Browsern.

Und eine Bandbreite. Unser Nutzer haben alle einen schmalen DSL Anschluss.

Dann können wir den Test starten. Der Eindruck eines Ergebnisses:

Ganz klar, der virtuelle Prozessor des virtuellen Entwicklerservers hatte gut zu tun (die ganzen roten Kreuze oben). Hier wird die Regel bestätigt: Lieber mehr Prozessoren als mehr RAM im Webserver. Während des ganzen Tests hat sich die RAM Auslastung des Webservers kaum verändert.

Ein Lasttest auf virtuellen Maschinen ist selbstverständlich wenig aussagekräftig. Aber es lassen sich dennoch die ersten Flaschenhälse und Tendenzen feststellen, denen man in der Entwicklung noch begegnen kann.

Die Load und Webtests sind in Visual Studio 2008 nur in der Test Suite oder in der Team Suite enthalten. Die Testfunktionalitäten der anderen Visual Studio Suites (Developer oder die Professional) enthalten nur Funktionen für Unit-Tests. Als freie Alternative bietet sich hier JMeter an.

Eine gute Übersicht, wie am Besten verteilte Standorte mit SharePoint versorgt werden, hat das SharePoint Team in seinem Blog veröffentlicht.

http://blogs.msdn.com/sharepoint/archive/2008/02/22/deploying-microsoft-office-sharepoint-server-2007-geographically.aspx

Die meiner Meinung nach beiden wichtigsten Szenarien habe ich mal rausgegriffen.

1. Aufbau einer zentralen Farm.

Jeder Standort greift über das Netz auf die Inhalte und Dienste der zentralen Farm zu. Auch Suchanfragen laufen über das Netz.

2. Aufbau einer zentralen Farm mit zusätzlichen regionalen Farmen.

Zu der zentralen Farm kommen an jedem Standort eine regionale Farm hinzu. Und genau hier gibt es jetzt mehrere Möglichkeiten. Hier muss man sich überlegen, ob das SharePoint Poral in erster Linie dazu dient, Inhalte (CMS, Dokumente) bereitzustellen oder für Collaboration genutzt werden soll. http://technet2.microsoft.com/Office/en-us/library/cbccbc4d-e560-4b92-89d0-56f49e7f3f4b1033.mspx?mfr=true

Bei der Suche kann die zentrale Farm die komplette Indizierung aller Farmen über das Netz übernehmen. Dies ist aber möglicherweise sehr langsam und endet in Timeouts. Bei einer schnellen Anbindung ist so aber natürlich ein zentraler Index aller Farmen vorhanden. Benutzer müssen so aber immer zur zentralen Farm navigieren, um eine Suche zu starten.

Bei den Suchergebnissen (Plan for global enterprise search) wird dann aber auch nicht zwischen lokalem Inhalt (der regionalen Farm) und der zentralen Farm unterschieden. Ein Mitarbeiter erkennt nicht gleich, ob das gefundene Dokument auf dem Server seiner Niederlassung oder der zentrale liegt. Es wird dabei auch nicht priorisiert, also dass Suchergebnisse aus der Niederlassung zuerst angezeigt werden.

Die Alternative, dass jede Farm nur ihren eigenen Index hat, halte ich dagegen nicht für sinnvoll, da so nicht in einem Schritt über das ganze Unternehmen gesucht werden kann, was ja dem Gedanken des Enterprise Search widerspricht.

Aber es gibt ja immer eine Möglichkeit:

Die zentrale Farm erstellt über den SSP einen Index über alle Farmen im Verbund. Zusätzlich hat jede regionale Farm einen eigenen Index. Über Suchbereiche kann der Benutzer auswählen, wo er suchen will. Dies reduziert die Suchanfragen über den gesamten Index der zentralen Farm, die Performance der Suchanfragen steigt.

Beim Aufruf der Datenanalyse im Project Web Access kam auf einem neu installierten Rechner folgender Fehler:

“The query could not be processed: Safety settings on this machine prohibit accessing a data source on another domain”.

Zunächst etwas verwirrend, die Domäne war bei Server und Client eindeutig dieselbe. Ein Blick in die Sicherheitseinstellungen des Internet Explorer half. Hier sollte die URL des PWA in die Zone “Vertrauenswürdige Sites” aufgenommen werden. In Abhängigkeit der gewählten Standardstufe muss u.U. noch eine Einstellung vorgenommen werden:

Unter Verschiedenes > Auf Datenquellen über Domänengrenzen hinweg zugreifen entweder aktivieren oder bestätigen lassen.

Wählt man bestätigen, erscheint für Benutzer jedesmal beim Aufruf der Datenanalyse Website im Project Web Access folgender Hinweis:

Beim Firefox stellt sich die Problematik erst gar nicht, siehe aussagekräftige Fehlermeldung von Project Web Access:

Selbst in einer Windows Server 2003 Domäne sollte man darauf achten, dass der Anmeldename für MOSS Accounts nicht zu lang ist.

MOSS verwendet zur Anmeldung scheinbar den Prä-Windows 2000 Anmeldenamen und dieser hat maximal 20 Zeichen.

Darum nicht wundern, wenn zum Beispiel beim Starten der Dienste in der Zentraladministration hartnäckig die Meldung “Benutzername oder Kennwort falsch” erscheint und man sich sicher ist, alles richtig eingegeben zu haben.

Standardmäßig lassen sich Mindmaps nicht direkt aus SharePoint Bibliotheken auschecken und editieren. Dafür gibt es aber eine freie Lösung direkt von Mindjet.

Dazu muss jeweils eine Erweiterung auf dem SharePoint Server und auf dem Client installiert werden. Dann können die Mindmaps direkt aus dem Kontextmenü geöffnet werden. Die Installationsdateien gibt es unter : http://mindjetlabs.com/cs/files/folders/mindjetlabs/rss.aspx?Tags=MOSS&AndTags=1

Über Project Web Access kann man die Eigenschaften eines Projektes ändern (Edit Project Properties). Hat man eine Eigenschaft geändert und klickt auf Save oder Save and Publish, so geschieht …. Nichts. Nur der Cancel Button funktioniert und verwirft brav alle Änderungen.

So … this is a known bug, wie in vielen Foren zu lesen ist. Warten wir also auf SP1.

Es gibt aber einen Workaround. Es müssen ALLE Felder geändert werden. Sprich, alle Felder auswählen und einfach die schon ausgewählten Werte anklicken bzw. wieder eintragen.

Dann funktioniert es. Umständlich, aber bis das SP1 dann mal da ist …

Da man ja sehr oft und sehr gerne auf virtuellen Maschinen entwickelt und auch zum Deployment nicht unbedingt ein paar hundert Kilometer reisen möchte, wird gerne zur Remote Desktop Verbindung gegriffen.

Dazu gibt es bei Unterwegs im Net eine ausführliche Beschreibung. Unter anderem die notwendigen Ports, damit man nicht an der Firewall des Kunden hängenbleibt.

Link: Unterwegs im Net

Bei Microsoft gibt es jetzt Zertifizierungen mit dem Schwerpunkt Enterprise Project Management. Natürlich gemünzt auf die Microsoft-eigenen Produkte Project Professional 2007 und Project Server 2007.

Der Project Professional Kurs ist ab August, der Project Server Kurs ist ab November verfügbar. Kentnisse von Projektmanagement auf Grundlage der PMI Richtlinien werden empfohlen. 

Link to MCTS: Enterprise Project Management with Microsoft Office Project Server 2007

Beim Umhängen eines MOSS 2007 Servers in eine andere Domäne funktionieren natürlich die Servicekonten nicht mehr, die man bei der Konfiguration des SharePoint Servers angegeben hat. Bevor man jetzt manuell überall die Credentials ändert (IIS, SQL Server), und auch nach einiger Zeit immer wieder über nichtssagende Fehlermeldungen des MOSS stolpert (ich sag nur: An unexpected error has occured), hier ein praktischer Befehl des stsadm.

Stsadm.exe –o updatefarmcredentials –userlogin –password

Danach auf jeden Fall iisreset /noforce aufrufen.

Endlich Schluss mit “An unexpected error has occured” ? (Hoffentlich )

Im Blog vom SharePoint Team ist ein Debugger Feature vorgestellt worden. Damit kann man einen Debugger an Teamsites hängen.

Das Feature kann bei CodePlex heruntergeladen werden.