Using Today field in SharePoint list views

One of the coolest things about SharePoint lists is that you can filter the items in a list to such values as [Today] and [Me]. There are many posts out there of people trying to display items from this week or this month. You can do this by using the Today field in a calculated column. This blog details how to do that. The issue that you will run into is that the Today value does not update unless you edit the list item.



I worked around this by creating a simple console application that is set up as a scheduled task on the SharePoint server. The application opens up the list and loops through the list items and calls item.Update() on each one. This causes the date modified date to update and it updates the Today reference.



I have successfully used this to maintain current month views on a list. If anyone knows of another way to keep the today value updated without running a separate application, let me know.

SP2 and should you install itt?

I came across the SP2 for MOSS and WSS and was interested in installing it on our corporate Intranet installation of WSS. I upgraded the test environment without any issues (other than an authentication issue, but that is my fault). I was then thinking about installing it on the Internet-facing installation of MOSS.



Good thing I didn't.



I came across a bunch off blog posts over the last few weeks and the Microsoft KB article saying that installing the service pack will reactivate the trial expiration date on MOSS and after 180 days MOSS will not be available to end-users.



I have to step back here for a minute and wonder if anyone in the Office realm of Microsoft tests any of the items they push out as Service Packs? It seems to me that you would test the code that you are going to send out to your clients to install in production environments. I realize this would not pop up until after 180 days passed, but I would hope that some testing goes into these things.



If you want to proceed with installing Service Pack 2 and "beta testing" for Microsoft, you will want to follow the procedure outlined in this KB article to make sure you don't lose functionality after 180 days.

Search Results not Security Trimmed

Recently, our new corporate Intranet went live and I happened to be performing a search while logged in as a limited user to verify that security-trimming was working. I was surprised to find that this user was getting back results that they did not have access to. I could tell this since there were items in the results that when clicked on took me to the access denied page.



I began looking for some answers but was unable to find anyone else out there that was having the same issue. This led me to believe that it must have been something that I did custom to our site that was causing the issue. I remembered that I was having trouble with the imppersonation piece when I was testing some custom code before and that I had went into the web.config file and set impersonation to false. So I thought it a wise decision to go back in there and set it back to what it normally is (true). I saved the change and ran a search and found that I was only getting back items I was allowed to see. I was relieved that at least SharePoint search was working the way it is suppose to.



Now I just had to figure out what to do in my code so that I could leave impersonation on. Impersonation allows the SharePoint application to impersonate other users and this allows a user to perform a search and SharePoint checks that users permissions to see which files they are allowed to see. It then returns only those items in the search result. By turning impersonation off I was running all of this as the System Account, which had access to all items in the site.



I was finally able to find a way in my code to perform the functions I needed to while allowing impersonation to continue. Let this be a lesson to me: Don't go changing items in web.config without fully understanding the implications.

Portal Site Connection - What is it?

I was poking around in the Site Collection Settings and came across the link to Portal site connection. I always wondered what that did so I clicked on the link and was taken to a page where I could connect to a portal site and enter the Web address and name for the portal site. This didn't really help me figure out what it does if I put a site in there, so I did some searching and cam across Gavin's SharePoint Blog. He has a post that talks about the portal site connection and it made a lot of sense to me.



Basically it adds a link to the top level breadcrumb trail that can point back to a top-level site collection. This might not be handy in most instances of SharePoint development but if you create a new site collection for projects or areas of the company, it makes it nice to be able to have a link back to a 'home' portal.

SP2 for MOSS and WSS 3.0

Just as I get all of my servers updated to Service Pack 1, I find that Service Pack 2 has been released. It includes some more performance enhancements and prepares for a better upgrade to SharePoint 2010, which isn't that far off. Below are links to the downloads for both clients and servers:



Office 2007 SP2



Office 2007 Language Pack SP2



WSS 3.0 SP2



Wss 3.0 Language Pack SP2



MOSS 2007 SP2



MOSS 2007 Language Pack SP2 (x86)



MOSS 2007 Language Pack SP2 (x64)



I just ran the updates on one of our test servers and it did not require a reboot, and the installation itself went well. I ran into some trouble with the Web application in that at one point to test something else I had turned off impersonation in the web.config file and I was getting a cannot complete action error on the site.



I poked into the 12 hive log and found an error that said, "Could not initialize the securable object for /default.aspx during an http get. I am thinking this is due to some of the changes for Forms Based Authentication that came in SP2. Once I changed that back to true for the impersonation, everything was back up and running.

The undocumented truth about SharePoint Search

Now that the new corporate Intranet has gone live, I decided I would test some of the Search functionality to make sure it is working correctly. I did a search on a keyword that I knew should return results from the Intranet and was only getting back results from the file share I had indexed. I logged into the Search Server 2008 administration site and found that my Local Office SharePoint Server sites content source had no items in the successes lately and had an error. So I looked at the crawl log and found the error "Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to the crawl repository...."



I knew that the account I was using could access the content because I logged into the site with that user account and was able to get to all of the pages without any problems. The next spot I looked was the SharePoint logs and I did not find anything out of the ordinary in them so I moved onto the Event logs. In there were some warnings for the Office Server Search that said "The start address <http://intranet/> cannot be crawled. Context: Application 'SharedServices', Catalog 'Portal_Content'



Details: Access is denied. Verify that either....."



This was repeated in the events every time I tried to run a Full Crawl. I knew that many things affect the crawling of a SharePoint site, including Alternate Access Mappings, content account privileges, and content rules or scopes.



I started looking into all of these things and they all looked ok to me and I knew that search was working before on this web app. The only thing I had changed since then was to extend the application to out production domains for internal and external access. I started searching and found that there were just as many answers as there appeared to be questions when it comes to this error. Many of the answers were "Check to make sure that the content crawl account has access to the site."



The answer ended up being a combination of many articles, one of them being this Event ID site. I scrolled down to the area where people added their comments and found one from Ionut Marin that said you should extend the web app with a new site. I then followed the Google Groups link at the bottom of that site and it took me to another person that said I should extend the web app. I ended up following his instructions to the letter.

• I went to Central Administration -> Application Management.


• Select Create or extend web application and make sure you have the right web application that you want to extend.


• Set all of the parameters on the extend web app. page as needed, but you should set the host header to be the name of the server.


• From the zone list pick anything other than Default.


• When you are done with that, go to Authentication providers and make sure that your newly created web app. is set to use windows integrated authentication.


• Then go to Operations -> Alternate Access Mappings for the web application.


• Click Edit Public URLs and switch out new URL you just created for whatever is currently in the Default zone. The URL that is in the Default zone can be placed in any other zone.


• Wait a few minutes and change your Local Office SharePoint Server sites content source to crawl the new web address. So for my example the server name is web2. I created a new extended web app. with a URL of http://web2:1234/. The port is not really important as you will not access the site at all using this URL. I then set the start address in the content source to be http://web2:1234/.


• I started a full index and noticed that items were showing back up in the index.

Another thing that I noticed after the crawling was working again was that I was getting warnings in the crawl log for all ASPX pages that said "Content for this URL is excluded by the server because a no-index attribute." This seems to be a generic error for a number of things that could go wrong and did not point to my issue specifically. So I tried clicking on the link that was having the issue and got back a more meaningful error that said "Code blocks are not allowed in this file."

I understood this because it was indexing the new web app. and I had added a Page Parser Path to the web.config for my other web apps in order to run some custom code. After I placed the Page Parser Path in the new web apps web.config file I could hit the page through the new URL and I ran another Full crawl of the site. This time the number of items in the index increased and the warnings decreased dramatically. I looked into the crawl log and there were no more warnings about the ASPX pages.

Although this resolution worked for me, it may not be the same for you. As I said, Search seems to have many issues or areas of configuration that could cause errors or prevent content from being indexed.

SEO Optimization for SharePoint

I have been keeping an eye on SharePoint blogs and the Microsoft SharePoint site for a while now and I happened across an article about SEO Optimization for Web Content Management Sites. This article outlines some best practices for optimizing an Internet-facing SharePoint site for search engines.

For a while I have been trying to figure out a way to handle URL chopping in our SharePoint site. This article provides a solution that works well and also takes care of the 302 temporary redirects that SharePoint uses and turns them into 301 permanent redirects.

I used the example in the article and also merged it with an example I found at Waldek Mastykarz's blog to handle both the case of SharePoint creating the 302 and also handling chopping at the pages document library level, which SharePoint does not do by default. The solutions are easy to deploy into the environment, just make sure to place the compiled code in the bin directory for that virtual site and add the additional lines to the web.config file.