Include or Exclude Users from SharePoint Profile Import

During a (default) import of user profiles (from Active Directory (AD)) inside SharePoint (MOSS) you will notice a bunch of user profiles you are not interested in (like system_mailbox, some dummy users as well as disabled accounts).
I was wondering if it would be possible to exclude these AD user profiles during the profile import in SharePoint. After a little search, I found the solution to obtain this.

You need to go to your SharedServiceProvider (from within the Central Administration). Navigate to 'User Profile and Properties' > 'Manage Connections'.
Here you will find the field called 'User filter'. The content will look like this (which is default):

(&(objectCategory=Person)(objectClass=User))

Between '(&' and the last ')' (let's say the filter placeholder) you can add fields you want to filter on. Add the following string just after the last fieldfilter to exclude those user accounts that are disabled in AD:

(!userAccountControl:1.2.840.113556.1.4.803:=2)

So the entire string will be like this:

(&(objectCategory=Person)(objectClass=User)(!userAccountControl:1.2.840.113556.1.4.803:=2))

If you also want to include only those user accounts where (e.g.) the company name is filled in, you need to include (company=*). In reverse, if you want to exclude those that have a company name, just place a exclamation mark right for company: (!company=*). The 'include' version will then look like this:

(&(objectCategory=Person)(objectClass=User)(company=*)(!userAccountControl:1.2.840.113556.1.4.803:=2))

An easy way to figure out to create your own filtersyntax (like company start with 'bla'), you can build easily a query inside AD which will show you the correct syntax.

Read more...

Is SharePoint a PITA?

Sometimes SharePoint drives me crazy. But not only me. Google, our big friend shows the following results on some search terms:

• moss 2007 problem: about 53.400.000
• moss 2007 errors: about 8.160.000
• moss 2007 bug: about 28.000.000
• moss 2007 failed: about 4.560.000
• moss 2007 failure: about 8.420.000
• moss 2007 not working: about 23.300.000
  
  
• sharepoint problem: about 8.270.000
• sharepoint error: about 3.380.000
• sharepoint bug: about 1.920.000
• sharepoint failed: about 892.000
• sharepoint failure: about 1.240.000
• sharepoint not working: about 16.300.000
  
  
• wss 3.0 problem: about 334.000
• wss 3.0 errors: about 237.000
• wss 3.0 bug: about 78.500
• wss 3.0 failed: about 90.500
• wss 3.0 failure: about 855.000
• wss 3.0 not working: about 289.000
  

Do these numbers say something? I don't know. Is SharePoint a PITA? Well sometimes it definitely is!

Read more...

A Solution for: SharePoint 2007 Workflow 'Failed on start'

The Problem:
I struggled some time to get my out-of-the-box (OOB) workflow working on a MOSS 2007 environment (Win2K3 64-bit). I got always the error 'Failed on Start'. The log file on the 12-hive shows two records like this:

w3wp.exe (0x0AF4)  0x0724  Windows SharePoint Services  Workflow Infrastructure  72fs  Unexpected  RunWorkflow: System.ArgumentException: Value does not fall within the expected range.     at Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties..ctor(SPWorkflow workflow, Int32 runAsUserId, String associationData, String initiationData)     at Microsoft.SharePoint.Workflow.SPWinOEWSSService.MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)     at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(Guid trackingId, SPWorkflowHostService host, SPWorkflow workflow, Collection`1 events, TimeSpan timeOut)     at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow originalWorkflow, SPWorkflow workflow, Collection`1 events, SPRunWorkflowOptions runOptions)

w3wp.exe (0x0AF4)  0x0724  Windows SharePoint Services  Workflow Infrastructure  98d7  Unexpected  System.ArgumentException: Value does not fall within the expected range.     at Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties..ctor(SPWorkflow workflow, Int32 runAsUserId, String associationData, String initiationData)     at Microsoft.SharePoint.Workflow.SPWinOEWSSService.MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)     at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(Guid trackingId, SPWorkflowHostService host, SPWorkflow workflow, Collection`1 events, TimeSpan timeOut)     at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow originalWorkflow, SPWorkflow workflow, Collection`1 events, SPRunWorkflowOptions runOptions)

The Solution:
I search a lot, but didn't find a working solution. Finally I found it. It turns out that I had changed the account for the SharePoint - 80 application pool (don't remember why, but I did). But, I did this on IIS 7 and not using the Central Administration (CA).
Well, this was a wrong action. Changing the account of one of the SharePoint application pools must be done using the Central Administration (Serviceaccounts on the 'operations' page inside the CA).
And again, a big SharePoint miracle occured: the workflows started to work!

Read more...

Work around ServerContext en UserProfile troubles

I struggled some time with working with the UserProfile and ServerContext inside SharePoint (MOSS 2007).
I wrote a web part to show more details of a sitecontact. For that, I needed to get details from the UserProfile. The UserProfile was obtained from the UserProfileManager.
The code (web part) was running fine on the SharePoint server itself, but it failed on a client machine.
After struggling a lot, trying different suggestions (like fake SPContext and so on) today I found the solution. You need to use the SPSecurity.RunWithElevatedPrivileges method. RunWithElevatedPrivileges runs the code in the brackets under the SharePoint System Account.
So here is the piece of code I am using:

try
{
  SPSecurity.RunWithElevatedPrivileges(delegate()
  {
    using (SPSite site = new SPSite(SPContext.Current.Site.ID))
    {
      ServerContext context = ServerContext.GetContext(site);
      HttpContext currentContext = HttpContext.Current;
      HttpContext.Current = null;

      UserProfileManager profileManager = 
        new UserProfileManager(context);

      UserProfile user = 
        profileManager.GetUserProfile("domain\\accountname");

      PropertyCollection propCollection =
        user.ProfileManager.Properties;

      if (user != null && propCollection != null)
      {
        \\ do your stuff with the 'user'
      }
      HttpContext.Current = currentContext;
    }
  });
}
catch (Exception)
{
  \\ handle the exception
}

I used this code for retrieving userprofile details. I didn't try to edit the user profile. But I assume it should work as well.

Read more...

Deployment of a class library with WSPBuilder

This topic contains some points about deployment class library with WSPBuilder. For a couple of weeks I am working with WSPBuilder (http://www.codeplex.com/wspbuilder) for creating SharePoint web parts.
Due to the lack of some functionality, I wrote a class library which contains some extension methods for the SPWeb object. At that time the problems began.
Situation:

• VMWare machine with MOSS 2007 on a Win2003 machine for development and test purposes
• Visual Studio 2008 with WSPBuilder extension
• Solution with several WSPBuilder web part projects
• Custom class library SPExtensions.dll
  

Three of the WSPBuilder projects in my solution are using this class library with the extension methods in it. That works fine, until you are going to deploy it.
The deployment of the first WSPBuilder project deployed the class library into the GAC. This will affect the build process of the other two WSPBuilder projects. Those two wsp-packages do not have the class library dll in it. This happens even the referenced dll property "copy local" is set to "true". This was/is a real PITA! Because after updating the SPExtensions project, the new dll was not updated in the GAC for the 2nd and 3rd project (because the dll is not included in the wsp file).
So I want the SPExtentions.dll deployed to the WebApplication bin and not in the GAC. After some search and trial and errors I found the solution to get this job done.

1. Make sure the SPExtensions.dll (or whatever your class library is called) is not present in the GAC anymore. You can use gacutil to uninstall the assembly.
2. Created a '80' folder with a 'bin' subfolder inside all of the projects (e.g. ..\ProjectFolder\80\bin) that uses the SPExtensions.dll.
3. Create for each of these project a post build event:
   move /Y "$(TargetDir)SPExtensions.dll" "$(ProjectDir)80\bin"
   NOTE: You should use the "move" command and not the xcopy. The WSPBuilder (by default) sets the DeploymentTarget of the assemblies found in folders, other than GAC and 80\bin to GlobalAssemblyCache. So make sure you move the SPExtensions.dll from the ProjectFolder\bin\release (or debug) to the 80\bin folder created in step 2.
4. Now you can build the project, create the wsp-files and deploy (or upgrade) them. After step 3, I used the "clean" option, just to be sure that I do not get messed up with some left crap.

Read more...