Adding Custom Styles to a Sitemap File

SharePoint has an excellent navigation mechanism that is provided by sitemap files. These files end in .sitemap and are XML files that define the structure of your site. The sitemap files contain a sitemap node that has one or more sitemapnode nodes inside it. In each of these you can give a title for the navigation item and the URL that the item should be a link to.



While SharePoint provides this nice navigation, it becomes a little tricky if you have a client that has specific needs for the fonts and colors of the navigation items. One of our clients navigation menus contains items that are one color on the first word or two of the item and a different color for the rest of the item. There was no easy way for me to modify these items to get more than one color to show up.



The answer came in the form of an HTML-XML hack. (I say hack in the nicest way possible on this one.) I simply inserted encoded HTML tags around the words or phrases that needed to be a different color. You need to encode the opening and closing brackets on the tags. This solution worked well to provide the custom navigation look that we needed for our client. As a side note, sitemap files will not allow a non-breaking space in them. If you add one (even encoded) it will throw an error telling you that a non-breaking space is not allowed.

Incoming Email In SharePoint

Last week I was at a client's re-installing SharePoint for them and I was just about done (or so I thought) when I came to the point where I needed to configure incoming email. For anyone who has configured incoming email you probably feel my pain. For those that haven't configured incoming email, this post will definitely help you. Incoming email can be really simple or it can make you want to rip your hair out, depending on how many Exchange servers and Spam filters are between your SharePoint server and the Internet.

I began my configuration by going to the incoming email settings in Central Administration and setting the install to allow incoming email and setting the incoming mail server (which was the local SMTP server on the SharePoint box). I left most of the other default settings and moved onto a list to allow incoming email on that list and give it an address. In the back of my mind I knew there was an Exchange server that I needed to work with so I wanted to make sure that email that would reach the SMTP server on the SharePoint box would deliver the emails to SharePoint. I did this by sending an email from Outlook Express on the SharePoint server and watching it get delivered to the SharePoint list. I was satisfied with that so I wanted to remove the email enabled part of that list. When I went to do that I got a wonderful SharePoint error that said 'Error in Application.' I knew from previous experience that this error usually means that there is not the right permissions on the Active Directory OU that stores the accounts created by SharePoint, so I checked with the client to make sure that the service accounts had the right permissions and they did. This puzzled me. What else could be causing this error. I found a blog post that had a couple of documents, one for configuring incoming email with Exchange 2003 and one for Exchange 2007 (since much has changed with 2007). The Combined Knowledge site contains links to those documents (which are invaluable).

I noticed that in the document for Exchange 2003 it stated to make sure that the account used for the web application that you want to email enable needs to be using the same service account as the one that is set for the Central Administration web app. I was pretty sure that mine was, so I searched for some other options online. After search for another 2 hours, I decided to double check to make sure that accounts were the same. They were not, but once I made them the same, the error went away on the lists. So now I was feeling confident that I was almost done.

I had the client test the email enabled list by sending an email from their Outlook and the emails were bouncing back. I helped them configure Exchange to relay emails to the SMTP server on the SharePoint box. This got emails from internal users into the lists. Since I was not internal to their network I tried sending an email to the list and it kept bouncing back. After thinking this over, the client and I determined that there was another server that external email was being routed through first, so we configured that server to relay to the SharePoint box and then I was able to send emails to the list.

After spending 9 hours on a task that I thought would take an hour or so, I was once again humbled by SharePoint. If you find yourself needing to configure incoming email with either an Exchange 2003 or 2007 server follow the Combined Knowledge articles. They are well written and include a troubleshooting section for those times that you run into an issue. If I would have followed them right away I would have saved a few hours of my day.

Exportation of Sites

Today I am at a client's reinstalling their SharePoint environment and one of the things I needed to do was backup the current sites they were using and move them over to the new installation. I knew this could easily be achieved using the stsadm export and import commands. I began by exporting the smaller of the two sites and then tried the larger site. I received an error that read 'Failed to compare two objects in the array.' I did some searching on Google to look for anyone else having this problem and there were a few out there that said it was an issue with a feature being uninstalled on the server and the site was looking for that feature.

I checked with the client to see if they were using any of the sites that were giving me a problem and they said they weren't (which is a good thing for me) as I could just delete those sites. For those of you that don't have the luxury of that case, you will need to search through all of the features to find the one that matches the GUID that is in the error. If the feature is not there, then hopefully you can find another copy of it, otherwise you won't be able to perform the export.

Once I finally got all of the sites exported, I copied over all the custom feature folders to the new server's 12 hive (if you don't do this the import will throw an error). I also made sure to copy any custom site templates over to the new server's 12\Template\SiteTemplate folder (if you don't do this either, the import will throw an error). One other thing that I forgot to check that hung me up was custom assemblies in the GAC of the new server. I was missing some and when I tried to do the import it said I was missing a feature, so I tried to install the feature using stsadm installfeature and that failed saying it couldn't find the assemblies. I imported the smaller site and took a look at some of the pages to make sure everything was importing all right.

What I found was that when exporting a site and then importing it to a new SharePoint installation the List View Web Part does not maintain the list view that it is suppose to display. There were some pages that contained the List View Web part and pointed to a List View that the users had created. When I went to any of these pages they all showed the default view for the list. I could not find anyone else that was having this issue, so I set to work changing the web parts back to the view they were originally using on the old installation.

PerformancePoint SP1 Released

As of Friday June 6, Service Pack 1 for PerformancePoint has been released. It fixes some issues with performance and a few other nagging issues.

For more information regarding SP1:

http://blogs.msdn.com/performancepoint/archive/2008/06/04/sp1-for-performancepoint-server-now-available.aspx


For information on updating to SP1, follow the TechNet Article:


http://www.microsoft.com/downloads/details.aspx?FamilyId=6245C354-9191-4C4D-8C0C-C10D6C778AF8&displaylang=en

InfoPath and SharePoint

The other day I was working with InfoPath to create a form for internal use that would allow employees to keep track of their objectives and goals for the month in relation to five key areas. This form would then be stored in a SharePoint document library, where I could then create views to allow the CEO to see how people were doing during the current month and the current quarter. There were additional requirements that involved security, such as no user should be able to see or open other users forms and only the CEO should be able to see the current month and current quarter views on the list.

I began the project looking at it as a learning experience with InfoPath and SharePoint integration. I had read about how easy it is to create the form templates, publish them out to SharePoint, and then aggregate the data or use it in other meaningful ways.

I created my form just fine and set the submit properties to submit it to the SharePoint document library. The trick was going to be setting up security so that users could see their own documents but not anyone elses and also allow the CEO to have his views that no one else could see.

I began doing some research into security trimming views in a SharePoint list and found many people saying that Microsoft did not include this functionality and they were right. Although you can security trim all the way down to items in a list, there is no way to allow certain views to be displayed to some users and other views displayed to other users. I found a blog post that described a hack to get around this. I tried determining who the current user was and then display only those items that they were allowed to see. The problem with this was that the user still had access to all of the views and could modify the views to see whatever they wanted.

I then tried to find a way to build functionality into the InfoPath form to only allow certain users to see certain things. This did not fair all that well either. I could make it so only certain users could see one view on the form and others saw a different view, but when a user tried to open their own form again, they were being sent to the second view when they shouldn't have been.

The next thing I am going to try, is to add some programming logic into the form to see if I can set the permissions on the list item in the SharePoint list. As a last resort I could always add an event handler to the list and set the permissions on each item in the list when it is added. It seems like there should be an easier way to add security to views on a SharePoint list and allow users to see only what they should see.

Upgrading from WSS 3.0 to Search Server 2008

A couple of weeks ago a colleague and me were sent to install WSS 3.0 and Search Server 2008 Express at a clients. Before we went up there I did some research as to the best way to install this combination. Did we need more than one server, one to run WSS and one to run Search Server? Can they coexist peacefully? Can you upgrade WSS to Search Server? These were all questions that were running through my head.

I did a search on the web and found a TechNet article entitled, Upgrade to Search Server 2008 from Windows SharePoint Services 3.0. The article outlined the process to take to successfully deploy both platforms. The good news that they can coexist on the same server and the upgrade is pretty straight forward.

There are a few items to consider first. Make sure that your SQL Server is running SQL 200 with service pack 4 or SQL Server 2005 with service pack 2. If you don't make sure of this, you will get pretty far into the installation before you find any issues. Also you can't upgrade from WSS 2.0 to Search Server 2008. To upgrade WSS 3.0 you will need to make sure that you installed Service Pack 1 for WSS 3.0 prior to the Search Server upgrade. You can get a slipstream version of WSS 3.0 that already contains the service pack here. Once you have WSS installed, you simply run the Search Server 2008 installation and then re-run the SharePoint configuration wizard.

Some additional things that we found when doing installations include:

Create your web application in WSS if one doesn't exist already before upgrading to Search Server. This makes the process a little easier as Search Server will make the changes needed to integrate itself into existing web apps. You can wait to create a web application and a site collection until after you install Search Server, you will just need to do a few more manual steps.

Keep in mind that Search Server 2008 Express (the free version) can not be extended into a farm.

Once you have installed Search Server 2008, you will notice that the Shared Services link will take you to the Search Administration page where you can control content sources, crawl rules, federated sources, and crawl schedules. If you want to access the keyword best bets, you will not find these on the Search Administration page. These can be found under the Search Center settings.

Search Server 2008 provides enterprise search that works well with the collaboration of SharePoint. With federated sources, you can include searchs from Yahoo!, Live Search, and others to allow your employees to search internally and externally at the same time. All of this is extensible as well so that you can write your own federated source connectors.