FAST Search Server for SharePoint–Number of Items Indexed

Having set up the FAST Search Server for SharePoint, I can tell you it is an interesting ordeal.  Because the product was purchased by Microsoft and productionalized for SharePoint, there are a few gotchas in the product like having to use FQDN domains for the User IDs and some fun with certificates.

However, once you’ve got the system up, running and integrated with SharePoint it is a very useful and powerful product.

One useful tool in your administration bag is the IndexerInfo.exe, which is useful when retrieving basic information about the number of items indexed or the status of the indexing process.

In order to use this tool, you have to log onto the FAST server and run the executable located here:


And that will give you some pretty useful basic information about your server’s index, such as total number of items indexed:


However, the tool has two drawbacks:

  1. You have to log into the server to use it.
  2. It doesn’t have a lot of granularity or visibility to SharePoint scopes and permissions.

In many cases, a great workaround for this is to use your SharePoint Search which is using the FAST engine and simply query for the ‘#’ character.


And this should give you a ball-park figure of how many items are in your index.  You’ll notice though that the numbers are slightly different.  If I were only querying against a SharePoint source and I was a Farm Admin, the numbers would be identical.  However, since I also index against websites and proprietary sources that I don’t have the ACLs for, these results are security trimmed to only show the total number of items that I have access to.  In this case, I can see from the two numbers that my account doesn’t have access to 1,528 documents (388252 – 386724 = 1528)

If I log in with my restricted test user account (and every SharePoint Admin should have a “regular” test account so they can see their site from the normal user experience) I can see I have access to even less documents:


This is again a good thing, as it allows me to see the number of documents that a particular user profile has access to.  If I perform the same ‘#’ search when using a contextual “This Site:” drop down scope, I can further refine the number of documents indexed to a particular subset based on scope.  For instance if I wanted to quickly know how many indexed items I had in my Knowledge Base I could use the contextual scope search and see that there were 751 indexed items in this particular sub-set of items that my account has access to (and since I am an Admin and this is running on SharePoint I know this is the total number for this site).


Note that when you want to know how many items are indexed in a particular scope, you don’t need to actually use the ‘#’ character, just reference the scope, and since you’ve got text in the search box it won’t pop up with the “Please enter one or more search words.” warning box.


Of course, if you want to get into the fine-grained status of your Indexer and the information that an admin might need to fine tune the engine itself, then it’s back to the command line to get your granular information:


SharePoint 2010 : Connect to Another Farm’s User Profile Service

Recently I had to review and configure two SharePoint 2010 farms to use the same User Profile Service.  The Publishing Farm was a large enterprise level farm that was used company wide.  The other was a smaller, single server farm that ran the Team Foundation Server 2010 SharePoint sites.  Rather than moving the SharePoint assets to the large enterprise farm, The Client wanted the TFS SharePoint farm to utilize the User Profile Services of the larger farm and to have the mysites and profiles features integrated within the smaller TFS sharepoint sites.

Now, before any farm can provide its services to another farm, we need to set up the Application Discovery and Load Balancer Service Application.  This is also referred to as the Topology Service (and in fact when you use the published URL you can see it’s calling the topology.svc web service).  In order to make this magic happen, the consuming and publishing farms must be set up so that they trust each other and that the consuming farm can find the proxies it needs to use on the publishing farm.

First thing you want to do is remote into the Central Admin servers of both farms.  Technically it doesn’t have to be the CA, but I find that if I do all my admin work on these boxes and store the artifacts of my work in a familiar directory structure it leads to less “where the heck did I put that file” moments. Now that you have both consoles up on each screen it’s time to begin (What, you don’t have dual monitors?  Get a second monitor if at all possible, studies have actually shown it increases productivity).

Setting Up Claims Providers

Consuming Farm:

1. From the consuming farm, open up our handy PowerShell (note, technically you can do a lot of this in the UI, but for me I just find it is much easier to cut and past my scripts into notepad, modify the bolded pieces that I need to and then copy the whole thing into the PS command line).



2. Copy the <CONSUMING FARM GUID> to notepad, you’ll need it later.

Publishing Farm:

$security = Get-SPTopologyServiceApplication | Get-SPServiceApplicationSecurity
$claimProvider = (Get-SPClaimProvider System).ClaimProvider
$principal = New-SPClaimsPrincipal -ClaimType "" -ClaimProvider $claimProvider –ClaimValue <CONSUMING FARM GUID>
Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control"
Get-SPTopologyServiceApplication | Set-SPServiceApplicationSecurity -ObjectSecurity $security

Creating the Certificates

Consuming Farm:

Now we need to get two certs from our consuming farm, the root certificate and the STS certificate.  Obviously these files can go anywhere, but I prefer somewhere other than the root of the HDD for these kinds of artifacts as it makes it easier to organize and clean up if I need to.

$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export("Cert") | Set-Content D:\INSTALL\RootCert\ConsumingFarmRoot.cer -Encoding byte
$stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
$stsCert.Export("Cert") | Set-Content D:\INSTALL\RootCert\ConsumingFarmSTS.cer -Encoding byte

Copy the resulting certs to the publishing farm, I generally like to use the same D:\INSTALL\RootCert location on both servers.

Publishing Farm:

$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export("Cert") | Set-Content D:\INSTALL\RootCert\PublishingFarmRoot.cer -Encoding byte

Again, copy the resulting certs to the consuming farm.

Importing the Certificates

Consuming Farm:

$trustCert = Get-PfxCertificate D:\INSTALL\RootCert\PublishingFarmRoot.cer

New-SPTrustedRootAuthority PUBLISHING_SERVER_NAME -Certificate $trustCert

Publishing Farm:

$trustCert = Get-PfxCertificate D:\Install\RootCert\ConsumingFarmRoot.cer
New-SPTrustedRootAuthority CONSUMING_SERVER_NAME -Certificate $trustCert

$stsCert = Get-PfxCertificate D:\Install\RootCert\ConsumingFarmSTS.cer
New-SPTrustedServiceTokenIssuer CONSUMING_SERVER_NAME -Certificate $stsCert

Publishing the User Profile Service

Publishing Farm:

  1. Open Central Administration.
  2. Click on Manage service applications
  3. Highlight the User Profile Service (you don’t want to manage it, just highlight it so you can use the ribbon bar buttons)
  4. Click on the Publish icon on the ribbon bar.
  5. Make sure the Publish this Service Application to other farms is checked.
  6. Copy the Published URL, you’ll need it for step 4 on the consuming farm below.  It will look similar to this:
    1. urn:schemas-microsoft-com:sharepoint:service:REALLY_LONG_STRING_OF_NUMBERS#authority=urn:uuid:REALLY_LONG_STRING_OF_NUMBERS&authority=https://SERVER:PORT/Topology/topology.svc
  7. Click OK.

Consuming Farm:

  1. Open Central Administration.
  2. Click on Manage service applications
  3. Click on the Connect icon on the top ribbon and choose User Profile Service Application Proxy
  4. In the Connect to a Remote Service Application dialog paste the Published Url from the consuming farm referenced in 6.1 above.
  5. Click OK.
  6. Highlight User Profile Service, make sure the check box is checked and click OK.
  7. You should get a confirmation screen and click OK again.

Congratulations!  You have now connected to the Publishing Farm and are consuming the User Profile Service.  In this way we are able to maintain one “Golden Record” of User Profile information, and when a user updates (or for that mater when Active Directory syncs with it) their profile data it will be the same on both farms. It will also be able to use the trusted My Site locations, the audiences, etc. from the publishing farm.  Remember that since the Publishing Farm is now the source of data/service for the consuming farm, anything for the consumer farm related to User Profiles needs to be done on the central administration of the publishing farm.

SharePoint 2010–Use PowerShell to Provision a Central Admin site

Recently I was working on a SharePoint 2010 farm where I accidently removed the last server that hosted Central Admin.  Whoops!  Now I had a farm with no Central Admin UI.  Now the Central Admin SharePoint Service is installed on every WFE by default, but is only enabled on the machines that you identify.  I went ahead tried to run the psconfig on the server and tried to re-add it, however the install checks were telling me that it could not be joined due to a patch level inconsistency (more on that in a different post).  End result was that I was sitting with a farm that did not have a Central Admin site configured…

The following PowerShell command will provide a list of all servers that have the Central Administration service installed, their status, and the Id:

Get-SPServiceInstance | Where-Object {$_.TypeName -eq 'Central Administration'}

TypeName Status Id
——– —— –
Central Administration Disabled 2d35f287-8d0f-4474-8a38-2dc2365c06e7
Central Administration Disabled 2052cc79-fce8-483a-83e4-9802db535237

The service instance can be started using the following PowerShell command, again restricted to the Id of the service instance I want.  Doing this will provision Central Admin on the WFE that it correlates with:

Get-SPServiceInstance | Where-Object {$_.Id –eq ‘2d35f287-8d0f-4474-8a38-2dc2365c06e7’} | Start-SPServiceInstance

Get-SPServiceInstance | Where-Object {$_.Id –eq ‘2052cc79-fce8-483a-83e4-9802db535237’} | Start-SPServiceInstance

This will start provisioning the service instance, which usually means creating the Central Administration website on the web front-end and starting the central admin service instance.  Given a minute or two, the Central Admin will appear on the WFE and can be accessed using the normal http://<machine name>:<admin port> standard.