Have you ever needed to update the web.config for your MOSS environment? This can be quite a difficult process as you need to modify it on every server in your farm, and of course monitor it. Today I stumbled over what seems like a pretty good way of doing this using some programming and a feature to deploy the changes. I haven't tried it yet, but probably will have to in the near future so will let you know how it goes.

In the meantime you can enlighten yourself by reading how to do it here.

Some time ago I wrote an article on styling the 'Best Bets' results in SharePoint. Recently I was looking at this XSL, and realised there is a much cleaner way of executing the same solution.

Instead of running a test within each match as per my first example, I think it is actually easier (and cleaner) to create a seperate xsl:template for all best bet results, which calls the individual xsl:template for each result.

So, for example, you would add a new template such as this:

<xsl:template match="Root/BestBetResults">    
  <xsl:if test="count(Result) > 0">
    <p>Recommended Results</p>    
    <xsl:apply-templates select="Result"/>
    <p>Search Results</p>
  </xsl:if>
</xsl:template>

Then you would need to adjust the result template as follows (and of course you can remove the checking to see if it is the first result etc.

<!--The Best Bets template-->
  <xsl:template match="Result">
    <xsl:if test="$DisplayBB = 'True'" >
      <xsl:if test="position() &lt;= $BBLimit" >
        ... <!-- Standard stuff in here -->
      </xsl:if>
    </xsl:if>
  </xsl:template>

I have previously written about one of the great under used features of MOSS 2007 which is email enabled lists, which enables users to be able to send content to an email address, and then have this content automatically appear in a SharePoint list. One of the unfortunate aspects of this is that it can be quite difficult and painful to setup, and there isn't always the most abundant amount of information floating around about it.

I recently setup email enabled lists for a client of mine's production environment but was having all kinds of difficulty. I installed the SMTP component of the setup on the application server, and email seemed to all send to Exchange fine and get into the SMTP queue on the SharePoint Application Server, however it never moved from this queue.

I realised after some playing around that the SMTP server should be on the web front end servers, however this wasn't of much use if I wanted to keep this separate in terms of the Farm setup for our environment. Fortunately I discovered a work around which seems to work fine, which is to create a share on the SMTP drop folder, give the SharePoint Timer Service account permissions to this file share, and then use this file share in the incoming mail settings.

So to configure this in central admin (after setting up the share on the incoming mail folder - by default c:\inetpub\mailroot\drop):

1. Go to 'Configure incoming e-mail settings'
2. Set 'Enable Incoming E-mail' 'Settings mode' to 'Advanced'
3. Set the e-mail drop folder to the shared folder
   eg \\<SMTPSERVER>\drop$