Gebruikers die in SharePoint 2010 een foutmelding of waarschuwing krijgen, zien een scherm dat er ongeveer uit ziet zoals hieronder. In basis niet heel speciaal lijkt het, maar dit scherm is krachtiger dan je denkt.
Op basis van het Correlation ID dat genoemd wordt in de foutmelding kan een beheerder zoeken in de trace log van SharePoint en het ID terugleiden naar de daadwerkelijke foutmelding. Het is dus belangrijk om de gebruikers te instruceren het Correlation ID te noteren/melden bij problemen.
In een korte demo over het gebruik van de Correlation ID heb ik gezien dat het betrekkelijk eenvoudig is om dit ID terug te leiden naar een foutmelding en een stack id. Deze informatie kan je dan in, bijvoorbeeld, Google zetten om online naar de oplossing te zoeken.
Het heeft overigens geen zin om het Correlation ID zelf in Google te gooien, want het zijn unieke nummers, welke indien ze ergens op de wereld overeenkomen niet eens op hetzelfde betrekking hoeven te hebben.
Ook is het mogelijk om middels Powershell deze foutmeldingen terug te zoeken. Onder de 500 verschillende Powershell commando’s voor SharePoint 2010 zijn er 8 specifiek voor logging en diagnostics. Ik ga ze niet allemaal hier bespreken, maar het zijn de volgende:
- Get-SPDiagnosticConfig
- Set-SPDiagnosticConfig
- Get-SPLogLevel
- Set-SPLogLevel
- Clear-SPLogLevel
- New-SPLogFile
- Merge-SPLogFile
- GetSPLogEvent
SharePoint log bestanden in de 14 hive kunnen snel groeien. Om te voorkomen dat dit ongecontroleerd gebeurd is er een functionaliteit toegevoegd aan SharePoint dit de grootte beperkt: Event Log Flood Protection.
Middels een simpele aan/uit setting in de Central Administration kan je regelen dat de logging event die vaker dan 5 keer in 120 seconden voorkomt niet meer registreert.
De default settings van de Event Log Flood Protection zijn opgenomen in onderstaand overzicht. Deze standaard instellingen zijn middels Powershell aan te passing naar eigen inzicht
Behalve de event log flood protection is er nog een tweede optie om de groei van de log te beperken. Er is namelijk een settings om de grootte van de trace log te limiteren op bijvoorbeeld 1 GB. Let hiermee wel even op: in tegenstelling tot veel settings die je moet doen in MB’s, dient deze opgegeven te worden in GB’s! M.i. is 1 of 5 wel genoeg een farm met een paar honderd gebruikers.
Verder zijn er verbeteringen aangebracht in de log, zodat ‘onzinnige’ of overbodige logs niet meer worden opgeslagen.
In de logging database van SharePoint 2010 wordt zowat alles opgeslagen dat gebeurd op de SharePoint farm. In ieder geval informatie van de volgende onderdelen wordt gelogd:
- Page requests
- Web part renders
- Performance counters
- SQL blocking queries / SQL IO/CPU intensieve queries
- Search crawl en query statistieken
- Usage: page requests, timer jobs, features usage, …
Er is wel één probleem met deze database: hij gaat heel erg hard groeien! Aangezien er heel veel informatie wordt opgeslagen, betekent dit dat iedere extra gebruiker op de SharePoint farm wel een aantal entries per dag zal veroorzaken.
Microsoft raadt nu al aan om deze logging database goed in de gaten te houden en zelfs om een aparte partitie of schijf hiervoor te hanteren. Dit nadeel weegt alleen niet op tegen het voordeel dat alle informatie van de diverse WFE’s wordt opgeslagen in deze ene database.
Op het gebied van Health Monitoring is het toverwoord in SharePoint 2010: Pro Actief!
SharePoint 2007 reageerde vooral reactief op fouten en problemen. Er moest namelijk eerst iets gebeuren alvorens SharePoint 2007 hier een melding van gaf.
SharePoint 2010 probeert dit voor te zijn en al meldingen te geven als iets ‘verdachts’ gebeurd, maar dat het nog niet daadwerkelijk een probleem is. Het is nog niet zo gek dat SharePoint in deze versie al zelf actie gaat nemen op fouten, maar misschien zien we dat gebeuren in de volgende versie…
Wat is er nieuw in SharePoint 2010 op dit gebied?
- De log files zijn 50% kleiner middels Event Log Flood Protection
- NTFS compressie op de log files
- Logging database van events in de farm
- Nieuwe web analytics feature
In een aantal volgende posts ga ik verder in op dit onderdeel.
Bij een nette installatie van SharePoint maak je gebruik van diverse service accounts voor o.a. search en application pools. In het ideaal plaatje zijn al deze wachtwoorden verschillend en wijzigen ze om de twee maanden. Echter in de praktijk blijkt één wachtwoord dat nooit verloopt toch handiger…
In SharePoint 2010 zit hiervoor een nieuwe feature: Managed Accounts. Deze feature zorgt ervoor dat het wachtwoord van de service accounts elke x tijd wijzigt. De Farm Administrator hoeft hier helemaal niets meer aan te doen.
SharePoint regelt dat het wachtwoord in de Active Directory wordt aangepast en dat de service verder draait met de nieuwe password gegevens.
Dit geheel is een samenwerking tussen Active Directory en SharePoint en houdt volgens mij rekening met alles: wijzigen x dagen voor verlopen, format regels, email notificatie, change schedule. Ook deze functionaliteit werkt middels ene timerjob.
SharePoint beveiliging is weer zo’n onderwerp waar je alleen al een hele blog mee kunt volschrijven. Ook op dit gebied veel nieuws te melden, mede door vernieuwingen in de architectuur zoals eerder genoemd bij voorbeeld de posts over Service Applications.
Enkele wijzigingen…
Delegeren van taken
De eerste vernieuwing die ik ben tegengekomen zit in de Central Administration (CA) van SharePoint 2010. Het is nu mogelijk om acties te delegeren binnen de CA. Het is bijvoorbeeld mogelijk om het beheer van Service Applications of zelf een specifiek deel van een Service te laten doen door iemand anders dan de farm admin. Hierdoor hoeft de SharePoint Farm Administrator niet altijd zelf actie te ondernemen.
Lockdown Mode voor Publishing Sites
In SharePoint 2007 heeft iedereen wel eens zitten worstelen met de Lockdown Mode als het gaat om een internet-facing site. De problemen en frustraties met deze feature blijven in SharePoint 2010 ongewijzigd
Beveiliging verbetert voor aanpassen site
In SharePoint 2007 kon iedereen met Contribute rechten een site aanpassen (o.a. webparts wijzigen). In SharePoint 2010 is dit niet meer mogelijk op het contribute niveau, maar zijn hier designer of admin rechten voor nodig.
Explorer view = weg
De explorer view bestaat niet meer in SharePoint 2010. In SharePoint 2007 werd de explorer view geopened in Internet Explorer (ondersteund door WebDav). In SharePoint 2010 maken we echt gebruik van de Windows Explorer!
“Business Continuity Management” een hele mooie kreet voor een best belangrijk onderwerp als we het over ICT hebben. Ook in de release van SharePoint 2010 zijn hierop weer de nodige verbeteringen aangebracht.
Aangezien ik niet heel actief ben op dit specifieke terrein noem ik slechts de hoofdpunten die mij zijn bijgebleven:
- Verbeterde logica om sites te verwijderen, zodat dit niet ten kostte gaat van de performance
- Backups kunnen teruggezet worden vanuit de Central Admin, waar voorheen STSADM nodig was
- “Unattached Content Database Restore”
- Snapshot support voor backups
- Read-only content databases
Twee van de bovengenoemde punten heb ik iets verder beschreven:
Verwijderen van sites
Microsoft heeft geprobeerd om de issues op het gebied van sites verwijderen te verminderen. Vooral bij grote sites, kon verwijderen nog al een aanslag zijn op de performance. Hier is aan gewerkt.
Sites worden nu niet meer direct verwijderd, maar uit de sitemap en navigatie weggehaald. Op de achtergrond staat vervolgens een timerjob gereed welke (by default) één keer per dag de sites echt verwijderd. De timerjob hiervoor is: Gradual Site Delete.
Unattached Content Database Restore
In SharePoint 2010 is het mogelijk om een SQL backup via de Central Admin van SharePoint te koppelen. Vervolgens kan je direct door de backup heen browsen om content te restoren. Zo is het mogelijk om content, site collecties, sites en lijsten op deze manier terug te halen.
Een hele verbetering met SharePoint 2007, want dan moest je altijd prullen met een backup welke teruggelezen diende te worden in een testomgeving om bij je verwijderde content te komen.
Restoren vanuit een Unattached Database kan middels Powershell (wat in SharePoint 2010 overigens het toverwoord is voor heel veel dingen):
- Restore-SPSite voor een sitecollection
Restore-SPSite -identity http://server/sites/site -path \\filelocation\site.back /force
- Import-SPWeb voor een site of list
Import-SPWeb -identity http://server/sites/site/web -path \\filelocation\list1.cmp -includeusersecurity
“Veel meer databases om te beheren” is iets dat ik in een eerdere post op mijn blog heb geschreven over SharePoint 2010. Voor de SharePoint beheerders is dit helaas waar. Aan de andere kant is er natuurlijk ook een betere spreiding van de data en kan je de performance beter monitoren.
De volgende Service Applications hebben in ieder geval een eigen database:
- Managed Metadata
- Secure Store
- State Service
- Business Data Catalog
- Web Analytics
- Word Conversion
- Usage and Health Data Collection (2 databases)
- Search service (2/3 to many databases)
- People service (3 databases)
Service Applications kunnen op meerdere manieren worden uitgerold. Wanneer je voorafgaand aan de installatie een goed design document hebt gemaakt, kan je tijdens het uitvoeren van de Farm Config Wizard al e.e.a. installeren. De andere optie is het achteraf configureren via de Central Admin of PowelShell commando´s.
Daarna ga je de Service Application koppelen aan een of meerdere Web Applicaties. Hiervoor ga je automatisch gebruik maken van Service Application Proxies of Proxy Groups. Het aanmaken van een nieuwe Service Application zorgt namelijk automatisch voor het aanmaken van een Service Application Proxy. Deze proxy gebruik je vervolgens om een link te maken tussen de Service Application en de Web Applicatie(s) die er gebruik van mogen maken.
Om het qua beheer eenvoudiger te maken, is het ook mogelijk om meerdere SA Proxies samen te voegen in een Proxy Group. Deze Proxy Group kan je vervolgens weer koppelen aan één of meerdere Web Applications.
Service Applications kunnen middels de bijbehorende proxies ook gekoppeld worden aan andere SharePoint 2010 farms. Zo kunnen meerdere SharePoint farms bijvoorbeeld gebruik maken van één centrale Metadata Service.
Het stuk van de proxies is m.i. niet lastig te leren, want na een eerste demo heb ik de grote lijnen voor mijn gevoel begrepen, maar na het lezen van bovenstaande tekst kan ik absoluut begrijpen dat er nog vraagtekens zijn rondom dit onderwerp. Als ik een betere uitleg vind zal ik deze later toevoegen op de blog.
Voor het eerst in jaren werken met SharePoint 2007 lukte het me niet op gebruikers uit de Active Directory toegang te verlenen tot SharePoint. Zo moeilijk is het toch echt niet: naar de juiste site gaan, gebruiker opzoeken/toevoegen, rechtenniveau aangeven en bevestigen.
Effect op deze SharePoint farm was dat ik alleen eerder toegevoegde AD gebruikers kon toevoegen aan SharePoint, maar nieuwe waren onvindbaar.
Na wat onderzoek op de SharePoint Server kwam ik onderstaande melding tegen in de eventlog van de server:
The SSP Timer Job Distribution List Import Job was not run.
Reason: The trust relationship between this workstation and the primary domain failed.
Technical Support Details:
System.SystemException: The trust relationship between this workstation and the primary domain failed.
at System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection sourceAccounts, Boolean& someFailed)
at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
at System.Security.Principal.NTAccount.Translate(Type targetType)
at Microsoft.Office.Server.Administration.JobHandler.Execute(Object state, Boolean timedOut)
De boodschap zit met name in het eerste deel van de melding: “The trust relationship between this workstation and the primary domain failed”
Om één of andere reden is de SharePoint Server dus de verbinding kwijt geraakt met de AD en het domein. Reboot van de SharePoint Server was niet de oplossing, dus hoe nu verder…?
In mijn geval was de oplossing als volgt:
- Haal de SharePoint Server uit het domein (plaats deze in een werkgroep)
- Herstart de server, zodat de nieuwe instellingen actief worden
- Meld de SharePoint Server opnieuw aan in het domein
- Nu kan je de gebruikers weer gewoon toevoegen
