I ran into an interesting problem this week in SharePoint (MOSS). On some sub-web sites, the attachment (paperclip) icon disappeared. I also noted that some other miscellaneous icons were replaced with the ugly red X. However, this problem did not occur in the top level site in the collection. Odd.

I checked permissions all over the place and couldn't find any reason why this would be happening. Then I discovered through a forum that the application pool settings do indeed affect permissions to virtual directories. A colleague had recently changed the primary application pool for our portal as a troubleshooting step with Microsoft support (we're experiencing some memory leak issues).

The changed application pool propogated down from the web site to the virtual directories, but not to the applications below (such as 'images'). Voila! Changed the app pools on those applications to the new app pool and everything worked again.

Another SharePoint mystery solved!

There are plenty of blogs and articles that explain how to add properties to Advanced Search in MOSS, so I'm not going to get into that here.

What I have found is that there is an issue with the ModifiedBy property, where by default, the number of items found with this property is a big fat zero (0).

Finally, a solution that works!

The post is here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2195994&SiteID=1&mode=1

I have copied Pritam Dahake's solution in case the forum post is somehow deleted:

Here are the steps to manually hook the Last Modified By field to the creawled field.

1) Open Central administration -> Shared Services -> SharedServices (X being the number of the shared services provider for the site you are creating a mapping)  - > search settings -> metadata property mappings
2) Click “Modifiedby” to edit the properties
3) Make sure  “Include values from all crawled properties mapped” is selected
4) Click “add mapping” and select the “Office” category from the dropdown list.
5) look for a property named “OFFICE:8” , click “OK”
6) Click “add mapping” and select the “ows_Last_x0020_Modified(text)” from the ALL categories dropdown list, Click “OK”
7)  Make sure the box is checked “Allow this property to be used in scopes”, click “OK”
8) Click on “Crawled Properties” link on the left side of the Shared Services Administration page.
9) Click On the “Office” Category.
10) The mapped property you just created should be listed in the “Mapped To” column of the Office:8(Text) category.
11) Click on the Office:8(Text) category to view the properties.
12) In the “name and information” section, you should see the “property Set ID:” value is  'F29F85E0-4FF9-1068-AB91-08002B27B3D9' ...This is very important!!!
13) In the “Mappings to managed properties” section the managed property you edited in steps 2 – 7 should be listed.
14) The box to “Include values for this property in the search index” should be checked.
15) Click “OK” to exit this page.
16) Open “Shared Services administration” -> “ShareservicesX” -> “Search Settings” -> “Content Sources and crawl schedules”
17) Click on “Local Office SharePoint Server sites” to expand the dropdown list and select “Start full crawl”
18) When the crawl has completed, navigate to the site collection -> click on the search tab.
19) Select “Advanced Search”
20) In the properties dropdown list select "Last Modified By"
21) Select contains
22) Enter a name that you know has added / edited a document
23) Click the magnifier to execute the search
24) Get back results.

 WOOHOO to Pritam!

Many people within my company have asked how they can add links to documents inside their document libraries so that there are not multiple copies of a single document floating around the system.

A quick and easy way to do this is to add a content type of Link to a Document and then use this content type for links.

How to set this up:

In your document library, go into Settings / Document Library Settings

Click on Advanced Settings and ensure that Allow Management of Content Types? is set to Yes.

From the Settings page, click Add from existing site content types

Select Link to a Document, click Add and click OK

From within the document library, select the drop-down arrow next to New and choose Link to a Document

Enter the document name and URL

• You can get the URL from another document by choosing the target document's drop-down menu and selecting Send To E-Mail a Link
• An email will open automatically 
• Copy and paste the link from the email into the URL field on the New Link to a Document form

Click OK and you will see the new document link in your document library view

[Note: Someone has documented these steps with pictures here! http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=49 ]

Problem: Alerts on document libraries in MOSS work for portal administrators, but not for regular users. Regular users do receive the email notifying them that their alert has been set up.

Information: This was only happening on sites created with custom site definitions. Testing showed that the 'approval' permission could be added to the Members or other group of the site and alerts would then work for those users, but that is not a good solution for most environments.

Solution: Not a pretty one, but the best that Microsoft could come up with.

On all document libraries on custom site definition sites, break permissions inheritance and then re-inherit. It seems that something was broken in the site definition with regard to permissions. MS developer support is investigating, but the cause is still unknown.

For months we have been having a problem with spell check in my environment where non-admin users were unable to run spell check within MOSS and receive the error "Spelling did not complete properly. If this problem persists, notify your system administrator."

In my case, users have Read access across the portal except to certain sub-sites where they are given Contribute and other permissions. As it turned out, the library for the custom dictionary that I had created also only had Read permissions for general users. Changing their permissions to Contribute solved the problem.

If you want to setup a custom dictionary in SharePoint you can do so on a Site Collection basis (i.e. one custom dictionary per site collection). To do so:

o                                Create a new Document Library at the root of your site collection called "Spelling"

o                                Upload a text document to this library called "Custom Dictionary.txt"

o                                In the text document place one term per line.

These terms will no longer be detected as spelling mistakes when you do a spell check through the UI.

These instructions came directly from: http://mosschampions.com/blogs/moss/archive/2006/11/21/Configure-a-Custom-Dictionary-for-Spell-Check-in-SharePoint.aspx

 -Just make sure to give all users contribute access to this library!

In trying to create a team site for a department called .../Commercial/Content, I use short names (e.g. .../CML/CON). Apparently CON is some kind of a system no-no. I have not searched on this problem, so there may be information posted out there on this issue somewhere:

When creating a site in Microsoft Office SharePoint Server (MOSS) 2007, the URL cannot be ..../con

The system allowed me to do it, and it created the site, but the page was 100% blank.

Microsoft, how about popping up an error or something when an illegal system name is used, rather than allowing the site to be created?

This post is not about how to configure incoming email (there is a GREAT white paper on the subject here: http://www.combined-knowledge.com/Downloads%202007.htm ). Instead, I will focus on an issue that I ran into while setting it up in a server farm environment with Microsoft Forefront Security. Forefront was installed on both of the front-end web servers.

When I followed the instructions in the white paper How to configure Email Enabled Lists in Moss2007 beta 2 using Exchange 2003 in the domain for receiving both local and external e-mail to the list (note that I opted to NOT automatically create distribution lists and contacts in Active Directory, so did not configure that piece) I found that email made it all the way to the inetput\mailroot\drop folder on the connected front-end MOSS server and was picked up by the timer service, however, an error was consistently reported:

OWSTIMER.EXE (0x0950)                 
Windows SharePoint Services  
E-Mail                       
6874
Warning An error occurred while attempting to create an attachment for an
item sent via e-mail. The e-mail was sent to the list "<doc library name>",
and the error was:

Useful, right?

Through some research and tons of troubleshooting, I disabled Forefront Security on the front-end MOSS servers. For those who are frustrated with it, the services will automatically restart unless you disable them. After disabling the Forefront services, I tried sending email to a document library again and received the following error message:

OWSTIMER.EXE (0x0950)                 
Windows SharePoint Services  
E-Mail                       
6874
Warning An error occurred while attempting to create an attachment for an
item sent via e-mail. The e-mail was sent to the list "<doc library name>",
and the error was: Unknown server error number: d.

I uninstalled Forefront Security and the problem went away, I was able to successfully email documents to document libraries.

At this point I called Microsoft Technical support and was eventually transfered to Forefront security. They provided me with the following fix:

The FSCRealtimeScanner.exe (old AntigenRealtime.exe) is running as Network Service account as default.  It does not have access to SPSTimer service.  There is a hidden registry key “LegacyScanAccount”.  When it is set to 1, FSCRealtimeScanner.exe will run as LocalSystem.

Do the following:

·       Stop FSCController service.  Check task manager to make sure FSCController.exe and all the FSCRealtimeScanner.exe are shut down.
·       Run “iisreset /stop”
·       Run “net stop sptimerv3”
·       Add registry DWORD “LegacyScanAccount” with value 1 under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Forefront Server Security\SharePoint\  for 32 bit machine or HKEY_LOCAL_MACHINE\SOFTWARE\
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Forefront Server
Security\SharePoint\ for 64 bit machine.
·       Run “net start sptimerv3”
·       Run “iisreset /start”
·       Send email to check if it works.  FSCRealtimeScanner.exe should run as SYSTEM after you send an email to doc library.

This worked... of course it also created additional issues created by Forefront. More on those later.

Update [3/14/07]: I have given up on Forefront, after this fix, stsadm would not work and there was some kind of .Net problem. Removing Forefront fixed the problem. Unfortunately, I did not save the event logs and they have rolled over. *Heck*, this all happened the week I went on vacation. I now have Trend Portal Protect for MOSS installed and it appears to be working quite well.