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.
From time to time it happens that the wrong language is selected when creating a SharePoint site collection. According to Microsoft there is no supported way to change the language of an existing site collection. This is the case because the provisioning language impacts the names of the pre-created items such as document libraries. From a user perspective to most annoying problem is the wrong language of mail notifications.
If you only need to ensure the correct mail language there is an easy workaround. Open SQL Management Studio and execute this query on the respective content database.
Update [dbo].[AllWebs] set Language = [LCID]
This will change the language on all site collections but you can add where-statements to update only the necessary entries. The LCID is the language code used by Microsoft (and SharePoint).
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=126.96.36.199, 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
Today I was working on some data integration issues and was creating a BDC model. So as always, I created the model, added a finder method and modeled my entity. Then I deployed the solution and tried to creating an external list to test my finder method. So far so good, but when opening the External Content Type Picker the following error appeared: External Content Types are not available. Contact your system administrator.
What is that? Did my deployment fail? I opened the BCS service application to check if the model was correctly deployed. But it was there. My next idea was that something with the permissions was wrong, but everything was as usual.
So, what could be wrong? After a few minutes of staring onto the BDC model, I discovered it. My model was simply missing the specific finder method. After adding it, the external content type appeared in the picker. So, lesson learned for today: always add finder and specific finder method before deploying the model.
Recently I was trying to deploy a BDC model to a SharePoint 2013 Farm. Creating the model was quite straight forward as known from the previous version. Then I hit Deploy and the deployment started. But suddenly this error appeared:
This solution for this problem was so easy that it took a few minutes until I figured out what the problem was. The Feature.Template.xml file was not correctly prepared. I simply added
<Property Key='SiteUrl' Value='http://portal/' />
And that was it. The installation went without problems. For sure you have to replace ‘http://sharepoint’ with the url of your SharePoint.
Recently I was experimenting with SharePoint 2013 Apps and different deploy possibilities. I made a few changes on the linked projects, changed some project and solution settings and out of a sudden the debugger did not work for my web project. No matter what I did, it just ignored the breakpoints and even exception did pop up in the Visual Studio. After searching a while I found the solution and it was so incredibly easy. When debugging SharePoint 2013 Apps both, the app and the web project, have to be set as start-up project. The solution property page should look like this: