Active Directory Synchronization with WSS and MOSS

In a Microsoft Office SharePoint Server 2007 deployment, a person defined in Windows SharePoint Services 3.0 and a person defined in Office SharePoint Server 2007 are the same. To deliver consistent objects across the deployment in both Windows SharePoint Services 3.0 and Office SharePoint Server 2007, both implement person synchronization.

Person synchronization is bidirectional. In the up direction, the Windows SharePoint Services site collection membership list is pulled into the Office SharePoint Server 2007 user profile database to inform Office SharePoint Server 2007 about which users are a member of which sites and allow incremental synchronization. In the down direction, the Office SharePoint Server 2007 user profile database sends down replicable user profile information for all members in the site collection.

Synchronization actions are either full or incremental. On first synchronization or restore, Office SharePoint Server 2007 may not have previous synchronization or site collection membership information, so a full synchronization takes place. If previous synchronization information is found, an incremental synchronization is performed instead.

If a user is removed from the Windows SharePoint Services site collection membership list, that user is no longer recognized as a member of the site collection, and Office SharePoint Server 2007 no longer synchronizes profile information for that user.

If a user leaves the environment (is no longer in the Office SharePoint Server 2007 user profile store or in Active Directory), that user remains in the Windows SharePoint Services membership list for that site collection until he or she is removed from the list. Office SharePoint Server 2007 flags the user and ceases to synchronize any information for that user. However, Office SharePoint Server 2007 does not alter the Windows SharePoint Services site collection membership list in response to a user who is no longer in the Office SharePoint Server 2007 user profile store.

stsadm -o sync sets the timing, deletes old sync info from the db and allows you to control the sync process.

There are third party tools UserProfile Sync on Codeplex http://userprofilesync.codeplex.com/releases/view/13227 and there are a couple of tools from bamboo Solutions: User Profile to Active Directory Export for SharePoint sites syncs from SharePoint to AD, there are five sync types offered with User Profile Sync.

They are: 

• MOSS 2007 User Profile database to Active Directory.
• Active Directory to a WSS 3.0 User Information List.
• WSS 3.0 User Information List to a WSS 3.0 User Information List(s).
• Active Directory to a Contacts List in WSS 3.0 or MOSS 2007.
• A Contacts List in WSS 3.0 to a WSS 3.0 User Information List(s).

In short, WSS doesn't synchronize. it's a once-only copy when the user is added to a site. If you want synch, install MOSS, and activate the user profiles feature on the site, and in the user profile properties you can map to AD properties, and you can set if the property is replicable - "if you want the property to display in the user info list for all sites"

For article to understand User Profiles and User Information List synchronization, click here

I hope this helps your understanding of UserProfile Syncronization with WSS, MOSS, and AD.

SPD Workflow to send reminder notification

Consider a list or library having fields such as End Date and Contract Owner. The requirement is to send the notification to Owner if the contract is going to expire within 30 days from today.

This functionality can be achieved using the SPD workflow with action “Pause Until Date”

To do this, create a calculated column, name it "Alert Date" with formula as [End Date] + 30

• Now, go into SharePoint Designer.
• Create a custom workflow with Action “Pause Until this time”
• Insert the “Alert Date”
• Pause Until [Alert Date]
• then Email

If the requirement is too complex to achieve using SPD workflow, then it is preferred to create custom Timer Jobs. Article for this is available at: http://msdn.microsoft.com/en-us/library/cc406686.aspx

Clear SPD Workflow Cache

Whenever the SPD workflow is opened, it fetch the workflow details from server. When the workflow is modified and closed, all the steps are recompiled on the local machine and the same changes finally gets updated on the server.
But some times, it may happen that the workflow show the modified steps, but doesn't work accordingly. This may be due to the changes updated in the cache of local machine, but not reflected on the server workflow. This is a bug from Microsoft.
To fix this problem follow the below mentioned steps to clear the SPD activity cache:

• Close SPD.
• Open “My Computer”.
• Go to %System Drive%\Documents and Settings\%user%\Local Settings\Application Data\Microsoft\WebSiteCache (If you are running Vista, that path is different - look for %System Drive%\Users\%user%\AppData\Local\Microsoft\WebSiteCache).
• Go to a directory that looks similar to the name of the website you were connecting to. (Alternatively, you can just delete all these directories and everything should work when you boot SPD).
• Delete the assembly with the name similar to the one you are changing.
• Boot SPD.

You can now work with your updated activity.

Filter items in a View by User or Group

SharePoint offers different types of views, depending on the type of list. We can filter the items in the views by taking any field as a filter. But if we want to filter the items so that a particular user(other than the user who Created the item) or a group can see them, then views are not directly helpful. We have to use some tricks in order to make them useful.

Let me present a scenario: Suppose I have a list and I want to filter the default view in such a way that every dept can see their own dept items. Lets see how this can be done without code.

Take the names of all the people who are working in respective departments. Like take the names of people working in finance department, then take the names of the people in HR department and like this, take the names department wise. Create a column in the list and give it the name "Users". Choose the type of the field as "People or Group" and select "username" in the last drop down list box. Dont forget to click Yes in "Allow Multiple selections". Once you are done, open SharePoint Designer. In SharePoint designer create a new workflow and write the if condition like:

If department is Finance
     then set the value of the field "Users" equal to usernames

Now here you need to write the usernames of the people who are in finance department in the following manner: jason; david; vic;

Always remember that you have to write the usernames as you selected "usernames" while creating the column "Users". You can get a person's username from his or her account. name like if SHAREPOINT\jason is the account name then the username is jason and SHAREPOINT is the Domain name. Username is case sensitive so write it exactly in the same way as it appears in the account name. You can write any number of usernames seperated by ";".

Create "If" conditions for other departments in the same way, writing their people's usernames in the "Users" field. Once you are done just finish the workflow.

Now come back to the list and click on "Modify this view" for the default view. In filter option, filter the items by selecting "Users" in the field, select "is equal to" and write its value as "[Me]".
Now the filter will work depending on the login user. If the login user name comes in the users column then he will be able to see the item else not.

Whenever an item is created in the list, workflow will run and depending on the departement column value mentioned in the item. Once the item is created, "Users" column value will be set and each department will be able to see their respective department's items.

Display list in subsites

This article explains the steps to display list in subsites: http://blogs.msdn.com/jackiebo/archive/2007/02/27/displaying-a-list-on-another-site-in-the-same-site-collection.aspx

Article in progress...

Filter list views by user groups

Though SharePoint Designer is a powerful tool, but even then there is a limitation to filter list views by user group. Only filter that can be applied is by using keyword [Me]. So if current user is the member of any group, then the [Me] keyword filter won't work.

The alternative idea is to use the Membership comparator, which is used by the "By My Groups" view. The Membership comparator seems to work just like the other comparators ("is equal to", "is greater than", "is less than", etc), but is not available in the "Filter" section of view.

Try following these steps:

• Create a new view, and open the corresponding Aspx in Sharepoint Designer
• In the source code, locate the ListViewXml tag
• Inside this tag, locate the Where clause (begins with "<Where" and ends with "/Where>")
• Replace the contents of this tag with the following:

<Where><Or><Membership Type="CurrentUserGroups"><FieldRef Name="AssignedTo"/></Membership><Eq><FieldRef Name="AssignedTo"/><Value Type="Integer"><UserID Type="Integer"/></Value></Eq></Or></Where>

Save the page, and you're ready to go.

Migrate SPD Workflows

Quite often I need to copy a workflow to another site or site collection (e.g. when provisioning an intranet portal for another client). I usually use the method described here. It basically boils down to a few simple steps:
1) Open the target list/library in SPD, click New --> Workflow. Note: Obviously, all columns used in the source list or library must be present in the target one, also internal column names must match.
2) In the new workflow create 1 step that includes 1 condition and 1 action (e.g. If [field] equals 1, “Set field in current item” to 2).  This step creates the .xoml and .xoml.rules files needed to migrate our source workflow.
3) Open the original source workflow in SPD, open the .xoml file as XML (Right-click --> Open as .XML) and copy its contents.
4) Open the target workflow in SPD, open the target .xoml file as XML, replace the content with the content copied in step 3.
5) Do the same for the .xoml.rules file.

Problem:
Normally after saving the files and opening the target workflow you will notice your workflow lookups display GUIDs rather than, as you would expect. fields, columns and parameters (see screenshot below). This is down to the fact that your .xoml and .rules files reference columns and lists used in the source workflow – if your target workflow is in a different site or site collection these will, obviously, not be recognized and, therefore, are displayed as GUIDs.

Old Solution:
Luckily, SPD is smart enough to re-map the workflow to the lists and columns in the current site. All you need to do is click on the GUID and press the “Add Lookup button” – you will see that SPD automatically finds the right list and field:

Pressing OK will update the field.

Now, this is all fine for a simple workflow – you just click and fix a few lookups and off you go. What if your workflow is a longer more elaborate one – containing many steps and even more lookups, especially ones looking up values in other lists? Suddenly, the above approach becomes quite a cumbersome one.

New Solution:
What I’ve been doing when dealing with longer workflows:
1) Follow the steps outline in the beginning of the post so you end up with .xoml and .xoml.rules files copied from your source workflow.
2) Make note of all the lists used in your source workflow, note their GUIDs. Do the same for the lists used in the target workflow.
TIP: You can use Sharepoint Manager 2007 to easily get the lists GUIDs
3) Open your new workflow in SPD, open the .xoml and .xoml.rules files as XML and replace the source GUIDs with the target ones.
That’s it – if you open your workflow now you’ll see all lookups display correctly and you no longer need to click through them all to have them updated.

Gotcha:
I’ve been happily using the above approach for the last year or so. However, today I ran into an issue that didn’t really make much sense. I noticed that something funny happened if my workflow used the “Create List Item” action” (I guess the same will be true for “Update List Item” and “Copy List Item” actions).




You can see in the above screenshots  that all lookups are displayed correctly. However, when I click on the “Tasks” lookup (first screen) to open the Create New List Item dialog box the List value was not populated (even though it’s shown properly in the first screen). Selecting the Tasks list from the drop-down menu had the effect of creating a new action – all the previously defined fields (Description, New Employee, Assigned to) disappeared and had to be put back in manually:

This was a major issue as I had over 20 steps using the “Create New List Item” action. I obviously didn’t like the idea of re-creating each of them manually. I opened the .xoml and .xoml.rules files and looked through the code, re-created the workflow in different sites a few times and tested all I could think of. I still couldn’t figure out what the problem is. Finally I spotted the culprit.

Solution:
Turns out the lists GUIDs I pasted into the workflow’s .xoml files were in lower case. SPD was happy with that for all lookup fields. However, lower case seems to trip up the Create New List item action (and possibly other related actions – e.g. Copy List Item). The moment I changed my GUIDs to upper case (e.g. from fabe5a1-c8d0-4c72-8a66-46c6917abdb5 to 1FABE5A1-C8D0-4C72-8A66-46C6917ABDB5) things magically started to work fine – all field lookups and references mapped properly, no actions need updating. Bingo, I can now copy even large elaborate workflows in a few minutes!

Reference: SharePoint Applied