Devit!

If you take a tour over to google or any other search engine to try and find the best way to filter a SharePoint list you will find many results that only provide partial success.  If you want to accomplish the following then this walk through is for you.

• filter a SharePoint list (using a TextBox)
• filter multiple columns
• only show a limited number of results on the page, however still have the filter apply to the whole list

Let’s do this – step by step instructions:

1. Go to your List
2. Select Settings -> List Settings
3. Create view
   1. Select your default view (will be listed under “Start from an existing view”)
   2. Call it Filtered[ListName] (Ex: FilteredCompanies)
   3. If desired make this the default view (CheckBox below View Name)
   4. Click OK
4. Go back to List Settings
5. Create Column -> Call it FilteredCompany (or something logical)
   1. Select Calculated
   2. In the Formula box add an = to start and then add every column that you want to search with a &”#”& in between. The “#” plays an important role!
   3. Uncheck “Add to default view” at the bottom
   4. Click OK
6. Open the site in Microsoft Office SharePoint Designer
7. Go to Lists
8. Go to your List (Ex: Companies)
9. Open FilteredCompanies.aspx (or whatever you called your new list)
10. Above your list add a ASP.NET TextBox to the page
    <asp:TextBox runat=”server” id=”txtSearch” AutoPostBack=”true” CausesValidation=”false”></asp:TextBox>
11. Select the list (Design View)
12. Right Click -> Select “Convert to XSLT Data View”
13. Click “Filter” on the menu that pops up.
    1. Select your new Column (Ex:FilteredCompany)
    2. Set Comparison to “Contains”
    3. For Value go to the bottom and select “Create a new parameter…”
    4. On the right hand side set “Parameter Source:” to Control
    5. On the right hand side set “Control ID:” to txtSearch (note: you may see some blank values – just scroll down)
    6. On the right hand side set # as the “Default Value”
       Note: This is done so if we have no search value we still get all of the results back!
    7. Click OK
    8. Click OK once more
14. Save the page
15. Success!

I hope this saves you both some time, energy and frustration.  Sometimes SharePoint is amazing and other times you’ll find that a simple functionality change can be a nightmare.

Please let me know if you have any other tips or if you’re having any issues getting this working.

Good luck,

Recently we discovered a interesting issue with SharePoint that will cause you copious amounts of grief if your not aware of this ‘functionality’.

What you may be experiencing:

• my site seems to have broken permissions
• administrator can’t make changes
• I can’t seem to restore a copy of my site
• nothing is working properly and there’s no errors in any log files

What is going on?

Basically your site has been locked. What!?! To fix this issue just take a peak below at “How can this be fixed?”.

What caused this?

A new feature in service pack 2 for Windows SharePoint Services (WSS 3.0) by default locks & unlocks your site when backups are performed.  The problem is if anything fails your site will remain locked.  This is in essence a good feature unfortunately there’s no obvious log or indications anywhere.  A giant red banner on the administration site would be a simple and effective way to bring attention to this ‘feature’ so anyone trying to get things working again has some direction.  Additionally the site lock feature when auto enabled or left on by the system should provide a clear list of the reasons this might occur so any individual monitoring a SharePoint site knows what to look for.

One of the following issues may be the cause to this ‘feature’ kicking in:

• backup failed (as of Service Pack 2)
• restore failed
• there’s more reasons – feel free to add the in the comments!

As of service pack 2 for Windows Sharepoint Services 3.0 (WSS 3.0) if your nightly backup fails your site will be locked!  In some cases you will see no errors in any logs and have no indication (depending where the backup failure occurred) that anything has failed.  In the instance we ran into the backup successfully completed but failed to exit causing the site to remain locked with no error messages.

How can this be fixed?

To get the system back into a normal state simply follow these steps:

• open Central Administration on your server
• select “Application Management”
• under “SharePoint Site Management” select “Site collection quotas and locks”
• using the drop down titled “Site Collection” move through each site and check the “Lock status for this site”
• change the offending site(s) to “Not locked” and click ok
• Success!

Additionally if you’d like your site to remain in a normal state if a backup fails then you can adjust your backup script to include the following setting “-nositelock” when using stsadm.

Please let us know if you have any other tips or tricks related to these issues.

One thing that can be frustrating for any developer is when you run into a problem and despite millions of search results when searching for a resolution nothing seems to solve the issue.  I thought I would share some simple solutions to two very frustrating WSS issues we’ve run into this past year.

The first issue is intermittent 403 Forbidden errors on a WSS (Windows Sharepoint Services) site.  We were seeing  anonymous users in our test environment who couldn’t use the website at all until an admin logged in.  After someone had logged in then anyone could use the website with or without a login.  What ended up being the problem was a permissions issue on the bin folder for the website.  To fix this problem please follow the simple steps below.

1. Ensure all sub folders that are virtual directories on the site are using the same application pool as the root site.  (This didn’t help me as everything was set properly, however I read countless posts of this causing problems for others)
2. Add read access on the bin folder for the account IUSR.  (You don’t need to add read access to the files, which is somewhat confusing but none the less that protects the files from being downloaded)
3. Success!

If you have any other problems please post your questions/solutions below.

Continuing on, I also ran into a strange DCOM error popping up in Eventlog on most of our servers with WSS sites running.  The error looks like this…

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1} to the user <serverName>\networkservice SID (S-1-5-21-<serviceSID>). This security permission can be modified using the Component Services administrative tool.

Needless to say, getting this error several hundred times a day in Eventlog is not ideal.  The resolution is rather simple but not overly easy to explain.  Please carefully follow the steps below.

1. Copy the GUID (In my case it was {61738644-F196-11D0-9953-00C04FD919C1})
2. Open the registry editor by running regedit
3. Click on ‘My Computer’ at the top then select Edit -> Find and Paste the Guid (remove the {})
4. You should see an application name in the right pane when the Guid is found – in my case this was “IIS WAMREG admin service”
5. Close the registry editor and open Component Services from Control Panel -> Administrative Tools
6. Expand Component Services, My Computer, DCOM Config and find the application name discovered above in step #4.
7. Right click on the the application name and select “Properties” then select the Security tab
8. The first block should be set to Customize – select edit on the right side.
9. Now add the service account (in my case this was network service) and add the appropriate access which in my case was “Local Activiation” (which you can see in the error above)
10. Success!

Please share this information as both of these errors can be both frustrating and a waste of time.

Good luck and happy coding!