Recently I worked on an interesting case during one that was blocking deployment of one of the SharePoint 2013 projects I was working for.
Basically what happened was that although deployment of SharePoint went well, some of the Service Applications like Managed Metadata, User Profile Service, Business Connectivity Services, and Search did not work properly. The symptoms varies, but a common error message in the ULS logs stated:

02/27/2013 09:58:52.07 w3wp.exe (0x1910) 0x2428 SharePoint Server Taxonomy ca42 Medium Exception returned from back end service. System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]:
AccessDeniedEx:The current user has insufficient permissions to perform this operation. (FaultDetail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.UnauthorizedAccessException: AccessDenied Ex:The current user has insufficient permissions to perform this operation. at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplication.GetServiceSettings(GuidrawPartitionId) at SyncInvokeGetServiceSettings(Object , Object[] , Object[] ) at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.In... 5510ed21-c1ef- 4b6f-8305-33afc4200a76

Also after doing some WCF tracing I found that there was an interesting claim in the SAML token (as part of Service Application authentication; Remember... Everything in the Service app world is claims):
<saml:Attribute AttributeName="isauthenticated" AttributeNamespace="http://sharepoint.microsoft.com/claims/2009/08" a:OriginalIssuer="SecurityTokenService" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims">
<saml:AttributeValue>False</saml:AttributeValue>

Clearly there is something fishy going on here J.

After working on this for most part of a week, even with help of my colleagues at Premier Support, we were not able to nail this one down. Fortunately someone at the customer remembered running into similar issues with a SharePoint 2010 project they did years back.
The solution for that problem was to set the advanced Anonymous Authentication settings of the IIS root node to IUSR:

http://technet.microsoft.com/en-us/library/cc770966(v=WS.10).aspx

Using a default Windows deployment will not require you to do this, but this customer in particular followed a "customize if possible" strategy for their Windows build images, and changing this setting (among many others) to a non-default setting of "Application Pool identity".

I have tried to find out why this breaks SharePoint functionality so severely, but was unable to. (If you know, please post to the comments!).

Fortunately we were able to move forward with the project. I hope I can help at least one of you peeps out there, by posting this!

SharePoint experts must love to hurt themselves. How else do we go through the pain of configuring Kerberos or getting User Profile Service to work.
Oh yeah don't forget the endless variations in Service Application configuration. There is a different way of doing things for every freakin' one of them.

Off course every one of us has their own bag of tricks scripts to help out. And for the sorry souls out there that don't …. Well …
At least now getting Kerberos to work can get a lot easier if you use the recently released Kerberos configuration tool for SQL Server.

It is a simple tool that connects to a server containing SQL compontents (for example: DB engine, analysis services, and reporting services), and checks AD if the appropriate SPNs are set.
It also lets you generate the scripts to configure them if they are not. Pretty neat huh?

Obviously this is not the entire story when it comes to configuring Kerberos for various scenarios within SharePoint, but it does does hurt a whole lot less if you use tools like these.

For more information on the tool, go to http://blogs.msdn.com/b/analysisservices/archive/2013/05/23/released-kerberos-configuration-manager-for-sql-server.aspx

For more information on configuring Kerberos for SharePoint, go to http://technet.microsoft.com/en-us/library/ee806870.aspx

Last week I was tasked with creating some backup/restore scripts for SharePoint. The backup scripts kept erroring out with the following issue:

Backup for 'Search Service 1(099045f6-a648-48f1-9a05-a9371c5d9b88)' failed. System.ServiceModel.FaultException: Management called failed with System.InvalidOperationException: 'Job failed: Have tried to perform backup/restore operation twice on all in-sync members in cluster SP569693711984.1, but none succeeded. Last failure message: Microsoft.Ceres.SearchCore.Seeding.SnapshotTransferException: Could not send chunk ms\%default\gen.000000000000024c.state: Localpath: [0-338> to target BackupDirectoryTarget[directory=\\servername\Backup$\spbr000D\I.2.1,validateTransfers=False]   

 at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.SendChunks(ISnapshot snapshot, ISeedSource source, ISeedTarget target, SeedStatus status, Func`1 checkAborted, Int32 targetFragIndex)   

 at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.FirstPhaseTransfer(ISeedSource source, ISeedTarget target, Action`1 updateProgress, Func`1 shouldAbort)   

 at Microsoft.Ceres.SearchCore.Seeding.BackupWorker.BackupWork.DoFirstPhaseWork()'

at  

 at Microsoft.Ceres.SearchCore.IndexController.BackupService.ThrowOnFailure(JobStatus status)   

 at Microsoft.Ceres.SearchCore.IndexController.BackupService.ProgressSecondPhase(String handle)   

 at Microsoft.Ceres.SearchCore.IndexController.IndexControllerManagementAgent.WrapCall[T](Func`2 original)    Server stack trace:    

 at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)   

 at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)   

 at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)   

 at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)    Exception rethrown

at [0]:    

 at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)   

 at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)   

 at Microsoft.Ceres.SearchCore.Admin.IIndexControllerManagementAgent.ProgressSecondPhase(String handle)   

 at Microsoft.Office.Server.Search.Administration.BRIndexComponent.RetryWhileNoEndPoint[T](Func`2 action, SPBackupRestoreInformation args, Guid ssaId, TimeSpan retryTimeout)   

 at Microsoft.Office.Server.Search.Administration.BRIndexComponent.RetryWhileNoEndPoint[T](Func`2 action, SPBackupRestoreInformation args, Guid ssaId, TimeSpan retryTimeout)   

 at Microsoft.Office.Server.Search.Administration.BRIndexComponent.<>c__DisplayClass13`1.<RetryWhileNoEndPoint>b__12()   

 at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass5.<RunWithElevatedPrivileges>b__3()   

 at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)   

 at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)   

 at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)    

 at Microsoft.Office.Server.Search.Administration.BRIndexComponent.RetryWhileNoEndPoint[T](Func`2 action, SPBackupRestoreInformation args, Guid ssaId)   

 at Microsoft.Office.Server.Search.Administration.BRIndexComponent.WaitPhaseComplete(SPBackupInformation args, Func`2 getProgress, Int32 sleepTime)   

 at Microsoft.Office.Server.Search.Administration.BRIndexComponent.WaitSecondPhaseBackupComplete(SPBackupInformation args)   

 at Microsoft.Office.Server.Search.Administration.TwoPhaseBackupHelper.WaitSecondPhaseBackupCompleteChildren(SPBackupInformation args)   

 at Microsoft.Office.Server.Search.Administration.SearchServiceApplication.OnBackup(SPBackupInformation args)

After trying dozens of things, in the end the solution to this issue is to run the script from a server that has a running Search service instance. The script will not work on servers that do not have search configured.

I'm running SharePoint 2013 RTM.