I came across an interesting post from Mark Arend today whichi nicely lists out all the Moss Timer Jobs with a description of what they do along with some assembly info, catch it here:

http://blogs.msdn.com/markarend/archive/2008/09/06/list-of-moss-timer-jobs.aspx

It was posted a while ago. But hey this way I'll find it again easily.

IainW

Over on the SharePoint Team blog they have published details of an update that resolves the product expiration issue with SP2. A quick quote from their blog:

The update can be applied before or after Service Pack 2 installation.  If the update is applied prior to installing Service Pack 2 it will prevent the expiration date from being improperly activated during installation of Service Pack 2, if it is applied after Service Pack 2 it will remove the expiration date incorrectly set during installation of Service Pack 2.

Also they plan on releasing an updated SP2 package that doesn't exhibit this problem, time to update my slipstreamed install sources...

I often go to execute a stsadm command and find it is not in the path on the server I am working on, so I looked for a while of a way of adding it permanently through powershell and then realised it's a straightforward task with .NET code. The following will add the BIN folder within the program files structure to the PATH environment variable at local machine level so that all users will benefit.

   1:  $envpath = [environment]::GetEnvironmentVariable("Path","Machine")

   2:  $binpath = $env:Programfiles + "\Common Files\Microsoft Shared\web server extensions\12\BIN"

   3:  if ($envpath.contains($binpath) -ne $true ) {

   4:  $envpath = $envpath + ";" + $binpath

   5:  [environment]::SetEnvironmentVariable("Path",$envpath,"Machine")

   6:  Write-output "BIN Path added."

   7:  }

   8:  else

   9:  {

  10:  Write-output "BIN Path already added."

  11:  }

I have added a check to not add it if it is already present as the traditional method of using

SET PATH=%PATH%;C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN

ends up with multiple copies of the BIN path in the variable and only applies for the current session.

Setting this up for the first time was a little challenging. I couldn't figure out why no matter what combination of settings and credentials I gave the search service it wouldn't crawl the public folders. I tried crawl rules, complex URLs, content access accounts, but eventually I gave up focusing on SharePoint options and started to look more closely at what was happening at the other end - what was exchange doing?

I had already checked the IIS settings for the public virtual directory and it showed that Basic and Integrated Windows Authentication were both enabled, so I next tried to hit the public folders URL with it in my local intranet zone so that windows would pass through my credentials automatically - just like we set up SharePoint all the time. Anyhow, I realised that no matter what I did with the IIS settings I couldn't get to the page without first entering my credentials on a form based login for OWA. I googled some more to find that although I was setting the authentication options in IIS, there are some additional settings in Exchange System Manger.

If you open ESM, then expand Servers, <server name>, Protocols, HTTP, you'll find the exchange virtual server, if you right click on the virtual server and select properties on the second tab there is an innocuous little box that says "Enable Forms Based Authentication".

So it didn't matter what I did in IIS Manager because it was overridden by the settings here. Well, someone helpfully pointed out in a forum that you can in fact create a second virtual server and set that to work without Exchange FBA. Yay! That's what I need, our existing users can keep their interaction the same on the current URLs, we'll create a new virtual server and set that not to use Exchange FBA, just Windows Integrated authentication and hopefully our crawl will work fine.

So the crawl has reached the end and 18,224 items are indexed and searchable in milliseconds. Lovely. I just need to make sure I've put all the settings back how they should be (you did make a note of all those changes you made as you fiddled in IIS, Exchange & SharePoint didn't you?) and once I'm happy that the URLs are accesible in the right places the job's done.

Working on a new intranet site for a client I was puzzled when only the homepage of the root site collection would appear in search results. We have site collections on managed paths below the root site and those weren't showing either. Crawls were running but the crawl log showed "Some parts of this document cannot be accessed". I checked the sharepoint logs and the windows event log, then googled away as usual but there weren't really any further clues, everything seemed to be as it should be.

I tried a reset all content on the search index and this made no difference, next up I tried a new content source as I had I noticed some blogs and forums had mentioned an error meessage saying

The start address http://intranet/sites/sitename is not valid for this content source type.

So I tried creating a content source of SharePoint Sites pointing at the site collections on managed paths, these also gave this message - Ah!, progress I thought as it gave another clue. But alas, no further clues were to be found. In the absence of any further hits on google revealing an insight that would solve it. I tried a restart on the Search Service and the Timer service followed by a full crawl. And straight away the crawl log started to give me more than just one hit on the new location, by the end of the crawl there were all the results I had been expecting first time round.

The only thing I can think confused it was that we recreated the site collections several times during deployment and that caused it to get confused.

I hope that little gem helps you out of a spot if search isn't bringing back the results you're expecting.

I've just completed a migration from SharePoint Portal Server 2003 to shiny new Moss 2007 implementation. And whilst looking for some content that had gone missing, I noticed that the search results page sometimes took 30 - 60 seconds to return the next page in the result set, whilst on other occasions it came back very quickly. My first thought was perhaps it's busy, all those users making lots of use of it! But no, processor usage on the boxes was all negligible.

As I explored this some more I discovered that it was consistently inconsistent! By which I mean that the first page of a particular query always came back quickly, the second slow, the third and fourth quickly, then the fifth slow and so on.  I think that's a quick step ( - I've been subjected to too much strictly come dancing), anyhow some digging around eventually showed up the following message in the logs:

 12/08/2008 22:32:19.57  w3wp.exe (0x1134)                        0x0EC4 Search Server Common           MS Search Query                0 High     Exception while finishing web request or starting web page read on http://search.live.com/results.aspx?q=safety&count=3&first=1&mkt=en-GB&format=rss&FORM=SHAREF: System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host 194.217.240.73:80     at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)     at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)     --- End of inner exception stack trace ---     at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)     at Microsoft.Office.Server.Search.... 
12/08/2008 22:32:19.57* w3wp.exe (0x1134)                        0x0EC4 Search Server Common           MS Search Query                0 High     ...Federation.HttpAsync.RespCallback(IAsyncResult asynchronousResult) 

and

12/08/2008 22:27:35.20  w3wp.exe (0x1134)                        0x0EC4 Search Server Common           MS Search Query                0 High     Exception while finishing web request or starting web page read on http://search.live.com/QSOnly.aspx?q=safety&count=3&first=1&mkt=en-GB&FORM=SHARES&format=rss: System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host 194.217.240.71:80     at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)     at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)     --- End of inner exception stack trace ---     at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)     at Microsoft.Office.Server.Search.F... 
12/08/2008 22:27:35.20* w3wp.exe (0x1134)                        0x0EC4 Search Server Common           MS Search Query                0 High     ...ederation.HttpAsync.RespCallback(IAsyncResult asynchronousResult) 

I thought it a bit strange that a federated search was being performed as there were no federated search webparts on the results page I was looking at. Anyhow it seems that by default the federated searches at Microsoft's live.com are run anyway... disabling these federated search locations in Search Administration > Federated Locations instantly gave me nice quick results all the time.  Well disabling - I added a prefix that's unlikely to get used as I thought they might come in useful when Microsoft has fixed the delay!

If you find another solution - please add a comment to let me know. Thanks.

One of the main complaints (?) of developers is that they have to undertake Sharepoint development inside of a virtual machine, or on a server. Personally, I don't find this a problem as long as you are not working against a live server!. Our new development environment (that I'm sure Iain will blog about) is almost entirely virtual, development, staging and test.

Although not supported by Microsoft, there are a few options to get around this....

a) Install WSS on Vista

Yes it can be done (although I haven't personally tried it yet) and the guys at Bamboo have posted an article on this

b) Install the various assemblies, XSD files onto the client PC as noted here (this is the route I've taken with the laptop so that I dont have to always work inside Virtual Machines)

The downside of both of these is that debugging gets more difficult - you will have to configure remote debugging on the server, plus some of the tools (such as WSS extensions) won't install or run correctly

One of the questions we are most frequently asked by our clients is whether they should be using Windows Sharepoint Services (WSS) or Microsoft Office Sharepoint Server (MOSS).

The normal tradeoff is between licensing cost & functionality required.  In some scenarios the client can achieve their desired requirements through a combination of WSS and some customisation to deliver the components which would have come with MOSS.  In other scenarious the additional functionality delivered by MOSS clearly outweighs any additional licensing costs.

For those that don't know the difference, WSS is the foundation for MOSS and delivers a lot of the core functionality in Sharepoint such as team sites, document management, collaboration capabilities, search and so on...MOSS then adds an extra layer on top of WSS and provides a significant level of additional functionality.

The main areas that we find usuall 'sell' MOSS are:

• Content Publishing
• My Site Functionality
• Extended Indexing and Search Capabilities
• Content Targetting through Audiences
• Ability to Integrate into Back End Applications
• Infopath Forms Services

There is a more detailed comparison here or if you contact us we can send you a more detailed spreadsheet with detailed functional differences.

We've been doing a lot of work recently with Sharepoint and InfoPath, both the client application and Forms Server.

Data Connections are a great way of centrally managing the connections to external data sources, whether they be Sharepoint Lists, Webservices or other. However, like most things, they need some thought and planning.

A good introductory article has been posted by the Infopath team http://blogs.msdn.com/infopath/archive/2007/03/21/infopath-data-connections-part-1.aspx

Some quick things that we have found with connections....

a) Create them first (create a .udcx file) and submit to the server before starting work on the forms.

b) Create them using either this template (courtesy of the InfoPath team) or another editor. Although you can use the InfoPath connection wizard to convert connections on the server, we encountered some problems with this approach in the earlier days of forms development.

c) When developing for InfoPath client, be mindful of the need for central connections. The client form will download the connection details each time it is opened adding potentially several seconds to each tiem a form is opened. This was found to be not so much of an issue on forms server.

d) Consider if a data connection is really necessary or if, for simple lists (e.g. drop down selections) a 'hard coded' set of options is more efficient.

e) Store the data connections in a high level location (so they are accessible by forms at any lower level of a MOSS heirarchy) and keep the connection paths as server relative

f) Consider using 'read' type webservices for submitting data to external locations, rather than 'submit' type services. We found submit services to be greate where all of the InfoPath form had to be submitted, but using read type services allowed us to submit small sections of data, and even use button rules rather than code.

For UK based charities there is an organisation called CT Exchange - see http://www.ctxchange.org who themselves are a charity. They provide hardware & software, including most of the Microsoft suite of products for a small admin fee - for example a copy of Microsoft Office Professional would cost £10+VAT. And if you are slightly larger then something like Microsoft Small Business Server for £35+VAT is an excellent product for running a network.

If you are after hardware then Cisco provide cheap (but top quality) kit for drastically reduced prices through the scheme.

We came across it as a charity wanted to purchase licenses for Microsoft Office Sharepoint Server and it was a very cost effective way of them getting the licenses.

There are some eligibility criteria (e.g. you have to be registered with the charity commission) and there are limitations on how many licenses you can order but it might be worth checking out. More info at http://www.ctxchange.org