On many of the lists in my farm, there are custom columns based on the needs of the group that is using the list. Every once in a while, we need to add a new content type to an existing list and want it to make use of those existing custom columns. When I first encountered this need, my search results were pretty fruitless and most of what I found said it could not be done. In fact, it can be done so I thought I'd share how I did it in case anyone else finds themselves in this position.

1. In the list where you have your custom columns, go ahead and add the new content type that you were wanting to add. In my case, I wanted to add the "Link to a Document" content type and wanted it to make use of the "Category" custom field that had been created in that list.
2. Go into List Settings (or Document Library Settings if you are adding a content type to a document library instead of a list)
3. Click on the content type you wish to add the custom column(s) to
4. Click the link for Add from existing site or list columns
5. Be sure that List Columns is showing in the drop down under Select columns from: and move the columns you want to add from the left side to the right side and click the OK button

That's it! I know this seems a bit simplistic but I think that what caught me and probably caught those who said this couldn't be done thought it wasn't working because I noticed that the custom columns I wanted to use wouldn't show up on the form until I went to check the item in. At first, when I clicked on new Link to a Document, I just got the name & URL boxes. But, once I filled them out and clicked OK, the check-in form appeared containing my custom columns.

I have been running the Office 2010 beta for several months now and have been extremely happy with it. Naturally, many applications don't understand how to work with it or detect it properly yet so, as one would expect with a new beta, there are some tweaks required to get things working properly. One such thing is the ability to use Access 2010 to edit a SharePoint list in Datasheet View.

When you first install Office 2010 and then try to edit a SharePoint list in Datasheet View, you'll receive a quaint little message telling you that "a datasheet component compatible with Windows SharePoint Services is not installed". While I'm sure this will be resolved by the time Office 2010 RTMs next month, in the mean time a tweak to correct is necessary.

I was able to find this great post on allowing SharePoint 2007 to properly detect the Office 2010 clients and this has worked on a mix of systems running Windows Vista & Windows 7, both 32 & 64 bit flavors. Thanks to Ivan for writing such a great and useful post!

http://neganov.blogspot.com/2009/11/cannot-edit-sharepoint-2007-list-in.html

A freind of mine wrote this great post on cross-site list views using RSS Feeds and keeping permissions intact. His steps were immensely useful in our environment and I wanted to make sure I shared it.

We are applying the steps outlined in Bryan's post to take the contents of a list view that exists in a departmental site and display the contents of that view on a person's MySite while still maintaining permissions to that list to prevent unauthorized access. Really great post.

http://fsugeiger.blogspot.com/2010/03/cross-site-rss-feed-with-sharepoint.html

After recently converting our SharePoint farm's authentication method from NTLM to Kerberos for Excel Services, PerformancePoint, and SSRS Integration among other things in a distributed environment, I found that People Search stopped working. Search for all other content within our content sources, both inside and outside of SharePoint, continued to work just fine. However, when you perform a search within the People Search, no results would be displayed.

To resolve this, I went into Application Management within the Central Administrator and Extended the web app that MySites were on (which is where the search gathers its People info for during an index) and created a new site that was using NTLM authentication instead of Kerberos. Next, I changed our content source in the SSP's Search Settings so that the People Search utilized the new MySite site instead of the normal one that is using Kerberos - sps3://mysite.domain.com:5556 instead of sps3://mysite.domain.com

Run a full crawl and Voila! - People Search started working properly.

To cut down on the possibility that someone would stumble across the new site and utilize it without Kerberos Authentication, I restricted access to this site via an IIS 7 Authorization Rule so that only the SharePoint service accounts are allowed to access that site. I also created a Server Name Mapping in Search Settings so that anything found in mysite.domain.com:5556 would be automatically rewritten as mysite.domain.com so that users won't know the difference.

I found myself very frustrated earlier this week when I found that SharePoint search was not working. It wasn't returning any errors when you submitted a search. It just wouldn't provide any results.

After a quick glance at the error logs, I found I was getting an Event ID 2436 saying Access Denied:

Details: Access is denied. Verify that either the
Default Content Access Account has access to this repository, or add
a crawl rule to crawl this repository. If the repository being crawled is a
SharePoint repository, verify that the account you are using has
"Full Read" permissions on the SharePoint Web Application
being crawled. (0x80041205)

Naturally, I immediately checked my Web Application Policy to confirm that my Search account had Read Access in case someone inadvertantly removed it. However, it was still there.

After about half the morning of removing and re-adding permissions and resetting passwords and re-creating the index, I finally found several posts pointing at the .NET 3.5 SP1 update causing this problem. Sure enough, the update had been installed over the weekend.

Thankfully, this one was an easy fix that could be done on the fly. Open RegEdit and go to HKLP\System\CurrentControlSet\Control\Lsa and create a new DWORD value named DisableLoopbackCheck. Then, set the value to 1. Lastly, restart the WSS Search service and then run the following from a command line to initiate a full crawl:

stsadm -o spsearch -action fullcrawlstart

Within a couple minutes, search was back online and users were happy.