Premier Field Engineering

Office 2010 Server en Client launch op 12 Mei

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

Posted door Mark Priem | met no comments
Opgeslagen onder: ,

Paste clipboard als platte tekst

Als je net als ik veel adviezen en rapporten moet schrijven dan ken je het verschijnsel. Je wilt een stuk tekst ergens vandaan copy (CTRL-C) & pasten (CTRL-V), maar het eindresultaat heeft een verkeerde layout of een verkeerd font. Of je bent bezig met een stukje internet research vast te leggen in Onenote, maar je wilt niet dat iedere keer de bronvermelding erbij komt. Lastig allemaal.

Natuurlijk heb je daarvoor workarounds. Veel applicaties kennen de Paste – Special menu optie, waar je vervolgens selecteert dat je platte text wilt pasten. Kan natuurlijk, maar je bent weer een paar klikken verder. Een andere workaround is om eerst naar Notepad te pasten dat immers niets anders kent dan platte tekst, en van daaruit weer naar de eindbestemming.

Het kan ook anders. Een collega van me heeft een heel klein appje geschreven, genaamd PureText. Wat doet het? Naast de CTRL-V toetscombinatie heb je nu Windows-V, en als je die combinatie typt wordt de selectie geplakt als platte text. Erg handig! Stop het appje in je Startup folder en je bent klaar. Hier kan je het vinden: http://www.stevemiller.net/puretext/

Posted door Willem Kasdorp | 1 comment(s)
Opgeslagen onder:

SSP Profile Synchronisatie in Sharepoint

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:

  1. Een tweetal timerjobs.
  2. Een set stored procedures op de Content database.
  3. 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:

  1. Content DB Synchronisatie
  2. Profile Synchronisatie
  3. 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:

  1. 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.
  2. 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.
  3. De timerservice zal vervolgens op basis van de Database Changetoken de changelogs van de content database afspeuren naar nieuwe sites.
  4. De gegevens bevatten GUIDS van de afzonderlijke sites, de site collectie waartoe ze behoren en de contentdatabase waarin ze te vinden zijn.
  5. 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.
  6. 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.
  7. 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).
  8. 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.
  9. 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.
  10. Gedurende het bijwerken van de User Information Lists worden meteen alle nieuwe ACLs voor de sites opgevraagd op basis van de Site Changetoken.
  11. De ACLs bevatten informatie over de site, site collectie, content database, group Ids en gebruikers Ids (SIDS), welke in de SSP geregistreerd worden.
  12. 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).
  13. 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:

  1. Profile synchronisatie voor sites / content databases is gestopt zonder dat daarvan melding gemaakt wordt.
  2. 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:

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


  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. Tijdens maintenance draai je vervolgens het commando stsadm –o sync –deleteolddatabases X om de profiel informatie te verwijderen.
  4. 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.
  5. 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!

Posted door Mark Priem | met no comments

Microsoft Sharepoint Server 2010 installatie

Het is eindelijk zover… De beta van Sharepoint 2010 is beschikbaar gemaakt voor een breder publiek. Daarom is het tijd voor een aantal posts. De komende tijd zal ik verschillende posts doen over dit geweldige nieuwe product. Deze post laat stap voor stap een basisinstallatie zien voor een small server farm. Nu zitten er eigenlijk maar bar weinig verschillen in het installatie proces ten opzichte van MOSS 2007, maar net genoeg om deze post te rechtvaardigen J.

Voorbereiding

Om te beginnen hebben we de volgende software nodig:

  • Windows Server 2008 x64 of later.
  • SQL 2008 SP1 CU2 X64 of later OF SQL 2005 SP3 CU2 X64 of later.
  • (Indien geen SP2) KB 953290 om een probleem met performance counters op Windows Server 2008 en Vista pre-sp2 op te lossen.

Ik ga niet vertellen hoe Windows Server 2008 te installeren en een SQL server op te tuigen. Dit spreekt voor zich.
Na installatie van Windows Server en KB 953290 start je PrerequisiteInstaller.exe van het installatiemedium, welke alle vereiste extra componenten voor Sharepoint 2010 installeert:

Verder moeten er - net als met MOSS – voor de installatie een aantal accounts aangemaakt worden, welke voor de setup van belang zijn:

Account

Doel

Vereisten

Setup user account

  • Draaien van Setup
  • Draaien van de SharePoint Products and Technologies Configuration Wizard.
  • Domain user account.
  • Lid Administrators local group op elke server in de farm.
  • SQL Server login met de volgende security roles:
    securityadmin fixed server role
    dbcreator fixed server role
  • Als je powershell met dit account gebruikt om Sharepoint te configureren dient je ook db_owner role te hebben op elke database.

Server farm account of database access account 

  • Beheer en configuratie van de farm.
  • Application pool identity voor de SharePoint Central Administration Web site.
  • Service account van de Windows SharePoint Services Timer service.
  • Domain user account.
  • Overige rechten worden automatisch geconfigureerd (dezelfde rechten als het setupaccount met toevoeging van db_owner role op elke database.

Managed Service Account

  • Service account voor farm services
  • Domain user account

Dit account mag gewoon mee in de reguliere password policies, daar dit een Sharepoint managed service account wordt.

Installatie

Nu kan de installatie echt beginnen. Net als met Office Sharepoint Server 2007 installeer je eerst de binaries en wordt later pas de farm gebouwd. Om de binaries te installeren:

  1. Meld jezelf aan met het setup user account op de machine waar Sharepoint 2010 geïnstalleerd gaat worden en start setup van het installatiemedium.
  2. Geef de installatiesleutel op:

  3. Lees J en accepteer de license agreement.
  4. Kies voorServer Farm en selecteer Complete op de ServerType tab en geef het installatie pad op in de File location tab.

  5. Selecteer vervolgens Install.

De installatie gaat van start. Net als met MOSS 2007 zal setup de verschillende MSI bestanden eerst installeren en vervolgens alle updates uit de /Updates folder in de root van het installatiemedium meenemen. Het is dus wederom erg eenvoudig om een slipstreamed versie van Sharepoint 2010 te maken, wanneer nieuwe updates uitkomen…

Farm aanmaken

Na de installatie geeft setup de mogelijkheid de Sharepoint Products and Technologies Configuration wizard te draaien. Ook nu hebben we de beschikking over een GUI versie (psconfigui.exe) en een commandline versie (psconfig.exe).

Kies ervoor om setup de wizard te laten starten. We zullen nu de farm aanmaken:

  1. Kies Next in het welkomst scherm en geef toestemming aan de wizard om een aantal Windows services te herstarten.
  2. KiesCreate a new server farmomeennieuwe farm aan te maken:
  3. Geef op de database settings pagina de juiste informatie op en selecteer Next:
    1. Database server:Een SQL 2005 of SQL 2008 database instance (bv: Servernaamof Servernaam/InstanceNaam)
    2. Database name: De naam van de Sharepoint Configuration database waar alle farm configuratie wordt opgeslagen. Standaard is dat Sharepoint_Config
    3. User name: Het database access- / central admin application pool- account naam.
    4. Password: Het wachtwoordhorendebij het database access- / central admin application pool- account.
  4. Nieuw in deze versie van het product is de Passphrase, welke gebruikt wordt om bepaalde configuratie te versleutelen. Deze passphrase is nodig voor elke nieuwe server die toegevoegd wordt aan de farm. Onthoud deze dus goed, en kies een willekeurig gegenereerde reeks:
  5. Kies in het Configure Central Administration Web Application venster voor een portnummer en authenticatie mechanisme. Hou er rekening mee dat, wanneer je voor Kerberos kiest, dit extra configuratie vereist, zoals bijvoorbeeld het registreren van SPN's. Dit is niet anders dan in MOSS 2007.
  6. Kies voor Next, controleer de instellingen en selecteer nogmaals Next om de configuratie te starten.
  7. De wizard zal de configuratie database aanmaken en vele andere taken uitvoeren, zoals het registreren van features, het aanmaken van de Central Administration web applicatie, en het beveiligen van systeembestanden en registry keys.
  8. Wanneer de wizard klaar is, selecteer dan Finish om de Central Administration site te openen. Dit is het moment om de website toe te voegen aan de trusted sites of local intranet security zones van Internet Explorer, en IE Enhanced Security Configuration uit te schakelen (uiteraard alleen als je gebruik zult gaan maken van de lokale browser om configuratie te doen).

Voordat de Central Administration website start krijg je eerst een popup met de vraag deel te nemen aan het Customer Experience Improvement Program. Ik adviseer iedereen hieraan deel te nemen. Deze informatie helpt Microsoft het product te verbeteren, waar uiteindelijk iedereen van profiteert. Informatie die verzamelt wordt voor geen enkel ander doel gebruikt.

Nadat je uiteraard hebt ingestemd met het verzoek Jzal de Central Administration starten en krijg je de mogelijkheid de farm services te configureren. Mocht dat niet zo zijn, controleer dan de logs in %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS.
Voor deze post zal ik de wizard gebruiken, maar in grotere omgevingen zal er nu begonnen worden met het toevoegen van extra servers. Via de Central Admin kan altijd weer teruggekeerd worden naar deze wizard onder Configuration Wizards.
Zoals je waarschijnlijk al vernomen hebt, is de Shared Service Provider zoals in MOSS 2007 verdwenen. Elke service is op zich staand en wordt vanuit de Central Administration beheerd. De services in Sharepoint 2010 zijn:

Service

Omschrijving

Access Services

Stelt gebruikers in staat Access Databases weer te geven in, en te manipuleren vanuit een web browser.

Application Registry Service

Stelt gebruikers in staat te werken met, en te zoeken naar business data. 

Business Data Catalog

Maakt het mogelijk line of business applicaties te ontsluiten via Sharepoint 2010.

Excel Services

Stelt gebruikers in staat Excel sheets weer te geven in, en te manipuleren vanuit een web browser. 

Lotus Notes Connector

Maakt zoeken naar data in Lotus Domino/Notes mogelijk. 

Managed Metadata Service

Stelt teams en afdelingen in staat hun eigen indeling, hierarchie, keywords en sociale tags te beheren, zodat deze gedeeld kunnen worden over de gehele organisatie.

People

Maakt een uitgebreide peoplesearch mogelijk. 

Search Service Application

Maakt search queries en indexing mogelijk van content.

Secure Store Service

Maakt het mogelijk data beveiligd op te slaan en toegang te beperken. 

State Service

Maakt session state mogelijk wat gebruikt wordt om tijdelijk de status van een bepaalde service of component op te slaan zodat deze niet verloren gaat in een load balanced en connectionless omgeving.

Usage and Health data collection 

Verzamelt gegevens over het gebruik en de status van de farm. 

User Profile Service 

Biedt profile services. 

Visio Graphics Service

Maakt het mogelijk Visio diagrammen weer te geven via het web en dynamisch te vernieuwen.

Web Analytics Web Service

Zorgt voor uitgebreide rapportage op het gebruik van de farm. (denk aan meest gebruikte search termen, top 10 sites etc). 

Word Conversion Service Application

Zorgt voor het, in bulk uitvoeren, van conversies van documenten.

In een latere post zal ik ingaan op de Architectuur rondom Shared Service applications. Dit is totaal anders dan hoe het werkte met Shared Service Providers in MOSS 2007.

Services configureren

Om de services te configureren:

  1. KiesvoorWalk me through the settings using this wizard…. en selecteerNext.


  2. Kies voor Create new managed account en geef het eerder aangemaakte AD account op. Managed service accounts zijn een nieuwe functionaliteit binnen Sharepoint 2010. Het stelt je in staat service accounts vanuit Sharepoint te beheren, en zelfs automatisch het wachtwoord te laten wijzigen met een bepaalde interval. Het mechanisme is zelfs in staat GPO password policies te detecteren en op voorhand het wachtwoord te wijzigen. Het lijkt mij erg handig, maar de praktijk moet uitwijzen of dat ook zo is J.

    Selecteer vervolgens alle services die geconfigureerd moeten worden en kies Next om de configuratie te starten.
    De Wizard zal vervolgens starten en alle services configureren.

    Voortgang is te volgen door de Application event log en de ULS logs in %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS te bekijken.
  3. Wanneer de services geconfigureerd zijn, zal de wizard vragen een site collectie aan te maken. Je kan het overslaan, maar ik heb een teamsite genaamd Sales aangemaakt.
  4. De farm is nu klaar voor gebruik. Een kort overzicht met de configuratie die zojuist is aangepast wordt getoond. Selecteer Finish om de wizard af te sluiten.

Wat is nu precies gebeurd???

We weten dat er nu een farm bestaat en dat er van alles geconfigureerd is, maar wat is er precies onder de motorkap gebeurd?

Laten we beginnen met het filesysteem. Onder andere de volgende wijzigingen zijn te onderscheiden:

  • C:\Program Files\Common Files\Microsoft Shared\SERVER14àConfiguratiebestanden die gebruikt worden door setup, wanneer je het product initieel installeert of later wilt wijzigen.
  • C:\Program Files\Common Files\Microsoft Shared\OFFICE14à Gedeelde binaries die door componenten onderling gebruikt worden.
  • C:\Program Files\Common Files\Microsoft Shared\Microsoft Office 14 Single Sign-onà Binaries voor de SSO service.
  • C:\Program Files\Common Files\Microsoft Shared\Speech* àOnderdelenvoor text-narration binnenSharepoint.
  • C:\Program Files (x86)\Microsoft Chart Controlsà Chart web controls gebruiktbinnenSharepoint.
  • C:\Program Files\Common Files\Microsoft Shared\FiltersàIFiltersvoor de Office documenttypes.
  • C:\Program Files\Common Files\Microsoft Shared\TextConv* à Binaries voor Document conversion.
  • C:\Program Files\Microsoft Office Servers\14.0àSharepoint Server core binaries (niet te verwarren met de Sharepoint Services binaries J)
  • C:\Program Files\Microsoft Analysis Services*à Onderdelen gebruikt door Access Services.
  • C:\Program Files\Microsoft Geneva Frameworkà Onderdelen gebruikt om Claims based authentication out-of-the-box mogelijk te maken in Sharepoint.
  • C:\Program Files\Microsoft Sync Frameworkà Bevat onderdelen om Profile Sync mogelijk te maken. Dat maakt nu gebruik van ILM agents.
  • C:\Program Files\Microsoft.NET* àOnderdelen voornamelijk gebruikt door Access Services.
  • C:\Program Files\Common Files\Microsoft Shared\Web Server ExtensionsàBevat de Sharepoint Services Core binaries.
  • C:\ProgramData\Microsoft\SharePointà Bevat applicatieconfiguratie waaronder de objectcache gebruikt door de Timer Service.
  • C:\Program Files\Microsoft SQL Server* àBevat de SQL client tools.

* C:\Program Files (x86) bevat dezelfde directory.

In het Registry is naast allerhande class-, control en documenttype-registraties het volgende gewijzigd:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0àLokaleconfiguratiecachevoorSharepoint Services componenten.
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0àLokaleconfiguratiecachevoorSharepoint Server componenten.
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Speech ServeràConfiguratievoor Speech Server, gebruiktvoor text narration binnenSharepoint.
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\àRegistratie van eenaantal custom applicatie event logs (bijvvoor Search).
  • HKEY_LOCAL_MACHINE\SYSTEM\SOFTWARE\Microsoft\Microsoft SQL Server\à Configuratie voor SQL Server client tools.
  • HKEY_LOCAL_MACHINE\SYSTEM\SOFTWARE\Microsoft\Microsoft Sync Framework\àConfiguratievoor het Sync framework.

Verder is er het een en ander gewijzigd in IIS. Wanneer we IIS manager openen, zien we dat we er een aantal IIS websites bij hebben gekregen:

  • Sharepoint Central Administration v4à Central Administration web site
  • Sharepoint Web Servicesà Web services web site, waar nu alle Shared Services web services ookondervallen. Het zijnvoornamelijk WCF service points.
  • Sharepoint – 80à Web site voor de default zone van de web applicatie, waar de teamsite site collectie, die we zojuist hebben aangemaakt, in is aangemaakt.

Op zich niet heel spannend, en anders dan in MOSS 2007. Als we dan vervolgens naar de application pools en de daaraan gekoppelde IIS applications kijken, zien we wel wat veranderingen:

Zo zien we de volgende Application Pools:

  • SecurityTokenServiceApplicationPoolà Host applications voorondersteuning van claims based authenticatie.
  • Sharepoint – 16501 à Host de applications voor de Sharepoint – 80 web applicatie(root en layouts).
  • Sharepoint Central Administration v4 à Host de applications voor de Central Admin web applicatie (root en layouts).
  • Sharepoint Web Services àGeenideeJ. Staat op disabled.
  • Sharepoint Web Services Defaultà Host de applicatiesvoor de Shared Services.
  • Sharepoint Web Services Systemà Host eenaantal system applications.

Op onderzoek uit!

Zoals je zult zien, is er qua installatie niet heel veel nieuws aan de horizon. Nu je een draaiend Sharepoint 2010 systeem hebt, is het tijd op onderzoek uit te gaan. Er zijn zo verschrikkelijk veel nieuwe mogelijkheden. In de reeks posts die ik in de komende weken zal plaatsen zal duidelijk worden, hoe gaaf Sharepoint 2010 geworden is.

Suc6!!

Posted door Mark Priem | 1 comment(s)

Sharepoint 2010 blog series

Sharepoint Conference staat voor de deur, en dat betekent dat we dan eindelijk mogen vertellen wat er allemaal voor moois te vinden is in Sharepoint 2010. Voor diegene die er graag bij wilt zijn, het kan nog steeds!

http://www.mssharepointconference.com/Pages/default.aspx#

Voor alle anderen, houd deze blog in de gaten, want vanaf 22 oktober zal er een blog series starten over Sharepoint 2010 met onder andere de volgende – voornamelijk op infrastructuur gerichte - onderwerpen:

  • Installatie Sharepoint 20101
  • Upgraden naar, en patchen van Sharepoint 2010
  • Search in Sharepoint 2010 howto
  • Managen van Sharepoint 2010
  • High Availability en Disaster Recovery

Andere blogs om in de gaten te houden zijn:

 

Tot snel!

Posted door Mark Priem | 3 comment(s)
Opgeslagen onder: , ,

R2 is niet R2: het verschil tussen 2003 en 2008

Binnenkort komt Windows Server 2008 R2 algemeen beschikbaar. Natuurlijk is dit de opvolger van Windows 2008, maar het gaat volgens een ander principe dan bij de vorige generatie van de Windows server. Toen hadden we Windows 2003, dat opgevolgd werdt door 2003 R2. De verschillen zijn dit keer echter groter dan de overeenkomsten.

Windows 2003 R2 had exact dezelfde kernel als Windows 2003. Toen 2003 R2 uitkwam hadden ze allebei de kernel van 2003 SP1. Toen een tijdje later Windows 2003 Service Pack 2 uitkwam was dit van toepassing op zowel Windows 2003 als Windows 2003 R2. Het grote verschil tussen beide systemen is dat Windows 2003 R2 een aantal optionele componenten heeft, zoals ADAM, ADFS, en nog een aantal andere zaken.

Dit is nu geheel anders met Windows 2008 en 2008 R2. Dit zijn verschillende operating systemen met een essentieel andere kernel. Ze delen dan ook geen service packs. Waar Windows 2008 uitkwam met SP1 en recentelijk voorzien is met SP1 komt Windows 2008 R2 gewoon uit met SP1 (RTM). Je kan dus niet 2008 bijwerken met SP2 en dan uitkomen op R2 zoals iemand al hoorde zeggen…

Je kan er ook nog op een andere manier tegenaan kijken. Sinds kort hebben we weer dat het client OS en het server OS weer in lock-step lopen. Kijk maar.

Client OS

Server OS

NT4 Workstation NT4 Server
Windows 2000 Workstation Windows 2000 Server
Windows XP -
- Windows Server 2003
- Windows Server 2003 R2
Vista SP0 (RTM) -
Vista SP1+ Windows Server 2008 SP1+
Windows 7 Windows 2008 R2

Na de introductie van Windows XP hadden we niet echt een bijbehorende server, hoewel de kernels van XP en 2003 erg dicht bij elkaar liggen. Toen Vista uitkwam was er geen tegenhangende server. Pas bij de introductie van Vista SP1 kwam ook Windows Server 2008 uit. Deze hebben dus wel dezelfde kernel. Service Pack voor Vista is ook meteen het service pack voor Windows 2008. En ja, Windows 7 heeft dezelfde kernel als Windows Server 2008 R2. De verwachting is dat we dit patroon voorlopig gaan voortzetten. Wel zo makkelijk, hetzelfde service pack voor workstation en server.

Het is jammer dat deze “R2” naamgeving zo tot stand gekomen is. Hoewel dit vijf jaar geleden al zo gepland is blijkt het voor de nodige verwarring te zorgen. Niet alleen bij klanten, maar ook bij mijn collega’s zoals me afgelopen week duidelijk werd. Vandaar deze kleine toelichting.

Posted door Willem Kasdorp | 1 comment(s)
Opgeslagen onder: ,

SQL Express edition upgrade

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!

Posted door Mark Priem | met no comments

VHD Difference Disks, een uitkomst voor meerdere testomgevingen op 1 machine

Nadat ik thuis kwam van een cursus wilde ik zo snel als mogelijk de Hyper-V images importeren en het lab opbouwen.

Ik liep echter tegen een probleem aan dat dit nieuwe lab settings op mijn Hyper-V client verwacht die anders zijn dan die ik op mijn huidige Windows Server 2008 R2 Hyper-V host heb draaien. Niet alleen IP adressen moesten verschillen maar ook software moest geinstalleerd worden op deHyper-V host. Ik had geen zin om nog een installatie te doen van Windows Server 2008 R2, ik had ook geen partitie meer vrij hiervoor, en zocht naar een simpele oplossing. Die was snel gevonden in VHD difference disks.

Even een uitleg. In Windows 7 en Windows Server 2008 R2 is het mogelijk om native van een VHD te booten. Een VHD disk is een Virtuele Hard Disk, een bestand waarop je een OS kan installeren of files kunt plaatsen. Je kunt de VHD attachen en vervolgens is deze te benaderen als een normale disk. Met VHD difference disks maak je eerst een basis installatie aan van het OS met alle settings zoals je wilt. Vervolgens maak je de difference disks aan vanwaar je daadwerkelijk boot. Het basisimage vervult de rol van parent en wordt niet meer gewijzigd tenzij je ervoor kiest de difference disk en de parent disk te mergen. In dat geval worden alle wijzigingen van de difference disk samengevoegd met de parent disk. Dit is erg handig als je eerst iets wilt testen en niet weet hoe het uitpakt. In het ergste geval heb je altijd je parent disk nog waar je simpelweg een nieuwe difference disk naar toe kunt laten verwijzen.

Parent Disk

Er zijn diverse sites die goede uitleg geven over het maken van een VHD disk, een boot optie in je startmenu en de installatie van het OS. De oplossing die ik gebruikt heb om de parent disk te maken is booten van een Windows 2008 R2 DVD. Dit mag ook een Windows 7 DVD zijn en de setup kun je ook starten vanaf USB. Wanneer het setup menu verschijnt gebruik je Shift-F10 om de command prompt te verkrijgen.

Als eerste moet er een nieuwe VHD disk worden gemaakt.

In de command prompt type je Diskpart.

Maak vervolgens een nieuwe VHD aan met het commando:

DISKPART>create vdisk file="C:\PadNaarVhd.vhd" maximum=SizeInMegabyte

Default wordt er een fixed size disk aangemaakt. Als je een disk wilt die klein start en groter wordt tot de maxmale grootte, gebruik je de optie TYPE=EXPANDABLE. Dit gaat echter ten koste van performance en fragmentatie van de VHD file.

Vervolgens selecteer je de disk en attach je hem als een fysieke disk.

DISKPART> select vdisk file="c:\vhdboot\Win2008R2.vhd"

DISKPART> attach vdisk

Exit vervolgens diskpart en keer terug naar het setup menu (ALT+TAB) en start de setup.
Vervolg de installatie, selecteer de Custom optie (Advanced) en installeer het OS op de zojuist aangemaakte disk, meestal de laatste in het rijtje. Negeer de warning : "Windows cannot install to this disk" en start de installatie.

Er wordt nu automatisch een extra bootoptie aangemaakt die verwijst naar de VHD. Deze basis OS installatie heb ik vervolgens ingericht zoals ik het wil, met Hyper-V en wat extra tooling.

Difference Disk

Vervolgens heb ik een difference disk aangemaakt. Deze difference disk verwijst naar de parent, de VHD die ik zojuist heb ingericht. Om een difference disk aan te kunnen maken moet je vanaf een Windows 7 of Windows 2008 R2 DVD starten of vanuit het native OS dat je wellicht hebt draaien. Je kunt geen differnce disk aanmaken als je geboot hebt vanaf het basis VHD image. Ik heb Windows 7 native draaien en daarnaast een VHD voor Windows Server 2008 R2. In mijn Windows 7 selecteer ik start en type cmd. Rechts klik op cmd en kies voor 'Run As administrator'. Klik OK op de eventuele User Account Control melding.

Afhankelijk van de manier waarop je geboot hebt, native OS of Setup DVD kan de drive letter van je partitie waar het basis vhd image zich bevindt verschillen. Het basisimage en de difference disk moeten zich op dezelfde disk bevinden.

In de command prompt type je: Diskpart

DISKPART> List Disk

Selecteer de disk waar het basisimage zich bevindt.

DISKPART> Select disk 0

Vervolgens DISKPART> list volume

De disk waar mijn parent VHD zich bevindt is volume 2, drive letter D

Met deze informatie kan ik een difference vdisk maken.

DISKPART> Create vdisk file="d:\vhdboot\Win2008R2-diff.vhd" parent="d:\vhdboot\Win2008R2.vhd"

Exit Diskpart maar sluit de command prompt niet. In tegenstelling tot het aanmaken van het basisimage is er nu nog geen boot menu optie aanwezig voor de difference disk.

C:\>bcdedit /v

Alle Boot Loaders worden weergegeven.

Zoek de identifier van de parent disk, in mijn geval {c189cf15-72d1-11dd-b637-00125a5fdb2f}

Vervolgens maak je een kopie van de boot entry van de parent in dezelfde system store:

C:\>Bcdedit /copy {c189cf15-72d1-11dd-b637-00125a5fdb2f} /d "Windows 2008 Difference"

Er is een nieuwe identifier gegenereerd. Deze identifier hebben we nodig om het device en osdevice naar toe te laten verwijzen. Voor de goede orde, we moeten verwijzen naar de difference disk.

C:\>Bcdedit /set {c189cf1c-72d1-11dd-b637-00125a5fdb2f} device vhd=[locate]\vhdboot\Win2008R2-diff.vhd

De [locate] optie zorgt ervoor dat de VHD altijd gevonden wordt door de boot manager, ook al is de disk waar de VHD zich bevindt niet juist bij het booten of zijn andere drives toegevoegd of verwijderd. Erg handig.

Vervolgens:

C:\>Bcdedit /set {c189cf1c-72d1-11dd-b637-00125a5fdb2f} osdevice vhd=[locate]\vhdboot\Win2008R2-diff.vhd

Het aanmaken van de bootoptie voor het starten vanaf de difference disk is klaar. De optie is zichtbaar bij de volgende reboot. Verwijder vervolgens het basis image uit het boot menu. Wijzigingen mogen alleen in de differnce disks worden gemaakt, niet in het basis image.

C:\>Bcdedit /delete {identifier van de basis image} in mijn geval {c189cf15-72d1-11dd-b637-00125a5fdb2f}

Mergen difference en parent disk

Als je de wijzigingen in je difference disk wilt samenvoegen (mergen) met de parent disk, start je wederom vanaf een Windows 7 of Windows 2008 R2 DVD of USB. Je kunt ook starten vanuit het native OS dat je wellicht hebt draaien. In elk geval kan dit mergen niet als je boot vanaf de difference of parent VHD.

Shift-F10 voor een command prompt in de setup of start een command prompt met adminstrator bevoegdheden .

Zorg dat je weet op welke partitie de difference VHD zich bevindt.

In de command prompt type je C:\>Diskpart

DISKPART>select vdisk file=d:\vhdboot\Win2008R2-diff.vhd

DISKPART>Attach vdisk

DISKPART>Detail vdisk

DISKPART>Detach vdisk

DISKPART>Merge vdisk depth=1

Mixen van full en incremental content deployment... Niet doen!

Onlangs kreeg ik voor de zoveelste keer de opmerking van een klant dat ze het vreemd vonden dat in hun content deployment scenario de source site collectie zoveel keer kleiner was dan de target site collectie. Mijn wedervraag was of ze toevallig zowel full deployments als incremental deployments mixen. Het antwoord mag zich raden, namelijk JA..

Dit was voor mij de reden om deze korte post te doen.

Het mixen van full en incremental deployment jobs is namelijk niet ondersteund en zorgt voor een aantal vervelende zaken:

  1. In sommige scenarios kunnen er verschillen ontstaan tussen de source en target site. Items die in de source site zijn verwijderd, kunnen nog steeds bestaan in de target site.
  2. Elke keer wanneer een full deployment een item opnieuw deployed naar de target site zal er –indien versioning actief is – een nieuwe versie van het item aangemaakt worden. Vandaar dus de grotere target site dan source site.

Gebruik full deployment alleen bij de initiële deployment. Mocht full deployment vereist zijn omdat er problemen zijn ontstaan met de incremental deployments (bijvoorbeeld als de changelog retentie is verlopen), gebruik dan full deployment op een lege site collectie en gebruik vervolgens incremental deployments.

Stefan Goßner – onze content deployment goeroe – heeft een aantal posts, welke meer informatie geven over content deployment:

http://blogs.technet.com/stefan_gossner/archive/tags/Content+Deployment/default.aspx

Posted door Mark Priem | met no comments

Database Statistics Timerjob wijziging in WSS/MOSS SP2

Om de prestaties, capaciteit en integriteit van Sharepoint databases te waarborgen is een gedegen maintenance plan van serieus belang. Voordat Service Pack 2 released werd, hadden we een gewelding Whitepaper van Bill Baer http://go.microsoft.com/fwlink/?LinkId=111531&clcid=0x409 welke ons de fijne kneepjes van Sharepoint Database Maintenance bijbracht. Daarnaast hadden we nog het overzicht over de mogelijkheden met Maintenance plans voor SQL op http://support.microsoft.com/kb/932744/.  Met de wijzigingen in Service Pack 2 komt hier iets verandering in.

In service pack 2 is er een grote wijziging aangebracht aan de Database Statistics timerjob. Voor SP2 was de enige taak van deze job de query statistics te updaten van de content databases. Na uitrol van SP2 is deze job echter ook verantwoordelijk voor het defragmenteren van de indices (oftewel het herstructureren van de data aangezien de sharepoint contentdatabases gebruik maken van clustered indices). Hiervoor gebruikt Sharepoint volgende stored procedure:

USE [WSS_Content]
GO
/****** Object:  StoredProcedure [dbo].[proc_DefragmentIndices]    Script Date: 05/08/2009 04:05:36 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[proc_DefragmentIndices]
AS
BEGIN
    SET NOCOUNT ON
    DECLARE @objectid int
    DECLARE @indexid int
    DECLARE @command varchar(8000)
    DECLARE @baseCommand varchar(8000)
    DECLARE @schemaname sysname
    DECLARE @objectname sysname
    DECLARE @indexname sysname
    DECLARE @currentDdbId int
    SELECT @currentDdbId = DB_ID()
    PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Starting'
    DECLARE @onlineState varchar(10)   
    DECLARE @edition int
    SELECT @edition = CAST(SERVERPROPERTY('EngineEdition') AS int)
    IF (@edition <> 3) SET @onlineState = 'OFF) '
    ELSE SET @onlineState = 'ON) '
    -- Loop over each of the indices
    DECLARE indexesToDefrag CURSOR FOR
    SELECT
        i.object_id,
        i.index_id,
        i.name
    FROM
        sys.indexes AS i
    INNER JOIN
        sys.objects AS o
    ON
        i.object_id = o.object_id
    WHERE
        i.index_id > 0 AND
        o.type = 'U'
    OPEN indexesToDefrag
    -- Loop through the partitions.
    FETCH NEXT
    FROM
        indexesToDefrag
    INTO
        @objectid,
        @indexid,
        @indexname
    WHILE @@FETCH_STATUS = 0
    BEGIN
        -- Lookup the name of the index
        SELECT
            @schemaname = s.name
        FROM
            sys.objects AS o
        JOIN
            sys.schemas AS s
        ON
            s.schema_id = o.schema_id
        WHERE
            o.object_id = @objectid
        PRINT CONVERT(nvarchar, GETDATE(), 126) + ': ' + @schemaname + '.' + @indexname + ' is now being rebuilt.'
        -- Fragmentation is bad enough that it will be more efficient to rebuild the index
        SELECT @baseCommand =
            ' ALTER INDEX ' +
                @indexname +
            ' ON ' +
                @schemaname + '.' + object_name(@objectid) +
            ' REBUILD WITH (FILLFACTOR = 80, ONLINE = '
        -- Use dynamic sql so this compiles in SQL 2000
        SELECT @command =
            ' BEGIN TRY ' +
               @baseCommand + @onlineState +
            ' END TRY ' +
            ' BEGIN CATCH PRINT CONVERT(nvarchar, GETDATE(), 126) + '': Going offline'' ' +
               -- Indices with image-like columns can't be rebuild online, so go offline
               @baseCommand + 'OFF) ' +
            ' END CATCH '
        PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Rebuilding'
        EXEC (@command)
        PRINT CONVERT(nvarchar, GETDATE(), 126) + ': Done'
        FETCH NEXT FROM indexesToDefrag INTO @objectid, @indexid, @indexname
    END
    CLOSE indexesToDefrag
    DEALLOCATE indexesToDefrag
    RETURN 0
END

Dit betekent echter wel dat deze 'limiet' van 100GB iets belangrijker wordt dan voor SP2, daar je bij het gebruik van deze timer job minder controle hebt over wanneer de defragmentatie wordt uitgevoerd, iets wat dus wel impact heeft op de server farm.

Denk dus na over je aanpak omtrent defragmentatie van databases.

Heb je een grote farm, dan zou ik adviseren maintenance plans te gebruiken voor statistics en defragmentatie. je zult dan via Central Administration de database timerjob moeten disablen. Heb je een kleine farm, adviseer ik de database timerjob te gebruiken. Eventuele maintenance plans die al defragmentatie (reorganize) jobs bevatten, dienen aangepast te worden.

Posted door Mark Priem | met no comments

Selective Authentication: de Extranet Trust

Van de week zat ik bij een klant die een veel voorkomend probleem had. Er was sprake van een gerelateerde maar externe partij die toegang nodig had tot interne applicaties, en de directeur had beloofd dat het gisteren af zou zijn. De architecten hadden aantal oplossingen aangedragen. Federation Services stond hoog op de lijst; dit betreft een open standaard om trust relaties te leggen op Web Service niveau middels certificaten. Op papier de ideale oplossing, maar met twee probleempjes: Federations Services is redelijk complex om te implementeren en vereist aanpassingen bij beide partijen, en de betreffende applicaties bleken niet of heel moeilijk werkend te krijgen met Federation Services. Kortom, niet gisteren gerealiseerd zoals ze zelf ook inzagen.

Een andere “oplossing” was om de externe partij accounts te geven in de interne AD, en toegang tot de applicatie te geven middels een Terminal Server farm of zelfs via een VPN. De beveiligingsproblematiek rond deze oplossing was wel vrij duidelijk. Het voorkeur scenario was een variant hierop: een nieuw forest (Extranet Forest) voor de nieuwe accounts, en een trust relatie met de bestaande AD. De lead architect had goed gezien dat er een interessant issue was met dit model: als de trust er eenmaal is dan heeft de Extranet gebruiker dezelfde rechten als Authenticated Users: effectief leesrechten in een groot deel van het productie forest. Zijn oplossing was simpel. We maken een groep waarvan alle Extranet users lid zijn, en geven die overal Deny rechten. Overal, vroeg ik? Ja, overal. Veel werk zeker? Ja, heel veel werk wel. Lastig te onderhouden ook? Ja, ook dat…

Toch is er een simpele oplossing, zei ik. Zet gewoon Selective Authentication aan. Toen viel het stil, al zaten er  heel wat MCSE’ers in de zaal. Dus stapte ik naar het whiteboard om uit te leggen wat dit is.

Sinds Windows 2003 kennen we het concept van de forest trust: een transitieve trust relatie, waarbij alle domeinen in het trusted forest onder het trust bereik vallen. Waar “normale” external trusts gebaseerd zijn op het authenticatie protocol NTLM maakt een forest trust gebruik van Kerberos. Volstrekt analoog aan de transitieve internal trusts tussen domeinen in een forest zorgt Kerberos ervoor dat ook een inter-forest trust transitief is. Selective Authentication is een schakelbare eigenschap van een forest trust die in feite zegt: “voordat je met een computer mag authenticeren heb je daarvoor expliciete permissie nodig”.  Kortom, standaard mag je nergens bij – precies het gedrag dat de klant zocht.

Tijdens het aanmaken van een forest trust door de wizard in Active Directory Domains & Trusts wordt je gevraagd of je Selective Authentication aan of uit wil hebben. Dit is overigens achteraf nog te wijzigen. Ik ga je hier niet vertellen hoe je een trust moet maken, maar ik laat je we zien hoe de properties van een forest trust eruit zien. In het volgende plaatje staat dat Selective Authentication aan staat. Het alternatief (Forest-wide authentication) is de default.

image

In dit voorbeeld heb  ik een domein genaamd sol.local, en een server s1.sol.local met daarop de share genaamd Tools. Vanuit het andere domein (dat even naamloos blijft, want het heeft de naam van een klant…) kan je die share NIET zomaar benaderen, ook al heeft Everyone leesrechten. De foutmelding van Explorer is nogal algemeen:

image

Echter, als je hetzelfde probeert met een command prompt krijg je een veel aardiger foutmelding:

image

“Logon Failure, […] protected by Authentication Firewall, […] not allowed to authenticate.”. Dat geeft precies aan wat er aan de hand is: je mag niet eens proberen te authenticeren. Overigens, de Authentication Firewall is de oude naam van Selective Authentication zoals die in de beta’s van Windows 2003 werd gebruikt. Marketing heeft toen op het laatste moment ingegrepen en de naam veranderd – maar dat is niet overal gelukt.

Om gebruikers uit het trusted domain door de voordeur te laten geef je ze het recht “Allowed to Authenticate” op het computer account in Active Directory Users & Computers. In dit geval heb ik de Domain Admins van het andere domein dit recht gegeven. Vanaf dat moment gelden de gebruikelijke NTFS en Share rechten.

image

Met precies hetzelfde commando heb je nu wel toegang:

image

 

 

 

 

 

Kort samengevat is dit het punt. Bij een gewone trust mag iedereen overal bij tenzij je het dichtzet. Met Selective Authentication op een forest trust zeg je het omgekeerde: je mag helemaal nergens bij tenzij ik je toestemming geef om een bepaalde computer te gebruiken. Juist deze eigenschap is nuttig in een beveiligde omgeving zoals een Extranet. Nadat ik mijn verhaal had gedaan en in een lab had laten zien hoe het werkt heeft de betreffende klant de forest trust met Selective Authentication opgenomen in het project.

Meer om te lezen:

ISA discovery via DNS – een weetje!

Vorige week was ik bij een klant die me vroeg om even te helpen bij het opzetten van WPAD records in DNS voor hun ISA 2006 server. Ze kwamen er niet helemaal uit. Ach, hoe moeilijk kan het zijn dacht ik, en ik schoof aan.

Het idee is simpel genoeg. Je laat ISA 2006 zijn gegeven publiceren op het interne netwerk, en je maakt in DNS een alias (CNAME) record aan met de naam “wpad”. Vervolgens zijn alle browser clients in staat de juiste gegevens op te vragen via de url http://wpad/wpad.dat, mits de client in het juiste domein staat. Immers, de DNS client zal de single name “wpad”  aanvullen tot wpad.domain.com, en dat aanbieden aan de DNS server. Dit geeft de alias terug met de juiste hostname (isa1.domain.com), die de client vervolgens opnieuw aan DNS vraagt om het IP adres te ontdekken.

Het netwerk van de klant is volledig gebseerd op Windows 2003, heet sol.local, en de ISA 2006 server is onderdeel van het domein onder de naam isa1.sol.local. Het alias wpad.sol.local was aangemaakt en wees naar de ISA server. Hun probleem was dat DNS het alias niet wilde teruggeven. Allerlei andere aliassen wel, maar wpad.sol.local bleef onbekend. Ik keek even of het alias correct was gespeld, en verwees naar de juiste FQDN hostnaam. Dat klopte:

image

Nou, dan blijft er maar een ding over: negative caching, het verschijnsel dat de DNS server en client onthouden wanneer een query niets oplevert en vervolgens niet verder zoeken als de vraag nog eens wordt gesteld. Dus ik deed lokaal de bekende ‘ipconfig /flushdns’ en maakte de cache van de DNS server leeg. Maar toen sloeg de verbijstering toe… :

image

Het was precies zoals de klant het zei: alles wordt geresolved, behalve wpad.sol.local. Ik heb nog DNS debug logging aangezet, gekeken met netmon 3, en nog allerlei andere dingen geprobeerd voordat ik besloot om mijn collega Dirk-Jan te gaan bellen. Hij is onze ISA expert. Hij moest diep graven in zijn geheugen, maar er kwam uiteindelijk iets boven.

Wat blijkt: er is een security issue met hosten van wpad records in DNS! Het is beschreven in ms09-008, en is daarmee behoorlijk recent. Het probleem is dat in een omgeving met dynamic DNS het mogelijk is om als eerste een wpad record aan te maken, en daarme clients naar een malafide proxy te laten wijzen. De bijbehorende security update kb968732 was inderdaad geinstalleerd op alle DNS servers van de klant. Wat doet de update? Hij implementeert een block-list voor DNS. Als een record op de block-list staat wordt het nooit teruggegeven. Voor bestaande situaties zal de update niets blokkeren. Als je nu al wpad records geconfigureerd hebt maar de update nog niet geinstalleerd hebt dan is er niets aan de hand. Maar bij een nieuwe implementatie loop je er tegenaan.

De block-list staat in de registry als een REG_MULTI_SZ value: HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList. De value is naar keuze te bewerken, en wordt actief na een herstart van de DNS service.

image

We hebben de waarde wpad verwijderd, DNS herstart, en alles begon weer “normaal” te werken:

image

Bovenstaand verhaal speelt zich af in een Windows 2003 wereld. Windows 2008 kent dezelfde feature, maar is het vanaf het begin ingebouwd. Hierbij is het ook niet nodig om de registry te editten, maar wordt de feature ondersteund via dnscmd zoals bijvoorbeeld beschreven op het ISA blog.

Posted door Willem Kasdorp | met no comments
Opgeslagen onder: , ,

Office Sharepoint Server 2007 Service Pack 2 bug zet licentie om naar triallicentie

In Service Pack 2 voor Office Sharepoint Server 2007 zit een bug die ervoor zorgt dat de expiration date van het product verkeerd wordt verwerkt in het register. Dit zorgt ervoor dat het product na 180 dagen grotendeels stopt met functioneren. Dit is niet terug te vinden in de eventlogs of ULS logs. De enige verwijzing is te vinden wanneer je kijkt naar Check Services Enabled on this Farm in de Operations sectie binnen Central Administration.

In deze lijst staat dan een melding welke zegt: The trial installation on server <servernaam> will expire on <datum>

Een workarround voor dit probleem is:

  1. Browse to Central Administration
    1. Click on the Windows Start Menu
    2. Click Administrative Tools
    3. Click SharePoint 3.0 Central Administration
  2. Click on the Operations tab
  3. Click on Convert License Type
  4. In the Enter the Product Key textbox, type in your product identification number and click okay.
  5. The License Synchronizer Job will execute on all machines in the farm after a few moments. Once all machines have updated their license from the timer job, the Convert License Type page will reflect the correct license.

Er is inmiddels een KB artikel beschikbaar: http://support.microsoft.com/default.aspx?scid=kb;en-us;971620&sd=rss&spid=11373

Posted door Mark Priem | met no comments

OpsMgr 2007 R2 RTM releases

Gisteren is zoals al op Microsoft’s Management Summit was aangekondigd System Center Operations Manager 2007 R2 (OpsMgr 2007 R2) gereleased.

OpsMgr 2007 R2 is Microsoft’s end-to-end service monitoring tool. OpsMgr 2007 R2 heeft de nodige verbeteringen en vernieuwingen t.o.v. OpsMgr 2007 SP1, te weten:

  • Cross platform monitoring
    • Geintegreerde monitoring van Windows, Linux en Unix servers
    • Integratie met System Center Virtual Machine Manager 2008
  • Service Level Tracking
    • Gedetailleerde rapportage van performance en beschikbaarheid
    • Service Level Monitoring d.m.v. Dashboard
  • Nieuwe monitoring templates
    • Monitoring templates voor process monitoring, OLEDB, Windows Services, etc.
  • Gebruiks verbeteringen
    • Browse MP Catalog vanuit Console
    • Verbeterde Notificatie configuratie
    • Overrides zichtbaar in Console
    • Health Explorer in Web Console
    • One-click maintenance mode
  • Performance verbeteringen
    • Console performance verbeteringen
    • Vergroting van de URL monitoring mogelijkheden
    • Support voor installatie op Microsoft SQL Server 2008

Hieronder zie je alle verschillen tussen MOM 2005, OpsMgr 2007 SP1 en OpsMgr 2007 R2:

Products

Microsoft Operations Manager 2005

System Center Operations Manager 2007 SP1

System Center Operations Manager 2007 R2

End-to-End Datacenter Service Management

 

 

 

Service Oriented Monitoring

 

Synthetic Transactions

Model-based architecture

 

Monitoring Templates

 

WS-Management support

 

SNMPv2 support

Service Level Reporting

 

 

Best of Breed for Windows and Beyond

 

 

 

Client Monitoring

 

Audit Collection

 

XML Management Packs

 

Reporting

Self-Tuning Thresholds

 

UNIX/Linux server and workload monitoring

 

 

Power Monitoring

 

 

Increased Efficiency and Control

 

 

 

Server roles

High availability

Monitoring Engine

Notifications

Connector Framework

Consolidated Console

 

Role-based security

 

Active Directory Integration

 

Windows PowerShell command console

 

Windows PowerShell hosting

 

 

Bulk URL Editor

 

 

Microsoft Office Visio Add-In

 

 

* Verbetering t.o.v. vorige versie

Op dit moment is de trial versie van OpsMgr 2007 R2 RTM (build 7221) beschikbaar op Microsoft Download Center. Algemene beschikbaarheid van OpsMgr 2007 R2 RTM zal plaatsvinden op 1 juli 2009, zodat nieuwe en bestaande klanten de software kunnen downloaden van o.a. MVLS.

Als je meer informatie over OpsMgr 2007 R2 wilt lees dan de overview whitepaper, What's New datasheet of ga naar Microsoft.com and Technet.

Forceer replicatie met Powershell

Een collega van me las de blog over het forceren van AD replicatie, en vroeg me waarom ik het niet in Powershell had geschreven. Immers, Powershell heeft de toekomst! Heel System Center maakt er gebruik van, Exchange 2007 ook en binnenkort heeft zelfs AD zijn eigen powershell provider in Windows 2008 R2.

Dat bleek minder moeilijk dan ik dacht, al ben ik absoluut geen expert in Powershell. Wel heb ik enige ervaring  met .NET. Omdat Powershell heel direct integreert met .NET is die ervaring wel handig. In de vorige post had ik een batch pipeline gemaakt om een lijst met DC’s te maken: "dsquery server -limit 0 | dsget server -dnsname | find "."". Al die calls naar externe processen kunnen we nu vervangen door code; zie de functie AllDCs.

Powershell ondersteunt ook ADSI voor directory services, maar ik geef de voorkeur aan .NET code in deze 21e eeuw. Op zich is de zoekroutine direct van het Powershell ScriptCenter op Technet. Ik zoek de objecten van type “server” in de Configuration Container. Dit zijn dezelfde die je ook kan zien in Active Directory Sites & Services. De complicatie is dat niet alle server objecten hier ook DC’s zijn. De DC’s hebben altijd een child object genaamd “CN=NTDS Settings”, dus daar check ik nog even op.  De manier waarop ik hier check verdient niet de schoonheidsprijs omdat ik voor ieder object een call doe… maar goed, voor een snel script is het goed genoeg.

 function AllDCs
{
    $objRootDSE = New-Object System.DirectoryServices.DirectoryEntry('LDAP://rootDSE')
    $objSites = New-Object System.DirectoryServices.DirectoryEntry('LDAP://CN=Sites,' + $objRootDSE.configurationNamingContext)

    $strFilter = "(&(objectCategory=Server)(dNSHostName=*))"
    $objSearcher = New-Object System.DirectoryServices.DirectorySearcher
    $objSearcher.SearchRoot = $objSites
    $objSearcher.PageSize = 1000
    $objSearcher.Filter = $strFilter
    $objSearcher.SearchScope = "Subtree"

    $colProplist = "dNSHostname", "distinguishedName"
    foreach ($i in $colPropList)
    {
        [void] $objSearcher.PropertiesToLoad.Add($i)
    }

    $colResults = $objSearcher.FindAll()

    foreach ($objResult in $colResults)
    {
        $objItem = $objResult.Properties
        $objNTDS = New-Object System.DirectoryServices.DirectoryEntry('LDAP://CN=NTDS Settings,' + $objItem.distinguishedname)
        if ($objNTDS.name -ne $null) {
            $objItem.dnshostname
        }
    }
}

$scriptname = $myInvocation.MyCommand.Name
$logfile = $scriptname -replace (".ps1$", ".log")
Remove-Item $logfile -ea SilentlyContinue

foreach ($dc in AllDCs)
{
    "==== Processing $dc"
    "==== Processing $dc" >> $logfile
    repadmin /kcc $dc >> $logfile
    repadmin /syncall /A /e $dc >> $logfile
    "" >> $logfile
}

"Please review the logfile for errors: $logfile"

Posted door Willem Kasdorp | met no comments
Meer posts Volgende pagina »