~ Just do I(nformation)T(echnology) ~

Office 2010 Server en Client launch op 12 Mei

Mark Priem — Sat, 06 Mar 2010 08:00:00 GMT

Eerder dan verwacht is de aankondiging gekomen dat de Office 2010 Server en Client releases in April RTM worden en publiekelijk beschikbaar komen op 12 Mei !!!
Geweldig nieuws natuurlijk. Eindelijk zullen we Sharepoint 2010 en Office 2010 met support kunnen uitrollen bij onze klanten.

De aankondiging is te vinden op http://blogs.msdn.com/sharepoint/archive/2010/03/05/sharepoint-2010-office-2010-launch.aspx

Registeren voor het online Launch event met Steven Elop kan op http://sharepoint.microsoft.com/businessproductivity/proof/pages/2010-launch-events.aspx#fbid=bMY49OOdlOI

Office Web Apps installatie

Mark Priem — Thu, 25 Feb 2010 15:46:14 GMT

Office Web Apps is een add-on voor Sharepoint Foundation / Server, die het mogelijk maakt Word, PowerPoint, Excel en OneNote te delen, te bewerken en uiteraard te bekijken. Deze blog post gaat in op de installatie van Office Web Apps.

Wat hebben we allemaal nodig?

Om te beginnen heb je een Sharepoint 2010 omgeving nodig. Ik ga niet vertellen hoe deze te installeren. Een eerder blog artikel kan je hierbij helpen.
Office Web Apps, waarvan de beta hier te downloaden is.

De procedure om Office Web Apps (OWA) te installeren is als volgt:

Install de bits en draaien van PSConfig
Activeren en gebruik van de functionaliteit

Installatie van de bits

Na de download start je de installatie van OWA. Dit is redelijk voorzelfspreken:

Geef een productkey op:
(Voor de beta staat deze in de handleiding op dezelfde download site als waar je de bits vandaan hebt.)
Accepteer de EULA.
Kies het installatiepad.
Even geduld…
Kies er voor om PSConfig te laten draaien.
Wanneer PSConfig gelopen heeft, dienen we de boel te activeren. Wederom even geduld om PSConfig uit te laten ratelen. Houdt er rekening mee dat services gestopt worden.

Wat is er gebeurd?

Na de installatie van OfficeWeb apps zijn er een aantal zaken gewijzigd. Wat hebben we nu precies gedaan?
Tijdens de initiële installatie van de bits zijn er verschillende zaken toegevoegd. Voornaamste wijziginen zijn de nieuwe service applications: de Word Viewing Service en de Powerpoint Service Application.
Excel Services Application bestaat uiteraard al in Sharepoint Server, maar wordt toegevoegd, mocht je Sharepoint Foundation draaien.

Verder zijn er een hele zwik nieuwe feature(staplers) toegevoegd. De featurestaplers zorgen ervoor dat de OWA features, bij het aanmaken van nieuwe sitecollections van nagenoeg elk template, geactiveerd worden.
Wees er wel bewust van dat de features voor bestaande sites wel nog geactiveerd moeten worden.
Dit zul je ook meteen na de installatie moeten uitvoeren om te voorkomen dat gebruikers bij het openen van browser-enabled documenttypes een foutmelding krijgen.

Functionaliteit activeren

Nu de installatie voltooit is, kunnen we de functionaliteit gaan activeren.

Om te beginnen starten we de services. Dit bereiken we door in Central Administration te kiezen voor System Settings > Services on Server.
Hier activeren we de Excel Calculation Services, Powerpoint Service en Word Viewing Service.
Vervolgens maken we een nieuwe Service Application in Central Administration onder Application Management > Manage Service Applications voor Excel Services Application, Powerpoint Service Application en Word Viewing Service.
Als voorbeeld een screendump van een nieuwe Excel Services Application. Het ziet er nagenoeg hetzelfde uit voor de overige services:
Tenslotte moet er voor alle bestaande sites met document libraries de Office Web Apps feature geactiveerd worden, om de eerder genoemde foutmelding te vermijden.
Dit doe je uiteraard onder Site Actions > Site Collection Features.

Dit is in principe alles om Office Web Apps werkend te krijgen. Wanneer je de features geactiveerd hebt op de site collecties zal je zien dat de contextmenu's voor de document libraries uitgebreid zijn met wat extra opties zoals View in Browser en Edit in Browser.
Deze context menu uitbreidingen redirecten je als gebruiker naar OWA webpages in de _Layouts folder met de itemURL als parameter (Dit zijn Wordviewer.aspx, Xlsviewer.aspx en Powerpoint.aspx).
De codebehind zorgt vervolgens voor de logica van het verwerken en tonen van de documenten. Via de mechanismen die beschikbaar zijn in het Service Application Framework zal er een vorm van load balancing plaats vinden tussen de servers in de farm die een instance van de WCF service draaien (die we in de eerste stap na installatie hebben geactiveerd).

De controls stellen je nu zelfs in staat documenten te wijzigen. Het is natuurlijk niet zo uitgebreid als de fat client, maar je kunt best aardig uit de voeten.
Voor bijvoorbeeld de Word App, heb je de beschikking over lists, tabellen, spellingscontrole en de document styles.
Wat ik persoonlijk nog wel mis zijn de review controls, omdat ik denk dat dat juist een veelgebruikt scenario zou kunnen zijn voor het gebruik van OWA. Je upload een document en iemand reviewt deze.
Hij zou dan changetracking, comments en Accept/Reject changes willen gebruiken. Het is natuurlijk allemaal nog beta, maar ik ben bang dat we dat voor RTM niet gaan zien.

Al met al vind ik het een prima toevoeging en denk ik dat vooral de viewers zeer veel gebruik gaan worden. Zeker in combinatie met de Broadcast Slideshow Site, waar het mogelijk wordt via Powerpoint een slidedeck te broadcasten, waarna anderen via hun webbrowser mee kunnen kijken met de slidedeck. Kan erg handig zijn gedurende een conference call. Wie heeft er tegenwoordig nu geen internet. Het is zelfs te gebruiken via mobile devices.

Voor een complete handleiding zie: http://download.microsoft.com/download/3/1/6/31679466-6DE6-42FC-82EC-8597F5072D98/broadcasting_whitepaper.doc

Als afsluiting nog een screendump van al dat mooie silverlight eyecandy J

SSP Profile Synchronisatie in Sharepoint

Mark Priem — Mon, 11 Jan 2010 13:53:00 GMT

Meer dan eens lopen klanten van ons tegen problemen aan met profielinformatie die niet up to date is binnen de farm of delen van de farm. Ook zitten beheerders met hun handen in het haar omdat ze maar niet begrijpen waar alle events gerelateerd aan profile synchronisatie vandaan komen, wat soms tot knalrode eventlogs leidt. Eerlijk gezegd snapte ik tot zojuist ook niet helemaal hoe de vork in de steel zat, vandaar ook deze post. Hierin ga ik redelijk indepth uit de doeken doen hoe profile synchronisatie precies werkt en hoe veel voorkomende problemen op te lossen en te voorkomen.

Huh.. Hoe? Wat?

Om te beginnen wat is profile synchronisatie precies?

In het kort: Profile synchronisatie zorgt voor het 'in sync' houden van MOSS profiel informatie op de afzonderlijke WSS profielen binnen een contentdatabase, en het 'in sync' houden van site membership informatie in de MOSS profielen.

Zoals velen van jullie weten, hebben we in Sharepoint profielen. Wat velen alleen niet weten is dat we twee afzonderlijke profielen hebben. We hebben namelijk profielen in Windows Sharepoint Services, maar ook in Sharepoint Server 2007 en dat zijn verschillende features. Om een consistente weergave te hebben van deze beiden profielen, moeten we dus synchroniseren.

WSS profielen

WSS profielen kan je vinden onder Welcome User > My Settings. De informatie hieruit wordt bijvoorbeeld gebruikt in People and Groups.

Een WSS profiel vind je op elke afzonderlijke site collectie. Elke site collectie heeft dus een ander WSS profiel voor een specifieke gebruiker. Onderstaand voorbeeld laat vergelijking zien tussen een site zien binnen een site collectie, waar ik net als gebruiker ben toegevoegd, en een site, waar ik al een tijdje lid van ben, en waar profile synchronisatie extra informatie heeft toegevoegd:

Ondanks dat deze site collecties in dezelfde content database zitten, gebruiken ze toch andere informatie. Elke site in de site collectie deelt een verborgen list, de User Information List, waarin profiel gegevens zijn opgeslagen. Je kunt deze informatie vinden als je browset naar http://urlwebapp/managedpath/sitecollectieroot/_catalogs/users, en wanneer je in de AllUserData table van een content database zoekt op tp_ContentType = 'Person':

AllUserData bevat alle informatie over items in alle lists binnen de alle sites in de content database. Zo zie je maar dat profiel informatie gewoon een item is in de verborgen User Information List.

MOSS Profielen en site memberships

MOSS profielen zijn de profielen die geïmporteerd worden vanuit een profielenbron. Dit is in de meeste gevallen Active Directory, maar dat kan ook een andere LDAP database zijn of zelfs een willekeurig systeem ontsloten via Business Data Catalog. De informatie die opgehaald wordt, wordt vervolgens weggeschreven in de profilestore, een verzameling tables in de SSP database (dbo.UserProfileFull en dbo.UserProfileValue bevatten het gros van de profielinformatie). Deze informatie wordt getoond, wanneer je een MySite bezoekt of wanneer je browset naar Shared Services Administration > User Profile and Properties > View User Profiles.

Een MOSS profiel bevat een publiek deel en een persoonlijk deel.

Als beheerder kan je aangeven welke properties getoond worden in het Details overzicht op het publieke deel van een MOSS Profile. Je kan als eindgebruiker bepaalde properties wijzigen. Welke dat zijn, is op te geven door de beheerder. Hierbij dient alleen rekening gehouden te worden dat, wanneer een property gemapped is aan een property in de profielenbron, deze overschreven worden bij de volgende import. Terugschrijven naar de profielenbron is in deze versie van Sharepoint nog niet mogelijk.

Een belangrijk onderdeel van een MOSS profiel zijn de site memberships. Deze zijn alleen zichtbaar voor jezelf en alle farm admins. Site memberships bevat een overzicht met sites waar je lid bent van een de Members sharepoint group. Andere groups zoals Visitors, Owners enz. komen niet voor in dit overzicht. Deze informatie wordt vervolgens gebruikt in het MOSS profiel om een overzicht te tonen, maar ook om het mogelijk te maken alle bestanden die je als gebruiker hebt geupload naar 1 van deze sites centraal terug te vinden. Erg handig dus!

Een andere handige functionaliteit is dat, waar je je ook bevindt in de structuur van je portal, je altijd snel naar 1 van je sites kan browsen door My Links > My Sharepoint Sites in de topbar.

Deze membershipinformatie is niet beschikbaar bij de initiële import van het profiel. Sterker nog, je kan natuurlijk allang member zijn van een site, zonder ook maar een MOSS profiel te hebben. Deze informatie moet dus ook gesynchroniseerd worden vanuit de afzonderlijke site collecties naar de profilestore. Membership informatie uit deze store, en ook informatie over My Colleagues en eigen toevoegingen op My Links, is terug te vinden met de volgende SQL query (Je weet dat het unsupported is om SQL queries te draaien tegen productiesystemen heh? J )

declare @RecordId int select @RecordId = RecordId

from dbo.UserProfile_Full

where NTName = 'HOME\Mark'

exec dbo.QuickLinksRetrieveAllItems @RecordId,@ViewerItemSecurity=31,@RequestedItemSecurity=16

Deze stored procedure haalt informatie uit de dbo.UserMemberships, dbo.UserLinks en dbo.UserColleagues tabellen op. Het mag zich raden welke informatie waar staat.

Onder water.

Goed… Genoeg over de basics. Laten we het nu over het echte werk gaan hebben. Hoe zorgen we nu dat we een synchronisatieslag kunnen maken tussen wat er in de profilestore staat en wat er in de contentdatabase staat?

Profile synchronisatie in Sharepoint is een samenspel van een 3tal componenten, te weten:

Een tweetal timerjobs.
Een set stored procedures op de Content database.
Een set stored procedures op de SSP database.

Zoals nagenoeg elke periodieke administratieve afhandeling binnen Sharepoint gaat profile synchronisatie via timerjobs, te weten de Profile Synchronization en Quick Profile Synchronization. Standaard draaien deze om respectievelijk het uur en de minuut. De normale job zorgt voor een volledige synchronisatie van informatie en verzorgd dat alle wijzigingen, toevoegingen en verwijderingen sinds de laatste job worden afgehandeld. De Quick job zorgt voor het synchroniseren van alleen nieuwe toevoegingen. Dus als ik mezelf lid maak van een site, wordt bij een Quick job mijn WSS profiel geupdate, maar dat van anderen op dat moment niet.

Bij het aanmaken van een web applicatie of SSP, wordt er een job definitie aangemaakt voor beide jobs:

Wanneer het tijd is om de job af te vuren, zal de Timer Service van een willekeurige server in de farm de jobs uitvoeren. De timerservice gebruikt vervolgens een set verschillende stored procedures op de content databases en SSP database om de synchronisatie te doorlopen. Op de content databases zijn er geen specifieke profiel synchronisatie stored procedures, omdat profiel synchronisatie een MOSS feature is en de content database een object is dat ook bestaat in de WSS wereld. De stored procedures waaraan ik refereer zijn bedoeld om informatie over de WSS profielen uit te kunnen lezen en te kunnen updaten. Op de SSP database zijn wel een set speciaal geschreven stored procedures aanwezig. Deze worden gebruikt om informatie over de synchronisaties bij te houden om ervoor te zorgen dat alleen wijzigingen doorgevoerd worden. Verder zorgen deze ervoor dat profiel informatie (membership info) bijgewerkt wordt.

Een volledig overzicht over de internals van deze stored procedures is terug te vinden in de Protocol specificaties op MSDN:
[MS-WSSDLIM]: Windows SharePoint Services: Content Database Document and List Item Management Communications Protocol Specification
http://msdn.microsoft.com/en-us/library/cc313081.aspx

[MS-UPSSYNC]: User Profile Synchronization Stored Procedures Protocol Specification
http://msdn.microsoft.com/en-us/library/cc313167.aspx

High level ziet een synchronisatie (niet Quick) er als volgt uit:

Gedurende profile synchronisatie hebben we 3 stadia waarin de sync plaats vindt, namelijk:

Content DB Synchronisatie
Profile Synchronisatie
Membership Synchronisatie

Deze stadia overgangen zijn voor het synchronisatie mechanisme om voortgang bij te houden. Gedurende elk stadia wordt er op verschillende plekken voortgang bijgehouden in tijdelijke in-memory tables (Staging data), maar ook in tabellen in SQL (bijv. dbo.ContentDBSync en dbo.SiteSync, waar we later nog op terug komen J). Ook worden er hier en daar extra checks gedaan om consistentie te bewaren. Om het overzichtelijk te houden heb ik het iets abstracter gemaakt en dergelijke checks en status updates weggelaten. Onthoud dat elk stadia dus een eigen werkgebied heeft in het geheugen of database. Terugkomend op mijn visualisatie, gebeurt er in grote lijnen het volgende:

Bij aanvang van de synchronisatie vraagt de timerservice de contentdb sync informatie op bij de SSP. Deze gegevens bevatten informatie over de laatste synchronisatieslag voor deze specifieke content database.
De SSP geeft de informatie terug indien aanwezig. Het belangrijkste daarbij is het Database Changetoken, wat een timestamp is van de laatste succesvolle synchronisatieslag. Wanneer de content database geen sync informatie heeft in de SSP database, wordt dat op dat moment aangemaakt in de dbo.ContentDBSync tabel. Deze sync informatie bevat naast het changetoken ook gegevens over de status van de content database gerelateerd aan profile synchronisatie.
De timerservice zal vervolgens op basis van de Database Changetoken de changelogs van de content database afspeuren naar nieuwe sites.
De gegevens bevatten GUIDS van de afzonderlijke sites, de site collectie waartoe ze behoren en de contentdatabase waarin ze te vinden zijn.
De nieuwe sites worden geregistreerd bij de SSP in de dbo.SiteSync tabel. Deze sync informatie bevat net als bij de content database sync informatie, gegevens over de status van de site met betrekking tot profile synchronisatie, waar een Site Changetoken een deel van is.
De timerservice zal vervolgens een overzicht van sites, die in de synchronisatie meegenomen moeten worden, ophalen bij de SSP. Dit is een overzicht van alle sites in de content database met bijhorende Site Changetokens. Dit is een gedeeltelijke resultset. Stap 6 t/m 12 worden iteratief uitgevoerd totdat alle sites zijn verwerkt.
Vervolgens zal de timerservice een overzicht van alle gewijzigde profielen op basis van de Database Changetoken opvragen. Dit is eveneens een gedeeltelijke resultset. Stap 7 t/m 12 worden iteratief uitgevoerd totdat alle profielen zijn verwerkt. Dit maakt het ook mogelijk nieuwe profielen te registreren op basis van nieuw gevonden ACLs (dus ook nieuwe WSS profielen).
De gewijzigde profielen bevatten dus de MOSS profiel informatie uit de SSP profilestore (dbo.UserProfileFull en dbo.UserProfileValue voornamelijk). Alleen gegevens over MOSS profielen die een WSS profiel wederhelft hebben worden teruggegeven. Een profiel moet eerst geregistreerd zijn voor synchronisatie.
De informatie wordt vervolgens gebruikt om de WSS profielen in de User Information Lists bij te werken via de List stored procedures. De informatie is opgeslagen in de dbo.AllUserData tabel in de content database, waar alle items voor elke list in elke site binnen de content database te vinden is.
Gedurende het bijwerken van de User Information Lists worden meteen alle nieuwe ACLs voor de sites opgevraagd op basis van de Site Changetoken.
De ACLs bevatten informatie over de site, site collectie, content database, group Ids en gebruikers Ids (SIDS), welke in de SSP geregistreerd worden.
Op basis van deze ACLs worden voor alle gebruikers die lid zijn geworden van een Site Members groep, of waar lidmaatschappen zijn verwijderd, het profiel bijgewerkt met Site Membership informatie (dbo.UserMemberships).
Op basis van de ACLs wordt er ook bepaald of er nieuwe profielen zijn waarvoor synchronisatie moet worden gestart. Deze worden geregistreerd.
Als nu alle sites en profielen zijn verwerkt stopt het Synchronisatie proces.

Nu het proces klaar is, bevatten alle WSS profielen up to date informatie op basis van de MOSS profielen en zijn site memberships op de MOSS profielen bijgewerkt. Tenminste als alles goed gaat J. Er kan namelijk wel eens wat mis gaan.

Crap… iets is er niet in de haak!

Profile Synchronisatie is een proces waar redelijk wat verkeerd kan gaan. Er zijn in principe twee veel voorkomende probleem scenario's:

Profile synchronisatie voor sites / content databases is gestopt zonder dat daarvan melding gemaakt wordt.
Errors betreffende het niet kunnen synchroniseren van sites in eventlog en tracelog.

Wanneer profile synchronisatie is gestopt voor sites/content databases zonder aanduidbare reden, dan is de kans groot dat iemand content databases of sites uit de synchronisatie heeft gehaald door de preparetomove stsadm operatie te draaien. Preparetomove werd voor de Infrastructure Update gebruikt om ervoor te zorgen dat, wanneer een content database detached werd van de farm en later weer werd attached, Sharepoint op de hoogte was van dit feit omdat voor IU de database GUIDS wijzigden bij het attachen. Hetzelfde gold voor het verplaatsen van sites binnen de farm. In de dbo.SiteSync table van de SSP database werd bij het gebruik van preparetomove een MOVING flag gezet, waarna profile synchronisatie stopt voor die content database of site, totdat deze opnieuw werden aangetroffen met een andere GUID.
Na Infrastructure Update wijzigen de GUIDS niet meer, waardoor site collecties die de MOVING = 'True' flag hebben, nooit meer meegenomen worden in de profile synchronisatie. Profile Synchronisatie wacht namelijk totdat de site collecties worden gevonden met een nieuwe GUID. Om deze reden moet dit commando niet meer gebruikt worden (http://blogs.msdn.com/toddca/archive/2009/01/30/preparetomove-away-from-running-this-command.aspx).
Gelukkig kan je nog altijd terug, wanneer je het commando gedraaid hebt. Het is kwestie van het commando draaien met de –undo parameter (http://technet.microsoft.com/en-us/library/cc262122.aspx).

Voorbeeld:

Gebruik de volgende SQL query om erachter te komen welke site collecties de MOVING status hebben:
USE SSP1_DB
SELECT ss.LastSynch, ss.ChangeToken, ss.SchemaVersion, ss.LastChangeSynchSuccess,
ss.Moving, ss.MovingDeleted, ss.Registered, so.Name AS db, so2.Name AS webapp,sm.Path FROM dbo.SiteSynch ss
JOIN SharePoint_Config.dbo.SiteMap sm ON ss.SiteID = sm.ID
JOIN SharePoint_Config.dbo.Objects so ON sm.ApplicationId = so.Id
JOIN SharePoint_Config.dbo.Objects so2 ON sm.DatabaseId = so2.Id
Gebruik respectievelijk stsadm –o preparetomove –site <siteurl> -undo en stsadm –o preparetomove –contentdb <dbserver:dbnaam> -undo om voor een site collectie dan wel contentdatabase de MOVING status te verwijderen.
Trigger de profile synchronisatie door de timerjob te resetten naar een rotatie van 1 minuut, gebruik makend van stsadm –o sync –synctiming M:1. Wacht vervolgens een minuut en reset de timing weer naar een rotatie van 1 uur door stsadm –o sync –synctiming H:1.
De synchronisatie zou weer moeten starten voor die specifieke site collectie of database.

Wanneer tijdens profiel synchronisatie op een gegeven moment allerlei EVENT IDs in application log en ULS logs verschijnen (IDs 5555, 5553, en 7888) betreffende het niet kunnen synchroniseren van bepaalde objecten, dan heeft dit in de meeste gevallen als oorzaak dat site collecties of content databases zijn verplaatst (bijvoorbeeld na het gebruik van stsadm –o mergecontentdbs) . In de meeste gevallen is dit probleem vervolgens te verhelpen door de synchronisatie informatie voor de content databases die deze 'probleemsites' bevatten te resetten. Dit gaat als volgt:

Gebruik het commando stsadm –o sync –listolddatabases x om een overzicht te genereren van alle databases die synchronisatie informatie bevatten die minimaal x dagen verouderd is. X moet bepaald worden aan de hand van de events in de eventlog. Het aantal dagen sinds het eerste event moet als waarde genomen worden.
Vergelijk de output van het commando met de events in de application log en ULS logs. De output bevat database GUIDS, welke je kunt matchen met database GUIDS uit de events. Wanneer deze informatie overeen komt, plan dan buiten kantoortijden een paar uur maintenance in.
Tijdens maintenance draai je vervolgens het commando stsadm –o sync –deleteolddatabases X om de profiel informatie te verwijderen.
Trigger de profile synchronisatie door de timerjob te resetten naar een rotatie van 1 minuut, gebruik makend van stsadm –o sync –synctiming M:1. Wacht vervolgens een minuut en reset de timing weer naar een rotatie van 1 uur door stsadm –o sync –synctiming H:1.
De synchronisatie zou weer moeten starten voor die database, en de events zouden verdwenen moet zijn uit de logs.

Wanneer er nog steeds errors voorkomen, dan kun je proberens stsadm -o sync -deleteolddatabases 0 te draaien. Dit verwijdert alle profiel informatie, waardoor ook site memberships niet meer beschikbaar zijn. Vandaar dus ook dat je deze commando's buiten kantoortijden moet draaien.

Er is 1 scenario waar het resetten van de sync informatie niet gaat werken, en dat is wanneer er twee site collecties zijn met WEBs (subsites) met dezelfde GUIDS. In deze gevallen blijf je 5553 errors houden:

Event Type: Error

Event Source: Office SharePoint Server

Event Category: User Profiles

Event ID: 5553

Date: 7/14/2009

Time: 5:01:08 AM

User: N/A

Computer: COMPUTERNAME

Description:

failure trying to synch site bd030447-46db-4bf4-9bc9-865b6b7fb293 for ContentDB 79eab52a-526c-4c7f-9adf-6c15a0b64a3b WebApp 1abfa921-6f2c-4d30-8e2e-1d807e5d060c. Exception message was Cannot insert duplicate key row in object 'dbo.UserMemberships' with unique index 'CX_UserMemberships_RecordId_MemberGroupId_SID'.

The statement has been terminated.

Duplicate GUIDS komen voor, wanneer je stsadm –o backup / -o restore gebruikt om een site collectie te restoren, terwijl de orginele site eveneens actief blijft. Bij de restore wijzigt weliswaar de site collectie GUID, maar niet alle GUIDS van objecten binnen de site collectie. Hier kan profile synchronisatie niet mee overweg. Nu zijn er verschillende artikelen die dan vervolgens als oplossing bieden om stsadm –o preparetomove –site <url> -oldcontentdb <GUID> te draaien. Dit biedt welliswaar een oplossing voor de events, maar hiermee introduceer je een nieuw probleem. Het enige wat je dan vervolgens doet is 1 van de twee actieve site collecties uit de profile synchronisatie houden. Nieuwe profielinformatie komt zo niet meer door naar die site collectie. Wanneer je dan vervolgens in de toekomst stadm –o deleteolddatabases 0 gebruikt, krijg je ook meteen de events weer terug. Oplossing voor dat specifieke probleem is dus om 1 van de 2 sites te verwijderen, dan wel de content de migreren naar een nieuwe site collectie.

Ik hoop dat profile synchronisatie nu iets duidelijker geworden is. Dit is eveneens een van mijn laatste 2007 blog posts. Vanaf vandaag zal ik mij voornamelijk gaan richten op 2010. Hou deze blog in de gaten!

Eerste officiele documentatie over Sharepoint 2010 (beta) op Technet

Mark Priem — Tue, 20 Oct 2009 16:43:46 GMT

Sinds vanmorgen is het Technet Techcentre voor Sharepoint 2010 live op http://technet.microsoft.com/en-us/sharepoint/ee263917.aspx.
Hier kan je verschillende documenten vinden die je als organisatie kan helpen voor te bereiden op Sharepoint 2010.

Vooral de Evaluation Guide is erg goed document met een introductie van de nieuwe functionaliteiten in Sharepoint 2010: http://technet.microsoft.com/en-us/library/cc262881(office.14).aspx

Een kort overzicht:

IT pro productivity

SharePoint Best Practices Analyzer

Backup and restore configuration data

Site collection migration

Content recovery down to the site and list level

Content restore of site or list

Windows PowerShell™ snap-ins and commands

Scalable unified infrastructure

Shared service applications

Hosting and multi-tenancy architecture with site subscriptions

Claims-based authentication

Profile synchronization

High availability automatic failover

Content type syndication

Sandbox solutions

Policy

Flexible deployment

Prerequisite installer

Visual Upgrade

Configuration wizards

Scriptable deployment

On-premise or online

Zorg dat je op de hoogte bent!

Sharepoint 2007 build nummers

Mark Priem — Tue, 06 Oct 2009 13:22:31 GMT

Ik krijg heel vaak de vraag wat de build nummers van bepaalde builds nu precies zijn. Hierbij dus een recent overzicht:

Binairies	Versie
Office SharePoint Server 2007 RTM	12.0. 4518.1016
October public update (2007)	12.0. 6036.5000
Service Pack 1	12.0.6219.1000
Post Service Pack 1 rollup	12.0. 6300.5000
Infrastructure Update (IU)	12.0.6320.5000
August Cumulative Update	12.0.6327.5000
October Cumulative Update	12.0.6331.5000
December Cumulative Update	12.0.6335.5000
February Cumulative Update	12.0.6341.5002
Service Pack 2	12.0.6420.1000
April Cumulative Update	12.0.6504.5000
June Cumulative Update	12.0.6507.5000
August Cumulative Update	12.0.6514.5002

Om de versie te achterhalen: http://blogs.microsoft.nl/blogs/mpriem/archive/2008/06/06/sharepoint-patch-level.aspx

Een complete bijgewerkt overzicht en een uitgebreide procedure voor het installeren van software updates is te vinden op:
http://technet.microsoft.com/en-us/library/cc263467.aspx

Suc6!

SQL Express edition upgrade

Mark Priem — Thu, 10 Sep 2009 18:50:18 GMT

Onlangs was ik bezig met een testsysteem, waar ik met SQL Express 2008 with Advanced features aan het spelen was met Reporting Services en wilde dit systeem later upgraden naar Standard edition, omdat ik tegen database size limieten aanliep. Nu heb ik eerder een upgrade gedaan van SQL 2005 Express naar SQL 2005 Standard door gebruik te maken van de commandline optie setup.exe –SKUUPGRADE=1, maar dit werkt niet meer in SQL 2008 Express. In onze documentatie kon ik het in het begin ook niet vinden. Maar de volhouder wint J: http://msdn.microsoft.com/en-us/library/cc707783.aspx

Omdat ik toch enige tijd kwijt was om erachter te komen, dacht ik dat er vast nog wel iemand met hetzelfde probleem zal komen te zitten. Vandaar deze post!

Upgrade

De upgrade optie zit op een beetje ongewone plek in de setupwizard, namelijk onder Maintenance > Edition Upgrade

Na de preinstallation rules, product key en andere voor zichzelf sprekende vensters krijg je de mogelijkheid de SQL 2008 instance te kiezen:

Na controle van de versie en functionaliteit is het een kwestie van kiezen voor Upgrade en Bob is your uncle

Eventuele extra features zijn gewoon toe te voegen via de normale setupmethoden!

Suc6!

Sharepoint 2010 Sneak Peak

Mark Priem — Mon, 13 Jul 2009 19:08:00 GMT

Sinds vanmorgen is er eindelijk meer informatie beschikbaar over Sharepoint 2010. Het product zal later dit jaar vrijgegeven worden als publieke beta met een RTM release in de eerste helft van 2010.

De content is te vinden op:

2010 Sneak Peek Home: http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/default.aspx 2010 Sneak Peek Overview Video: http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/Overview-Video.aspx
2010 Sneak Peek IT Pro Video: http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/IT-Pro-video.aspx
2010 Sneak Peek Developer Video: http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/Developer-video.aspx
2010 Sneak Peek Get Ready: http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/Get_Ready.aspx
2010 Sneak Peek FAQ: http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/FAQ.aspx

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

Mark Priem — Tue, 19 May 2009 15:28:00 GMT

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

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

Het Test project

Begin met het aanmaken van een test project:

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

De WebTest

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

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

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

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

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

Zou dit genoeg zijn???

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

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

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

Als we de test nu draaien, gaat alles goed:

Op naar het Data Binden!!

Databinding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Als we nu de webtest starten, gaat alles goed:

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

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

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

Opschonen

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

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

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

Ik verwijder het eerste request dus!

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

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

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

Validation Rules

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

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

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

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

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

Nu is onze webtest eindelijk klaar!!

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

Load Test configuratie

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

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

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

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

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

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

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

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

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

Terminal Services Gateway beveiligen met ISA Server 2006

Mark Priem — Sat, 09 May 2009 08:08:52 GMT

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

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

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

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

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

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

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

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

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

Certreq.exe –accept <padnaarcertificaat.cer>8

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

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

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

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

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

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

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

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

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

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

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

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

Waar vind ik mijn technische informatie over Microsoft producten?

Mark Priem — Tue, 05 May 2009 09:23:42 GMT

Ik krijg vaak te horen dat men door de grote hoeveelheid informatie niet kan vinden wat men zoekt, of dat de structuur van onze sites onhandig is. Ik ben het hier niet helemaal mee eens en wil met deze post laten zien wat de mogelijkheden zijn om aan informatie te komen op Microsoft.com. Ik zal niet ingaan op elke Microsoft site, maar tips geven hoe aan informatie te komen.

Bijna alle informatie over onze producten is te vinden op Microsoft.com. Het probleem met Microsoft.com is dat er zo verschrikkelijk veel informatie voor handen is, en er zo veel mensen content editen, dat het lastig kan zijn informatie terug te vinden. Toch vind ik dat er op zich een goede structuur is, en met de juiste methoden de informatie prima te vinden is. Mensen beginnen gewoon op de verkeerde manier met informatie zoeken.

Waarschijnlijk 9 op de 10 mensen zal hun favoriete zoekmachine openen en via zoektermen proberen de vereiste informatie boven water te toveren. Dit werkt vaak goed, maar het kan vaak makkelijker. Het probleem met zoeken is dat men veelal niet kort kan verwoorden wat men precies zoekt, waardoor het moeilijk in zoektermen te vatten is. Vaak kom je net zo makkelijk aan informatie zonder een zoekmachine te gebruiken. Net als bij bijna elk ander bedrijf start het internetavontuur bij een internet portal, in dit geval http://www.microsoft.com

Zoals elke portal is dit de toegang tot alle informatie in het microsoft.com domein. Afhankelijk van het type informatie dat je zoekt, kan je kiezen voor een categorie en bijhorende site. De meest bekende zijn sites als Technet, MSDN, Support, Connect en Download. Aangezien we technische informatie zoeken kunnen we kiezen voor een van de vele productspecifieke sites, waar voornamelijk de algemene informatie te vinden is, of bijvoorbeeld Technet met informatie specifiek voor IT professionals. Informatie over downloads is te vinden op download.microsoft.com, informatie over support op sites als support.microsoft.com en ga zo maar door. In de toplink bar zijn de sites gegroepeerd.

Als het puur om technische informatie gaat zoals informatie over het installeren of configureren van software, dan is Technet 'the place to be'. Sinds enige tijd maakt Technet gebruik van TechCentres, wat subsites zijn voor specifieke producten.

Binnen een TechCentre is veelal de informatie heel netjes gegroepeerd, zoals te zien is op het Sharepoint TechCentre, waar voor verschillende topics als Update, Disaster Recovery en Deployment weer aparte Resource Centres (TechCentre subsite) waar alleen informatie te vinden is over dat specifieke onderwerp. Van hieruit wordt je doorgestuurd naar verschillende plekken binnen Microsoft.com. Zo zal het Updates Resource centre veelal artikelen linken vanuit support.microsoft.com en patch downloads vanuit downloads.microsoft.com. Zo is veel informatie snel voor handen binnen slechts enkele muisklikken.

Mocht het via deze weg nog niet mogelijk zijn de informatie te vinden heeft Technet (en de meeste andere Microsoft.com sites) ook nog de zoekoptie, welke gebaseerd is op Live Search:

Nu kan het zijn dat je de informatie die je zoekt niet kan vinden. Voornamelijk wanneer je met een specifiek vraagstuk zit, wat net even anders is dan gebruikelijk, loop je tegen de beperkingen aan van online documentatie. In zulke gevallen wil je terugvallen op lotgenoten en experts. Gelukkig zijn daar genoeg mogelijkheden voor. Communities hebben binnen microsoft.com een prominente plek onder http://www.microsoft.com/communities/default.mspx . Zo zijn er veel informatiebronnen als blogs, nieuwsgroepen, chats en community sites terug te vinden. Op elk van deze bronnen is het mogelijk in contact te komen met andere IT-pro's waaronder veel Microsoft medewerkers en MVPs. Voornamelijk de nieuwsgroepen en fora zijn veelbezochte locaties. Mocht je dus met vragen zitten of op de hoogte willen blijven van wat er voor problemen en vraagstukken spelen bij collega IT-ers, zorg dan dat je regelmatig een kijkje neemt op de nieuwsgroepen en fora.

Het op de hoogte blijven met de ontwikkelingen op bepaalde gebieden kan veel tijd in beslag nemen. Ook hier zijn er een aantal mogelijkheden, die dit een stuk makkelijker maken. Zo zijn er newsletters ,RSS feeds en zelfs tijdschriften waarop geabonneerd kan worden.
Email newsletters kunnen aangevraagd worden via https://profile.microsoft.com/RegSysProfileCenter/SubCntDefault.aspx . Hier heb je de mogelijkheid te registreren voor heel veel verschillende newsletters, ook in de eigen taal.

Voor de RSS feeds bestaat er de Feeds directory op http://www.microsoft.com/rss/, waar je kan registreren voor honderden feeds waaronder de feeds voor de laatste KB artikelen voor bepaalde technologieën of de Microsoft Security Bulletins. Even registreren in Outlook 2007 en.. VOILA! Binnen een paar seconden ben je op de hoogte van de laatste nieuwe content.

Zoals gezegd zijn er ook tijdschriften waarop geabonneerd kunnen worden. Microsoft Nederland heeft een aantal tijdschriften, die gratis zijn voor IT-pro's. Dit zijn MSDN .Net Magazine en Technet Magazine. Abonneren kan via:

.NET Magazine:
https://profile.microsoft.com/RegSysProfileCenter/wizard.aspx?wizid=d7805d54-2171-4601-b654-55537eefb3bc&lcid=1033&fu=/belux/msdn/nl/community/netmagazine/subscribed.mspx

TechNet Magazine:
http://technet.microsoft.com/nl-nl/cc514308.aspx

Zo zie je. Er zijn genoeg bronnen voor informatie, en als je weet wat je doet kan je prima de informatie vinden die je zoekt. Neem af en toe de tijd om je kennis bij te spijkeren en vergeet vooral de blogs op http://blogs.microsoft.nl, http://blogs.msdn.com en http://blogs.technet.com niet!

Backup/Restore van Publishing sites over farms is vanaf heden mogelijk

Mark Priem — Fri, 01 May 2009 09:04:00 GMT

Voorheen was het niet mogelijk Sharepoint sites die de publishing features gebruiken te restoren op een andere farm dan waar de backup was genomen. Dit omdat bepaalde hardcoded URLs en GUIDs in de content database opgeslagen waren, zoals bijvoorbeeld de URLs van de page layouts. Omdat veel klanten hierover klaagden is dit met een fix in de April CU voor Office Sharepoint Server 2007 aangepast. Er waren wel wat workarrounds voor, maar het wordt nu dus officieel ondersteund.

April CU (global):
April CU for Windows SharePoint Services 3.0, x86 & x64 (UBER PACKAGE)
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=968850&kbln=en-us

April CU for Office SharePoint Server 2007, x86 & x64 (GLOBAL only. Uber package wordt verwacht over een week)
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=968859&kbln=en-us

Bron:
http://blogs.technet.com/stefan_gossner/archive/2009/05/01/red-is-green-up-is-down-and-the-unsupported-suddenly-becomes-supported.aspx

401.1 Authentication failed bij browsen naar lokale IIS5 en IIS6 websites

Mark Priem — Fri, 17 Apr 2009 07:34:00 GMT

Sinds kort komen er steeds meer incidenten binnen van problemen bij het browsen naar websites op de lokale machine waar gebruik wordt gemaakt van windows integrated authenticatie. 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.

Office System 2007 Service Pack 2 aangekondigd

Mark Priem — Thu, 16 Apr 2009 14:05:53 GMT

28 April is de datum dat Service Pack 2 voor Office clients en server vrijgegeven wordt. Deze release bevat onder andere de volgende verbeteringen:

Office Clients:

Ondersteuning voor OpenDocument Format (Text (*.odt), Spreadsheet (*.ods), Presentations (*.odp)).
Save As PDF or XPS is toegevoegd aan het product.
Performance is verbeterd wanneer vele images gerenderd moeten worden.
Overal performance van Outlook is aanzienlijk verbeterd. Voornamelijk in Offline mode, met grote offline caches.
Printkwaliteit is verbeterd (voornamelijk op PCL Printers)
Ondersteuning voor Internet Explorer 8, Windows 2008 SP2, Windows Vista SP2, Windows 7 en Windows 2008 R2 is toegevoegd.

Office Servers:

Sharepoint is uitgebreid met een aantal STSADM commando's.
Ondersteuning voor Internet Explorer 8, Windows 2008 SP2, Windows Vista SP2, Windows 7 en Windows 2008 R2 is toegevoegd.
Forms based authentication voor Sharepoint is aanzienlijk verbeterd.
Content deployment in Sharepoint is beter schaalbaar en presteert veel beter. Het is tevens betrouwbaarder.
Ondersteuning voor 3rd party browsers is verbeterd binnen Sharepoint.
Search / Index performance is verbeterd in Search Server en Sharepoint.
Backup restore mogelijkheden voor Search zijn uitgebreid.
Groove Server synchronisatie is betrouwbaarder geworden.
Groove ondersteunt nu SQL 2008.
Forms rendering in Sharepoint en Forms Server is sneller en heeft een lagere memory footprint.

Zelf draai ik al tijden de beta van Service Pack 2 en ben zeer te spreken over de verbeteringen, voornamelijk op het gebied van performance.

Nog een paar weken en jullie kunnen er ook van genieten!

Sharepoint Designer nu gratis

Mark Priem — Thu, 02 Apr 2009 16:42:33 GMT

Om Sharepoint nog meer aandacht te geven is er besloten Sharepoint Designer nu gratis aan te bieden. Voor bestaande licenties is er de mogelijkheid over te stappen op Expression Web.
Sharepoint Designeren veel meer informatie is hier te vinden: http://office.microsoft.com/en-us/sharepointdesigner/default.aspx?ofcresset=1

Veel plezier!

Virtual Server 2005 R2 Enterprise op Windows 7

Mark Priem — Sat, 28 Mar 2009 15:31:00 GMT

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

Installatie IIS7
Installeer Virtual Server 2005
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:

IIS 6 Management Compatibility*	IIS Metabase and IIS6 configuration compatibility IIS 6 Scripting Tools IIS 6 WMI Compatibility IIS 6 Management Console
Application Development Features*	CGI
Security*		Windows Authentication

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