mylifeinaminute.com

System.Security.SecurityException: There are currently no logon servers available to service the logon request with a KerbS4ULogon exception? Kerberos strikes again.

The Error

UserProfileApplication.SynchronizeMIIS: Failed to configure ILM, will attempt during next rerun. Exception: System.Security.SecurityException: There are currently no logon servers available to service the logon request.
at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn)
at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type)
at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName)
at Microsoft.IdentityManagement.SetupUtils.IlmWSSetup.GetDomainAccountSIDHexString(String domainName, String accountName)
at Microsoft.IdentityManagement.SetupUtils.IlmWSSetup.GrantSQLRightsToServiceAccount()
at Microsoft.IdentityManagement.SetupUtils.IlmWSSetup.IlmBuildDatabase()
at Microsoft.Office.Server.UserProfiles.Synchronization.ILMPostSetupConfiguration.ConfigureIlmWebService(Boolean existingDatabase)
at Microsoft.Office.Server.Administration.UserProfileApplication.SetupSynchronizationService(ProfileSynchronizationServiceInstance profileSyncInstance) The Zone of the assembly that failed was: MyComputer.

Root Cause

A security feature introduced in Windows Server 2003 prevents the KDC from distributing a service ticket (TGS) for an account that does not have a Service Principle Name (SPN) defined. As the SPTimerV4 account is unable to obtain a valid service ticket, the above exception is thrown. At the end of the day, without properly set SPNs, Kerberos authentication is not possible.

The Fix

As stated on Yvan Duhamel’s blog, setting a temporary SPN on the account running the SPTimerV4 (OWSTIMER) service will allow you to start the service.

setspn –a NONE/NONE OWSTimerAccount

The SPN can be removed after the service is provisioned and the FIM services will continue to start properly after restarts. However, if the User Profile Synchronization Service ever needs to be restarted through Central Administration, the SPN will need to be in place. That being said, it is most likely best to keep the SPN on the account.

Reference

• You get a System.Security.SecurityException when you try to start the User Profile Synchronization Service
• How the Kerberos Version 5 Authentication Protocol Works

More fun SharePoint errors in the system log. If you’re seeing 10016/17 errors in the Event Log and want to resolve them, perform the steps outlined in KB920783.

Note that these errors are more of a nuisance than anything. The existence of these errors is expected and will not impact the functionality of your farm. That being said, less errors being generated is a “good thing” in my mind.

Ah yes, the people picker again. I recently inherited an environment where the previous administrator was kind enough to not document anything, especially the items he/she had been playing with in development.

When trying to designate a user as a Primary Site Collection Administrator in Central Administration, I was unable to query for subsets of domain users on a single web application. After checking all of the usual suspects (Peoplepicker-searchadforests I’m looking at you) with no success, it was off to the not-so-usual suspects.

It turns out the previous admin was kind enough to set the Peoplepicker-searchadcustomfilter property on the main portal site collection. After setting the property to null

stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "" -url [URL]

all was once again right with the world.

Now where did I leave my sledgehammer?

When upgrading from a standard SKU to an Enterprise SKU in SharePoint (MOSS 2007), things can (and do) go wrong. Come to think of it, I’ve never seen one complete successfully without some type of manual intervention. Fortunately, the majority of errors that are experienced are recoverable. Take for instance:

An existing request to enable the Enterprise feature is in progress. To check the status of this request, go to the Timer Job Status page in Central Administration Operations and check the status of the Office Server Enterprise Features Upgrade Job.

When you find the job in the Timer Job Status page, you will see that it needs to run on all servers in your farm. Chances are it has failed on one (or more) servers. The quick fix? Restart (or start if stopped) the Windows SharePoint Services Timer service on the server where the upgrade job failed. After the job has completed, return to Central Administration to verify that your farm has been upgraded.