En wanneer je 2 dagen nog niet genoeg vind, dan zijn er op 27 en 30 september nog aanvullende workshops.

Meer informatie is te vinden op de website: http://www.devconnections.com/speurope/

Access is Denied to the User Profile DB

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General
Event ID: 7888
Date:
Time:
User: N/A
Computer:
Description:
A runtime exception was detected. Details follow.
Message: Access Denied! Only site admin can access Data Source object from user profile DB.

Techinal Details:
System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB.
at Microsoft.Office.Server.UserProfiles.SRPSite.AdminCheck(String message)
at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(IDataRecord rec)
at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(String strDSName)
at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site, Boolean fAllowEveryoneRead)
at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site)
at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.GetDataSource()
at Microsoft.Office.Server.UserProfiles.BDCConnector.RefreshConfiguration(String sspName)

Mocht je deze fout ooit tegenkomen, dan is de oplossing betrekkelijk eenvoudig. Je moet de “User Profile Import Account” toevoegen aan de groep voor local administrators op de SharePoint front-end. Mijn problemen zijn hiermee verholpen.

In SharePoint 2007 hebben veel gebruikers van SharePoint de Site Directory ingezet binnen de organisatie (waaronder ik). De site template van de Site Directory is echter in SharePoint 2010 niet meer out-of-the-box beschikbaar.

Middels het doorlopen van onderstaande stappen kan je de template weer beschikbaar maken:

1. Open de Windows Explorer
2. Ga naar “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\1033\XML\”
3. Open het bestand “webtempsps.xml”
4. Wijzig in dit bestand de Site Directory van Hidden=”True” naar Hidden=”False”
5. Sla je wijzigingen op en sluit het bestand
6. Open nu de CMD en navigeer naar “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Bin\”
7. Voor het volgende commando uit: stsadm.exe -o activatefeature -id 5F3B0127-2F1D-4cfd-8DD2-85AD1FB00BFC
8. Maak nu een nieuwe site of site collectie en je zult zien dat de Site Directory beschikbaar is

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

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.

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

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.

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.

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!