Dave Wollerman's SharePoint Blog

Memberships located in a users personal site are managed for the user automatically by 2 timer jobs that run.

Profile Synchronization (default interval is every 1 hour)
Quick Profile Synchronization (default interval is every 5 minutes)

These schedules can be changed by running the following stsadm command with the "-SyncTiming" (profile sync) and the "-SweepTiming" (quick profile sync) parameters.

stsadm -o sync
           {-ExcludeWebApps <web applications> |
            -SyncTiming <schedule(M/H/D:value)> |
            -SweepTiming <schedule(M/H/D:value)> |
            -ListOldDatabases <days> |
            -DeleteOldDatabases <days>}

These timer jobs synchronize user information tables in every site collections with any updated profile information in the user profile database. They also identify whats sites the user is a member of and store that information for the user in the memberships list on the users personal site.

Being a member of the site was a little vague as to how does sharepoint know. Do I just need to be assigned permissions to the site, be in a special group? The answer is that by default when a site collection is created there is a members sharepoint group created too. This group is assigned as the "members of this site" group. You can create a custom sharepoint group and assign the custom sharepoint group to be the "members of this site" group. This can be done from the people and groups settings, viewing the members of any sharepoint group and selecting "Settings -> Set Up Groups" option in the toolbar.

Also, even though sharepoint groups are managed at the site collection level, each site in the site collection can identify the group that will be considered "members of this site" group. So when the timer job checks out the groups for memberships it will look at each site in the farm to determine the sharepoint group to use and then update each users membership with that information.

Keep in mind that if the user is also using Office 2007 their memberships show up as "My SharePoint Sites" in the open and save dialogs. From what I am lead to understand is the information that renders under this section of your office client application is updated upon the first time an office application is started for the day.

This information also shows up in the users "My Links – My SharePoint Sites" dropdown in the top right of a sharepoint site.

This is a MOSS only feature and is available with MOSS Standard and Enterprise editions.

I was customizing a search core results web part display recently and I wanted to have a sinle instance of the XSL used to translate the results since I will have multiple instances of the same search core results on many different site collections. I thought the "XSL Link" web part property of the search core results web part would allow this, but I was mistaken.

The issue is you can only reference an XSL file in the XSL Link web part property only if the XSL file resides on the same site collection as the web part is displayed. I tried referencing the file from _layouts and received and error, I tried referencing the file from another site collection, received same error. I know permissions is not a problem since none of these locations are locked down.

If there is anyone that knows a workaround for this I would love to hear it. Also, this was on an instance of MOSS Standard SP1.

*** UPDATE *** 
I was made aware of a fix in SP1 that should cover this issue. http://support.microsoft.com/kb/941422 

I have recently done a restore of a SharePoint farm without first creating the web applications as Microsoft suggests. (read previous post about web application timer jobs not created during a SharePoint restore). The issue was the problem wasn't found right away so Microsofts recommendation of running the restore again wasn't an option. I searched and searched for a solution that allowed me to manually fire up these timer jobs for these web applications, but nothing was found. Seemed like creating a new web application was the only option. Below are the steps that I took to resolve this issue for each web application involved (usually it would be every web app except for central administration).

Step 1: Backups and Preparation
Before starting any endeavor that can potentially hose up a web application and / or database it is recommended that the entire farm run a full backup just in case . Next we will have to make sure we stop the IIS web sites so there are no additional changes being made to the databases as we are trying to move them. Do this by going into IIS and stopping the appropiate virtual servers running. 

Step 2: Create a new Web Application
I created a new web application on a different port number and a temporary database name (WSS_Content_Port_DELETEME). I did so that I knew when finished which databases to delete. The temporary port number is there as a place holder until I could manually swap the ports with the "old" web application later.

Step 3: Prepare to move the Databases
There is a command that Microsoft has included with the new version of SharePoint called "PrepareToMove". This command is used as an operation under stsadm. This command allows the profile syncronization properties for the users for each site collection in the database to be disconnected, ultimately allowing the new web application to take over the role without causing errors in the syncronization process. You will have to run this command on every site collection in the database.

The first thing you would need to get is a list of site collections in the database. The command used to gather the list of site collections is "enumsites". The syntax for this can be found by running stsadm -help enumsites from the command prompt. What I typically do is output the results of that command to a text file so I can parse out the site collection URLs. I do this by running stsadm -o enumsites -url http://webapp >c:sites.txt. Keep in mind that if you have more than one database on your web application, but you are only moving one of the databases, only the sites that are part of the database you are moving need to run the preparetomove operation.

When I have a list of the sites i need to move. I create a BAT file that will process all the sites using the preparetomove operation. What I do is create a command in the BAT file for each site collection I am preparing to move. The command looks like this: stsadm -o preparetomove -contentdb DBSERVER:DBNAME -site SITEURL. You will have to replace DBSERVER with the name of the database server the database is located, replace the DBNAME with the name of the database to move, and replace SITEURL with the url of the site collection in the database. Keep in mind that there must be a colon in between the DBSERVER and DBNAME values. Once I have the BAT file create I run it.

Step 4: Swapping Databases
Now that the sites have been identified and the preparetomove operation has been executed on the identified site collections. Now is the time to swap the databases to the web application we created in Step 1.

• You do this by going into Central Administration and select "Application Management -> Content Databases"
• Once in the content databases management area, select the "old" web application as the filter
• Click on the database name(s) that the preparetomove operation was run against
• Check the box to "Remove Database". You will get a warning saying that you are removing a database that contains sites and that nobody will be able to access the sites if the database is removed. Click "Ok"
• Now you should be returned to the content database management area, select the "new" web application as a filter
• Click on the temporary database that was created when the web application was created and remove the database by following steps above.
• When the temporary database has been removed, attach the database from the "old" web application by clicking on the "Attach Database" link in the toolbar.
• When attaching an existing database it is very important that the name entered for the database name is exactly the same as the database that exists in SQL that you are attaching
• Once the name is entered in correctly, click ok and the database should be attached successfully.

Step 5: Swapping URL Addresses
This step we will have to swap the URL addresses in both SharePoint and IIS, since Microsoft did not build into the Alternate Access Mappings an automated feature that changes IIS for you… but I digress… . Below are the steps to swap the URL addresses

• Navigate to Central Administration and goto the Operations -> Alternate Access Mappings page.
• Select the "old" web application AAM and change the url to another port that is not currently being used.
• Select the "new" web application AAM and change the url to the port that the "old" web application was using.
• Navigate to IIS Management
• Right click on the "old" web application and select "Properties"
• Change the port number to the port number you set for the "old" web application in the AAM area, click ok.
• Right click on the "new" web application and select "Properties"
• Change the port number to the port number you set for the "new" web application in the AAM area, click ok.

Now your new web application is running and users are able to access their content using the same URL as before, but now they are accessing the new web application. Repeat these steps for each web application that you need to recreate for the timer jobs to be present.

Step 6: Cleanup
This final step once everything has successfully be moved and tested is to remove all the "old" references in the system.

• In Central Administration, navigate to Application Management -> Delete Web Application
• Select the "old" web application to delete
• Select "No" for each the remove database and remove IIS options. I recommend removing manually just in case SharePoint has some connection to the moved databases and application pools.
• Go to the SQL Server and remove the temporary databases created called "DELETEME"
• Go to the IIS Management area and remove the "old" IIS virtual servers that were used for the "old" web applications.

Now everything should be back to normal and all cleaned up. I hope that this will help someone resolve their issues and not have to go through the headache of figuring it out for yourselfs.

*** UPDATE *** 
I was made aware of a fix in SP1 that should cover this issue. http://support.microsoft.com/kb/941422

SharePoint administrator beware!!! You must manually recreate your web applications (with the exact naming as compared to what was backed up) to ensure that all the timer jobs for each web application is created when restoring from a SharePoint backup. The problem seems to be the automatic SharePoint restore that restores the databases and web applications must not follow the same method as if you were to do it manually because the automated restore does not create the necessary timer jobs for any web application restored. This includes immediate alerts, so if you have done a restore and you are wondering what has happened to your alert emails and your assigned-to emails it is because the restore didn't do a proper job.

Of course the recommendation for getting the timer jobs created and associated with the web application is to manually create the web applications BEFORE you restore. The problem is you might not realize there is a problem until after a couple weeks / months after your restore. Now you have to delete the web applications, create them manually, and restore from the last full backup.

Here is the Microsoft KB article that discusses the issue.
http://support.microsoft.com/kb/942989

Here is the link to my work around and fix for the issue that is less intrusive than running a complete restore of your farm.
/llowevad/archive/2008/02/18/workaround-for-creating-timer-jobs-after-a-restore-in-sharepoint.aspx

Updated on 1/28/2008 to include link to post related to web application timer jobs and SharePoint restore. 

There comes a time when SharePoint databases will have to be moved to another database server. The problem is that it is not that easy to just move the databases to a new database server and have everything work. In SharePoint 2003, it was realatively simple to move all the databases, but in 2007 there is alot more involved with communication between the databases making it a more complicated scenario.Outlined below are the steps taken to move a SharePoint farm to a new database server.

1. Perform a farm level backup of the current farm using the SharePoint backup utility in Central Administration. Make sure the backup gets saved to an accesible location either on this server or on the network.
2. Run the SharePoint Products and Technologies Configuration Wizard to disconnect the server from the configuration database. If there is only one server in farm, then all you have to do is that server. If there are multiple servers in the farm, make sure the server running central administration is the last server disconnected from the farm. I don't believe this is a requirement, but I would recommended it anyway.
3. Once all the servers have been removed from the farm. Run the SharePoint Products and Technologies Configuration Wizard on the server to host the central administration site first to create a new SharePoint farm. Once Server is configured, run the configuration wizard on the remaining servers adding them to the new SharePoint farm.
4. Start both the Office SharePoint Services Search and the Windows SharePoint Services Search services

   *** UPDATE ***

5. Read the post about web application timer jobs before moving to step 6 VERY IMPORTANT
   *** UPDATE ***
6. Restore the backup made in step 1 using the SharePoint restore utility in Central Administration. You will have to supply the file path to the files that were backed up
1. There are 4 steps to restoring from the backup. Step 1 is to locate the backup set that was ran in Step 1

   

2. Step 2 is selecting a backup to restore from the location specified in the previous step

   

3. Step 3 is selecting a component of the backtup to restore… in this case you want to restore at the farm level

   

4. Step 4 is to select the restore options. In this step you want to select new configuration for the type of resture and besure to go through all the databases, web applicatons, and SSP information to specifiy the new database server name and database file locations for each item. Double check everything before hitting ok.

   

5. Finally after all selections are made and the restore process is kicked off, you see a summary of the restore in progress.

   

7. Once restore is complete the databases should be in their new location and the SSP should be back up and running. To finish the move, you must reconfigure the farm using central administration. Then kick off a full crawl to repopulate the content index.

Huge MOSS Workflow Issue… What is Microsoft Thinking!!!! the original post 

Ok, recently I came across a blog post called SPWorkflowAssociation.AutoCleanupDays from Robert Bogue, a SharePoint MVP, that tries to explain away my original complaint of this process as to be not that big of a deal. I believe that he missunderstood my original posting.

My overall intention of the original post was to get the word out to the SharePoint community to make sure they are informed of this process. My goal was to get people to make sure Microsoft was aware that they were not happy with this design and that it needs to be re-designed or at the least configurable. At the very least I am glad that Robert brought this to the SharePoint product group attention. What I am not happy with is what Robert explains as their reasoning behind this little hidden gem.

The main reason for cleaning out the associations is because of a performance issue. If this is a true reason, then the product team should of reconsidered their storage model for the workflow history and associations. If anyone knows the limitations of SharePoint it would be the product team and they purposely used a SharePoint list for storage knowing those limitations and performance issues. I can't see this being their only option for a storage model and if it was, then this must of been one of those last minute features added to meet a deadline of some sort.

The second reason for saying that this is not a big deal is auditing. Robert explains that the workflow history is meant to be more of a log file then an audit trail and that MOSS has its own audit logging outside of the workflow. I can see where Robert is going, but I still don't agree. Working with large enterprise customers who are audited on a regular basis will not take that the workflow history is a log not an audit trail as an explaination. These customers will need the workflow history, comments, and everything else associated with that workflow to be part of their existing retention policies for both auditing and legal situations. MOSS Auditing will show the editing of the tasks and such, but it is not as robust as the workflow association view. Meaning that there has to be a manual association made to determine which tasks ran for a particualr document or item. Plus MOSS Auditing needs to be configured to capture these events, where workflow history is automatically there. Also, auditing is captured at a site collection level meaning you will get all workflow tasks across the entire site collection making the manual assocation more difficult, where workflow associations are for a particular document or item. Again making it easier for auditing and legal situations. In business time is money, and SharePoint is fixing that for the most part opening communication and getting tasks completed on a more timely basis, but things come up (like they always will, murphy's law).

Now, I don't want people to missunderstand me. I am not saying all workflows required this. There might be some minor approvals that do not require this kind of attention. I am stateing this because I know there are organizations out there that have developed critical business processes using SharePoint workflow and will possibly need to rely on this information in the future.

Again, I just want to make sure people are aware of this. Once the community is aware of these issues, then those people and organizations can make an educated decision as to use SharePoint workflow, turn off the auto cleanup jobs, turn on auditing, etc. An informed community and community feedback to the product team (good and bad) makes for a better product in the future. Don't get me wrong, I enjoy working with SharePoint and believe that it is a product that can change a company, like email did years ago, but with the good comes the bad and I want people to be aware of the bad as well.

This post is inspired by a comment I recently recieved from someone asking about when to use site collections vs sub sites and what things are shared within a site collection and what things are not. Since I don't really see this type of foundation topic being discussed (compared to all the topics about the fun cool features), I figured that I would try to put together a list and some examples together for everyone.

First, I want to discuss the definition of site collections (at least in my opinion). Site collections are a means to provide a stand alone secure container to allow like, or related content to be shared within. If you see, I refer to site collections as "containers" or in Active Directory terms, "Organizational Units". Its a means to provide organization in your environment while keeping the content inside physically unrelated to any other container.

So, the question is when do you use site collections rather than just building out a heirarchy on a single site collection? I have another post that goes into the logical archiecture of site collections and the benefits of some of the features it provides, but in this post I wanted to discuss other reasons for people to think about when designing the site collection taxonomy. In the above definition I mention the container allows for "like" or "related" content to be shared. What I mean by this is the site collection content will be related back to a sole purpose, topic, and/or area.

You can think of this as the separation of "public" (or formal) content and "private" (or informal) content. Formal content is content that requires a formal buisness process. This content is usually public (internal public to a company) content that requires specific approvals before being displayed to the masses. Informal content is content that is more ad-hoc and privately shared with a team or a small group of individuals. There are times where informal content being worked on by a team becomes formal content when published to the main intranet web site.

For example, everyone's first thought with SharePoint is "I want to use it for my Intranet". Thats fine, first we need to define the term InTRAnet. InTRAnet to me is internal internet, meaning that if SharePoint is your providing application then the entire SharePoint farm is technically your inTRAnet. Looking at it this way you can relate to the external inTERnet (or internet for short). You don't think that the inTERnet is a single site right? With Microsoft and google as sub sites..  Then why does the thinking behind creating an inTRAnet start with a single site and includes the entire companies content, workspaces, and what have you all within that single site?

The bottom line to think about is not what every single site needs… the object is to "categorize" your companies needs into a manageable intranet environment. Examples of this are

• Personal Sites (1 site collection per person, more ad hoc, life cycle managed, self service creation, personal space for that person only. Informal Content)
• Project Workspaces (1 site collection per project, more ad hoc, life cycle managed, self service creation, content avaiable for that project only. Informal Content)
• Team sites (1 site collection per team, more ad hoc, life cycle managed, self service creation, content available for that team only. Informal content.)
• Division Portals (1 site collection for each division and department, content available across that division or department only. Formal Content)
• Central Portal (1 site collection, content available across the ogranization. Formal Content)

I am not looking to preach to what people should do rather then to give them alternative ways of thinking when it comes to what SharePoint is and what it can do. The big thing I tell all my clients is that there is no clear right or wrong decision on using SharePoint. If a single site collection is all that is required, then that is right for that situation. I hope that this post helps people with their decisions in using SharePoint.

We all know that content types are inheritable assuming that the features of a content type is also inheritable. In most cases this is true, for site columns and workflow. Where it doesn't work is when it comes to Information Management Policies. IMP's are set for the content type and any content type that inherits from it. When trying to change the IMP for a child content type or a document library that is using that content type you get a warning that states that you are unable to modify the IMP and if you want to change it you will have to do it at the parent content type.

So, I was working on creating a record center site today and had a couple errors show up on me. The errors were "Access Denied", "System.Exception", and "Error in Application". I was confused being a system administrator why I was not able to create these. When I searched for a resolution I found solutions basically saying it was permissions releated and that it needed to be a top level site in a site collection. I couldn't believe that these were the limitations since the system allows you to select the records center template for creating a sub site.

The actual problem that was causing these errors was that I was naming the title of the new site (or sub site) as "Records Center". For some reason this conflicts with creating the site or creating something in the site since the site is created when i get the errors. I tried again using another name such as "Demo Records" and it created it just fine, I then just renamed the site after it was provisioned back to "Records Center".

Hope this helps.

I recently had a question on my SharePoint Architecture posting asking about more details on the use of managed paths. In the email I was asked about a specific scenario regarding 180 departments, managed paths, and scripting out the creation of these site collections. I wanted to share my response for anyone else who might have the same question. Below is my response….