Error messages 7888 - "System.Data.SqlClient.SqlException: Could not find stored procedure 'proc_ar_BumpCacheInvalidationCounter'."

This is a known issue, the missing stored procedure is part of the BDC functionality, which is a MOSS 2007 Enterprise feature. The error messages can be safely ignored.

NB: The same error (or similar) can appear if you are trying to use BDC functionality on a MOSS 2007 standard environment. BDC is an enterprise functionality and need enterprise license of MOSS.

Possible solutions here: https://support.microsoft.com/kb/896861/en-us

From Larry Kuhn’s blog:

SharePoint Index Server Local Crawling affected by MS09-014 - KB 963027

I’ve created an application page and I used an InputFormTextBox control to give users the possibility to write some html content. This is the code I used:

<wssawc:InputFormTextBox 
          Title="My Field" 
          ID="myField" 
          Rows="15" 
          Runat="server" 
          TextMode="MultiLine" 
          RichText="true" 
          RichTextMode="FullHtml"/>

You can see the page rendering in the following picture:

As you can see, the control’s width is not at 100% of available space.

Trying to enlarge the control with style and CssClass attributes were unsuccessful. I made some investigations and I discovered that code rendered by the control simply ignores those attributes.

Looking at html generated by the control, I saw that it is rendered as two main element, a table element to display the toolbar and an iframe element for the html container. Both have a css class defined, ms-rtetoolbarmenu for the table (toolbar) and  ms-rtelong for the iframe (html container).

My solution to the problem was to override those classes with the following code

<style type="text/css"> 

table.ms-rtetoolbarmenu{ 
    width:100%;
} 

iframe.ms-rtelong{ 
    width:100%;
} 

</style> 

The page rendering after this modify was:

Hope this can help you.

If you want to do the same with Content Type field, the above hint simply don’t work.

To make it working you have to modify the rendering template of the edit form. To do this you have to create a new rendering template:

1. copy the standard ListForm template from DefaultTemplates.ascx (ControlTemplate folder)
2. create a new ascx file in the same folder and paste ListForm template
3. change the template id to MyCustomForm
4. remove the Sharepoint ContentTypeChoice control from the custom template

Then you have to associate the edit form to the custom template created above, to do this you can modify the content type definition inserting XmlDocuments tag under ContentType tag like in the following example:

<XmlDocuments>
  <XmlDocument 
  NamespaceURI="https://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
    <FormTemplates  
    xmlns="https://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
      <Display>ListForm</Display>
      <Edit>MyCustomForm</Edit>
      <New>ListForm</New>
    </FormTemplates>
  </XmlDocument>
</XmlDocuments>

If you don’t have content type you can change the list definition schema by using the following code:

<Forms>
  <Form Type="DisplayForm" 
        Url="DispForm.aspx" 
        SetupPath="pages\form.aspx" 
        WebPartZoneID="Main" />
  <Form Type="EditForm" 
        Url="EditForm.aspx" 
        SetupPath="pages\form.aspx" 
        Template="MyCustomForm" 
        WebPartZoneID="Main" />
  <Form Type="NewForm" 
        Url="NewForm.aspx" 
        SetupPath="pages\form.aspx" 
        WebPartZoneID="Main" />
</Forms>

HTH
Dario

In WSS, when you click on a profile link you are redirected to the User Information Page used by WSS to display WSS profile informations, this page is userdisp.aspx and is located in the same web.

In MOSS (with profile services enabled), instead, when you click on a profile link you are redirected to a different User Information Page, person.aspx. This page is the page showing the public profile of a user and is located under mysite site collection.

Sometimes happens that in MOSS (with profile services enabled), when you click on a profile link you are redirected to userdisp.aspx instead of person.aspx and this page doesn’t permit you to change user profile attributes. I will give you in a moment a reason for this behaviour.

When you are in MOSS and click on a profile link, you are always redirected to userdisp.aspx. This page loads ProfileRedirect control which uses MySiteRedirectionUserControl to redirect to public profile page on mysite. For security reasons, this redirection is made only if the public profile page url is safe.

What does it mean safe? Ok, right question!

The following URLs are considered safe in redirection:

1. Same host name as the original URL (portal at https://mycompany:80, and my site under https://mycompany:8080).
2. The URL to be redirected is a Portal URL. That is, if we set Portal site connection (from site actions -> site settings -> Portal site connection) to be
   https://mysite.[hostheader], https://mysite... will then be considered as a safe URL.
3. Loop back addresses like https://localhost, https://127.0.0.1.

HTH

Dario

If you simply use  

<xsl:value-of select="@Attachments"/>

the result displayed will be a boolean (Yes/No) value. If you want to display the list of attachments with corresponding links you must use AttachmentsField control as described below. This control contains the logic needed to get the attachments and render the list with links.

First of all, locate the template with name dvt_1 and add the html code to insert a new column header like in the following example:

    <xsl:template name="dvt_1">
        <xsl:variable name="dvt_StyleName">Table</xsl:variable>
        <xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row"/>
        <table border="0" width="100%" cellpadding="2" cellspacing="0">
            <tr valign="top">
                <xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">
                    <th class="ms-vh" width="1%" nowrap="nowrap"></th>
                </xsl:if>
                <th class="ms-vh" nowrap="nowrap">Title</th>
                <th class="ms-vh" nowrap="nowrap">Author</th>
                <th class="ms-vh" nowrap="nowrap">Modified</th>
                <th class="ms-vh" nowrap="nowrap">Attachments</th>
            </tr>
            <xsl:call-template name="dvt_1.body">
                <xsl:with-param name="Rows" select="$Rows"/>
            </xsl:call-template>
        </table>
    </xsl:template>

Now, locate the dvt_1.rowview template and add a new column with the AttachmentsField control:

<xsl:template name="dvt_1.rowview">
  <tr>
      <xsl:if test="position() mod 2 = 1">
          <xsl:attribute name="class">ms-alternating</xsl:attribute>
      </xsl:if>
      <xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">
          <td class="ms-vb" width="1%" nowrap="nowrap">
              <span ddwrt:amkeyfield="ID" 
                        ddwrt:amkeyvalue="ddwrt:EscapeDelims(string(@ID))" 
                        ddwrt:ammode="view">
              </span>
          </td>
      </xsl:if>
      <td class="ms-vb">
          <xsl:value-of select="@Title"/>
      </td>
      <td class="ms-vb">
          <xsl:value-of select="@Editor" disable-output-escaping="yes"/>
      </td>
      <td class="ms-vb">
        <xsl:value-of select="ddwrt:FormatDate(string(@Modified), 1040, 5)"/>
      </td>
      <td class="ms-vb">
          <xsl:element name="SharePoint:AttachmentsField">
          <xsl:attribute name="runat">server</xsl:attribute>
          <xsl:attribute name="ListId">
                 {D2C70ED5-8551-446D-B0CF-AC4B30387CF0}
          </xsl:attribute>
          <xsl:attribute name="FieldName">Attachments</xsl:attribute>
          <xsl:attribute name="ControlMode">Display</xsl:attribute>
          <xsl:attribute name="Visible">true</xsl:attribute>
          <xsl:attribute name="ItemId">
              <xsl:value-of select="@ID"/>
          </xsl:attribute>
          </xsl:element>
      </td>
  </tr>
</xsl:template>

Important: you must change the value of ListId attribute with your list id!

HTH

Dario

If you have multiple farms (or simply one farm with two or more SSPs) and you want to set-up User Profiles and My Sites that are shared between SSPs, this post is for you.

Introduction and Sample Scenario

Let me describe a sample scenario with geographically distributed farms. In this scenario, users work in different regions, each of which uses a different SSP. Some users have to collaborate across regions, and must have access to multiple SSPs. This is particularly common if an employee in a global deployment moves between geographic locations.

Suppose that, as usually, users of each farm are configured in the same forest.

If you want to give users the possibility to see other users’ profiles you have to configure in each farm the import of profiles from Active Directory and if you want that users in a region can see profile of users of other regions you have to import all users profiles in each farm.

This works well and in each farm you can see all users details but what happen if you want to give users the possibility to update their details (like skills, blog site and so on)? Let me show you an example: MyLinks. MyUser1 is browsing a site collection located in Farm 1 and adds a shortcut to a page with MyLinks OOB functionality. This link is recorded in a property of the user profile on SSP1. If the same user MyUser1 goes to a different site collection hosted on Farm 2 and looks at the list of his links he cannot find the previous added link on Farm 1. This happens because of Farm 2 is using a different SSP and user profiles are not synchronized between SSPs.

We have a similar behavior with My sites. Each SSP hosts My Sites, so if a user click on MySite link from a site on Farm 1 he is redirected to the MySite hosted on SSP1 but if the same user click on MySite link from a site on Farm 2 he is redirected to a different MySite hosted on SSP2.

Ok, it seems quite bad but… MOSS has My Site Host Locations! If you don’t know what host locations are, you can read the following two paragraphs (from technet).

My Site host locations

As the name says, a My Site host location is the location where My Sites reside. A My Site host location is created automatically when a Shared Services Provider (SSP) is created. The host location is created in its own site collection on the default Web application, and all personal sites are stored in that location. In most scenarios, this is the only My Site host location for the entire deployment of Microsoft Office SharePoint Server 2007. Users can view My Sites if the SSP for the My Site host location imports their user profile information from directory services, and only if they have the Create personal site permission enabled. Individual personal sites are created when individual users click the My Site link on the top link bar of the site.

Managing multiple My Site host locations over multiple SSPs

In some cases, like our scenario, users can be members of two or more sites that use different SSPs and different My Site host locations. In that case, by default, the user can see the My Sites in the host location used for the SSP of the current site. My Sites in other host locations cannot be seen, and the personalization features of those sites cannot be used. This configuration results in an unpredictable My Site experience. Each user's My Site changes depending upon the site, and the My Sites of other users are not reliably available on each site.

To avoid this situation, it is usually a good practice to limit each user to one SSP. However, in our scenario, this is not possible and it is a good idea to think through the reasons for multiple SSPs and then create a predictable experience for My Sites and personalized content.

To enable users to view My Sites and use personal features on multiple host locations, each host location must enable support for global deployments on the My Site Settings page. This makes personalized content on each host location available across SSPs, but only if the host location is trusted by an SSP. Each SSP has a list of trusted My Site host locations links. Each link can be targeted so that only users in selected audiences can view My Sites in a particular host location. Profile information for all targeted users is replicated to each SSP and is available to all sites on the SSP. My Site host locations are used by each SSP in the order of the trusted My Site host locations list. If a user is a member of an audience targeted by one host location link, then that My Site host location is used for that SSP and the later host locations are ignored. This results in one set of personalized content for each user being made available to all targeted users in each SSP.

Configuration and Interface Behavior

Coming back to our sample scenario, to appropriately configure My Site host locations we have to enable on each SSP support for global deployments and define for each SSP the following host locations:

• Host Location 1 (Region 1), targeted to audience “Users of Region 1”
• Host Location 2 (Region 2), targeted to audience “Users of Region 2”
• Host Location 3 (Region 3), targeted to audience “Users of Region 3”

After that the My Site link in each site of each farm will point to the My Site in the SSP where the user belongs. Furthermore, the “Add Link” and “Manage Links” links are targeted to the same (correct) SSP. All other functionalities that show profile information (such as the list of links defined by the user) are instead targeted to the SSP which is related to the current site. This underlines the needs of a profile replication mechanism (described later in this post).

This picture illustrates MOSS behavior for a user belonging to Region 2:

The following picture shows the option to be enabled in My Site Settings page of each SSP

This picture shows the Add new My Sit Host Location form:

Replication of User Profiles

To keep MOSS 2007 profile data across three worldwide regions consistent for People Search and Audiences targeting we need a Geo Replication mechanism.

Each farm hosts only a subset of user’s MySites/Profiles and can be consider as “Master” on this subset of users for the other farms. So the replication engine should replicate user profiles from each Master farm versus other farms.

Microsoft has released the Sharepoint Administration Toolkit which include User Profile Replication Engine, a tool that does replication of user profiles.

The replication mechanism can be represented by this picture:

First of all you need to discover the correct URLs to use as search engines/providers.

Open your Search Centre (for example https://search.litewareinc.com/) and search for something using the default scope. You will be redirect probably to a page like https://search.litewareinc.com/Pages/results.aspx?k=SOMETHING, write down this URL.

Now change the scope (if you have defined scopes, obviously) and perform the search again. The URL should be https://search.litewareinc.com/Pages/results.aspx?k=SOMETHING&s=MYSCOPE, write down this URL also.

(NB: You should write down an URL for each scope you have defined)

Don’t forget to search for people and write down the corresponding URL, it should looks like https://search.litewareinc.com/Pages/peopleresults.aspx?k=SOMETHING.

The last URL you need is the Search Web Service URL: https://search.litewareinc.com/_vti_bin/search.asmx

At the end you should have something like this:

• Search with Web Site
  • https://search.litewareinc.com/Pages/results.aspx?k=SOMETHING
  • https://search.litewareinc.com/Pages/results.aspx?k=SOMETHING&s=MYSCOPE1
  • https://search.litewareinc.com/Pages/results.aspx?k=SOMETHING&s=MYSCOPE2
  • https://search.litewareinc.com/Pages/peopleresults.aspx?k=SOMETHING
• Search with Web Service
  • https://search.litewareinc.com/_vti_bin/search.asmx

Note that MYSCOPE, MYSCOPE1 and MYSCOPE2 are your scopes and are fixed, instead you will have to replace the word SOMETHING with $w or TEST depending on the configuration you are doing (described below).

Now take a look at how to configure this Unified Search Experience in different products/technologies.

Configuring Windows Search 4.0 (beta) on Windows XP

You can customize the behavior of WS4.0 by adding a new button in Search Bar to search for the “Primary Intranet Search Location”. Besides you can also add other “Secondary Intranet Search Locations” that will be visible in Search Companion location selection menu.

To perform this configuration, you have to work with local computer policies (you can also create group policy objects to manage this settings centrally) following the steps below:

• Run gpedit.msc
• Right click on Administrative Templates under Computer Configuration and select “Add/Remove templates…”
• Verify that Search.adm is listed otherwise add it from c:\windows\inf
• Now locate “Add Primary Intranet Search Location” under “Windows Component\Search”
• Right click --> properties
• Enable it and specify the value with the sintax: name,url - for example you can use the default scope specifying this value: MyIntranet,https://search.litewareinc.com/Pages/results.aspx?k=$w
  Note that you must replace SOMETHING with $w
• Apply the changes
• Now Locate “Add Secondary Intranet Search Locations” and enable it specifying all other locations with the following sintax: name1,url1;name2,url2;name3,url3
• Apply changes

After above steps you will be able to search in MOSS also within WS4.0 Search Bar and Search Companion.

Useful links:

Windows Search 4.0 Administrator's Guide
https://technet2.microsoft.com/windowsserver2008/en/library/f98696ed-6e3e-47b7-ab38-511439bce7ae1033.mspx?mfr=true

Group Policy for Windows Search
https://technet2.microsoft.com/windowsserver2008/en/library/c55e6003-8b70-4d5e-a0ce-55c25a35015a1033.mspx?mfr=true

Configuring Windows Vista Search
(from Mark Harrison’s post)

You can add an Intranet search location directly into Windows Vista Desktop. To perform this configuration, you have to work with local computer policies (you can also create group policy objects to manage this settings centrally) following the steps below:

• Run gpedit.msc (requires elevation)
• Locate “Custom Instant Search Internet Search Provider” under “User Configuration --> Administrative Templates --> Windows Components --> Instant Search”
• Right click --> properties
• Enable it and specify a name (ex: Search MSWeb) and the url of the default scope (ex: https://search.litewareinc.com/Pages/results.aspx?k=$w)
  Note that you must replace SOMETHING with $w
• Apply the changes
• You must reboot or run gpupdate /force from an elevated prompt

Now you will find a new search location in Vista Search Window like the following

Configuring Office Research Task Pane

Both Office 2003 and Office 2007 include the Research Task Pane that permits to add external search services to be used for querying external content. This is accomplished by implementing a well defined contract that MOSS2007 exposes out of the box. In this case we will use the “Search with Web Service” URL defined above.

Open for example MS Word 2007 (in 2003 is quite similar), click on Review and then on Research: this will shows the Research Task Pane.

Now click on the “Research options” bottom link and then click the “Add services…” button.

Specify the address of your Web Service and follow the instructions.

Now you are able, inside Word, to search for content indexed by MOSS and the results will be displayed (grouped) together with results from other services.

This configuration automatically affects also other MS Office applications and also IE.

Configuring IE7

In IE7 you can add custom search providers which will be added to the search provider list available via Search Options (down arrow near search box and magnifying glass).

To do it, you have to click on “Find More Providers…” in the search Options Menu. It will display a web page in which you have to specify your Own Provider using the “Search with Web Site” URLs defined above. Don’t forget to replace the word SOMETHING with the word TEST. Click Install to add it to your provider list.

When you will have installed all URLs, you will be able to use IE7 search box to search for content inside the corresponding scope in MOSS simply by selecting it in Search Options Menu.

• Batch Site Manager
  Feature accessibile dalla pagina Application Management della Central Administration che permetterà di gestire e amministrare operazioni multiple inerenti la cancellazione, lo spostamento e il blocco (lock) di una o più Site Collection all'interno della stessa Web Application.
• Alert Fixer
  Una nuova operazione (updatealert) di STSADM.EXE che dà la possibilità ad un amministratore, in seguito ad un cambio dell'indirizzo di una Web Application, di aggiornare l'URL della Web Application usato nelle email di alert.

Il toolkit è scaricabile qui (la versione x64 invece è scaricabile qui) ma consiglio vivamente di leggere il relativo White Paper che illustra anche alcuni aspetti dell'installazione e i requisiti per il corretto funzionamento.