Just do I(nformation)T(echnology) : Portal Server 2003

401.1 Authentication failed bij browsen naar lokale IIS5 en IIS6 websites

mpriem — Fri, 17 Apr 2009 10:33:00 GMT

Sinds kort komen er steeds meer incidenten binnen van problemen bij het browsen naar websites op de lokale machine waar gebruik gemaakt wordt van windows integrated authenticatio. Dit komt door wijzigingen in het NTLM Authenticatie mechanisme binnen HTTPWebRequest. In voorgaande versies was het mogelijk om een reflection attack uit te voeren, waarbij het mogelijk was een systeem zijn eigen challenge via een tweede connectie voor te schotelen, waardoor de aanvaller een geauthenticeerde connectie overhoudt . Dit is verholpen door standaard niet meer toe te staan een challenge die door zichzelf is verstuurd is te authenticeren behalve als het om een challenge voor het loopback adres is (127.0.0.1).

Als je nu dus browsed naar een pagina, gebruik makend van een hostheader, krijg je een mooie HTTP 401.1 - Unauthorized: Logon Failed

Er zijn twee manieren om dit te omzeilen.

Specifieer hostnames die gekoppeld zijn aan het loopback adres:

Start de registry editor en browse naar de volgende key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Maak een nieuw Multi-String Value aan met de naam BackConnectionHostNames.
Specifieer alle hostnames die gekoppeld moeten worden aan het loopback adres.
Stop de registry editor en herstart IISAdmin service.

Disable de loopback check

Start de registry editor en browse naar de volgende key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Maak een nieuw DWORD Value aan met de naam DisableLoopbackCheck.
Geef het DWORD een waarde van 1.
Stop de registry editor en herstart de machine.

Het moge duidelijk zijn dat de eerste optie de voorkeur geniet.

Voor meer informatie:

http://support.microsoft.com/kb/896861

http://msdn.microsoft.com/en-us/library/cc982052.aspx

Dit probleem komt vaak voor in Sharepoint omgevingen waar de indexer gebruikt wordt om de lokale machine te crawlen. Ook wanneer beheerders beheer doen op de lokale machine treedt dit op.

Ontwikkelen voor Sharepoint zonder Visual Studio op Windows Server

mpriem — Tue, 17 Mar 2009 13:18:00 GMT

Ik programmeer wel eens wat voor Sharepoint om mij te ondersteunen bij het oplossen van incidenten of voor rapportage. Het vervelende is dat ik altijd binnen een Virtual PC VM zat te kloppen, wat nu net even wat minder presteert (wat een understatement) dan de fysieke machine. Nu blijkt dat het ook prima mogelijk is voor Sharepoint te ontwikkelen op een client OS. Dit door gebruik te maken van de mogelijkheden binnen Visual Studio voor remote debugging en development. Deze post gaat daar verder op in.

Installatie Visual Studio

Voor het ontwikkelen maken we uiteraard gebruik van Visual Studio. Ik gebruik in dit document de Team Suite editie. Je kunt echter ook de Professional editie gebruiken. Alle andere versies ondersteunen geen remote debugging/development dus kunnen in het scenario in deze post niet gebruikt worden.

Het installeren van Visual Studio spreekt voor zich. Ik kies voor de volgende installatie, maar je kunt uiteraard zelf bepalen welke componenten je wel of niet wilt gebruiken, als je maar minimaal 1 van de language tools installeert zodat je de IDE hebt:

Na de installatie is het aan te raden Service Pack 1 te installeren (http://www.microsoft.com/downloads/details.aspx?FamilyId=27673C47-B3B5-4C67-BD99-84E525B5CE61&displaylang=en ), en Windows Update te configureren om de laatste updates te downloaden (SP1 kan ook via Windows update binnengehaald worden). Voordat je SP1 installeert moet je echter eerst de Service Pack Preparation tool (http://www.microsoft.com/downloads/details.aspx?FamilyId=A494B0E0-EB07-4FF1-A21C-A4663E456D9D&displaylang=en ) uitvoeren.

Vervolgens installeer je de Visual Studio 2008 extensions for Windows SharePoint Services 3.0 v1.2 http://www.microsoft.com/downloadS/info.aspx?na=40&p=2&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=b2c0b628-5cab-48c1-8cae-c34c1ccbdc0a&u=http%3a%2f%2fwww.microsoft.com%2fdownloads%2fdetails.aspx%3ffamilyid%3d7BF65B28-06E2-4E87-9BAD-086E32185E68%26displaylang%3den (of de CTP van 1.3 als je het aandurft, of X64 draait http://www.microsoft.com/downloadS/details.aspx?familyid=B2C0B628-5CAB-48C1-8CAE-C34C1CCBDC0A&displaylang=en ). Het is niet vereist, maar biedt Sharepoint project- en item templates. Deze extensions draaien alleen op Server Operating Systemen, maar daar is een truc voor. Draai gewoon het volgende commando om een registry key aan te maken om de MSI te misleiden:

REG ADD 'HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0' /v Sharepoint /t REG_SZ /d Installed8

Nu kan je de extensions ook installeren op Vista of Windows 7. De installatie spreekt voor zich (Let wel… v1.2 draait alleen op x86).

Installeren Virtual PC

Installeer nu Virtual PC 2007 SP1 en een Sharepoint VM. We gaan code kloppen op onze lokale machine maar de project bestanden komen in de VM te staan. Verder gaan we de code draaien en debuggen op de VM via remote debugging. Hiervoor moeten we een netwerk verbinding hebben met de VM. Je wilt echter niet dat een VM contact kan leggen met het netwerk waar je developer PC inhangt. In Hyper-V en Virtual Server hebben we zoiets als een host only network, waar de VM's contact hadden met de host, maar niet met andere netwerken waar de host een verbinding mee kan leggen. In Virtual PC moet je echter wat meer doen om dit voor elkaar te krijgen.
Om een host only netwerk op te zetten tussen je VM host en je VMs in Virtual PC kan je gebruik maken van de loopback adapter. Om deze te kunnen installeren onder Vista of Windows 7 moet je even zoeken. Je kan gebruik maken van devcon.exe (devcon.exe install %windir%\inf\netloop.inf *msloop8 ) of je kan hem toevoegen gebruik makend van Device Manager. Hiervoor moet je echter de 'Add Legacy Hardware' optie gebruiken:

Configureer vervolgens ip settings voor de loopback adapter en configureer de VM in Virtual PC om gebruik te maken van de loopback adapter:

Stel het ip adres van de VM in op hetzelfde subnet als je hostip van de loopback adapter en pingen maar!
Maak vervolgens een share aan voor '%Program Files%\Common Files\Microsoft Shared\web server extensions\12\ISAPI' in de VM, en maak daarnaast nog een project folder aan waar vanuit je de debug builds wilt gaan draaien, en share deze ook. Map de share voor de ISAPI folder op de developer PC.
De ISAPI folder bevat de objectmodel dlls, die je nodig hebt om als REFERENCE te dienen in je Sharepoint VS projecten.

Configuratie remote debugging

Nu de verbindingen gelegd zijn en de shares zijn aangemaakt is het tijd om remote debugging te configureren. Dit gaat als volgt:

Installeer de remote debugger http://www.microsoft.com/downloads/details.aspx?FamilyID=440ec902-3260-4cdc-b11a-6a9070a2aaab&displaylang=en#filelist

Na de installatie start automatisch het debugger configuratie venster, waarin je eigenlijk alleen maar hoeft aan te geven of je de debugger als Service of als Windows applicatie wilt draaien. Ik draai het als windows applicatie, maar je kan hem ook als Windows Service draaien.

Ik had met de debugger als Service wel wat problemen met het verbinden met de debugger. Hier kom ik later op terug. Ook heb je als Windows Service geen console output als je een console applicatie debugged. Het window is hidden, omdat de Service in de background draait, en elk childprocess ook als backgroundprocess wordt opgestart. Nu moet je voor een Windows Service een service account opgeven. Nu kan je kiezen voor Local System, echter werkt dit niet als je developer PC in een ander Domain hangt dan de VM, wat meestal zo is. Het service account wat je opgeeft heeft administrator rechten nodig en het 'Logon as Service' user right. Nu moet er een wederzijds vertrouwen zijn tussen de developer pc en vm. De remote debugger moet zich kunnen authenticeren met de developer pc en vice versa. Als je developer pc of laptop (in mijn geval) dus lid is van het ene domein en de VM van het andere, heb je een uitdaging. Een trust aanmaken gaat vaak niet. Zeker niet als je laptop of pc lid is van het bedrijfsdomein en de VM van een eigen testdomeintje. Nu is er een oplossing voor. Je zorgt er gewoon voor dat er in het testdomein op de VM een account bestaat met dezelfde accountnaam en hetzelfde wachtwoord als het account waarmee je jezelf aanmeldt op de laptop of pc. NTLM zal ervoor zorgen dat er geauthenticeerd kan worden (http://support.microsoft.com/kb/102716)

Ik start de debugger dus als Windows applicatie. De vereisten voor authenticatie zijn hetzelfde. De gebruiker die de debugger start, moet zich kunnen authenticeren bij de developer pc en de gebruiker die visual studio start, moet zich kunnen authenticeren bij de VM. Ik gebruik bijna altijd PSEXEC van SysInternals, om de debugger bij het aanmelden op te starten (http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx)

PSEXEC /d /u <domain>/<user> /p <password> "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe"8

Je kan ook Secondary Logon gebruiken om de debugger te starten:

Runas /noprofile /user:<domain>/<user> "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe"8

Nu de debugger draait, moet de firewall nog geconfigureerd worden op zowel de client als de server. Je krijgt dan vervolgens vanzelf de firewall meldingen en UAC meldingen. Dit gaat het makkelijkst door in Visual Studio te kiezen voor Debug > Attach to Process Geef in het venster de VM server naam op en als het goed is krijg je dan de benodigde firewall waarschuwing op de client. Mocht je nog problemen hebben; de porten die geopend moeten worden zijn: DCOM (TCP Port 135) en IPSEC (UDP 4500 / UDP 500) http://msdn.microsoft.com/en-us/library/h0d7tte4(VS.80).aspx )
Hierbij is het belangrijk de echte servernaam te gebruiken, want je kan de debugger niet benaderen op IP. Je moet er dus ook voor zorgen dat name resolutie plaats kan vinden. Zet de VM dus bijvoorbeeld in je HOSTS file.

Voor de server zal je de vereiste firewall instellingen moeten zetten, maar aangezien het een afgeschermde development VM is, schakel ik de firewall gewoon altijd uit. Maar mocht je het aan willen laten staan, is de File and Printersharing firewall rule genoeg. Als de firewalls zijn geconfigureerd moeten we alleen nog de .NET code access security (http://msdn.microsoft.com/en-us/library/930b76w0(VS.71).aspx) op de VM bijwerken. .NET heeft een mechanisme het uitvoeren van code te beveiligen. Dit heeft veel weg van de manier hoe Internet Explorer werkt met security zones. Het uitvoeren van .NET code van een fileshare heeft te maken met andere policies als het uitvoeren van code op de lokale machine. Met remote debugging zal de debugger de code starten vanaf de locatie die aangegeven staat in de projecteigenschappen. Je zult zo zien dat dat een fileshare op de VM is, namelijk de share die we in een eerder stadium hebben aangemaakt voor de VS build bestanden. Deze share valt in een andere security zone, waardoor .NET een SecurityException zal genereren als er code gestart wordt die een hoger trustlevel vereist (wat met sharepoint assemblies vaak zo is) dan de zone waarvandaan het gestart wordt heeft toegewezen gekregen.

Een voorbeeld daarvan is:

System.Security.SecurityException was unhandled

Message: Request for the permission of type 'Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' failed.

Om dit te verhelpen moet je de caspolicy aanpassen, zodat jouw locatie wel het juiste trustlevel heeft. Dit doe je door caspol.exe te gebruiken. Deze tool is te vinden in de directory van het .NET framework 2.0 (%Windir%\Microsoft.NET\Framework64\v2.0.50727 bijv.)
Let op… Je gaat op de VM dus een share trusten van de VM zelf.

Het commando wat je op de VM uit moet voeren is als volgt:

CasPol.exe -m -ag 1. -url "\\<vm>\<visual studio debugshare>\*" FullTrust8

In mijn geval was dat:

CasPol.exe -m -ag 1. -url "\\192.168.0.100\Visual Studio\*" FullTrust8

Nu kun je jouw eerste applicatie gaan debuggen!! J

Maak eerst een project aan voor bijvoorbeeld een console application. Als je dit project hebt aangemaakt, vraag je de properties van het project op in de solution explorer. Stel vervolgens in de Build sectie in dat je de build output wilt wegschrijven naar de share waarvoor je zojuist de CAS policy hebt gewijzigd:

Stel vervolgens in de Debug sectie de remote debugger in. De remote debugger registreert zich als pipe server. Normaal gesproken, als je hem als windows applicatie opstart, wordt de server gestart met de qualifier <username>/<domain>. Ik verwachte hetzelfde gedrag te zien met het starten als Windows service. Je zou de debugger moeten kunnen benaderen onder <username>/<domain>@<server>. Echter met de remote debugger als Windows Service, werkt het echter niet. Een snelle kijk in de named pipes lijst via Sysinternals pipelist liet mij gelukkig zien hoe deze dan wel geregistreerd stond (Gek genoeg niet in de utilities index, maar de functionaliteit zal wel overgenomen zijn door een andere tool. Ik weet alleen niet welke. Pipelist is iig te vinden op http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx ):

De debugger stel je vervolgens in de Debug sectie in de project properties in als <domain>\<user>@<servernaam> (of svc=msvsmon90@<servernaam> als je als Windows Service draait).

Vervolgens moet je uiteraard als je sharepoint code wilt gaan kloppen de juiste References leggen. Dus ga naar References > Add reference in de solution explorer en kies voor Browse tab. Browse naar de Drive Mapping die je in een eerder stadium had aangemaakt voor de ISAPI folder op de VM. Hier kan je vervolgens de binaries kiezen die de juiste namespaces bevatten. Voor WSS 3.0 kan je die vinden in het volgende overzicht: http://msdn.microsoft.com/en-us/library/ms453225.aspx
De meest gebruikte zijn te vinden in Microsoft.Sharepoint.dll:

Schrijf nu een stukje voorbeeldcode met een breakpoint en druk op F5… VOILA… remote development en debugging werkt! Zo bewijzen de volgende screens..

Een breakpoint in VS:

En de Output op de VM:

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…

Virtualisatie support voor Sharepoint Server en SQL server producten

mpriem — Sat, 08 Nov 2008 16:11:00 GMT

Gisteren ben ik terug gekomen van een 60+ uur durende critsit bij een klant in Oostenrijk, waar zij MOSS in single-server configuratie op VMWare Server (dus de gratis versie… In productie J ) draaien op 40+ locaties.

Gedurende deze critsit kwam ik, zoals vele malen eerder, in de discussie terecht over het support van Microsoft op VMWare producten. Dit is de aanleiding dat ik het nu luid en duidelijk probeer neer te zetten in deze post.

Microsoft heeft beperkte support op niet-microsoft hardware virtualisatie producten voor onze Windows Server besturingssystemen. Dit houdt in dat wij FULL support leveren op onze eigen producten en alle producten die onder het Server Virtualization Validation Program (SVVP) (http://go.microsoft.com/fwlink/?LinkId=125649&clcid=0x409).

Op dit moment zijn dat:

Cisco WAAS Virtual Blades 4.1.1
Citrix XenServer 5 Embedded Edition
SUSE Linux Enterprise Server 10 SP2
VMware ESX 3.5 Update 2
XenServer 5

Naast het FULL support leveren wij BEST EFFORT support voor PREMIER klanten voor producten die niet onder het SVVP vallen. Let wel, dit is dus best effort, en alleen voor klanten met een premier contract, en alleen voor Windows Server besturingssystemen.

http://support.microsoft.com/kb/897615

Voor onze Server applicaties gelden aparte regels. Elk product team kan zelf bepalen wat deze regels inhouden.

Voor Sharepoint en voor SQL server zijn deze als volgt

http://support.microsoft.com/kb/909840

http://support.microsoft.com/KB/956893

Uiteindelijk bleek het probleem dus ook mede veroorzaakt te worden doordat SQL gevirtualiseerd was en de VM problemen had met de hardware klok en 461 identieke items aanmaakte in de database wanneer er een workflow gestart werd.

Search results worden niet juist weergegeven door limiet op ACL grootte

mpriem — Wed, 22 Oct 2008 21:48:00 GMT

Onlangs ben ik voor de tweede keer een probleem tegen gekomen bij een klant waar de resultaten van Sharepoint Enterprise Search niet juist worden weergegeven door een limitatie van de buffer van de WIN32 API InitializeAcl functie, welke gebruikt wordt door de indexer wanneer deze de wijzingen bepaald voor de index.
Deze buffer is 64KB groot, wat inhoudt dat de ACL's op objecten in sharepoint niet meer entries mogen bevatten dan in de buffer opgeslagen kan worden.

Hoeveel entries zijn dat dan??? … Nou dat hangt er bijvoorbeeld vanaf hoeveel groepen een userobject lid van is, en wat het SIDhistory property op zijn/haar AD object voor waardes bevat. Daarnaast zijn er nog enkele andere eigenschappen van een security object wat de grootte van een enkele ACE bepaald.
Om het makkelijk te maken zou ik zeggen dat +-1000 entries teveel is.

Het maakt hier niets uit of je de gebruikers los hebt toegekent of eerst lid hebt gemaakt van een Sharepoint Group. De enige manier om te zorgen dat de indexer niet tegen het limiet aanloopt, is de gebruikers te organiseren in AD Groups en deze in de ACLs op te nemen.

Dit probleem geldt voor zowel Office Sharepoint Server 2007 als Sharepoint Portal Server 2003

De foutcode die de indexer geeft bij het crawlen van een item is PRTH_E_ACL_TOO_BIG (0x80041211L)

....