Just do I(nformation)T(echnology) : Deployment

Load Testen van Sharepoint met VSTS 2008 en VSTT Load Agents – Deel 3

mpriem — Tue, 19 May 2009 18:34:24 GMT

Het is al weer enige weken geleden dat ik mijn laatste post heb gedaan over het loadtesten van Sharepoint met Visual Studio Team Test. Deze post zal ik wijden aan het maken van webtests en het bundelen daarvan tot een loadtest.

De webtests zijn de losse acties die je wilt uitvoeren. Een simpele webtest is aan te maken door deze te recorden vanuit Visual studio en verder te bewerken via de GUI. Een geadvanceerde webtest zal veelal geprogrammeerd moeten worden. In deze post ga ik niet in op gecodeerde webtests. Het is met deze blogserie de bedoeling eenvoudig een loadtest uit te voeren op Sharepoint. Met de GUI kan je al aardig wat goede loadtests uitvoeren op basis collaboratie of web content management omgevingen, zonder ook maar een regel code te kloppen.

Het Test project

Begin met het aanmaken van een test project:

Als de configuratie gevolgd is uit mijn vorige blogpost zal er meteen een venster verschijnen voor het aanmaken van een loadtest. Selecteer Finish om de default instellingen te behouden. Selecteer in de Solution Explorer de properties van LocalTestRun.testrunconfig.
In de Web Test kies je bij Number of run iterations voor One run per data source row. Verder kan ervoor gekozen worden de default Browser type veranderen.

De WebTest

Om een webtest aan te maken kies je in het Visual Studio menu voor Test > New Test. Selecteer vervolgens de Web Test en geef de test een naam. Wanneer je er nu voor kiest de test aan te maken zal Internet Explorer openen om de test te recorden. Ik zal niet elke actie uit de testmix uit eerdere posts uitleggen, omdat deze post anders veel te groot wordt J (ok, ik ben gewoon te lui). Ik zal echter een redelijk complexe actie stap voor stap uitwerken, welke je kunt gebruiken als referentie voor de overige acties. De actie die ik ga gebruiken als voorbeeld is het Uploaden van een document.

Browse naar een teamsite en selecteer een document library. Upload vervolgens een document. Je zult nu in de linkerkolom alle opgenomen acties zien:

Stop vervolgens de recording door in de linkerkolom voor Stop te kiezen. Er vindt een analyse plaats van de output en je zult in de webtest de recording terugvinden. Als we nu de webtest opnieuw zouden uitvoeren, dan zouden we elke keer hetzelfde document uploaden naar dezelfde document library op dezelfde site. Dit is uiteraard niet wenselijk. We zullen dus een stukje databinding moeten doen. Voordat we dat doen, controleren we eerst onze recording. Als we hem draaien zou hij moeten werken.

Echter als we de test draaien krijgen we meteen een error:

Als we de requests bekijken, zie je een AccessDenied.aspx request. Sharepoint geeft dus aan dat je geen rechten hebt op de pagina. Dit komt omdat je vanuit gebruikers context de Visual Studio test uitvoert. Je kunt dit echter aanpassen door in het WebTest tabblad de security aan te passen:

Zou dit genoeg zijn???

Helaas, de volgende melding die we krijgen is als volgt:

Dit betekent dat Visual Studio het bestand niet kan vinden dat geupload moet worden. Om dit voor nu even op te lossen passen we de File Upload Parameter van het Upload.aspx request aan om het volledige pad naar het bestand te gebruiken:

LoadAgentKnownIssues.rtf wordt in mijn geval dus C:\Temp\LoadAgentKnownIssues.rtf

Als we de test nu draaien, gaat alles goed:

Op naar het Data Binden!!

Databinding

Ik maak gebruik van CSV bestanden maar je kunt ook een database of xml bestand gebruiken. Maak dus een CSV bestand aan en geef op de eerste regel headers op. In dit geval gebruik ik een enkele kolom met als header DocumentPath. Op de volgende regels zet ik de namen van de bestanden. Daarnaast heb ik nog een CSV bestand nodig met de verschillende sites die ik wil gebruiken. Geef het bestand de SiteName header en voeg de namen van de sites toe. Als laatste heb ik een bestand nodig met alle gebruikers en de wachtwoorden. We willen natuurlijk met meerdere accounts testen. Dit resulteert in de volgende drie bestanden:

Zoals je ziet vervang ik slechts delen van de padnaam en de URL. Dit doe ik omdat door het minimale tekstdeel te vinden dat variabel gemaakt kan worden, de kans groter is dat het CSV bestand voor meerdere parameters gebruikt kan worden. Ik loop hierdoor ook minder tegen problemen aan met het URL encoden van parameters, maar dat merk je vanzelf als je vaker dit soort tests ontwikkelt.

Nu is het belangrijk om te onthouden dat je bij het uploaden van files de uploadbestanden beschikbaar moet hebben op de loadagent machines. Nu kan dat op de volgende 2 manieren:

De bestanden kunnen toegevoegd worden aan de solution. Je hoeft dan niet het volledige pad te gebruiken. Bij het uitvoeren van de test worden de bestanden gekopieerd naar de load agents (als de Copy to Output directory properies van de bestanden juist ingesteld staan).
De bestanden moeten handmatig op de loadmachines gezet worden. Je dient dan het volledige pad te gebruiken als waarde. Ik gebruik deze manier.

Kopieer dus de bestanden naar de gewenste directory op de loadagent(s) en kies vanuit de WebTest tab van het project voor Add Data Source:
"

Kies voor CSV en selecteer het eerder aangemaakte bestand. Je kunt nu nog bepaalde kolomen selecteren, maar we hebben er maar 1. Kies ervoor het bestand toe te voegen aan het project. Doe dit ook voor het tweede bestand. Nu ze toegevoegd zijn, kun je de waarden gebruiken in de webtest.

Om een waarde te gebruiken, kan je in de properties van de test kiezen voor een datasource, maar vaak wil je slechts een gedeelte van een property vervangen door een variable waarde. Dit kan ook; je dient dan de volgende syntax te gebruiken:

{{<datasourcenaam>.<table>.<kolom>}} à {{Sites.sites#csv.SiteName}}

Als we nu in elk request de Url en Expected Response Url properties parametriseren hebben we de webtest bijna zover aangepast dat we hem kunnen draaien voor alle sites in ons CSV bestand. Voor en na is als volgt:

De test is nog niet helemaal gereed om tegen alle sites in ons CSV bestand te draaien. Als je het nu draait, mislukken alle iteraties behalve de eerste. Als je naar het mislukte request kijkt, dan krijg je de melding:

Request failed: Context parameter '$HIDDEN1.__EVENTARGUMENT' not found in test context

Dit betekent dat er schijnbaar een parameter gevuld had moeten zijn via een Hidden Field Extraction rule. Het gaat dus ergens eerder al mis, ondanks dat Visual Studio aangeeft dat de eerdere requests goed zijn afgehandeld. Als we van onder naar boven de requests aflopen komen we meteen in het vorige request de boosdoener tegen:

Schijnbaar kan Sharepoint een bepaalde List niet vinden. Als je vervolgens requests eens nader bekijkt, zie je dat er in de POST continu dezelfde List parameter wordt meegegeven. Aangezien elke list in een content database een unieke GUID heeft, zal Sharepoint de list in combinatie met een bepaalde site alleen kunnen terugvinden voor de eerste iteratie. We zullen de post parameter dus moeten parametriseren. Als we in voorgaande requests kijken is er nergens een GUID als parameter opgenomen. We kunnen hem dus niet direct uit te recording halen. Als we echter de ListID opzoeken in het ruwe Responses van de eerste iteratie, dan zien we dat in het response van het AllItems.aspx request de GUID een aantal malen voorkomt. We kunnen hem dus uit de response HTML plukken via een Extraction Rule:

Nu kan je het met een extraction rule op verschillende manieren aanvliegen, maar de makkelijkste is via een Text Extraction. Gebruik de volgende configuratie:

Een andere manier is om een Regular Expression te gebruiken. Ik gebruik dan als regular expression:

\{[A-Fa-f0-9]+\-[A-Fa-f0-9]+\-[A-Fa-f0-9]+\-[A-Fa-f0-9]+\-[A-Fa-f0-9]+\}

De index (welke occurance hij moet gebruiken) is voor OOTB Sharepoint teamsites 2.

Als we de Extraction Rule hebben aangemaakt voor het AllItems.aspx request, kunnen we hem gebruiken als QueryString parameter voor onze POST requests richting Upload.aspx. Zorg dus dat de List parameters als waarde onze GUID parameter gebruiken ( {{GUID}} ).

Zoals je hierboven kunt zien, zijn er nog meer request parameters die aangepast kunnen worden, namelijk RootFolder en Source. Zorg ervoor dat deze ook geparametriseerd zijn.

Een andere actie is dat we moeten zorgen dat niet steeds hetzelfde bestand wordt geupload. De laatste databinding is dus voor de te uploaden file. Als we de requests eens nader bekijken zie je in de context parameters van het tweede Upload.aspx request het File Upload Parameter.

Deze passen we aan met {{Files.files#csv.DocumentName}} is het Data Binden gereed. Het complete overzicht van mijn test ziet er als volgt uit:

Als we nu de webtest starten, gaat alles goed:

Als je de requests 1 voor 1 doorloopt, zie je in de context parameters dat er op elke site een ander document wordt gebruikt. Je kunt via de opties op de Data Sources nog bepalen of de files iteratief of random worden gekozen.

Als laatste binden we de user accounts. Dit gaat via het menu, waar we eerder het gebruikers account wijzigde:

Nu het Data Binden klaar is, zijn we nog niet klaar. We gaan nu onze webtest opschonen.

Opschonen

De bedoeling is het uploaden van het bestand te meten. Ik wil alles wat daar niet mee te maken heeft, uit de test hebben. Dit betekent dat alle resources (gif, css en scriptbestanden) niet meegenomen worden, en dat alle voorlooprequests (voor zover ze geen properties vullen) uit de recording gehaald worden. Ik doe dit om mijn meetresultaten niet te overspoelen met deze veelal lichte acties. Ieder heeft hier zo zijn eigen ideeen over, en ik zal niet pretenderen dat dit de enige manier is, maar meetresultaten zien er altijd veel mooier uit als je al die andere requests wel meeneemt, en ik heb altijd "Hope for the best, but plan for the worst". Uiteindelijk komen die requests toch bijna altijd uit clientcache of servercache.

Goed… Voordat ik begin met het opschonen, sla ik de WebTest altijd even op onder een andere naam als backup.

Het opschonen vereist een beetje gezond verstand. Bekijk de requests, probeer de structuur te achterhalen, en het zin van het onzin te scheiden. Het feitelijke uploaden is een POST naar Upload.aspx. Daar ik begonnen ben met het openen van de rootsite en van daaruit gebrowsed ben naar de document library, vertelt mij dat ik die requests normaal gesproken eigenlijk al niet nodig. Je ziet eveneens dat er geen properties zijn opgeslagen aan het ontbreken van de + voor het request. Dit betekent dat er geen waardes in de web context zijn opgeslagen die gebruikt kunnen worden in het volgende request:

Ik verwijder het eerste request dus!

Wat ik vervolgens meestal doe is tijdens het opschonen elke keer de test gewoon nog een keer aftrappen, om te controleren of de test nog steeds werkt.

Misschien valt het op dat de resource requests niet zichtbaar zijn in de recording. Dat klopt, maar bij uitvoering worden ze wel opgehaald. Om dit te voorkomen, dien je in de properties van de requests Parse dependent requests op false te zetten (elk request apart):

De webtest is zo voldoende opgeschoond. We zijn nu bijna klaar met de webtest. Er rest nog 1 belangrijke taak, namelijk het aanmaken van validation rules.

Validation Rules

Zoals we al een aantal malen hebben gezien geeft Visual Studio soms aan dat een request goed is uitgevoerd, terwijl we niet het verwachte response hebben gekregen. Denk maar aan de AccessDenied.aspx pagina. We kregen successful request van Visual Studio terug, maar dat is niet wat we willen. We zullen hier wat validatie moeten toepassen via Validation Rules.

Zo begin ik met een validation rule voor dat specifieke geval op elk request. Het makkelijkst is dat via een Text Found rule. Ik gebruik de volgende:

Hou er rekening mee dat Pass If Text Found op False moet staan. Hij moet namelijk failen als die tekst wordt gevonden op de pagina. Een andere die ik altijd op elke request toepas is een Text Found rule die zoekt naar de tekst: Troubleshoot issues with Windows SharePoint Services. Deze tekst staat namelijk op de Error pagina die Sharepoint gebruikt (tenzij je custom error pages gebruikt, of volledige errormeldingen toestaat in Web.config).

Met deze twee validation rules vang je bijna alles af. Standaard triggert Visual Studio al een failure op http status codes als 500 en 404.

Wat ik persoonlijk in dit scenario nog toevoeg is een Text Found rule voor de filename die geupload wordt. Ik parametriseer de tekst waarop gezocht wordt met {{Files.files#csv.DocumentName}}.

Nu is onze webtest eindelijk klaar!!

Als we nu meerdere tests gemaakt hebben kunnen we de LoadTest gaan configureren:

Load Test configuratie

Met meerdere webtests kunnen we gaan loadtesten. De configuratie is redelijk eenvoudig. In de solution explorer hebben we onze load test staan (bestand eindigt op .loadtest). Hernoem en dubbelklik deze om een tabblad te krijgen. Standaard ziet de configuratie er zo uit:

De belangrijkste settings zijn de Test Mix, de Browser Mix, de Network Mix en het Load Pattern. De Test Mix staat er nog niet tussen, maar hierin bepaal je welke tests en met welke verdeling uitgevoerd dienen te worden. Verder kunnen we met de browser Mix bepalen welke type browsers gesimuleerd dienen te worden, en met de Network Mix welke type netwerken (Deze laatste knijpt echter alleen de bandbreedte en doet niets met latencies en is daardoor dus niet echt spannend.). De Loadpattern bepaalt welke load er op de omgeving gezet wordt.

In deze test laat ik de Browser Mix en Network Mix default en zet ik de LoadPattern op een Step Load. Een stepload stelt mij in staat over een bepaalde periode telkens een aantal gebruikers op te schalen. Dit is aan te bevelen om de de te testen omgeving de Sharepoint en IIS caches te laten opbouwen. Met een constant userload, zet je meteen de maximale load op de omgeving, wat dus tot problemen zou kunnen leiden. Een typische step configuratie ziet er zo uit:

Met deze configuratie wordt er begonnen met 10 users en wordt er elke 10 seconde 10 users bijgeschakeld totdat we aan het maximum van 200 users zitten.

Nu is het de bedoeling testen toe te voegen aan de loadtest. Dit gaat door het aanmaken van een testmix. Kies voor Edit Test Mix van het context menu van de load test:

In de Test Mix kan je voor een aantal modellen kiezen, maar de Test Mix op basis van het aantal tests is het meest voor de hand liggende. Ik heb twee tests toegevoegd, welke ik met een 90% - 10% percentage verdeel. Dit betekent dat 90% van de acties het benaderen van de homepage is:

Nu is eigenlijk mijn load test al klaar. Ik kan via de Counter Settings nog System Counters toevoegen. Hiervoor moet het visual studio account rechten hebben op de machine (minimaal Performance Log User), en moeten de firewall rules juist zijn ingesteld. Via de Run Settings kunnen we bijvoorbeeld bepalen hoe lang de loadtest moet duren (Timing), maar ook bijvoorbeeld SQL tracing configureren of de connectie pool instellingen aanpassen.

De Timing instellingen zijn altijd van belang. Je bepaalt met Run Duration de looptijd, met de Sample Rate met welke interval performance counters worden gelogd en met Warm-Up Duration en Cool-down Duration hoe lang het duurt voordat er begonnen wordt met het verzamelen van meetgegevens en hoe lang voor het eind er gestopt wordt. Het opwarmen van cache en het opstarten van applicatie pools vervuilen immers alleen de meetresultaten.

Als dit alles is geconfigureerd, kan er begonnen worden met het load testen. Meer hierover in het volgende en laatste deel van deze blogserie J

Terminal Services Gateway beveiligen met ISA Server 2006

mpriem — Sat, 09 May 2009 11:13:30 GMT

Met ISA Server 2006 kan je een Terminal Services Gateway voorzien van extra beveiliging door deze te publishen via een Web Listener. Daar TSG gewoon gebruik maakt van RPC over HTTPs zoals Exchange met Outlook Anywhere dat ook doet, gaat het publishen hiervan net zo gemakkelijk.

Om te beginnen moeten we SSL certificaten hebben voor zowel de ISA server als de TSGateway. Aangezien de ISA Server draait op Windows Server 2003 hebben we nog niet de mogelijkheid om vanuit de Certificates Snap-in een Certificate Signing Request (CSR) te maken. Veelal moet er een offline request gemaakt worden, omdat dat bijvoorbeeld naar een Public Certificate Authority zoals Verisign gestuurd moet worden. Op Windows Server 2003 hebben we beperkte mogelijkheden. Zo kunnen we een request maken via IIS, maar een webserver installeren voor een CSR is een beetje overdone. Ook kunnen we gebruik maken van een Microsoft CA via de certificate Server Website, maar ook die is niet altijd voor handen. De laatste mogelijkheid is om een certificaat aan te vragen op een Windows 2008 machine met de mogelijkheid de private key te exporteren en dan vervolgens het complete keypair te exporteren en importeren. Dat is echter minder secure, want als het systeem gecompromitteerd wordt, kan het complete keypair gestolen worden, in plaats van alleen de public key.
Dan blijft er dus eigenlijk alleen CertReq.exe over, wat onderdeel is van de Administration Toolkit http://www.microsoft.com/downloads/details.aspx?familyid=86b71a4f-4122-44af-be79-3f101e533d95&displaylang=en

Hiervoor moet een INF bestand aangemaakt worden volgens de syntax op http://technet.microsoft.com/en-us/library/cc736326.aspx

Nu lijkt dit heel moeilijk, maar als je het even goed doorleest valt het allemaal wel mee. Mijn INF bestand ziet er als volgt uit:

[NewRequest]
Subject = "CN=rdp.home.com"
PrivateKeyArchive = FALSE
KeySpec = 1
KeyLength = 1024
Exportable = FALSE
UserProtected = FALSE
MachineKeySet = TRUE
Silent = TRUE
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
ProviderType = 1
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0x30
EncipherOnly = TRUE
[RequestAttributes]
CertificateTemplate = "WebServer"

Nu sign ik mijn eigen certificaten, maar Internet CAs hebben vaak bepaalde eisen over de opmaak van het CSR (voornamelijk rondom het Subject en usage attributen). Op de internetsites van deze bedrijven is vaak meer informatie te vinden. Zorg dus dat je aan deze voorwaarden voldoet.

Na het aanmaken van de INF, kan ik een CSR creëren met het volgende commando:"

Certreq.exe –new <padnaarinf.inf> <padnaarcsr.req>8

Met het CSR kan je vervolgens het certificaat aanvragen. Wanneer je het certificaat terugkrijgt van de CA (mocht je een Windows 2008 CA hebben zoals ik, kan je via de Certificate Authority MMC snapin het request honoreren, en het certificaat opslaan), dien je het als keypair op te slaan door het volgende commando te draaien:

Certreq.exe –accept <padnaarcertificaat.cer>8

De keypair wordt nu opgeslagen in de Computer > Personal certificate store. Vergeet dit laatste commando niet, want je kunt prima het certificaat opslaan via andere wegen, maar dan wordt het niet gekoppeld aan de private key die gebruikt is bij het vervaardigen van het request. Je hebt dan geen keypair en kan het certificaat dus niet gebruiken voor SSL/TLS doeleinden. Nutteloos dus.

Het tweede CSR is een stuk simpeler. Daar Terminal Services Gateway een Windows Server 2008 service is, kunnen we heel simpel een Custom Request maken vanuit de Certificates MMC snapin.

In het request, kies je voor het Web Server template. Behoudt de default settings, welke automatisch de common name als Subject neemt. Dit is voldoende voor ons scenario, tenzij je dit interne certificaat ook door een publieke CA wilt laten aanmaken, waardoor je weer met bepaalde eisen te maken kan hebben. Voor een interne CA –bijvoorbeeld de Windows 2008 CA – is dit meestal voldoende. Genereer het certificaat bij de CA (voor Windows 2008 CA via de Certificate Authority MMC Snapin > New Request) en importeer het certificaat in de Computer > Personal certificate store.

Na het installeren van de certificaten gaan we een Web Listener aanmaken. Dit doe je vanuit de Network Objects in de ISA Console.

Kies voor New Web Listener.
Geef een naam voor de Web Listener.
Kies er vervolgens voor Secure verbindingen te gebruiken
Geef de netwerken op waar de Listener, moet 'Listenen' J. Ik heb een 3-leg configuratie dus ik kies voor het External Network.
Kies vervolgens het certificaat dat we zojuist hebben aangemaakt.
Authentication moet op basic HTTP staan, met als directory Active Directory of LDAP. Voor meer informative over LDAP authenticatie, zie http://www.isaserver.org/tutorials/LDAP-Pre-authentication-ISA-2006-Firewalls-Part1.html
SSO kan niet met HTTP basic, dus selecteer Next en Finish om af te sluiten.

Vervolgens moet er een Publishing Rule aangemaakt worden. Dit gaat als volgt:

Vanuit de ISA Console ga je naar Firewall Policy > New > Exchange Web Client Access Publishing Rule.
Kies vervolgens voor Exchange 2007, Outlook Anywhere (RPC/HTTPs) en deselecteer Publish additional folders…
Kies voor Publish a single Web site or Load balancer.
Kies voor een SSL connectie richting de backend.
Geef de interne FQDN van de Terminal Services Gateway en de machinenaam of ip adres op:
Kies vervolgens voor This domain name only (type below:) en geef de externe FQDN op die we bij de certificaat aanvraag hebben opgegeven (de CN in het subject, in mijn voorbeeld rdp.home.com).
Selecteer de Web Listener die we zojuist hebben aangemaakt.
Kies voor No Delegation, but client may authenticate directly.
Selecteer een user set en maak de installatie af.

Verder kan het zijn dat het CA certificaat in de Trusted Certificate Root Authorities store van het Computer Account opgeslagen moet worden. Dit moet gebeuren op de server machines, maar ook op de client machines. Ik gebruik een interne CA, dus ik heb het op alle non-domainjoined machines en mijn client machines handmatig moeten toevoegen. Het certificaat is te vinden in de Computer > Personal store van de CA (veelal bevat deze er minimaal twee, dus controleer goed dat je het CA certificaat te pakken hebt, en niet het computer certificaat of enig ander certificaat)

Als Laatste vraag je de properties op van de Rule, en selecteer je Test Rule (vanaf ISA 2006 Service Pack 1). Dit controleert de configuratie. Als er iets mis is met certificaten, zal je dat nu zien.

Nu alles geconfigeerd is, is het tijd om het te testen met een terminal services client. In de advanced properties van de client, geef je de externe FQDN op van de ISA server:

Op de terminal services gateway geef je in je Connection Policy op, welke users connectie kunnen maken met de Gateway. In de Resource Policy geef je de users op die verbinding mogen maken met de resources, en je geeft de machines op die als resource mogen dienen. Als je nu een verbinding maakt, krijg je eerst een prompt voor Connectie, en vervolgens voor de resource. Ik vind het persoonlijk fijn om slechts een enkel account rechten te geven voor de connectie; deze verder geen rechten te geven op enig andere resource, en via AD Auditing te tracken; En vervolgens een ander account te gebruiken voor de connectie naar de resource.

Mocht je tegen problemen aanlopen, check dan de Terminal Services Gateway logs op de TS gateway en de ISA Logs. Verder is er nog enige informatie te vinden op: http://technet.microsoft.com/en-us/library/cc731353.aspx

Load Testen van Sharepoint met VSTS 2008 en VSTT Load Agents – Deel 2

mpriem — Sun, 15 Mar 2009 01:49:00 GMT

Deze post gaat over het installeren van je testrig en (slechts beknopt) over het vullen van de testomgeving met data.

Voor een testrig heb je in principe drie componenten nodig. Dat zijn de Test Controller, de Test Agent en de machine waar je Visual Studio Team System 2008 Test Edition draait. Nu kan uiteraard alles op 1 machine worden geïnstalleerd, dus voor deze reeks posts gebruik ik een enkele machine. Normaal gesproken werk je in ieder geval met een losse controller en losse agents. Visual studio voor het aansturen van de tests wordt nog wel regelmatig op de controller geïnstalleerd. De vereisten voor de componenten zijn als volgt:

Software:

Component		Software
Test agent		Windows Server 2003 RTM*, Vista, XP Sp2 Visual Studio Team System 2008 Load Agent SQL 2008 Express edition
Test Controller		Windows Server 2003 RTM*, Vista, XP Sp2 Visual Studio Team System 2008 Load Controller (SQL Server 2008 optioneel. SQL vereist Windows Server 2003 SP2)
Tester PC		Visual Studio Team System 2008 Test Edition SP1

* Test Agents en Controllers vereisen Windows Server 2003 RTM of hoger service pack. Windows Server 2008 wordt officieel niet ondersteund. Windows Vista echter wel, dus het zal waarschijnlijk ook wel werken op Server 2008, maar waarom zou je je niet aan de prerequisites houden?

Mocht je voor de Tester PC Windows Server kiezen, dien je de 'Internet Explorer Enhanced Security' uit te zetten. Dit voorkomt dat je problemen krijgt bij het recorden van de test scenario's.

Hardware:

Bij het kiezen van de hardware moet je er rekening mee houden dat de Load Agents voornamelijk de zwaarste last leggen op de machines. Ze zijn zeer hongerig naar CPU cycles en geheugen; dus het is aan te raden gewoon hele dikke bakken te nemen, met minimaal een moderne dual core, draaiend op 64 bits architectuur met 8GB aan geheugen. Verder is het testen op een Gigabit verbinding eigenlijk ook wel vereist, daar zware tests een flinke hoeveelheid bandbreedte kunnen verbruiken. Dit ligt uiteraard aan het type test en de test scenario's, maar houd er rekening mee. Vaak moet hardware ruime tijd van tevoren worden aangevraagd en je wilt niet tegen beperkingen aanlopen als het testplan toch anders wordt dan vooraf gedacht. Je zou er ook aan kunnen denken om hardware te huren. Met virtuele machines is geen ervaring, waardoor het lastig is in te schatten of dit een goede optie is. Dit zou getest moeten worden.

Configuratie	Component	CPU	HD	Memory
< 1000 virtual users	Test agent	2.6 GHz	10 GB	4 GB
< 2000 virtual users	Test agent	Dual proc 2.6 GHz	10 GB	8 GB
*N 2000 virtual users**	Test agent	Scale out N agents elk met Dual 2.6 Ghz	10 GB	8 GB
< 30 servers in test (test agents en te testen servers).	Test Controller	2.6 GHz	Met SQL : (N* 24 uur testdata * 10GB) + 10GB Zonder SQL : < 1 GB	Met SQL : 4 GB Zonder SQL : 2 GB
*N 30 computers in the test environment. This includes agents and servers under test.**	Test Controller	N* 2.6 GHz processors	Met SQL : (N* 24 uur testdata * 10GB) + 10GB Zonder SQL : < 1 GB	Met SQL : 4 GB Zonder SQL : 2 GB
	Tester PC	2.0 GHz	3GB	1 GB

In principe geeft deze tabel aan dat je dus een extra Test Agent moet bijschalen voor elke 2000 actieve users. Voor elke 30 agents heb je een controller nodig.

Netwerk

Voor de simulaties heb je in ieder geval een tweetal accounts nodig voor de agents en de controller (we gaan even uit van een Domain installatie. Workgroup is ook mogelijk). Maak dus twee service accounts aan voor de controller en voor de agents. Het controller account moet minimaal toegevoegd zijn aan de Performance Log Users op de machines die getest gaan worden (dus de sharepoint farm servers). Houd er ook rekening mee dat de Windows Firewall in de weg kan zitten. Voor Windows Server 2008 en Vista zal je meer stappen moeten verrichten zoals beschreven in http://blogs.msdn.com/edglas/pages/load-agent-and-load-controller-installation-and-configuration-guide.aspx Daar staat de Firewall standaard aan en de services die nodig zijn om de counters te loggen standaard uit.

Als je een testscenario met NTLM of Kerberos authenticatie providers wilt maken, zal je ook test users moeten aanmaken. Een voorbeeld is te vinden op : http://www.petri.co.il/create_users_for_testing_purposes.htm Nu hoef je niet voor elke virtual user een testuser aan te maken, maar voor elke 25 users zou ik toch wel een account willen hebben, met een minimum van 10. Dus 10.000 virtual users maakt 400 user accounts. Dit om toch enigszins het effect van authenticatie op de Sharepoint omgeving te kunnen benaderen, MySites en ook om het effect van audiencing mee te kunnen nemen in de tests.

Installatie Visual Studio

De installatie van Visual Studio spreekt redelijk voor zich. Alle prerequisites worden door de installer zelf geïnstalleerd. Visual studio is een zeer uitgebreid product, maar voor onze tests heb je in principe alleen de testing tools en 1 van de language tools nodig. Deze laatste is om de VS IDE te verkrijgen. Kies daarom alleen de Team System Test Tools categorie en een taal naar keuze (in mijn geval C#). De rest van de installatie spreekt voor zich. Installeer verder SP1 en de laatste fixes.

Installatie Load Agents en Load Controller

Voor de installatie van de Load Agents en de Load controller zijn de twee service accounts vereist die eerder zijn aangemaakt. Bij het starten van de installatie zal je de keuze krijgen een Agent of Controller te installeren.

Eerst installeer je de Test Controller. Deze zal meteen ook SQL Express installeren, maar die heb ik niet nodig aangezien ik de volledige versie van SQL ga installeren. Bij het starten van de controller installatie vraagt de installer alleen om de credentials van het controller service account. De rest van de installatie spreekt voor zich. Na installatie is de Controller als windows service geïnstalleerd en kan je hem configureren via Visual Studio.

Vervolgens installeer je de Agent software. Tijdens deze installatie wordt enkel gevraagd naar het agent service account en de naam van de agent controller. Geef dus de servernaam op waar de controller draait, in dit geval de lokale machine.

Installatie Visual Studio Service Pack 1

Na het installeren van de agents en controllers, moet Service Pack 1 voor Visual Studio geinstalleerd worden. Dit omdat anders SQL Server 2008 niet zal installeren. Deze vereist namelijk SP1 voor Visual Studio. SP1 update zowel de IDE als de controller en agents.

Voor het installeren van Service Pack 1 heb je echter ook de Visual Studio 2008 Service Pack Preparation tool nodig. Deze is te vinden op http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=A494B0E0-EB07-4FF1-A21C-A4663E456D9D&displaylang=en . Service Pack 1 (ISO) op http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=27673C47-B3B5-4C67-BD99-84E525B5CE61&displaylang=en

Installatie SQL Server

Net zo makkelijk als de installatie voor Visual Studio is de installatie van SQL Server 2008, mocht je daarvoor kiezen. De installer installeert zelf de prerequisites, en bij het kiezen van de componenten draait het alleen om de Database Engine en de management tools. Verder kan je de SQL Server Agent gewoon onder NETWORK SERVICE en de SQL Server Service onder LOCAL SYSTEM laten draaien. De rest van de installatie spreekt voor zich.

Configuratie Controller

Na installatie van de software dient de controller via Visual Studio geconfigureerd te worden. Maar maak eerst een LoadTest database aan op de SQL server instance door loadtestresultsrepository.sql uit te voeren op de SQL server (gebruik SQLCMD of dubbelklik en execute via de SQL Management Studio). Pas wel op… Als er reeds een LoadTest database bestaat, wordt deze gedropped. Na het aanmaken van de database dien je nog het Controller service account db_datawriter of db_owner rechten te geven op deze database.

Vervolgens start je Visual Studio en configureer je de IDE en de test controller voor de webtests. Kies bij het opstarten voor de Team Test Settings om de IDE voor testprojecten te optimaliseren.

Ga vervolgens naar Tools > Options > Test Tools > Test Project in de menubalk en configureer het standaard project template:

Creëer daarna een nieuw project via File > New > Project in de menubalk en kies voor een test project.

Het project wordt aangemaakt en je krijgt een wizard voor je kiezen. Negeer deze even en configureer eerst de controller agent door te kiezen voor Test > Administer Test Controllers in de menubalk. Voer de naam van de server in het controller veld. Een enter zou het scherm moeten refreshen. Als je problemen hebt met het benaderen van de controller service, probeer deze dan een keer te herstarten. Controlleer ook of je dezelfde versies van de controller en agent gebruikt door de versie van Microsoft.VisualStudio.QualityTools.LoadTestFramework.dll te controleren. Een mismatch kan ervoor zorgen dat de agent als disconnected in de agent lijst komt:

Zoals je in het venster hierboven kan zien, zal de controller standaard de SQL EXPRESS installatie gebruiken als datastore. Als je de stappen voor het aanmaken van de LoadTest database in SQL goed hebt uitgevoerd kan je deze nu veranderen. Gebruik dus de … knop om deze te veranderen naar de juiste SQL instance:

Datapopulatie

Ik ga in deze post niet geheel uit de doeken doen hoe je een testomgeving voorziet van de juiste testdata, maar ga er nu wel kort bij stil staan.
Om goed te kunnen testen moet je een goed gevulde testomgeving hebben. Ik kies er zelf voor om minimaal 25% van de uiteindelijke datagrootte te verkrijgen. Dus voor 1TB aan uiteindelijke data, wil ik minimaal testen op 250GB testdata. Ik vul de omgeving volgens de capaciteitsplanning die vastgelegd is voor de omgeving. Als er in de Architectuur gekozen wordt voor sites van maximaal 500MB, ga ik daar niet overeen. Idem voor de grootte van de contentdatabases. Probeer zo goed mogelijk de uiteindelijke structuur van de omgeving na te bootsen. Hierbij wat tips voor het vullen van de data:

Gebruik http://www.codeplex.com/sptdatapop om sites aan te maken, en lists te vullen. Op deze site staan eveneens veel voorbeelden.
Gebruik powershell om scripts te maken om makkelijk documenten te uploaden naar document libraries. (ik zal binnenkort wat scripts delen)
Gebruik powershell om mysites te genereren.
Gebruik echte data. Probeer van de klant data van fileservers te verkrijgen.
Probeer zoveel mogelijk unieke data te gebruiken. Als het even kan alle data. Het hergebruiken van data op meerdere plekken heeft een negatieve invloed op de testresultaten bij Search tests, daar een duplicate niet zorgt voor een groeiende index, slechts voor extra pointers voor de geïndexeerde chunks. Toch kan het soms niet anders, en moet je een dataset meerdere keren gebruiken. Voor search zou je er nog voor kunnen kiezen om een externe datasource te indexeren als het mogelijk is, om toch een redelijke index te hebben voor wat search tests. Toch is dat niet helemaal hetzelfde omdat security trimming daar niet plaats vindt.
Zorg voor goed gevulde sites, maar hou je aan de capaciteits adviezen in http://technet.microsoft.com/en-us/library/cc262787.aspx . Dus geen lists van meer dan 5000 items.

Dit is het einde van deel 2. In de volgende post zal ik laten zien hoe je test scenarios aanmaakt. Tot dan!

Load Testen van Sharepoint met VSTS 2008 en VSTT Load Agents – Deel 1

mpriem — Sat, 14 Mar 2009 22:19:00 GMT

Het load testen van een Sharepoint omgeving is niet iets waar makkelijk over gedacht moet worden. Voor een test moet je toch al gauw 6 tot 8 weken uittrekken om het gedegen voor te bereiden. Dit is uiteraard allemaal afhankelijk van wat je precies wilt testen en hoeveel tests je uit wilt voeren. Een voorbeeldplanning voor een doorsnee test zou er als volgt uitzien:

Opstellen van een Testplan (5 dagen)
1. Bepalen testscenarios
2. Bepalen verwachte resultaten
3. Planning en resources vaststellen
4. Uitwerken testplan
Configureren testomgeving en test rig (5 dagen)
1. Installeren testcontroller en agents
2. Configureren testomgeving (sharepoint configuratie, aanmaken test accounts, dns etc)
Vullen testomgeving met testdata (5 dagen)
1. Ontwikkelen data populatiescripts
2. Verzamelen testdata van fileshares of andere media
3. Vullen van de data
4. Vullen van de Index
5. Profile Import
Ontwikkelen webtests en load tests (10 dagen)
1. Maken van de test scenario's
2. Databindings maken voor webtests
3. Testen van webtests
Uitvoeren van de loadtests (2 - 10 dagen)
1. Uitvoering van verschillende tests
2. Opnieuw uitvoeren van tests als verwachte resultaten uitblijven en aanpassing in infrastructuur vereist is.
Analyse van testresultaten (2 – 5 dagen)
Opschonen testdata (1 dag)

Zoals je ziet komt er veel bij kijken. Voornamelijk het ontwikkelen van de testscenario's en het vullen van de testomgeving met testdata is een zware taak. Webtests aanmaken in Visual Studio is namelijk niet zo gemakkelijk als het lijkt. Hier zal ik verder op ingaan in het 4^e deel van deze serie posts.

Voordat je ook maar begint met het uitvoeren van tests, moet je duidelijk zien te krijgen wat je precies wilt gaan testen en wat je verwacht te gaan scoren op elke test. Nu gaat deze reeks posts over Load testing, maar naast het testen van je applicaties en infrastructuur, moet je ook nadenken over het eventueel testen van procedures, processen en functionaliteit. Denk bijvoorbeeld aan het testen van een Disaster Recovery plan, het testen van High Availability mogelijkheden en het testen van je custom workflows. Puur en alleen load testen is niet voldoende om te bepalen of de architectuur die gekozen is, voldoet aan de verwachtingen van de business en de vastgestelde service levels, en goed aansluit op de structuur van de beheerorganisatie.

Goed… Er is dus besloten Load Tests uit te voeren, maar wat gaan we precies testen en wat verwachten we van de tests? Je kan voor verschillende doeleinden een load test uitvoeren. Je kan een smoketest uitvoeren om te zien of je applicatie werkt. Je zet deze onder lichte druk en controleert de responses, de logs en systeemcounters om te zien of er iets stuk is in de applicatie en deze doet wat je ervan verwacht. Je kan een stresstest uitvoeren waarmee je de applicatie onder zware druk zet om te bepalen waar de bottlenecks in de omgeving zitten en hoe ver je kan gaan voordat de omgeving omvalt. Tenslotte kan je nog performance of capacity tests uitvoeren waarmee je in stappen de omgeving onder druk zet om te bepalen hoe een omgeving zich houdt onder verschillende loads. Deze gegevens kunnen eveneens gebruikt worden om een stuk capaciteitsplanning te doen in de aanloopfase van een project of later in het project als de applicaties al op de uiteindelijke hardware geland zijn.

Wat voor type test je ook kiest, je zult van te voren moeten bepalen wat de verwachte resultaten zijn. Wil je de throughput van je omgeving (Requests per Second, ofwel RPS) of de gebruikerservaring meten ( Page Time, of ook wel Time To Last Byte)? Wil je het maximaal aantal geïndexeerde documenten per seconde, of Publishing Cache hit ratio meten? Er zijn zoveel verschillende redenen waarom je een Load Test zou willen uitvoeren. Hoe dan ook, het is belangrijk van te voren te bepalen wat je precies wilt gaan meten en wat de verwachte resultaten zijn. Verreweg de meest gekozen reden van een Load Test is om de throughput van de farm te bepalen of valideren; dus het aantal RPS. Laten we er voor het gemak van uit gaan dat we willen verifiëren of een omgeving gaat voldoen aan de throughput requirements van onze klant. Verder wil deze klant dat de requests voor de homepage en teamsites gemiddeld binnen 5 seconden zijn afgehandeld. In dit geval gaan we dus een performance test uitvoeren en zijn zowel Page Time als RPS van belang.

Maar hoe bepaal je nu de gewenste RPS… Laten we dit voorbeeld verder uitwerken, want dit is vaak een groot vraagteken en je moet op z'n minst een weloverwogen schatting kunnen maken, om een zinnige test te kunnen doen.

DUS STEL…

Deze klant had, zoals zoveel klanten, geen duidelijk beeld van het gebruikersprofiel van hun gebruikers.
Ze gebruiken Windows Sharepoint Services voor basic collaboration en ze hebben 100.000 medewerkers.

Van deze gebruikers verwachten ze dat maximaal 50.000 medewerkers gedurende de dag gebruik gaan maken van de omgeving. Maximale concurrency wordt geschat op 5%, wat uitkomt op 2500 gebruikers.

Dit cursief gemarkeerde gedeelte is ongeveer het meest belangrijke gegeven dat een klant kan geven over hun gebruikers, want onthoudt het volgende:

Aantal gebruikers zegt helemaal niets!

Ik kan namelijk prima 100.000 gebruikers ondersteunen op mijn Virtual PC VM met 512 RAM op mijn 4 jaar oude laptop, als deze gemiddeld elke 12 uur een request doen. 100.000 request over 12 uur is namelijk slechts 2RPS.

Wat belangrijk is, is het gebruikersprofiel en de user concurrency.

Concurrency weten we nu dus, maar zoals ik al aangaf heeft de klant dus geen duidelijk beeld van het gebruikersprofiel van hun gebruikers. We kunnen hiervoor echter de voorbeeld profielen gebruiken die op technet te vinden zijn onder: http://technet.microsoft.com/en-us/library/cc261716.aspx Deze zijn opgesteld op basis van uitvoerige interne tests en tests met TAP en andere Enterprise klanten.

Dus, stel we gebruiken het volgende profiel:

Operation	Percentage of throughput
Get home page	15.00
Get cached document	15.00
Get static document	15.00
Get list page (HTML)	10.00
Get list page (grid)	10.00
Get list form	7.00
404 errors	5.00
Insert list item	2.00
Edit list item	2.00
Delete list item	2.00
Insert document	2.00
Synchronize with Outlook	2.00
Delete document	2.00
List URLs	2.00
DAV (Distributed Authoring and Versioning) open document for edit	1.00
DAV save document	1.00
FPRPC (FrontPage Server Extensions Remote Procedure Call) open document for edit	1.00
FPRPC Save document	1.00
Short-term check-out	1.00
Incoming e-mail	1.00
RSS (Really Simple Syndication)	1.00
Start workflow	0.75
Workflow task completion	0.75
Add/remove user	0.50

Dit profiel is een typisch profiel voor WSS collaboration scenarios: http://technet.microsoft.com/en-us/library/cc261795.aspx
Laten we verder stellen dat we de volgende gebruikerscategorieën hebben:

User load	Request rate
Light	20 requests per hour. An active user will generate a request (operation) every 180 seconds.
Typical	36 requests per hour. An active user will generate a request (operation) every 100 seconds.
Heavy	60 requests per hour. An active user will generate a request (operation) every 60 seconds.
Extreme	120 requests per hour. An active user will generate a request (operation) every 30 seconds.

Wanneer we de klant de gebruikers laten indelen in deze categorieën kwamen we tot de volgende resultaten:

	% users	Users	Active users	Concurrent Users	OPS per Users	Total OPS
Light	50%	50.000	25.000	1.250	0,0056	7
Typical	25%	25.000	12.500	750	0,0100	7,5
Heavy	20%	20.000	10.000	500	0,0167	8,35
Extreme	5%	5.000	2.500	125	0,0333	5,15
Total	100%	100.000	50.000	2.500	0,0112	28

Het blijkt dus dat met het huidige gebruikersprofiel en de maximale geplande concurrency, de omgeving geschaald moet zijn om 28 Operaties te ondersteunen en dat de pageloads binnen de 5 seconden moeten blijven. Operaties zijn echter nog geen RPS. Om dit te bepalen heb je ook weer een schatting nodig, want dit is sterk afhankelijk van de usageprofielen die je gaat simuleren in je webtests en de applicatie waartegen je gaat testen. Een redelijk normaal getal om te onthouden is 5 - 10 requests per operatie. Dus je verwacht tussen de 140 en 280 RPS te halen met pageloads binnen de 5 seconden.

Nogmaals: Onthoud dat je altijd uitgaat van de maximale concurrency, en dat aantallen gebruikers niets zeggen.

Nu je de tests in het vizier hebt, is het tijd om het complete testplan uit te werken. Zie dit testplan als een plan van aanpak. Hier hoort dus alles in te staan, wat je normaal gesproken in een plan van aanpak zou vinden, inclusief een complete beschrijving van de uit te voeren tests en de configuratie van de testomgeving en testrig.

Als het complete plan klaar is, en er overeenstemming over is bereikt, kan er begonnen worden met het prepareren van de testomgeving en de testrig. Meer hierover in deel 2 van deze serie.

Load Testen van Sharepoint met VSTS 2008 en VSTT Load Agents – Proloog

mpriem — Fri, 13 Mar 2009 12:15:44 GMT

Onlangs ben ik gevraagd voor een grote klant een testplan te ontwikkelen voor een nieuwe omgeving in ontwikkeling. Daar ik in het verleden wel wat testplannen had geschreven voor Exchange en ook wel wat IIS testen had gedaan, dacht ik dat wel even te doen. Op dat moment stond ik net op het punt te vertrekken naar Amerika voor een intern event, waar een van de senior architecten van ons Sharepoint Online platform een presentatie zou houden over het load testen van Sharepoint. Na deze sessie stond ik weer met beide benen op de grond. Het "Dat doe ik wel even" gevoel had plaatsgemaakt voor "HELP, dat is ingewikkelder dan ik dacht". Nu schuw ik een uitdaging nooit, dus vol goede moed ben ik aan de slag gegaan, en uiteindelijk pakte het zeer goed uit. De komende reeks posts zal ingaan op hoe een test voor te bereiden en uit te voeren, gebruik makend van Visual Studio Team System 2008 Test Edition en de Visual Studio Team System 2008 Load Agents.

Het eerste deel zal gaan over de vereisten voor een gedegen test en opstellen van een basisplanning. Het tweede deel zal vervolgens ingaan op de installatie van de test machines (de controller en load agents). Het derde deel zal ingaan op het ontwikkelen van de test scenario's en het bundelen van deze scenario's tot een load test. In het laatste deel behandel ik het uitvoeren van een load test.

Hou daarom de komende weken deze blog in de gaten…

Microsoft Office Sharepoint Server 2007 op Windows Server 2008

mpriem — Fri, 12 Dec 2008 14:22:00 GMT

De installatie van MOSS op Windows Server 2008 is uiteraard net even anders dan op Windows Server 2003. Hierbij een korte procedure:

MOSS installeert alleen op Server 2008 als SP1 in het installatie medium geslipstreamd is. Slipstream dus eerst SP1 (aanbevolen is de laatste updates meteen mee te nemen).
http://blogs.technet.com/mpriem/archive/2008/12/11/sharepoint-2007-slipstream.aspx
Installeer vervolgens de .NET 3.0 feature en de Web Server role met IIS6 metabase compatibility en .NET ondersteuning door ze te selecteren uit server manager of het volgende commando uit een admin console te draaien:

ServerManagerCmd.exe –install Web-Server Web-Metabase Net-Framework8
Ik zou aanraden .NET framework 3.5 SP1 ook meteen mee te nemen.
http://www.microsoft.com/downloads/details.aspx?familyid=ab99342f-5d1a-413d-8319-81da479ab0d7
Start vervolgens de installatie van MOSS zoals je gewend bent.

Technet: http://technet.microsoft.com/en-us/library/cc263408.aspx

Suc6!

Sharepoint 2007 slipstream

mpriem — Thu, 11 Dec 2008 16:32:39 GMT

Bij een farm installatie komt een hele hoop kijken. Gelukkig kunnen we dat redelijk goed automatiseren met een unattended setup, gebruik makend van een config.xml bestand (http://technet.microsoft.com/en-us/library/cc261668.aspx).

Echter dienen ook altijd de laatste updates dienen geïnstalleerd te worden. Slipstreaming is daarbij een term die meteen teboven komt, maar hoe werkt dat nu voor Sharepoint?

Het is eigenlijk heel simpel. In de root van het Sharepoint installatie medium staat een folder /Updates. Tijdens de installatie checked de installer of daar nog .msp bestanden (MSI patch bestanden) die meegenomen moeten worden in de installatie. Nu zijn de patches die je download van download.microsoft.com geen MSI patch bestanden maar executable archives. Het is echter heel simpel om de msp bestanden hieruit te halen.

Op dit moment zijn de benodigde fixes:

Service Packs:

Feature Packs:

Update Rollups (October):

Security fix:

Microsoft Security Bulletin MS08-077 - Important

De procedure is als volgt:

Download de fixes.
Extract de fixes naar een eigen folder door de volgende parameters mee te geven:

<update.exe> /extract:<path>8

Bijvoorbeeld voor WSS3.0 SP1:
wssv3sp1-kb936988-x64-fullfile-en-us.exe /extract:C:\Temp\WSSSP18

Meer parameters: http://support.microsoft.com/kb/262841
Na alle patches uitgepakt te hebben, kopieer je de complete content van de fixes naar de /Updates folder op het installatie medium.
Zorg echter dat je de fixes kopieert in de volgorde dat ze zijn uitgekomen en overschrijf bestanden waar nodig. Het gaat hier voornamelijk om de srvsetup.dll en wsssetup.dll. Deze bevatten de installatiemethodes voor de installer, en veranderen soms met een nieuwe rollup. Ook kan het zijn dat bepaalde mps bestanden vervangen worden in de toekomst.

In principe kan je ook gewoon de extract in de juiste volgorde doen, maar ik zie persoonlijk liever wat er precies overschreven wordt. De extract laat dat zien namelijk.

Nu de /Updates folder is gevuld kan je de installatie uitvoeren. Nog een kleine tip… Om van een directory gemakkelijk een ISO bestand te maken die gemount kan worden in een VM, gebruik ik altijd Folder2Iso, een handig freeware tooltje dat niet geïnstalleerd hoeft te worden (losse executable).

Enjoy J

Forefront Threat Management Gateway BETA

mpriem — Wed, 10 Dec 2008 23:25:00 GMT

Zoals voor velen al bekend houdt de merknaam ISA Server op te bestaan. Deze veelzijdige security oplossing gaat verder onder de naam Forefront Threat Management Gateway (TMG), waarvan reeds een publieke beta beschikbaar is op http://www.microsoft.com/forefront/stirling/en/us/default.aspx .

TMG is onderdeel van de suite onder de codenaam 'Stirling', waar onder andere ook een centrale management console onderdeel van is. Met deze console kunnen alle producten onder de Forefront merknaam beheerd worden.

Deze post gaat over de installatie van TMG. TMG heeft alles wat ISA Server 2006 heeft, maar installeert daarentegen WEL op Server 2008 en op 64 bits versies. Sterker nog, de uiteindelijke versie draait alleen op 64 bits versies van 2003 en 2008.

Installatie van TMG is zeer eenvoudig en vereist eigenlijk geen configuratie vooraf, behalve vaste IP addressen voor de NICs die gebruikt gaan worden en de volgende systeemeisen:

1GB RAM
150MB disk ruimte
1 NIC voor elk netwerk dat verbonden wordt met TMG.
64 bits architectuur

De installatie zal verder alle prerequisites installeren. In dit geval zijn dat:

Routing en Remote Access Services voor de NAT, remote access en routing diensten.
Internet Information Services voor de reports.
SQL Express voor de opslag van de configuratie en logs.

Na de ISO gebrand en geladen te hebben start de installatie met de volgende stappen:

Welcome Screen à Next
EULA à Next
Customer Information , je naam en bedrijf à Next
Component Selection à Next
Internal Network, waarbij je de iprange van het interne netwerk moet opegeven. à Next

Op dit moment waarschuwt de installatie dat het services gaat herstarten als IIS, Routing en Remote Access en SNMP service. Echter op een kale server zijn deze nog niet aanwezig J
Wanneer je de waarschuwing hebt geaccepteerd, kan er gekozen worden de installatie te starten.

Setup installeert de software en alle benodigde extra componenten. Schijnbaar installeert het enkele fixes, want ik moest tijdens de installatie de server rebooten door een hotfix installatie. Aangezien ik geen internetverbinding had, kan het dus niet anders dat TMG dat heeft gedaan.
Ik moest de setup dus opnieuw starten en alle stappen nogmaals doorlopen. Erg slordig vind ik.

Na de installatie start de Getting Started Wizard waarmee de initiele configuratie gestart kan worden.

De Configure Network Settings sectie stelt je in staat te kiezen uit een aantal netwerk typologieën zoals deze ook aanwezig zijn in ISA Server 2006.

De Configure System Settings stelt je in staat de domain/workgroup en hostname voor je server te configureren. Deze beta is echter alleen geschikt voor Domain installaties zoals de helpfile mij verteld. Ik heb echter een workgroup installatie gedaan en deze werkte wel voor de basis firewall.

De Define Deployment Options is tenslotte bedoelt om MS Update, Customer Experience Reporting en Telemetric Services te configureren. Deze laatste stuurt informatie over malware dat geblockeerd wordt naar Microsoft om verbeteringen in het product aan te brengen. Ik stel dus voor dit in te stellenJ

Na de wizard doorlopen te hebben kan je aan de slag met TMG, en zal je zien dat het eigenlijk nog ISA 2006 is, met wat extra managebility features.

Ik zou zeggen, aan de slag!

Workflow beheren (Deel 1)

mpriem — Fri, 14 Nov 2008 14:45:00 GMT

Problemen met workflow zijn vaak lastig te achterhalen. Zeker omdat klanten vaak eigen custom workflows ontwikkelen. Deze posts bevatten wat informatie over workflow internals en hoe workflow te beheren als Sharepoint admin. Deze eerste post gaat voornamelijk over de structuur van een workflow.

Workflow 101

Een workflow is een reeks activiteiten die uitgevoerd moeten worden in bepaalde volgorde, op basis van bepaalde condities. Een simpel voorbeeld is een workflow die handtekeningen voor een nieuw document verzameld alvorens het te archiveren. Als iemand het document afkeurt halverwege, zal het document teruggestuurd worden naar de persoon die om goedkeuring vroeg.
Workflow komt in veel applicaties voor. Daarom is sinds het .NET framework 2.0 een engine opgenomen die gebruikt kan worden om dit te vergemakkelijken voor ontwikkelaars. Deze engine is onderdeel van de codetak binnen het .NET framework genaamd Windows Workflow Foundation.

De standaard (maar ook de meeste custom) workflows binnen sharepoint zijn gebaseerd op deze engine, welke wordt gehost binnen het worker process van de Web applicatie waar de workflow wordt gebruikt.

Windows Workflow Foundation maakt het mogelijk twee verschillende workflows te creëren, namelijk State Machine workflows (event-driven) en Sequential workflows. In essentie is het verschil dat een sequential workflow een van te voren bepaald pad volgt en een state machine workflow reageert op bepaalde events en dynamisch kan veranderen van status. Een workflow kan daardoor dus ook terugkomen op het startpunt doordat de status wijzigt naar de beginstatus. Met een sequentiële workflow kan dat dus niet. State Machine is dus veel meer een workflow die past bij binnen bedrijfsprocessen, waar sequentiële workflow meer past binnen procesautomatisering.

Workflow binnen Sharepoint

In Sharepoint worden gegevens gestructureerd en aangeboden via content types die het schema van de gegevens bepalen en de lists en libraries (library is in prinipe gewoon een geadvanceerde list, dus vanaf nu zal ik alleen list gebruiken) die de structuur bepalen. Een workflow werkt op verschillende niveau's. Hoe de workflow is ontwikkeld bepaald waaraan een workflow toegekend kan worden.

Een workflow kan ontwikkeld worden via Visual Studio of via Sharepoint Designer. Een workflow template via Visual Studio kan geassocieerd worden met een list of contenttype. Een workflow via Sharepoint Designer kan alleen met een list geassocieerd worden. Er wordt daarvoor een instance gecreëerd van een workflow voor elk item in de list.

Een workflow kan dus gestart worden voor een item in een list (bijvoorbeeld een document in een document library). Er wordt dus een instance gestart van de workflow voor een bepaald item. Bij de creatie van de instance gaat er een activiteit van start, welke wordt bijgehouden in een tasklist. Daarnaast hebben workflows meestal een history list waar het verloop van de workflow wordt bijgehouden. Dit zijn normale sharepoint lists.

Ik heb in principe nu al een aantal belangrijke termen genoemd. Template, Instance en Associatie.

Ik hou voorlopig even de focus op Visual Studio workflows, daar deze het meeste voorkomen en ook het meest complex zijn. Een workflow binnen Visual Studio wordt ontwikkeld tot een workflow template, welke via een feature wordt geactiveerd en meestal door een solution wordt uitgerold. Voor een beheerder is het niet zo zeer van belang om de structuur van een workflow feature te begrijpen, maar om er toch kort aandacht aan te besteden, bestaat een workflow feature in ieder geval uit een feature.xml en een workflow configuratie xml. Daarnaast kan de feature gebruik maken van 1 of meerdere ASPX pagina's of XSN forms, en 1 of meerdere binaries of XOML bestanden. Door de feature uit te rollen met een solution bepaal je in de solution waar deze bestanden zich gaan bevinden. Het kan zijn dat deze bestanden reeds bestaan op het filesysteem. Ze kunnen echter ook deel uitmaken van het feature.

De feature.xml moet aanwezig zijn in de feature directory (default = c:/Program Files/ Common Files/Microsoft Shared/web server extions/12/TEMPLATE/Feature). Het bevat de metadata van de feature. Een typisch feature.xml bestand zou er voor een workflow als volgt uitzien:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Feature Id="<guid>" Title="Workflow" Description="My Custom Workflow" Scope="Site ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver" xmlns="http://schemas.microsoft.com/sharepoint/"> <ElementManifests> <ElementManifest Location="workflow.xml"/> <ElementFileLocation="initiationform.xsn"/> </ElementManifests> <Properties> <Property Key="GloballyAvailable" Value="true" /> <Property Key="RegisterForms" Value="*.xsn" /> </Properties></Feature></Elements>

Het workflow configuratie bestand dient ook aanwezig te zijn in de feature directory (in deze feature workflow.xml) en bevat de metadata rondom de workflow en ziet er ongeveer zo uit:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Workflow Name="AdventureWorksWorkflow"
Description="Use this workflow to track sequential tasks of users."
Id="C6964BFF-BG8D-41ac-AC5E-B61EC111731C"
CodeBesideClass="AdventureWorks.Workflow1"
CodeBesideAssembly="AdventureWorks, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e3bce121e9429c"
TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
AssociationUrl="myAssocPage.aspx"
InstantiationUrl="_layouts/IniWrkflIP.aspx"
ModificationUrl="myModPage.aspx">
<Categories/>
<AssociationData>

…

</AssociationData>
<MetaData>
<Instantiation_FormURN>urn:schemas-adventureworks-com:workflow:ReviewRouting-Init</Instantiation_FormURN></MetaData>
</Workflow>
</Elements>

Zoals je ziet in de workflow.xml staan er een aantal URL's (AssociationURL, InstantiationURL, ModificationURL en StatusPageURL) genoemd en is er ook een Instantiation_formURN benoemd. Deze waardes verwijzen naar webpagina's die getoond worden binnen de verschillende stadia van de workflow. Dus bij het associeren van de workflow met (toekennen aan) een list of content type, bij het starten van een nieuwe workflow (dus het instantieren van een geassocieerde workflow op een item) en bij het wijzigen van een lopende workflow. Je kunt hier ASPX pagina's of InfoPath forms voor gebruiken. ASPX pagina's geef je gewoon op in deze properties. Als je echter InfoPath forms wilt gebruiken moet je de volgende waardes gebruiken voor de verschillende fases waar je ze wilt gebruiken:

AssociationUrl="_layouts/CstWrkflIP.aspx"
InstantiationUrl="_layouts/IniWrkflIP.aspx"
ModificationUrl="_layouts/ModWrkflIP.aspx"

Verder moet je in de MetaData scope opgeven welke forms je wilt gebruiken, door de URN op te geven. In het workflow.xml voorbeeld zie je een voorbeeld van een instantiatie formulier wat gebruikt wordt:

<MetaData>
<Instantiation_FormURN>urn:schemas-adventureworks-com:workflow:ReviewRouting-Init</Instantiation_FormURN></MetaData>

De URN vind je door een form in InfoPath te openen in designer mode en via File > Properties het FormID veld te nemen.

Verder kan je voor de volgende fasen in een workflow een form opgeven.

Associatie à Association_FormURN
Instantiatie à Instantiation_FormURN
Aanpassen workflow à Modification_FormURN
Configuratie voor bepaalde taak in een workflow à Task<ID>_FormURN (Bijv: Task0_FormURN)

Verder zie je in de workflow.xml een assembly en classnaam genoemd. Dit is de code die uitgevoerd dient te worden binnen de workflow. Het is meestal een DLL die in de Global Assembly Cache is opgenomen. Echter er kan ook gewerkt worden met markup XOML files, wat via Extensible Application Markup Language logica beschrijft wat een workflow precies doet. Dit is identiek aan de Sharepoint Designer workflows and kan alleen worden toegepast op een List. Daarnaast kan er slechts gebruik gemaakt worden van een aantal activiteiten en condities. De XOML workflow wordt dus geïnterpreteerd gedurende runtime en is beperkt.

Als je de feature via een solution deployed hebt en geactiveerd hebt voor de site, kan je workflows gaan gebruiken. Je kunt ze handmatig starten via de GUI of automatisch via bijvoorbeeld via Events die getriggerd worden door gebruikersinteractie en afgehandeld worden door code via Eventhandlers in een custom feature.

In de volgende post zal ik dieper ingaan op het deployen van een workflow en het gebruik ervan….

Sysprep & Imaging Windows Server 2008

mpriem — Tue, 16 Sep 2008 17:52:00 GMT

Deployment van Windows Server 2008 zal in de toekomst meer en meer gebruik gaan maken van imaging. Dit zie je terug komen in de strategie van de deployment software die momenteel op de markt verschijnt. WIM (Windows Image) is het toverwoord. Dit artikel zal laten zien hoe je een Windows Server 2008 installatie imaged en configureert, gebruik makend van Sysprep, WinPE 2.0 en Windows Automated installation kit.

De stappen die je moet uitvoeren zijn de volgende:

Installeer Windows 2008 Server met additionele software.
(optioneel) configureer unattend.xml
Sysprep je systeem.
Boot WinPE met ImageX tools
Maak een WIM van je Systeem.

STAP 2:
Een unattend.xml bestand stelt je in staat de configuratie van een systeemimage te voltooien na de eerste boot. Hiervoor kan je Windows System Image Manager gebruiken. Het probleem is dat je echter eerst een WIM image moet hebben (staat er 1 op de Windows server 20078 DVD) om een XML bestand te kunnen configureren. Daarnaast zijn de opties vreselijk uitgebreid en schiet het zijn doel in veel gevallen voorbij. Ik verwijs daarom naar een artikel dat een voorbeeld geeft, mocht je het toch willen.
STAP 3:

Dit artikel gaat je niet vertellen hoe je een Windows Server 2008 systeem installeert, dus ga ik ervan uit dat je dat al gedaan hebt. De volgende stap is om Sysprep te draaien om je systeem te sealen voor deployment.

Sysprep zit vanaf nu standaard in het OS. In Windows Server 2008 (en Windows Vista) vind je het onder:

c:\Windows\System32\Sysprep\sysprep.exe

Wanneer je deze nu start krijg je de opties om je image in "Audit mode" of "Windows Welcome mode (out-of-box Experience)" wilt brengen. De "Audit mode" stelt je in staat je Windows image te customizen met eigen software en scripts en zorgt ervoor dat je niet het standaard Welcome screen krijgt als je image opgestart is. Hier worden andere secties uit de unattend.xml/sysprep.xml gebruikt dan bij de andere mode. Na het booten van het image zullen stappen uit AuditSystem en AuditUser uitgevoerd worden.

"Enter System Out-of-Box Experience (OOBE)" is de standard mode waarmee je je image sealed. De gebruikelijke secties uit de unattend.xml worden uitgevoerd.

"Generalize" verwijdert alle systeemspecifieke informatie uit het OS (bijvoorbeeld de SID), en vormt een algemeen image.

Naast de 'System Cleanup Action' kan je met de 'Shutdown Options' wat je systeem doet nadat je Sysprep gedraait hebt. Kies voor de 'System Out-of-Box Experience (OOBE)', en 'Generalize' en laat het systeem afsluiten. Je systeem is nu klaar om een Image van te trekken.

Als je er voor kiest om een unattend.txt te configureren zou ik de commandline variant gebruiken:

sysprep.exe /oobe /generalize /shutdown /unattend:

STAP4:

Om het image te maken heb je tools nodig. We gaan een WinPE bootimage maken met de ImageX tools om vervolgens vanaf te booten en het WIM image van het systeem te trekken. Download en installeer daarom de Windows Automated installation kit op je admin pc. Uit je program list kan je een command shell openen waar de meest gebruikte tools al in je PATH staan. Draai vervolgens het volgende commando: Copype.cmd x86 C:\WindowsPe

Dit commando kopieert de x86 sources van WinPE naar een door jou te kiezen directory, in dit geval C:\WindowsPe. Je kan dit ook voor x64 doen... Het laat zich raden wat het commando dan moet zijn :) .

Kopieer vervolgens ImageX naar een subfolder van de iso directory die aangemaakt is in C:\WindowsPe.

[viewcode] src=http://www.spurius.nl/scriptfiles/Imagex.txt showsyntax=no [/viewcode]

Ook dien je een win image configuration bestand aan te maken. Dit bestand wordt voornamelijk gebruikt om bestanden en directories te excluden bij de creatie van een image. Een voorbeeld bestand is het volgende:

[viewcode] src=http://www.spurius.nl/scriptfiles/wimscript.ini.txt link=yes showsyntax=no scroll=yes scrollheight=200px[/viewcode]

Kopieer dit wimimage.ini bestand naar dezelfde directory waar ImageX staat.

STAP5:

Open nu de command shell via de cmd-link vanuit de " Windows AIK tools" program group.
In de shell draai je het volgende commando om een bootable ISO image te maken:
oscdimg.exe -n -bc:\WindowsPE\etfsboot.com c:\WindowsPE\ISO c:\WindowsPE\bootcd.iso

Brand het iso image nu naar cd of mount het via remote media boards. Boot het systeem en dump een image naar een netwerkshare. Doordat veelgebruikte NIC drivers gewoon in de HAL van WinPE zitten, zal de netwerkverbinding (hopelijk) gewoon gestart zijn. Als je geen DHCP hebt draaien kan je met NETSH ip addressen toewijzen en daarna met NET USE een netwerk share aanmaken:

Statisch IP:
Netsh interface ipv4 add address address=x.x.x.x/x gateway=x.x.x.x
DNS Server:
Netsh interface ipv4 add dnsserver x.x.x.
Share:
Net Use Z: \\\ /user:

Nu de share gemaakt is, maak je een WIM image: Imagex /capture /compress max C: Z:\Cdrive.Wim “Spurius Cdrive Image” .

Nu heb je een image die klaar is om gebruikt te worden door bijv Windows Deployment Services.

Ik zal in een later artikel ingaan op WDS voor 2008...

Suc6 met testen :)