>Nice powershell to display Managed, crawled and mapped metadata properties in SharePoint 2010


So on your SharePoint server, paste the script below into powershell_ISE or a script file e.g. PropListing.ps1 and edit the $searchAppName variable to be the exact name of your search application.

Run the script and the output should explain itself.


$PSSnapin = Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

$searchAppName = “Your name Enterprise Search Service Application”

$app = Get-SPEnterpriseSearchServiceApplication -identity $searchAppName

$cats = Get-SPEnterpriseSearchMetadataCategory -SearchApplication $app
$ManagedMapped = @{}

Write-Host “Categories”
$cats | % {
$cat = $_
Write-host “`t” $cat.name

$crawledprops = $cat.GetAllCrawledProperties()
Write-host “`t`t” “Crawled properties”
$crawledprops | % {
$crawledProperty = $_
Write-Host “`t`t`t” $crawledProperty.name

$mappedManagedProps = $crawledProperty.GetMappedManagedProperties()

if($mappedManagedProps.Count -gt 0) {
Write-Host “`t`t`t`t” “Mapped to managed property(s)”
$mappedManagedProps | % {
$mappedManagedProperty = $_
Write-Host “`t`t`t`t`t” $mappedManagedProperty.name
if(-not $ManagedMapped.ContainsKey($mappedManagedProperty.name)) {
# record this prop for later

# Find unmapped managed properties
Write-host “Listing of unMapped Managed properties”
Write-host “————————————–”

$allManProps = $app.GetManagedProperties()
$allManProps | % {
$allprop = $_
if(-not $ManagedMapped.ContainsKey($allprop.name)) {
Write-host “`t” $allProp.name


No warranties implied or otherwise Smile

>SharePoint Content pushdown

>This is a bit of a challenge.
Create and deploy a content type to Moss, lets say a “person” content type. Which consists of a couple of columns, Name and Address.

Then later you decide you need “phone number” …..

Simple, add an additional site column and re deploy the feature.

This is fine for any new “Person” you create, however all your existing “Person” will not allow you to add the “Phone number”

Enter the need for Content type push down.

Simple, go into site settings and manage site content types, click “propagate down” and all is well.

Unless you do scripted deployments that is.

So along comes Søren Nielsen and Gary Lapointe with a nice stsadm command to fix this issue for us.

For me though their solution has a couple of issues.
It seems to mix up display and internal name, causes me to lose (Hide) content, this is bad
It dosent “Seem” to fix up “list column title” which it may have messed up in the “List content type”

So if you have lost content by using “propagate content type changes” you are not alone, and if like me yours is just hidded by Gary’s issues, you can get it back.

I wont post the code here as its quite large and work in progress.

Drop me a mail if you are suffering from this and I’ll let you have the code. (At your own risk of course 🙂 )


This is a fun object, consider this

SPSite site = new SPSite(“legitimate site collection url”) ;

SPWeb webA = site.OpenWeb(“Some bogus url”) ;
SPWeb webB = site.AllWebs[“some bogus url”] ;

You wold expect this code to throw two exeptions, you would be wrong.
Well you would expect webA and webB to at least be null, you would be wrong.

Apparently (not for the sake of consistency )

Do stuff with webA

Is the prescribed way to deal with this, how many of us have seen code like the following scattered all over blogs and such

if (webA != null) ….

Well, you live and learn.

>PSCONFIG is your pal

>Having some issues with scripting psconfig at the moment also. We have written some scripts based lossely on a ms white paper and posts from Spence and a few others (Plus previous experience of doing a simmilar scripting job for MS)

Our aim is to create a standalone script which can be run from a TFS build service, the script should take an Operating system only windows server and take it to SharePoint, SSP, Central admin a couple of web apps and various custom visual studio peices.

It should do this every night (CI, Continuous integration) and furthermore it should do all this from a tfs build box accross the wire to the deploy box.

For the remoteing we are using WinRs and a fine tool it is too.

Except, it dosent work in a couple of notable instances.

WinRs psconfig to create config DB fails

WinRs to run a powershell script to re set a hyperv machine to a particular checkpoint fails.

Both of these two work when executed locally they just fail when run over winRs. The latter works via telnet (for those looking for a solution that works)

I would welcome discussing this with anyone going through the same pain.

I will follow this up once PSS get me a definitave answer on if this is supported scenario or not.

Update (October 2009)
Seems that this scenario is not supported, according to MS PSS.

However, as is often the case, needs must …

A solution: May or may not work for you.
Configure Integration macjhine to automatically log in as userx and boot time (You will now have a fully logged in session)
Create a login script which copies you integration script locally and runs it

Not Elegant, but it works.

>What you need to know about advice …

>In my last posting I passed on some advice I got from a collegue relating to december cumulative updates for SharePoint server 2007.

Well, you live and learn, following that advice caused some issues with subsequent updates in my case.

So the fact is, your mileage may vary. My mileage turned into a full restore from backup, re download the offending updates (now magically working as expected) re install and all is now well, moral, always back these things up before any major changes.

Thank god for Hyperv checkpoints.

>SharePoint December Cumulative updates

>Had an issue installing this, well a couple of issues actually;

State of Farm prior to December updates: Standalone install also server running Sql 2005

  • Moss 2007
  • SP1
  • Infrastruture update
  • 2 x Security patches (Pre August updates)
  • August updates (However version number did not increment – known ‘to whom’ issue I understand)

The first update (Wss) installs fine but on running the SharePoint configuration wizard, that fails with a nondescript error (States the upgrade failed but gives no reason)
This is annoying as the reason (in this case) actually is in the upgrade log file created by the wizard.

[SearchQFE23318DatabaseAction] [] [DEBUG] [12/21/2008 10:47:28 AM]: SearchQFE23318DatabaseAction.Upgrade: Upgrading MSSCrawlHistory table index on database WSS_Search_MossDev.

[SPSearchDatabaseSequence] [ERROR] [12/21/2008 10:47:28 AM]: Action of Microsoft.SharePoint.Upgrade.SPSearchDatabaseSequence failed.

Or something simmilar in your case.

Fortunately for me we have an MVP on staff and he suggested a resolution to me, which seems to do the trick nicely. Thanks Ben.

Here goes, may or may not work for you.

In Central admin -> operations -> Services on server, disable the search services – both of them

  • Office SharePoint Server Search
  • Windows SharePoint Services Help Search

Confirm / Ensure these services are stopped in windows services

  • Windows SharePoint services Timer
  • office SharePoint server search
  • Windows SharePoint Services Search

Re run the configuration wizard – should now succeed
Re configure the search services back in central admin
You will need to re associate a index server with your SSP
You may need to issue an IISRESET before this finally works

Subsequant install and Config wizard for Moss worked without a hitch.

Second issue:
Although the SharePoint team blog states:

“The version of content databases should be after successfully applying these updates.”

I found it to be Apparently, another known ‘to whom’ issue 🙂


>Scripted WinNT user creation

>Well, I seem to spend most of my life these days building some new virtual environment to develop against MOSS (Biztalk is a distant memory, I understand thats all about to change though)

I nearly always need to create some degree of system accounts to have my build comply with best practice, very tedious in MOSS as you need quite a few system accounts.

I came up with this script which I use to automate the account creation process in a predictable repeatable way

This flavour works with WinNT provider on windows server 2003 and XP, it will run on a Vista box if you choose to ‘run as administrator’

So, edit the createWinNTusers.vbs file to specify the name of the computer, the name of a single group the names of the users you want to create and the password they will all share, then

Usage is :-
cscript createWinNTusers.vbs [create clean]

The create parameter causes users to be created along with a group to contain them.
The clean parameter causes the users and group to be deleted.

Hope someone finds it usefull.