In order to do site specific search (a.k.a. “This Site” scope) you can append a query string parameter as follows-
http://server/results.aspx?k=sharepoint&u=http%3A%2F%2Fserver%2Flists
Problem
The above will return zero results if you have a server name mapping configured in your search settings-
Solution
Removing the server name mapping will resolve this issue and site specific search works as expected
Tip: Adding a query string url restriction is equivalent to the following-
Problem
After installing Kwizcom Calendar 3.2.90, text selection is disabled on your sharepoint site on pages that have the calendar webpart. This was a huge issue for us since we had the minicalendar in the page header.
Workaround
Modify one of the Kwizcom javascript files (“12\TEMPLATE\LAYOUTS\KWizCom_KSCP\KSCP.js”) to comment out the drag drop functionality (See lines 13, 21 & 22) -
1: function kwiz_cal_DragDropOnLoad(q)
2: {
3: g_WPQ = q;
4:
5: // attach onscroll event (needed for recalculating table cells positions)
6: window.onscroll = kwiz_cal_Scroll;
7:
8: if(browseris.ie || browseris.safari)
9: {
10: kwiz_cal_Calculate_Cells();
11:
12: // disable text selection for ie, safari
13: //document.onselectstart = function(event) {return false};
14: }
15: else
16: {
17: // firefox does not execute this function when assigning to onscroll event, but IE & Chrome do
18: kwiz_cal_Scroll();
19:
20: // disable text selection for firefox
21: //if (typeof document.body.style.MozUserSelect != "undefined")
22: // document.body.style.MozUserSelect = "none";
23: }
24: }
More Info
The official word from Kwizcom Support on this issue is as follows:
“The issue is caused by dragdrop functionality. The new release version 3.3.00 will allow the users to disable drag drop through settings. Currently there is no exact timeline for release.”
Are your alert emails defaulting to the generic template (SPAlertTemplateType.GenericList) even after you’ve specifically updated the list to use a custom alert email template (using myList.AlertTemplate)?
Turns out that if you already have an existing alert setup on the list then even if you switch the list to use a different alert template, sharepoint sends you alert emails using the template that was assigned to the list when you ORIGINALLY setup the alert.
So the SOLUTION is to delete your existing alert and re-subscribe to the list.
If you would like to know more on how to customize the alert email templates in sharepoint then this is a great resource: Customizing Alert Notifications and Alert Templates in Windows SharePoint Services 3.0
We recently upgraded one of our SharePoint boxes to Service Pack 2 of Windows Server 2003. The upgrade broke our Content Deployment from the upgraded server to any other servers. The error message in Central Admin said something to the tune of “The remote web upload request failed”
Upon further investigation I found out from the IIS logs on the target machine that all the exported .cab files were actually being transferred over successfully and IIS was returning back a status code of 200 for each transfer. However on the last CAB file upload, IIS returned a status code of 400 every time for some reason. After that, everything just died out and the source machine could not confirm that the transfer was complete.
Rob has a more detailed account of why SP2 broke Content Deployment but in short, the fix involved making changes to the registry since service pack 2 has issues with networking and I am being told that there is no way to roll-back from SP2.
SharePoint 2007 has really nice looking alerts that you can configure from the site itself. For example, you can subscribe to a discussion board by clicking “Actions > Alert Me” and you will start receiving alerts if and when there are changes on that discussion board.
However, if you want to make changes to how the alert email looks – perhaps to make the email look more like your corporate emails – you have to modify a file called alerttemplates.xml located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\XML. Combined-Knowledge has a great white-paper on how to do so.
However, I just wasted a bit of my time figuring out why my changes were not taking effect. It turns out that after making changes to your alert template, you must use the stsadm -o updatealerttemplates to update the alert template for the site collection you want. Then you MUST re-subscribe yourself to receive the alert by clicking “Actions > Alert Me“
It appears that the site creates a separate alert template for each user. Seems inefficient if it is true – can someone confirm this?
MOSS 2007 allows for the ability to send emails (incoming email) to Document Libraries and Discussion lists etc., so that content is automatically populated in these lists and libraries.
Sharepoint also allows the ability to send out emails (outgoing email) for things such as Content Deployment jobs.
We put 2 & 2 together and thought – “Why don’t we setup a list called ‘Alerts’ that will receive daily emails from our Content Deployment job? That way whoever wants to receive these can setup an ‘Alert’ on the Alerts list”. It was an excellent idea except for the fact that it DIDN’T work!
After a bit of snooping around it turns out that Sharepoint doesn’t like receiving email from itself! Here is the email that was dropped into the SMTP drop folder and was picked up by the timer service-
1: x-sender: ALERTS@computer.domain
2: x-receiver: ALERTS@computer.domain
3: Received: from computer ([127.0.0.1]) by computer.domain with Microsoft SMTPSVC(6.0.3790.1830);
4: Wed, 22 Aug 2007 17:50:37 -0400
5: Date: 22 Aug 2007 17:50:37 -0400
6: From: <ALERTS@computer.domain>
7: To: <ALERTS@computer.domain>
8: Content-Transfer-Encoding: 8bit
9: Content-Type: text/html; charset=utf-8
10: Subject: JOB FAILED: Content deployment job 'INCREMENTAL deploy' started at 8/22/2007 5:50:31 PM
11: MIME-Version: 1.0
12: X-Mailer: Windows SharePoint Services (version 3)
13: Return-Path: ALERTS@computer.domain
14: Message-ID: <computerXvpFVjCR00000005@computer.domain>
15: X-OriginalArrivalTime: 22 Aug 2007 21:50:37.0488 (UTC) FILETIME=[79882B00:01C7E506]
16:
17: The content deployment job 'INCREMENTAL deploy' on path 'Dev to Production' failed. A detailed report is available at: <a href="http://computer:8000/_admin/DeploymentReport.aspx?ReportId=77b99034-ba11-4072-9983-ba1ee4dc8483" >http://computer:8000/_admin/DeploymentReport.aspx?ReportId=77b99034-ba11-4072-9983-ba1ee4dc8483</a>
Notice on Line 12 that the X-Mailer is “Windows SharePoint Services (version 3)”. This email was REJECTED after being picked up
So I replaced the X-Mailer header with Outlook Express’s X-Mailer header-
1: x-sender: ALERTS@computer.domain
2: x-receiver: ALERTS@computer.domain
3: Received: from computer ([127.0.0.1]) by computer.domain with Microsoft SMTPSVC(6.0.3790.1830);
4: Wed, 22 Aug 2007 17:50:37 -0400
5: Date: 22 Aug 2007 17:50:37 -0400
6: From: <ALERTS@computer.domain>
7: To: <ALERTS@computer.domain>
8: Content-Transfer-Encoding: 8bit
9: Content-Type: text/html; charset=utf-8
10: Subject: JOB FAILED: Content deployment job 'INCREMENTAL deploy' started at 8/22/2007 5:50:31 PM
11: MIME-Version: 1.0
12: X-Mailer: Microsoft Outlook Express 6.00.3790.2929
13: Return-Path: ALERTS@computer.domain
14: Message-ID: <computerXvpFVjCR00000005@computer.domain>
15: X-OriginalArrivalTime: 22 Aug 2007 21:50:37.0488 (UTC) FILETIME=[79882B00:01C7E506]
16:
17: The content deployment job 'INCREMENTAL deploy' on path 'Dev to Production' failed. A detailed report is available at: <a href="http://computer:8000/_admin/DeploymentReport.aspx?ReportId=77b99034-ba11-4072-9983-ba1ee4dc8483" >http://computer:8000/_admin/DeploymentReport.aspx?ReportId=77b99034-ba11-4072-9983-ba1ee4dc8483</a>
And Lo and Behold, this email was picked up and processed and it showed up in my Alerts list!
I’m not sure if this is a bug or not because one can imagine a scenario where an alert for a list goes out to the same email address as the incoming email address for the list. The developers were probably trying to prevent an infinite loop in such a scenario. However, that means that even for all legit purposes, you CANNOT HAVE SHAREPOINT EMAIL ITSELF.
There is an issue in Vista where a user tries to open a document from a document library in Sharepoint and they are prompted by Office to authenticate themselves. This would be acceptable behavior if the user weren’t already authenticated on the MOSS site they were browsing.
For some reason, when XP users try to open the same document from Sharepoint, they DO NOT get prompted for authentication. This is a Vista only issue. I’ve stumbled across many newsgroup posts that claim that this issue has something to do with the “Protected Mode” in IE7. Their recommended solution is to add the Sharepoint site to Trusted Sites in Internet Explorer 7 and to disable “Protected Mode”.
However, even after adding the site to trusted sites in IE and disabling protected mode, the issue still persists. The issue is only replicable after a fresh reboot – once a user authenticates in office, those credentials are cached for future use. Due to this caching in office, many people cannot pinpoint how to replicate this issue.
The First SOLUTION to this issue is to DISABLE the WebClient service in Vista. Here is a quick script that accomplishes this: VistaMossOfficeMossSSOFix.bat Here is the code for those who’d like to incorporate this script into their environment:
net stop "WebClient" WMIC SERVICE WHERE Caption="WebClient" CALL ChangeStartMode "Disabled"
There is also a second workaround that involves tricking IE to use a fake proxy and to have IE bypass the fake proxy for everything – this workaround is PREFERRED since the first Solutions ends up severing some of the nicer integration features between Office and MOSS (such as the ability to save directly from office on to a sharepoint document library)
In Internet Options, click the “Connections” tab and then click “LAN Settings”:
Click “Advanced” and enter * as an exception to the proxy:
In conclusion, the SECOND SOLUTION seems to be more appropriate as the first one tends to do more harm than good.