in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

Dave Wollerman's SharePoint Blog

I use this blog to share information with the community plus also as a repository for reference material on unique situations that I have come across.

View Dave Wollerman's profile on LinkedIn      Sogeti Logo

February 2008 - Posts

  • My Sites and Memberships

    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.

  • Search Core Results Web Part and XSL Link Property

    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.

  • Workaround for creating timer jobs after a restore in SharePoint

    *** 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.

     


Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts