Today I had a SharePoint installation that started to throw errors when opening the User Profile Service Application. After examining the ULS log I noticed this log entry:
Requested registry access is not allowed.
So something with the permissions in the registry seemed to be wrong. I manually browsed through the registry settings and compared them to another, working installation but I couldn’t find anything. Luckily I stumbled across this cmdlet: Initialize-SPResourceSecurity I ran the cmdlet and everything started to work fine again.
Recently I had a SharePoint installation that stopped writing log files without any clear reason. Restarting the timer service or the whole server did not solve the problem. The only thing I noticed was this entry in the event viewer:
Tracing Service failed to create the trace log file at location specified in SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\WSS\LogDir. Error 0x0: The operation completed successfully. . Traces will be written to the following directory: C:\Users\SVCSPD~3\AppData\Local\Temp\.
Something seemed to be wrong with the log directory but the folder and its permissions looked totally normal. So I opened the Monitoring Settings (Central Admin -> Monitoring -> Configure diagnostic logging), change the path of the trace log to c:\temp and back to its normal location. As soon as I saved the second change, log files started appearing again.
During my last two SharePoint installations I came across the same issue. When setting up the user profile synchronisation every property but the profile picture is nicely imported. When checking the user profiles, the ProfilePictureTimestamp is correctly set and it looks like the data is correctly synced. After a while of research I came across this Update-SPProfilePhotoStore cmdlet. I was setting up a new SharePoint installation and the MSDN documentation states that the cmdlet is only necessary when migrating from 2007 to 2013. Nevertheless I gave it a try and executed:
Update-SPProfilePhotoStore –CreateThumbnailsForImportedPhotos 1 -MySiteHostLocation
After this, all profile picture are correctly set. I am not sure what causes this behaviour and if the cmdlet has any side-effects for the future but it is a short term workaround. Did anyone experienced similar issues?
From time to time, you need to add some credentials to the SharePoint secure store. Depending on the type of credentials you enter, you also need to provide the SecureStore Provider implementation. If you are simply using the default implementation, you also need to provide a value because SharePoint does not allow you to leave that field empty. Just enter the following value for the SecureStore default implementation:
Microsoft.Office.SecureStoreService.Server.SecureStoreProvider, Microsoft.Office.SecureStoreService, Version=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bce111e9429c
Having a build server to compile all checked in code is a very useful thing but preparing the build server for SharePoint 2013 projects requires a few steps (applicable for TFS 2010 and TFS 2012). In order to complete it, you need to have a SharePoint development machine to copy the assemblies from.
- Run the SharePoint Prerequisites Installer in order to install all dependency (like Windows Identity Foundation etc.)
- Open the GAC on the development machine (C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ ) and copy the following assemblies:
- Copy all SharePoint related assemblies from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI to C:\Program Files\Reference Assemblies\SharePoint\ on the build server
- Open the registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.5.50709\AssemblyFoldersEx and add the following key: SharePoint15]@=”C:\Program Files\Reference Assemblies\SharePoint\”
- Copy the folders SharePointTools,Web, WebApplications from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0 to the corresponding path on the build server
- Copy the file C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\XML\appManifest.xsd to the corresponding path on the build server (only necessary if you want to build SharePoint 2013 Apps)
Hint: This tutorial assumes that the TFS binaries are installed and the build server is already connected to a TFS. The required steps are listed here: http://msdn.microsoft.com/en-us/library/hh395023.aspx