Back in the pre-release days of SharePoint 2010, one of the most reliable sources of information on infrastructure issues was Russ Maxwell’s SharePoint Brew blog. It’s still a great resource, although he’s posting less frequently now than he was during the beta. In this post I want to share my findings regarding Pre-Windows 2000 Compatibility Access group rights in Active Directory. Everything I have to say is supplementary to Russ’s foundational explanation of Why the tokenGroupsGlobalAndUniversal (TGGAU) attribute matters in SharePoint 2010. I’m picking the discussion up from his closing comment, “At a minimum, certain service accounts like the search service account need to be a member of this group.”
My colleague Anthony Clegg and I have recently been working on a project together, for which I’ve designed and delivered the infrastructure, while he’s been delivering the solution. As part of my design, I extended the SharePoint Web Applications from the default HTTPS zones to new HTTP zones, exclusively for crawling. This approach has been around for some time, but there’s a new wrinkle on the SharePoint 2010 Enterprise Search Centre People Search results page, which I’ll discuss here:
A couple of months ago I was happily building a client’s SharePoint Server 2010 farm when I stumbled at Search. The Service Application provisioned fine, but when I pushed out topology changes I started to have problems. Later, these problems returned in different forms, but the root cause appears to have been consistent. In this post I will review the symptoms, the single fix and the reason why this issue emerged in this environment. I’ll also look at some unexpected permission changes that occur when new servers receive Search Service Instances.
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.
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
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. Continue reading “SharePoint 2007 administration part IV: SSP administration”
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.