Monday, July 29, 2013

Three very useful powershell commands

PowerShell gains clarity the more you use it.  In SharePoint 2010, there are numerous things that are only possible via PowerShell.

These are three PowerShell command-lets that I find very useful in administering SharePoint and this example is one way to use them together to interrogate objects within SharePoint:

Where-Object -

Get-Command -

Get-Member -


Assumes your powershell has the SharePoint snap-in loaded or that you are using the SharePoint management console.

Get-SpFeature ran by itself will return a list of SharePoint features that are present in your SharePoint environment.  One of the headings (aka properties) in the list that results from running this cmdlet, is DisplayName.

Get-SPfeature piped into Get-member will return a list of all the methods and properties that are present within the Get-SPFeature.

Get-SPFeature | Get-Member

Now let's backup a few and assume that the exact name of the powershell command-let with that gets SharePoint features is partially uknown, but that it is known that it has "feature" as part of the word in the noun section.  Verb-Noun, *-*Feature*

So, run Get-Command -Noun *feature* and a generate list of comand-lets which appear with feature in the noun section, Get-SPFeature, included.

Finally, the where-object command used in conjunction with get-spfeature will bring a list of features that contain "WebParts" in the displayname, as follows:

Get-SPFeature | Where-object {$_.Displayname -like "*webparts*"}

The results of the one-liner above,  include only three of the properties of Get-SpFeature, one of them shows the admin that webparts are scoped at the Web (application), Farm, or Site (collection) level.  This is handy when troubleshooting activation of features, as sometimes solutions that are scoped at web parts which are scoped to the site collection, require the use of ?Scope=Site appended to the control page, in order to access the button tied to the method that allows activation.

Wednesday, July 24, 2013

How to delete an orphaned Project Server Site

Let's say you go to provision a Project Web App via managed service applications, project server server application, and it fails.  There is a chance that the particular site you are trying to provision is orphaned within the Project Server Service Application.

this occurs after the Site collection that held the PWA site is deleted before it is unprovisioned.  And sometimes it occurs even if the PWA site is unprovisioned and then deleted.

The advice listed by Alexander on this technet forum, works

PS C:\Users\sp_farm>Get-SPServiceApplication
mark out the GUID for the project service application

PS C:\Users\sp_farm>$psi = get-spserviceapplication | ? {$_.Id -eq "GUID of the Project Service App from above"}
PS C:\Users\sp_farm> $a = $psi.Sitecollection | where {$_.SiteID -eq "< Guid of the orphaned site, see text below on how to find this>"}
PS C:\Users\sp_farm>
PS C:\Users\sp_farm> $a
PS C:\Users\sp_farm>
PS C:\Users\sp_farm> $a.Delete()

to test this series of commands, after you've ran the above you can perform the following steps, and actually you can perform these steps to get the guid that you need in the above "<Guid>"

From an administrative management console, type


then Mark the GUID for the Project Service App and run

$sa = get-spserviceapplication | ? {$_.Id -eq "GUID of the Service App from above"}

followed by

 $sc = $sa.SiteCollection

The guid associated with the SiteID is guid that you're after, you can find this a few rows above the name field.

"Details of what each section of the above powershell commands are returning are neatly documented in this technet post by Alex Burton -"

Notice how, if you run $sc by itself, it will show you all the site collections that the project service application thinks are in place.  After you run

$a = $psi.Sitecollection | where {$_.SiteID -eq "< Guid>"}



when you run $sc, it will contain one less, based on the siteID used in the <Guid> of 

$a = $psi.Sitecollection | where {$_.SiteID -eq "< Guid>"}

Monday, July 15, 2013

Deploying Fast Search for SharePoint


SQL server running Windows SQL Server 2008 R2
Search admin server running Windows Server 2008 R2
Search query server running Windows Server 2008 R2

These are the abbreviated high level steps to deploy fast, based on this page:

1. Already have a SharePoint Farm
2. Already have SQL installed and have your Search Account, domain based, with the dbcreator login role, make sure that this user is a member of the FASTsearchAdministrators group, as well.
3. Download the bits for FAST and then run through them, make the Search Account a local admin on the search front ends before execution.
4. Fill in the boxes for FAST, using the search account when asked for an admin account, create a multi-server deployment xml file.
5. Attempt to use the FQDN for the SQL box, but just use the Netbios host name if the FQDN does not work.
6. Repeat on the query server that you designated in your deployment file.
7. Create the FAST Content Search application and then make the Sharepoint farm trust the Admin server, add a content source, run a full crawl
8. Make the query search application using the information found in install_info.txt, and make sure that it is the only search application configured in the default proxy group.
9. Create the trust between the web server and the farm
10. test that indexing is occurring,
11.  If thumbnails are not appearing in search results, make sure Office Web apps is installed on each SharePoint front end and then run the Products and Technologies Wizard.

Sunday, July 7, 2013

Modifying the Deployment.xml file for a FAST 2010 search server farm

Here's an example of a deployment file for a three server farm, 1 admin, 1 query, and 1 back end server,

The file above is based off the multi server example found on this page: t

The text in red shows how the example code was modified:

<?xml version="1.0" encoding="utf-8" ?> <deployment comment="FAST Search Server three node deployment example" xmlns="">   <instanceid>FASTSearchMultiNodeDemo <--- Changed to the mancave</instanceid> 
 <!-- NOTE: Host names "", "" and "" must be changed to the actual server names in use   -->   <connector-databaseconnectionstring /> 
<host name="Changed to 2010App1....">  
    <admin />   
    <indexing-dispatcher />   
    <content-distributor />  
    <webanalyzer server="true" link-processing="true" lookup-db="true" />   
   <document-processor processes="2" />   
<host name="Changed to 2010App1... SECTION and Deleted.">  
    <searchengine row="0" column="0" /> <--- Moved to 2010app1 section  
</host> <---Deleted
 <host name="Changed to 2010Web1...FQDN...">   
   <searchengine row="1" column="0" />   
   <query />   
 <row id="0" index="primary" search="true" />   
<row id="1" index="none" search="true" />   

Getting error message when attempting to view a powerpoint or word doc via the browser

The following was adapted from <- this link has detailed steps.

If you're getting error message when attempting to view a PowerPoint or word doc via the browser, perform the following:

1. Check that PowerPoint Service and Word Viewing Service are both started

2. If either are not listed in manage services on this server, go to manage service applications and create them.

3. After you create them add them to the default proxy list and make sure the FAST search query proxy is the only search proxy listed.

4. Make sure that the account that is running the service app for both of these is a member of the Farm admins on your farm; as this account will need to retrieve content and settings from the configuration database and the content databases.

5. Make sure you are not using "The Farm Account"; but rather, another registered account that is a member of the farm admins.

All of the above assume the Office Web Apps has been downloaded from MSDN, installed on each web front end (WFE) server, and that the SharePoint Products and technologies wizard has been run on each WFE server.

After you've made the above changes, recrawl your content

and use the steps on this page to verify that your FAST farm is working:

Use this command on your indexer server :

Get-FASTSearchContentCollection -Name "sp"

- it should show a document count other than 0

And, finally, don't fret, sometimes it takes a little while for all the thumbnails to appear, even on servers that have more than the minimum recommended resources

Following are the Hardware and Software prerequisites for Microsoft FAST Search Server 2010 for SharePoint

Hardware requirements:

Operating SystemWindows Server 2008 x64 with SP2Windows Server 2008 R2 x64 with Sp2
CPU4 CPU cores, 2.0GHz CPU8 CPU cores, 2.0GHz CPU
HDD50 GB disk1 TB disk space on RAID across 6 spindles or more

Software prerequisites:

· Web Server (IIS) Role
· Power Shell 2.0
· Distributed Transaction Support
· Microsoft .NET Framework 3.5 SP1
· Windows Communication Foundation Activation Components
· XPS Viewer
· Microsoft “Geneva” Framework
· Microsoft Primary Interoperability Assemblies 2005
· Microsoft Visual C++ 2008 SP1 Redistributable Package (x64)
· Microsoft Filter Pack 2

Check out this blog for a superb overview of the installation and configuration of FAST Search Server for SharePoint 2010 -

Popular Posts