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

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

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…

February Uber Packages zijn uit

mpriem — Tue, 10 Mar 2009 11:54:00 GMT

Zoals onderhand wel bekend is, is het patchbeleid veranderd voor Sharepoint patches. Er wordt vanaf December om de 2 maanden een rollup pack uitgebracht en eventuele tussentijdse critical (security) updates. Ook zijn de localized versies van de patches er niet meer. Alle localized MSPs en global MSPs zitten nu in 1 Uber package voor WSS en 1 package voor MOSS.

De februari releases zijn onlangs vrijgegeven en kunnen gevonden worden op:

February Cumulative Update Uber Package for Windows SharePoint Services 3.0 (Version: 12.0.6341.5000)

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=961755

February Cumulative Update Uber Package for Microsoft Office SharePoint Server 2007 (Version: 12.0.6341.5002)

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=961756

Office Server 2007 en Windows Server 2008 Advanced Firewall

mpriem — Fri, 12 Dec 2008 21:06:27 GMT

Ook voor Office Server 2007 heb ik maar even een lijstje met porten opgesteld om dit in samenwerking met Windows Server 2008 advance firewall te gebruiken.

Direct Hosted SMB	445 TCP/UDP
Office Web Services	56737, 56738 (SSL) TCP
RPC endpoint mapper	135 TCP
Dynamic Ports SSO	Standaard = 49152 - 65535 TCP/UDP
Non-default Web Sites	Alle sites die niet op 443 en 80 draaien hebben een firewall rule nodig.

MOSS heeft SMB nodig om de index te propageren naar de Query servers, search query results op te halen van de Query servers, en om de crawl data te versturen naar de Index Server. Verder gebruikt Sharepoint Web Services voor administratie van de farm services en dergelijke. Ook gebruikt MOSS, wanneer SSO geconfigureerd is gebruik de SSO service een dynamische port, geregisteerd bij de RPC endpoint mapper.
Tenslotte dien je voor elke website die niet op standaard HTTP porten draait een gaatje te prikken.

Gebruik de MMC snapin of console om de rules aan te maken, waarbij het aanbevolen is gebruik te maken van de meer geadvanceerde features van de advanced firewall. Je kan namelijk filteren op RPC en RPC-EPMAP porten, en deze zelfs koppelen aan programma's of windows Services. Voor de SSO rules zou ik dus een rule aanmaken waarbij alleen de RPC service en de RPC-EPMAP port zijn toegestaan, en een rule waarbij alleen de Microsoft Single Sign-on service gekoppeld wordt aan een bij de endpoint mapper geregistreerde port.
Daarnaast kan je voor het System process (waar http.sys leeft) een rule maken die de toegang tot de non-default web applicaties en tot de Office Web Services toestaat.
Tenslotte is er al een standaard rule voor SMB, genaamd "File and Printer sharing (SMB-In)", welke geactiveerd dient te worden.

De volgende voorbeeld commando's (wederom voor het domain profiel, zonder profile=domain gelden de rules voor elk firewall profiel) kunnen gebruikt worden via admin console:

netsh advfirewall firewall add rule name="SSO Service dynamic RPC" service=entsso action=allow protocol=TCP dir=in localport=rpc profile=domain8

netsh advfirewall firewall add rule name="RPC endpoint mapper" service=rpcss action=allow protocol=TCP dir=in localport=rpc-epmap profile=domain8

netsh advfirewall firewall add rule name="Sharepoint intranet portal" program=System action=allow protocol=TCP dir=in localport=81 profile=domain8

netsh advfirewall firewall add rule name="Sharepoint web services" program=System action=allow protocol=TCP dir=in localport=56737,56738 profile=domain8

netsh advfirewall firewall set rule name="File and Printer sharing (SMB-In)" new enable=yes profile=domain8

Meer over NetSh advfirewall: http://support.microsoft.com/kb/947709

Meer informatie over MOSS hardening: http://technet.microsoft.com/en-us/library/cc262849.aspx

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

Microsoft Security Bulletin MS08-077 - Important

mpriem — Wed, 10 Dec 2008 21:54:00 GMT

***UPDATE*** Servers met October of December rollup hebben de fix niet nodig.

Gisteren is het nieuwe security bulletin verstuurd. Deze maal bevat het een fix voor een Sharepoint lek die uitgebuit kan worden door een lek in een van de administatieve pagina's binnen sharepoint sites.

Het bulletin is hier te vinden: http://www.microsoft.com/technet/security/Bulletin/MS08-077.mspx
De fix details hier: http://support.microsoft.com/kb/956716
En natuurlijk de fix zelf: http://www.microsoft.com/downloads/details.aspx?familyid=a7fda284-273c-42ab-8188-433beaacca86&displaylang=en

Een workarround voor dit lek is de volgende:

Block malicious HTTP requests using a firewall

Configure your firewall, such as Microsoft ISA Server, to block all HTTP requests to your SharePoint site that contain "mode=ssp" in the URL, but do not contain "/ssp/admin/_layouts" in the URL.

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….

Oktober rollup is vrijgegeven

mpriem — Fri, 31 Oct 2008 17:34:00 GMT

Eergisteren is de oktober rollup vrijgegeven. Daarnaast is er een losse fix voor problemen met workflow vrijgegeven.
Je kunt de fixes vinden op:

WSS 3.0 Global
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957691&kbln=en-us

MOSS 2007 Global
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957693&kbln=en-us

MOSS 2007 Taal specifiek
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=958567&kbln=en-us

MOSS 2007 Workflow Hotfix
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=958569&kbln=en-us

....

Timer Job Cache

mpriem — Wed, 22 Oct 2008 22:03:00 GMT

Als je problemen ondervindt met timer jobs die niet willen draaien of vastlopen, of rare errors krijgt tijdens het draaien van PSCONFIG, kan het verstandig zijn de configuratie cache van de timer service eens te flushen. Soms is deze data corrupt en kan een rebuild de oplossing zijn van de rare problemen. Om dit te doen doe je het volgende:

Stop de Windows SharePoint Services Timer service op alle sharepoint servers in de farm (NET STOP SPTimerV3).

Vervolgens voor je op de volgende servers in exact deze volgorde de onderstaande stappen uit: 1. Index server, 2.Query server, 3. Web front end server, 4. Applicatie server
Browse naar <n>:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\<GUID>
Verwijder alle XML bestanden in deze directory
Edit de cache.ini en verander het nummer naar 1.
Start de Windows SharePoint Services Timer service op de server (NET START SPTimerV3)
Wacht tot je weer XML bestanden ziet verschijnen voordat je naar de volgende server gaat

Maak je geen zorgen, je maakt niets stuk J

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)

....