Today I stumbled upon Yet Another SharePoint Problem (YASP) with a custom timer job. The custom timer job is supposed to synchronize some user information between site collections (on a WSS 3.0 installation). In some cases the timer job has to add users to site collections. Sounds like a no-brainer, right!
The problem is that we are using this installation as an internet facing site and the external users are stored in AD LDS (Active Directory Lightweight Directory Services, formerly known as ADAM) and our own custom authentication provider.
When the timer job was running it found users in one site collection and could not add them to the other site collections, using EnsureUser(). It just threw an exception and stated that it could not locate the user.
We made sure we had the right privileges, that the timer service was running under correct account etc. Finally we hooked up the debugger and set some breakpoints in our custom authentication provider to see where it failed when it tried to resolve the users. But the Visual Studio debugger never loaded our provider assembly!
Then it struck me; how would the OWSTimer.exe know what assembly our custom authentication provider is located in, in Central Administration you only specify the name/prefix of the forms authentication provider. The definition for the custom authentication provider is only specified in the web.config of our web application.
So we added a configuration file to the OWSTimer.exe, called OWSTimer.exe.config and specified the authentication provider, see below. Then after a restart of the service, everything worked like a charm.
<?xml version="1.0" encoding="utf-8" ?><configuration> <system.web> <membership defaultProvider="TODO"> <providers> <!-- Add providers here --> </providers> </membership> </system.web></configuration>
Everyday with SharePoint gives you new obstacles…