With SharePoint 2010 RTM looming, I’ve stumbled across an architectural change that may surprise some people – namely, that SharePoint 2010 no longer supports multiple server farms without a domain infrastructure. In SharePoint 2007 it was possible to create SharePoint farms in a Workgroup, so long as all of the user accounts for the services and application pool identities were named the same and had the same password. You could even manage users with an Active Directory Lightweight Directory Services (AD LDS) or Active Directory Application Mode (ADAM) LDAP directory (albeit with some fairly limiting restrictions). However, it was possible to use these farms for testing or when an Active Directory infrastructure was undesirable (as some people see it in a DMZ). Now, it is still possible to do a Simple installation on a single server without full domain services, but it is no longer supported on multiple servers, and the Simple installation comes with its own planning considerations, to which I’ll return in a bit. First, there’s another wrinkle regarding the single server Complete installation.
PDF iFilter performance benchmarks, in which FoxIt performs nearly 40x better than Adobe
I’m not usually keen on re-posting other blog entries here, but I think this is quite important. Jie Li from Microsoft has been releasing some good guidance on SharePoint 2010 recently. In his most recent posts he’s been looking at FoxIt’s PDF iFilter 2.0 and comparing performance against TET and Adobe. Both TET and FoxIt are optimised for multicore processors while Adobe will only use a single CPU. This has massive performance implications. In his tests a full crawl too 13 minutes with FoxIt versus 8 hours+ with Adobe. http://blogs.msdn.com/opal/archive/2010/02/09/pdf-ifilter-test-with-sharepoint-2010.aspx
SharePoint 2007 administration part IV: SSP administration
This is the fourth post in a six-part series on SharePoint 2007 administrative commands. The first part was an overview, the second covered Farm administration, the third covered web application administration, and this post is devoted to Shared Service Provider (SSP) administration. The bulk of this post only applies to MOSS, as there is no SSP for WSS. read more »
Windows 7 and Windows Server 2008 R2 Federated Search
Federated Search is one of the most useful and interesting additions to MOSS 2007 since it was launched. It’s now been announced for Windows 7 and Windows Server 2008 R2.
Federated Search was integrated into MOSS 2007 with the post-SP1 Infrastructure Update, which effectively brought the Search Server 2008 product to the MOSS 2007 platform. Federated Search will pass a query from a single interface to multiple OpenSearch-compatible indices. It will then render matching results from these indices asynchronously as they return. In MOSS 2007 a federated search web part is added to a search results page and each web part renders only if results are found through that Search Connector. This works brilliantly, as local results will typically return first, then remote sources will render in due course.
This functionality has now been added to Windows Search. I think this is a fantastic move, as these choices will often be very preferential. I may want Wikipedia while you will want Britannica. I may roam among three branch offices and need to query each of the regional SharePoint portals. It’s very powerful stuff – especially when it moves to the client and can be configured to individual needs.
Find more Search Connectors on the Enterprise Search site. Read the Windows 7 Federated Search Provider Implementer’s Guide.



