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

3 April organiseren Microsoft en Quest een gratis Best Practices Seminar op het Microsoft kantoor. De agenda is als volgt:

Join international and local SharePoint experts in Amsterdam and learn how to master your SharePoint environment. Sponsored by Quest Software and Microsoft.

Date: Friday, April 3rd, 2009
Time: 10.30 - 16.30 (Registration begins at 10.00)
Location: Auditorium, Microsoft Netherlands (map) 
Cost: Free (Lunch is included)

Agenda:

10:00 Registration

10:30 Welcome and Introductions

10:40 SharePoint Successful Deployments in 10 Steps 
Joel Oleson, Quest Software

11:30 SharePoint, the Social Computing Platform (Business Strategy and Adoption)
Daniel McPherson, zevenseas

12:30 Lunch

1:30  SharePoint Logical and Physical Infrastructure Fundamentals  
Joel Oleson, Quest Software & Robin Meure, zevenseas

2:30 Backup Demystified
Mike Watson, Quest Software

3:30 Experts Panel and Q&A

4:30 Wrap Up

Meer informatie over inschrijvingen is te vinden op

Join international and local SharePoint experts in Amsterdam and learn how to master your SharePoint environment. Sponsored by Quest Software and Microsoft.

Date: Friday, April 3rd, 2009
Time: 10.30 - 16.30 (Registration begins at 10.00)
Location: Auditorium, Microsoft Netherlands (map) 
Cost: Free (Lunch is included)

Agenda:

10:00 Registration

10:30 Welcome and Introductions

10:40 SharePoint Successful Deployments in 10 Steps 
Joel Oleson, Quest Software

11:30 SharePoint, the Social Computing Platform (Business Strategy and Adoption)
Daniel McPherson, zevenseas

12:30 Lunch

1:30  SharePoint Logical and Physical Infrastructure Fundamentals  
Joel Oleson, Quest Software & Robin Meure, zevenseas

2:30 Backup Demystified
Mike Watson, Quest Software

3:30 Experts Panel and Q&A

4:30 Wrap Up

Join international and local SharePoint experts in Amsterdam and learn how to master your SharePoint environment. Sponsored by Quest Software and Microsoft.

Date: Friday, April 3rd, 2009
Time: 10.30 - 16.30 (Registration begins at 10.00)
Location: Auditorium, Microsoft Netherlands (map) 
Cost: Free (Lunch is included)

Agenda:

10:00 Registration

10:30 Welcome and Introductions

10:40 SharePoint Successful Deployments in 10 Steps 
Joel Oleson, Quest Software

11:30 SharePoint, the Social Computing Platform (Business Strategy and Adoption)
Daniel McPherson, zevenseas

12:30 Lunch

1:30  SharePoint Logical and Physical Infrastructure Fundamentals  
Joel Oleson, Quest Software & Robin Meure, zevenseas

2:30 Backup Demystified
Mike Watson, Quest Software

3:30 Experts Panel and Q&A

4:30 Wrap Up

Voor meer informatie zie: http://blogs.microsoft.nl/blogs/mhoekstra/archive/2009/03/06/sharepoint-best-practices-seminar-3-april.aspx 

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…

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:

1. Opstellen van een Testplan (5 dagen)
   1. Bepalen testscenarios
   2. Bepalen verwachte resultaten
   3. Planning en resources vaststellen
   4. Uitwerken testplan
2. Configureren testomgeving en test rig (5 dagen)
   1. Installeren testcontroller en agents
   2. Configureren testomgeving (sharepoint configuratie, aanmaken test accounts, dns etc)
3. 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
4. Ontwikkelen webtests en load tests (10 dagen)
   1. Maken van de test scenario's
   2. Databindings maken voor webtests
   3. Testen van webtests
5. 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.
6. Analyse van testresultaten (2 – 5 dagen)
7. 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:

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:

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

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.

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:

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

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!

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:

Een groot gedeelte van de supportcalls bij premier support heeft te maken met crashes, memory leaks en andere van die voor velen ongrijpbare problemen. In veel gevallen is de oorzaak echter redelijk simpel te achterhalen, en zou je een support call en veel tijd en ergernis kunnen besparen. Het probleem is dat velen niet weten dat je geen die-hard debugger hoeft te zijn om een memory dump te analyseren (ok. Ok. Eerste stap daartoe J.), of een memory leak te traceren.

Je hebt alleen de juiste tools nodig een klein duwtje in de goede richting. Die ga ik je vandaag geven J

Tools

Er zijn een aantal tools die in mijn optiek niet mogen ontbreken in de gereedschapskist van een admin. Dat zijn:

• Windows debugging tools: http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
• DebugDiag 1.1: http://www.microsoft.com/downloadS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

De installatie spreekt voor zich, dus daar ga ik jullie niet mee vervelen, echter voor de debugger die we gaan gebruiken (WinDBG) is het aan te raden een symbolserver te configureren (http://www.microsoft.com/whdc/DevTools/Debugging/debugstart.mspx) . In principe is dat voor deze eerste stapjes in de wereld van debugging nog niet nodig, maar ik zou het niet laten, daar het je toch net even wat meer inzicht geeft in wat er precies gebeurd onder de motorkap. Ik prefereer de Environmental Variable, aangezien deze door veel debugtools automatisch wordt opgepakt.

Introductie

In deze post ga ik drie type scenario's behandelen. Dat zijn:

• Eerste analyse van een kerneldump, naar aanleiding van een crash/BSOD (Blue-Screen-Of-Death).
• Troubleshooten van usermode crashes.
• Troubleshooten van memorydumps.

Voordat we daaraan beginnen zal ik toch een klein stukje theorie moeten behandelen, om een en ander duidelijk te maken.
Moderne CPU architecturen hebben verschillende modi waarin zij opereren. Deze noemen we ook wel Rings (er zijn nog tig andere benamingen). Deze modi stellen een ontwikkelaar in staat bepaalde functionaliteit van de CPU architectuur niet toe te staan voor de code die op dat moment wordt uitgevoerd. Denk hierbij aan toegang tot bepaalde CPU registers of onderdelen van het geheugen. Dit om de stabiliteit en veiligheid van het systeem te waarborgen. In Windows NT besturingssystemen (Alles behalve 3.*, 9* en ME) maken we gebruik van 2 van deze modi, namelijk de modus waarin alles is toegestaan, welke wij 'Kernelmode' noemen (Ring 0) en een modus waarin toegang tot hardwareresources beperkt worden, welke wij 'Usermode' noemen (Ring 3; in x86 en x64 architecturen zijn het er 3 (Ring 1,2,3), maar Windows gebruikt alleen de meest beperkte). De structuur van Windows zorgt ervoor dat eigenlijk alleen code die hoort bij het operating system in Kernelmode mag draaien. Er zijn wat uitzonderingen, waarvan drivers de meest belangrijke zijn.
Code wat in Kernelmode draait heeft dus onbeperkt toegang tot systeemresources, en kan dus ook geheugen structuren veranderen van andere processen, wat kan leiden tot datacorruptie, dataloss en een instabiel systeem. Windows beschermt zich hiertegen door in dergelijke gevallen op de noodknop te drukken en het systeem te stoppen of bugchecken met een BSOD. Wij noemen dit een crash, maar het is eigenlijk Windows die je redt van nog grotere problemen. Windows zal dan op basis van de instellingen wel of niet een dump maken van het kernelgeheugen. Dit heb je niet voor usermode processen.
Code wat in Usermode draait heeft dus beperkte toegang tot systeemresources. Zo heeft het alleen toegang tot geheugenbereik dat het proces toegewezen heeft gekregen en dient het toegang tot hardware aan te vragen bij het operating system. Qua performance lever je hierdoor wel wat in, maar bijkomend voordeel is dat het ene proces niet zo makkelijk een ander proces om zeep kan helpen, laat staan een BSOD kan veroorzaken, en je een verhoogde mate van veiligheid hebt, doordat geheugenstructuren van het ene proces niet uit te lezen zijn door het andere proces.

Waarom is deze informatie nu belangrijk?

Voor deze post om twee redenen:
Enerzijds is het belangrijk om te weten dat een BSOD dus in bijna alle gevallen veroorzaakt wordt door OF een bug in het operating system, OF een driver.
9 van de 10 keer zal het gaan om een driver.
Anderzijds is het belangrijk om te begrijpen dat het analyseren van een usermode crash anders is dan het analyseren van een kernelmode crash. Bij een kernmode crash heb je vaak de beschikking over een volledige dump van het geheugen. Bij usermode crashes, moet je memorydumps zelf generen en verzamelen.

Blue Screen of Death – BSOD

Wanneer een systeem geplaagd wordt door BSODs is de eerste plaats waar je gaat kijken de memorydump. Ik ben van mening dat elk systeem geconfigureerd moet zijn om een volledige dump te maken, daar in de volledige dump de meeste informatie staat. Je kan met een MiniDump soms ook wel af, maar meestal zal een support engineer vragen om de volledige dump. Ik neem aan dat je jouw systeem niet nogmaals wilt laten crashen met alle gevolgen van dien voor de data en uiteindelijk de business. Opties voor het maken van een memorydump kan je vinden op http://support.microsoft.com/kb/254649/en-us

Verder adviseer ik mijn klanten altijd, dat als er een memorydump heeft plaatsgevonden, deze veilig te stellen. Een volgende dump overschrijft deze namelijk. Meerdere dumps is handig daar de oorzaak van de crash niet altijd meteen duidelijk is. Helaas is dit vaak het geval. Het kan namelijk zijn dat de veroorzaker van de crash allang uit het geheugen is verdwenen, voordat het systeem struikelt over het probleem dat deze code veroorzaakt heeft. Door meerdere dumps te analyseren kan je soms correlaties trekken, en zo tot een conclusie komen.

Goed… We hebben een crash gehad en we hebben een memory dump. What's next??

We starten WinDBG en openen de memory dump. Deze dump is standaard te vinden op %SystemRoot%\Memory.dmp. Je kan uiteraard de memory dump naar een andere machine kopiëren en hem daar analyseren:

Nu je de memorydump geopend hebt, zal WinDBG de dump snel analyseren. Dit levert al vaak meteen waardevolle informatie op, zoals je kan zien op de analyse van 1 van mijn recente dumps:

Probably caused by : rismcx64.sys … Schijnbaar geeft WinDBG rismcx64.sys de schuld. Een korte blik in mijn drivers, gaf aan dat het om een smartcard driver ging uit 2006. Even een bezoekje aan de Windows Update en de vendor website en voila.. Nieuwe drivers. Sindsdien heb ik die crash nooit meer gehad.

Nu kan je WinDBG een verbose output laten zien van deze analyse, waar je vaak ook wel wat aan hebt. Dit doe je door !analyze –v uit te voeren. De output laat dan bijvoorbeeld ook de stacktrace zien, die je een idee kan geven, van wat het systeem op dat moment aan het doen was:

Je leest een stacktrace altijd van onder naar boven. In mijn dump was windows duidelijk bezig met het afhandelen van een IO request richting mijn smartcard device, te zien aan termen als IopXxxControlFile, NTDeviceIoControlFile en andere IO routines. Verder zie je verwijzingen naar Wdf modules wat staat voor Windows Driver Foundation. Deze informatie kan ik zien doordat ik WinDBG geconfigureerd heb om de public symbols van de Microsoft SymbolServer te halen. Zonder symbols ziet de output er anders uit.

Een hele hoop van de functienamen zijn weggevallen. Hierdoor is het lastig in 1 oogopslag te bepalen of de modules behoren tot het besturingssysteem of niet. Ik kijk altijd even naar de stacktrace. Je kan bijvoorbeeld zien of er nog andere 3rd party modules zijn die rond die tijd acties aan het uitvoeren zijn geweest. Deze kan je dan vervolgens eveneens aan een grondig onderzoek onderwerpen.

Zo zie je… In een aantal simpele stappen kan je al snel wat zaken uitzoeken en proberen voordat je een case aanmeldt om een BSOD te laten onderzoeken.

User mode crash

Voor usermode crashes heb je standaard geen memory dumps. Echter je kan een debugger attachen aan een proces en een memory dump laten generen op het moment dat deze klapt. In de debugging tools kan dat op verschillende manieren, maar ik gebruik eigenlijk altijd DebugDiag, wat een schil rondom de debuggers uit de debugging tools is.

In mijn geval crashed een application pool regelmatig. Ik start dus debugdiag en kies voor de 'Crash' optie (een Hang is niet hetzelfde als een crash):

Vervolgens kan ik twee kanten op. Ik kan kiezen voor een proces, en selecteer gewoon het juiste w3wp.exe proces, of ik kies voor Application Pool. Dit is uiteraard eenvoudiger dus doe ik dat:

Vervolgens kies ik de application pool, en krijg ik de mogelijkheid om advanced opties mee te geven, zoals op welke Exceptions debugdiag moet reageren. Ik selecteer gewoon de standaard opties, daar dat in de meeste gevallen voldoende is.

Uiteindelijk kies ik Next > Next > Activate Rule.

Als dan vervolgens het proces klapt, maakt DebugDiag een memory dump, welke geanalyseerd kan worden. Na een paar keer mijn webapplicatie te hebben geprobeerd te starten, had ik 3 memory dumps:

Ik kan dan vervolgens kiezen om de data te laten analyseren door Analyze Data te selecteren. Na een tijdje door de dumps te hebben gewroet, laat DebugDiag een rapport zien met de bevindingen. In de meeste gevallen kan je dat rapport gebruiken om verder onderzoek te plegen. In mijn geval wist ik wat het probleem was, daar ik zelf een kapotte ISAPI filter had gebakken om demo's van DebugDiag te geven. Het rapport laat daarom ook netjes zien dat mijn UpCaseStackOverflow.dll filter het probleem heeft veroorzaakt.

Memory Leaks

Memory Leaks worden vaak gezien als zeer lastige problemen om te analyseren, maar met de juiste tools valt dat best mee. Ook hier gebruik ik meestal DebugDiag voor. Je start DebugDiag en kiest voor Memory and Handle Leak. Vervolgens kies je het proces waaraan je de debugger wilt koppelen. Het valt hier op dat we nu niet de keuze hebben om een Application pool te kiezen. Als je nu meerdere application pools hebt, en deze ook nog eens onder hetzelfde application pool account draait, lijkt het lastig deze processen te onderscheiden. Gelukkig is er een redelijk makkelijke manier om erachter te komen om welke application pool het gaat. Je scrolled helemaal naar rechts in het DebugDiag window en controlleert de commandline kolom. Dit bevat de naam van de application pool:

Je dient vervolgens aan te geven wanneer er precies een Memory dump gemaakt moet worden. Dit kan na een bepaalde tijd, maar vaak is het handiger een maximum aantal MB's aan te geven. Dit doe je door te kiezen voor Configure in de Userdump generation sectie:

Ik kies hier meestal voor Virtual Bytes, omdat Private Bytes daar een subset van is. Virtual Bytes is namelijk het aantal bytes dat het proces gealloceerd heeft binnen het Virtual Address Space van het proces. Private Bytes is het geheugen dat daadwerkelijk in gebruik is (commited). Ook hou je zo rekening met een een ander memory management fenomeen, namelijk page sharing. Wanneer een proces namelijk een module laadt met shareable data (code afhankelijk dus), die al geladen is door een ander proces, wordt deze niet nogmaals in het geheugen geladen, maar gedeeld door processen. Dit geheugen wordt gemapped naar het proces. De virtual bytes geven vervolgens aan dat het proces het aantal bytes voor die module gealloceerd heeft, maar fysiek is er geen extra geheugen gebruikt. Deze shareable bytes zie je dus ook niet terug in de Private Bytes.

Om te bepalen wanneer een memory dump te maken, zal je monitoring moeten inregelen. Dit kan door System Monitor (perfmon) te gebruiken en de Private Bytes en Virtual Bytes van het systeem en processen te monitoren.

Als laatste selecteer ik weer Next > Next > Activate Rule en kan het wachten beginnen.
Zodra er weer een memorydump is gemaakt, kies je wederom voor Analyze Data en Voila… een rapport.

Net als bij de Usermode Crash, was het in mijn geval wederom een zelf geschreven ISAPI filter, met ditmaal een memory leak. Het rapport laat ook netjes zien dat er een module UpCaseLeak.dll is in mijn w3wp.exe proces die aardig wat geheugen heeft gealloceerd. In dit geval heeft DebugDiag te kort gelopen om echt een harde analyse te doen, maar je snapt waar dit heengaat.

Zo zie je… Debugging is niet alleen voor code junkies, maar iedereen kan een aantal basis stappen zetten, die in veel gevallen al tot de oorzaak van het probleem kunnen leiden!

Zojuist is Internet Explorer 8 vrijgegeven. Hij is te vinden op: http://www.microsoft.com/ie8

Met de komst van Internet Explorer 8, komen een aantal nieuwe features zoals:

• Search suggestions, waarbij je search provider geraadpleegd wordt en je terwijl je typt al wat zoekresultaten aangeboden krijgt.
• Accelerators die het mogelijk maken met een simpele druk op de knop, content op internet pagina's te mailen, bloggen, of op te zoeken in Encarta. Deze accelerators zijn ook nog eens uit te breiden, waardoor ze voor allerlei zaken ingezet kunnen worden.
• InPrivate browsing, waarbij de browser geen tijdelijke rommel achterlaat op je systeem en alle plugins en menubars uitgeschakeld zijn.
• Web Slices stelt een gebruiker in staat zich op de hoogte te laten houden van wijzigingen in delen van een webpagina, denk aan bijvoorbeeld de koersgegevens. Het lijkt een beetje op RSS, maar geldt voor delen van een pagina.

Nu maken die nieuwe features veel mensen weinig uit (waaronder ik). Maar…. Internet Explorer 8 zit niet alleen boordevol features. IE8 voldoet als geen enkele andere IE browser aan de meeste bekende web standaarden, en hij is ook nog eens razendsnel, zo bewijst een onafhankelijk onderzoek uitgevoerd door comScore:

De volledige resultaten zijn hier te vinden: http://blogs.msdn.com/usisvde/archive/2009/03/13/ie-8-performance.aspx

Update rollup 7 voor Exchange 2007 SP1 is vrijgegeven. De release notes zijn te vinden op http://support.microsoft.com/kb/960384
Het dowload package is te vinden op http://www.microsoft.com/downloads/details.aspx?FamilyID=2074fefd-fa1a-4c3e-bf72-94585e454150

Voor het laatste ontwikkelingen betreffende Exchange updates is er een Updates forum. Neem een kijkje om te zien of er nog known issues zijn: http://social.technet.microsoft.com/Forums/en-US/exchangesoftwareupdate/threads/

PowerShell MVP en PowerShell blogger Keith Hill heeft een verzameling van zijn artikelen samengevoegd tot een gratis Ebook. Deze is te vinden op: http://keithhill.spaces.live.com/blog/cns!5A8D2641E0963A97!6930.entry

Veel plezier ermee!

MergeContentDB wordt door veel beheerders gebruikt in hun Capacity planning processen om site collecties te verplaatsen tussen databases om zo de databases onder de aanbevolen max van 100GB te houden, of om een database te ontlasten van een zwaarbelaste site. Nu blijkt echter dat onder sommige omstandingheden zowel de Source als Target contentdatabase corrupt kunnen raken door een probleem in de code. Er wordt druk gewerkt aan een fix voor dit probleem. Neem vooralsnog de juiste maatregelen door in ieder geval een backup te maken voordat je MergeContentDB gebruikt, en anders andere mogelijkheden benut om site collecties te verplaatsten.

Meer informatie: http://blogs.msdn.com/sharepoint/archive/2009/03/24/possible-issue-with-mergecontentdb-stsadm-operation.aspx

Zojuist heb ik een IPv6 101 post gedaan op de PFE Team Blog.

Check it out!!

Om Virtual Server 2005 R2 op Windows 7 te draaien, doorloop je de volgende stappen:

1. Installatie IIS7
2. Installeer Virtual Server 2005
3. Start Virtual Server als administator

Om IIS7 te installeren kies je voor 'Turn Windows Features On of Off' in de Programs and Features sectie van het control panel. Vervolgens kies je voor Internet Information Services met een aantal extra opties:

* Dit zijn extra opties. Laat de standaard opties geselecteerd staan.

Installeer vervolgens Windows Server 2005 R2. De installatie spreekt voor zich.

Nadat Virtual Server is geïnstalleerd, dien je Virtual Server te starten vanuit een elevated IE. De link is http://localhost/VirtualServer/VSWebApp.exe?view=1
Het moet vanuit een elevated IE om problemen met de COM servers te voorkomen.

Enjoy!