Building a SharePoint farm with AutoSPInstaller on Windows 2012 Server

Sigh…another day, another SharePoint headache…

The plan today was to create a SharePoint farm on a brand new Windows Server 2012 R2 VM, using the excellent AutoSPInstaller scripts to install and SharePoint and create my farm. I’ve done this loads of times on Windows Server 2008 R2 SP1, and never really hit any issues. I was therefore totally unprepared for the pain I would find on 2012. But I’ve emerged out the other side, and here are the key takeaways:

Issue 1: SharePoint 2010

If you are building a SharePoint 2010 farm on Server 2012, be aware that this configuration was only officially supported by Microsoft as of May 2014. At that point they released a new slipstreamed ISO for SharePoint 2010 containing Service Pack 2, which was the point at which you could install it on Server 2012. However even here, you then have to patch the SharePoint install to the Feb 2014 Cumulative update as a minimum, in order to have full functionality supported. See KB2724471 for further details

In my scenario, I was building a 2010 farm, so this was pretty important. Because of the requirement to have the Feb 2014 CU installed, I modified my SP2 slipstreamed ISO to add those files to the Updates folder too

Issue 2: Running AutoSPInstaller to install the SharePoint binaries

After launching AutoSPInstaller, it failed on installing the Pre-Requisites. AutoSPInstaller does not fully support installing SharePoint 2010 on Windows Server 2012 R2. With SP2, support was added for SharePoint 2010 on Server 2012 in the form of a updated PrepequisiteInstaller.exe, but AutoSPDeployer, at least the version I’m running (V3.0), does not support that yet. I see from the change log for AutoSPInstaller on Codeplex that attempts have been made to rectify this (May 7 entry), so I’m guessing this will be sorted eventually

My solution to this was to install the pre-requisites manually directly from within the mounted ISO (PrerequisiteInstaller.exe).

Issue 3: Running AutoSPInstaller to build out the farm

So after manually installing the pre-requisites and installing the SharePoint 2010 binaries, I then attempted to build out the SharePoint farm, which basically fell over at the first hurdle:

New-SPConfigurationDatabase : Microsoft SharePoint is not supported with version 4.0.30319.34014 of the Microsoft .Net

This isn’t as drastic as it sounds, after a bit of head-scratching I found out the problem was not SharePoint itself, but the version of the PowerShell console that was opened up by AutoSPInstaller when it was processing the scripts. It turns out that by default the version that is opened is V4.0, which does not play at all well with the SharePoint 2010 PowerShell modules. Again, as per the issue above, it looks like upcoming updates to AutoSPInstaller will sort the problem, but for now, I was able to tell the Launch.bat file to open in version 2.0 by this simple update to the following line in the launcher script (highlighted):

“%SYSTEMROOT%\system32\windowspowershell\v1.0\powershell.exe” -Command Start-Process “$PSHOME\powershell.exe” -Verb RunAs -ArgumentList “‘-Version 2.0 %~dp0\AutoSPInstallerMain.ps1 %InputFile%'”

After that, I was able to create my SharePoint 2010 farm (finally!)

Update:

Issue 4: Import-Module WebAdministration – Fail

So the farm creates, but web applications fail to be created. The reason for this? A required PowerShell module for manipulating IIS settings is not able to be loaded in the version 2 of the PowerShell window. As this article says,

the catch 22 is that SharePoint commandlets requires PowerShell v2 with .NET runtime v2, while the WebAdministration commandslets in Windows Server 2012 requires PowerShell v3 and .NET runtime v4

Am I going to bother trying the workaround? I think not, I’ve had enough

SharePoint 2013 and JavaScript – best practices

Whilst I’ve not played around too much with the new client side rendering techniques available with SharePoint 2013 and JS Link, or indeed the wider application of JavaScript OM code on the platform, it has appeared to me from what I can see out there in terms of online resources, its a bit of an unstructured free-for-all. So you want to change the what’s in the display of your custom list view? Just Google something and chuck a JS link file at it!

All of this expedient scripting can be quite useful in getting something up and running quickly, and even enables power users to get their hands dirty with entry level customisation techniques, but it worries me as this will only lead to bad practices and not enough structure being applied.

Fortunately I’m not the only one thinking these sort of things, and others are actually doing something about it, in terms of trying to promote good practices and design patterns to the whole subject area.

The following article talks about the dangers of polluting the global namespace in JavaScript by declaring an immediately invoked function expression in your script – we’ve all seen (and done?) this in our scripts:

(function () {

var override = {};

//etc

)();

As the article explains, there are simple techniques for falling into this trap, and they should be used.

The other link refers to a new Wiki site that has been created to promote design patterns and best practices for SharePoint 2013 and JavaScript. I am hoping the resources on this site will prove very useful indeed. Enjoy!

SharePoint 2010, custom master pages and CSS3

If you are still doing things on SharePoint 2010 these days (some people still are!), please be aware of the following gotcha.

The scenario is when you are creating custom branded master pages, and you want to employ the latest CSS3 trickery to get your page looking nice (things like drop shadow, rounder corners, link transitions and the like). In a SharePoint 2010 master page, this means you tell your page to render in the latest IE browser mode. This is accomplished via the meta tag which contains something along these lines:

<meta http-equiv=”X-UA-Compatible” content=”IE=edge;Chrome=1;FF=3;OtherUA=4″ />

Where “Edge” tells IE to use the highest supported document mode of the browser

The big issue with this meta tag is that for SharePoint 2010 sites at least, you will be unable to drag and drop web parts on your page when in edit mode! For this to work, the meta tag needs to be the following:

<meta http-equiv=”X-UA-Compatible” content=”IE=8″/>

In other words, you specify the page to render in IE8 mode. However when you do that, none of your CSS 3 styles will work – so not a happy place to be in really!

Is there a solution to all of this? I found the following blog post which suggests applying an update to the meta tag via jQuery when in page edit mode, but I tried this out and was unable to get it to work.

So not really a workable solution for me, and therefore all I can do is offer a word of warning instead. As for whether this happens in SharePoint 2013, I am not able to confirm this at present, but I would of course expect it to all work ok with the Edge setting in place!

Providing Extranet access to SharePoint sites

Opening up access to a SharePoint web application in an extranet scenario represents the worst aspects of the product and platform. There are so many moving parts to get this working correctly from end to end – from setting up the infrastructure correctly (gateway, firewall rules/ports, certificates and so on), to getting various pieces of software in place (SharePoint and Office), requiring all of it to be held together by a myriad of admin configuration steps, that it really is easier for it to go wrong somewhere, than to get it right the first time.

The following post attempts to document some of the issues and pitfalls that can happen, as most of these were encountered in real-world scenarios – i.e. learnt via painful experience!

First of all, it is worth outlining three of the key design considerations that can present themselves in an extranet scenario (there are obviously a lot more but these were pertinent to my situation):

• The extranet requires an authentication solution for external users. The web application has already been created for internal access using Windows “classic” authentication, for example, and now a different authentication mechanism is required for external access
• The extranet is required to be used in full collaboration scenario, with the need for document management for example, which requires a rich client experience and Office integration
• Users are connecting to the extranet site using a multitude of different browsers

With those in mind I now throw down a challenge: Can you configure your environment correctly so that an external user can browse to a document in a SharePoint document library, and open it up in a client application in edit mode?

Whilst this sounds like a simple enough challenge, I would assert that given the considerations above, and coupled with other factors such as the version of SharePoint you are running in your farm, this is a near impossible task! To illustrate, lets break down each of the key considerations above in more detail.

Authentication for external users

As I already said, the web application that was being opened up for external access was already accessible by internal users. The web application was set up with default authentication of “Windows/negotiate (Kerberos)”, accessible by a URL on port 80 (HTTP only)

According to the best practice documentation from Microsoft on extranets, in this scenario, what you do for external access is:

Use forms-based authentication on the firewall or gateway product to collect Windows credentials that are forwarded to the SharePoint farm. This works in environments that use classic-mode authentication in which forms-based authentication for SharePoint sites is not supported

So this is what we did, using the Microsoft Forefront Threat Management Gateway (TMG) product to handle the authentication from external users. This was set up to intercept URLs to the extranet site and present users with a login form. From there, entering Windows username and password credentials (and we also used 2nd factor Radius authentication), would ensure a client cookie was generated and passed on to SharePoint. As connectivity to the login screen is via HTTPS/SSL, we had to ensure that a HTTPS URL for the extranet site was also configured. This was done by creating a new Alternate Access Mapping (AAM) to the existing web application in Central Administration, and aligning it to the Internet access zone. So now we had a single web application, with 2 URLs for access:

(Example)
Internal: http://extranet.myapp.com
External: https://extranet.myapp.com

This setup is enough to get a basic login scenario up an running, so that external users are authenticated and passed through to the SharePoint site, but this is NOWHERE near enough to getting our basic scenario working, outlined in the challenge above (open up a document in edit mode). What are the problems here?

Ensure rich client experience with full Office integration

1. No Persistent Cookie

The big problem here is that by default, client integration is just not enabled in our extranet scenario. This manifests itself in the dreaded “multiple logon prompts” issue that you experience when you try to open up an Office document in a SharePoint document library. The issue is well documented by Microsoft, and they stress it is in fact “by design”. Essentially what they are saying is that in the Extranet scenario, the user is known as an untrusted client, which means that even though they are authenticated to the SharePoint site via their browser, those credentials (in the form of a browser session cookie) are not passed on to any other application within that session (e.g. when you try to open document in Word)

For users authenticating via TMG, there is a solution to this problem, but it is not without its own problems. The solution is to enable single sign on and create a persistent auth cookie within TMG. This is all covered in the Microsoft KB article: http://support.microsoft.com/kb/2756625

The use of a named persistent cookie within TMG presents the following couple of problems however.

• If the persistent cookie is not enabled “on all computers”, it requires the user to select “this is a private computer” option on the logon screen, otherwise it will assume the connection is a public computer and the user will still get the login prompt when opening documents. To prevent the user missing this important step at logon, you therefore need to specify “on all computers” as the scope for the persistent cookie
• Session timeout duration needs to be configured. By default, the timeout is an absolute timeout value, for example, login time + 10 minutes  for the session to expire. This needs to be set to a sliding expiration timeout, which resets the time to expire on each web request

2. No End-to-End SSL Communication

Enabling persistent cookies is not enough in itself to ensure that the external user will not encounter login prompts and other undesirable behaviour when using the site in read/write full collaboration mode (as opposed to just browsing pages of content). Additional configuration needs to be performed to ensure the users connection to the site is fully enabled via SSL (and there are also good security reasons for this). In our scenario outlined so far, SSL has actually only been configured between the external connection and the TMG gateway. Connectivity from TMG to SharePoint is actually only performed via HTTP, notwithstanding our usage of an AAM starting with HTTPS. To enable full SSL connectivity, you need to do the following:

1. Extend the existing web application in SharePoint, setting it up to use the HTTPS URL over port 443

2. Align the web application authentication to the “Internet” zone created earlier

3. Ensure a valid SSL certificate (domain or wildcard) is installed on all SharePoint web servers and TMG servers

4. Within TMG, turn off ‘Redirect requests to HTTP port’ and ensure that communication between the TMG and the SharePoint web servers is over port 443

Browser Compatibility Issues

The final part of the our Extranet scenario survey relates to issues of browser compatibility. This is the most problematic area in ensuring our key challenge is met, because it is the one area that we have least control over from an admin/configuration scenario: external users will be using any flavour of browser they wish to connect to SharePoint. And whilst Microsoft has made bolder statements in recent years about the supportability of SharePoint sites for a variety of browsers, I would say this is purely related to a “browse-only” experience, not for a full collaboration scenario. What’s been more infuriating is that in my experience it has been Microsoft browsers as much as rival ones that are proving their incompatibility!

The issue here is a dependency on the version of SharePoint you are running. In my example, we have SharePoint 2010 SP1, and this will not fully support newer versions of IE (10 and 11) without having SP2 installed (specific support for IE10 was added with SharePoint 2010 SP2). The following table documents the results of my experience with the various browsers that can be used to connect to SharePoint, with a particular emphasis on the collaboration scenario:

	Browser	Compatibility	Notes
1	IE8 or IE9, 32 bit only.	Optimum Configuration	Full compatibility
2	IE10, 32 bit only	Compatibility issues. Must have either compatibility mode enabled, or SharePoint 2010 running Service Pack 2	Full compatibility with SharePoint Server 2010 SP2, or browser Compatibility mode enabled
3	IE11, 32 bit only	Compatibility issues. Must have either compatibility mode enabled, or SharePoint 2010 running Service Pack 2	Issues if compatibility mode not enabled. Not fully tested however, and inconsistent behaviour encountered when editing documents, even with compatibility mode enabled
4	64 bit Internet Explorer	Full read-only browsing supported, but not all usage scenarios	Certain scenarios require the use of ActiveX controls within the browser. These are only native to 32-bit versions of Internet Explorer. See item 6 below for more detail
5	Non-IE browsers (Firefox, Chrome and Safari)	Full read-only browsing supported, but not all usage scenarios	Certain scenarios require the use of ActiveX controls within the browser. These are only native to 32-bit versions of Internet Explorer. See item 6 below for more detail
6	Non-IE 32 bit browsers	The following activities within SharePoint are not supported in non-IE 32 bit browsers (which includes IE64-bit flavours, Firefox, Chrome and Safari):	1.       Connect to Office (option is greyed out)2.       Sync to SharePoint Workspace (option is greyed out)3.       Open in Datasheet view (option is greyed out) 4.       Open in Explorer view (option is greyed out) 5.       Export List to Excel (option is available but leads to an error: “To export a list, you must have a Microsoft SharePoint Foundation-compatible application”)6.       Edit Library with InfoPath 7.       “New document” creation from the ribbon – will not open up the appropriate document template. Instead displays a limited UI which only allows the addition of a file only but not the ability to edit it directly 8.       File upload – does not allow the upload of multiple documents, or drag/drop from explorer view 9.       Edit Document in Office client application – (option is available but leads to an error: “The document could not be opened for editing. A Microsoft SharePoint Foundation compatible application could not be found to edit the document”) 10.   Edit document in Browser – to be detailed

So there you have it, all these things need to be considered before you think you can enable such a seemingly simple thing as allowing an external user the ability to open up a document and edit it! I hope you are struck by how ridiculously complicated the whole thing is. Surely it shouldn’t have to be that way?!

Wiki vs. Web part pages – a note of caution

In SharePoint 2010 standard team sites, the landing page and all subsequent pages that are added to the Site Pages library of the site are of the type known as Wiki pages. It is of course also possible to add web part pages to the site, if you prefer to have a more structured layout and restrict what the user can add to the page.

There are various differences between Wiki and Web part pages, and these have all been documented elsewhere, but there is one important aspect of that difference between the page types that I wish to draw attention to, as it has the potential to cause a major problem for end users of the team site, and it will only become apparent to them when it is too late.

The big difference is in how the page is saved whilst in edit mode.The following screen shots illustrate the difference.

In the first example, that of a Wiki page, the user is presented with the following ribbon options – in particular the ability to save and close, save and keep editing, and also to checkout/check-in.

For a web part page however, the options are greatly curtailed:

The big differences are there is no ability to save the page, either to save and close, or save and keep editing, or indeed to even checkout the page.

In fact, as a point of comparison, the options presented by the Wiki page are more akin to that of a publishing page. I wondered how this was done, given that a standard Team site does not normally have publishing enabled. I had a peek at the mark-up behind the Wiki page layout (found in 14\TEMPLATE\DocumentTemplates\wkpstd.aspx), and it is generating it own local ribbon buttons running inside an UpdatePanel control to accomplish this.

However, the big issue with the options presented in Wiki pages versus those in Web part pages are this: If you edit and save a Web part page, by selecting the only option available to you (“Stop editing”), it will NOT save the page as a new version, whereas it DOES, if you are editing a wiki page (where you have the options to “Save and close”, or “Save and keep editing”). So the history of changes to a web part page are not available to the end user. And if the user accidentally deletes a web part, then they will not be able to restore the page to an earlier version to get it back.

This has big implications for content management on SharePoint team sites. You might say that by default team sites adopt the wiki page model, and so this should not really happen, but there is no restriction on the user adding a web part page from the “Site Actions…More Options” if they so wish. And in fact, (and this is why I’m telling this cautionary tale), this is a scenario that has happened in of my live SharePoint team site deployments. The user ended up losing several weeks of important edits to a number of web parts by someone accidentally deleting them.

So, to combat the scenario of web part page edits not creating new versions, the only option is to enforce check-outs on the Site page library. This will require the user to check-out the page every time they want to make a change (which is less than ideal), and the user will also have to actively ensure the page is checked back in each time they finish editing the page to ensure the changes are tied into a new version of the page

Displaying hidden folders in SharePoint document libraries

So I performed a recent content migration from a network file share into a SharePoint document library, and afterwards the customer contacted me to say that they couldn’t see some of their folders in the library.

A bit of investigation led me to identify that the “missing” folders all started with an underscore in the folder name. In Windows, such folders are identified as system folders, and are normally hidden, and it appeared that SharePoint was doing something similar.

So I opened up the library in question in Explorer view, and changed explorer settings under “change folder and search options” to show hidden files and folders, and then I renamed the folder to remove the underscore. All appeared well in explorer view, but when I refreshed the document library view in SharePoint, the folder was still missing. Great.

After a bit more digging, it appears that you also have to set folder attributes from the command line, to effectively “unhide” it. This can be performed using the “attrib” command, as follows:

attrib -s -r -h “\\<url-of-site>\<url-of-library>\<url-of-folder>”

Centralised document template management in SharePoint

The idea of having a centralised document templates library in SharePoint has much to recommend about it. It makes sense to push standard corporate templates from one central location to ensure that everyone within an enterprise is using the same single set of templates, and having them in one location also helps to provide ease of maintenance and updates when required. However, there are a number of drawbacks and pitfalls to this approach, all as a direct consequence to how they must be set up to work in SharePoint. This article will provide some information around the drawbacks, so that users can be better informed if this sounds like an approach they wish to adopt.

In my scenario, I had multiple site collections for a number of collaboration team sites, and decided that each site would ship a standard set of content types, with each content type tied to a corporate Microsoft Office document template. I had a root site collection, in which I created the centralised “Document Templates” document library, where I uploaded the corporate templates.

Using the following article as a guide, I configured the Templates document library with the following settings. Note, this is the only way to get the templates working correctly when hooking them into standard document library later on.

1. Created a number of site content types – for example one for a corporate Word template, one for Excel, one for PowerPoint and so on

2. Added the site content types to the Document Templates library (they create local list versions of the content type)

3. Edited the properties of each document template in the templates library, to point each template to it’s appropriate content type

4. Edited the site content type under Advanced Settings and pointed the Url of the document template property to the location of the template in the Templates library

Following this, I could then create other standard document libraries where I wanted to make the templates available under the New…document Ribbon options. All I needed to do was to have the same document template-aligned content types added to my other document libraries. So far, so good.

However, as the templates were rolled out to the site collections and became used over time, a number of issues have surfaced that has severely undermined my confidence in the solution.

Issue 1: Use of person or group fields in the site content type metadata

The templates were configured to expose a “document owner” field that the end user could assign from the document information panel when the document was being saved for the first time. This was set up as a mandatory field, so the user had to set it first time round. Unfortunately this led to a rather bizarre outcome. Whilst setting ownership to their own SharePoint account via the document information panel, when it saved and refreshed in the library view, it was showing up as another user entirely! After some painful troubleshooting, it was discovered that because the centralised templates library was in a separate site collection to the one where the document was being created, the hidden user information tables (the place where the user account is referenced via the person/group metadata field) in both site collections had separate sets of Ids for the same user account. So opening a document template from the original centralised templates location could not be supported in this scenario, and I had to revert to site collection specific versions of the templates. A major plank of the approach to centralise document templates was removed from my solution straight away, rendering the endeavour pretty fruitless. Of course, the workaround is to not use person/group fields in you custom content types, but that was just not an option for me.

Issue 2: Use of localised metadata default values

Another major drawback of the centralised approach is when using them in conjunction with the requirement to have library-specific metadata default values. Going back to our previous setup, one of the fields in our custom site content types was a choice field, which presented values that had to be one thing for a certain set of document libraries, and another for a different set of document libraries. This just won’t work properly if your content types are added to a local library but are using centralised document templates in another “document templates” library, where no default values are set. When you create a new document in a local library based on one of your document template-aligned content types, it hooks into the content type that the template is assigned to in the document templates library, not the local library.

It is possible to workaround this disappointing, though not unexpected outcome, (given how the document templates have been set up above), by instead setting library specific default metadata values not at the local column level, but at root folder level, by configuring the default value using the “Set column default values” management screen under list settings. This though again cranks up the management overhead, and make the overall approach even less attractive.

All of this general dissatisfaction is compounded if you want to add any new library specific metadata in addition to that provided by the content type. So for example you might want to add a list column that is specific to the library you are in (a not unreasonable requirement). However using this approach in a library with centralised document templates tied to content types will again raise issues, in that if you create a document via the “New document” ribbon options, the additional metadata will not be picked up and presented in the document information panel (as they are not part of the content type that is aligned to the document template!) If you make your new field mandatory, and try to save the document, the document validation fails, and the new field does then appear in the document information panel the second time round, which from a usability perspective is pretty poor indeed.

So there you have it, a good idea becomes a minefield of issues when implemented. I’ll let you decide whether the approach is worth the nasty side effects.

Why “nt authority\authenticated users” is your friend

Next instalment in the series of annoying and painful gotchas you can encounter with the SharePoint platform. The “nt authority account\authenticated users” account is something that appears in the list of people and groups whenever you create a new site collection in SharePoint. If you create a publishing site, you also get a few default groups such as Viewers, Style Resource Readers, Approvers and so on.

I was engaged in a groups and permissions clean-up exercise for a site in SharePoint and was looking to remove unnecessary users and groups. So I used the check permissions functionality under _layouts/user.aspx to see where it was used, and the check came back as “limited access…given directly”. I thought, I’m already providing read access via the Visitors group to a large AD group, so I went ahead and removed the authenticated users group, and never thought any more about it.

Until some strange and seemingly unrelated issues started to occur. I had enabled managed metadata in the site, and set up a few site columns to allow tagging with term store information. Again this was all working ok for me….but not for others. Others could tag with the information from the term store, could see the choices when editing the properties of a particular document and so on…but then in the document library view the metadata was showing up as blank. Hmm…

Elsewhere I had content types containing managed metadata hooked up with document libraries, and when users, set up as Owners with Full control permissions tried to create these libraries, the metadata was again absent from the libraries at creation time.

That got me thinking…I knew managed metadata is handled within individual SharePoint sites via a hidden list that can be navigated at /Lists/TaxonomyHiddenList. So I browsed the list (I’m a site collection admin), and checked permissions, and lo and behold, there were none. I quickly created another site collection to confirm what I suspected was now the cause of the issue – browsing TaxonomyHiddenList in the new site, one where I had kept the default users and permissions, and there it was – Read permission assigned to the group “nt authority\authenticated users”. It was a quick fix to assign Read permission back to list in my other site, and all was well again.

So there you have it…never remove “nt authority\authenticated users” from your site collection…it’s there for a good reason!

Update: I have since found the following blog explaining the issue, so I know I’m not the only one who has felt this pain…

Beware Claims Authentication and SharePoint 2010

Not the title you would expect to read, given that Windows Claims Authentication is the defacto authentication method when setting up Web Applications in SharePoint 2013. Moreover, if we ever need to upgrade legacy SharePoint 2010 web apps to the new version, it is a pre-requisite of that upgrade that the web apps are converted to Windows Claims authentication.

So I had a scenario where I needed to create a new web application on a SharePoint 2010 farm, and with one eye on the future, I decided to create it using the Windows Claims authentication. A few weeks in, I have encountered three major (in my view) issues with this configuration. In fact, I would go so far to say that had I knew about them in advance, I would still be using Classic auth!

Issue 1: Claims and Document Previews in FAST Search for SharePoint 2010 just don’t work. Ok – so I was using that feature, gee, thanks Microsoft. Their recommendation? Go back to using Classic auth. Nice! See here for details.

Issue 2: SharePoint’s “Check Permissions for a user” feature won’t work with Active Directory groups. Claims doesn’t know about AD groups – how did I not know that?! Guess what, I’ve been using AD groups for permissions management in SharePoint up to this point. This useful permissions checking feature is not going to work in my new Claims enabled web application.

Not only that, there are bigger implications of using Claims with the inability to assign them to AD groups that you need to be aware of. It has a major impact on Access Control List (ACL) limits in SharePoint – see this informative article for more…

Issue 3: Claims authentication does not work with the WebDav protocol. Apparently WebDav is not claims-aware – again, no-one told me about this until it’s too late. Surely this must have been resolved though  – opening document libraries in Explorer view for SharePoint 2013 web sites looks ok. In my scenario though, on SharePoint 2010, The WebDav protocol is bypassed and instead it opts for the down-level, and ancient, Front Page RPC. Windows 98 style 2-D icons in explorer view, lovely!!

So all in all, I’m wishing I never moved to Claims now. More pain, no gain!!

Updating the default search scope for a site collection

I have a scenario where I need to update the default scope for over 300 site collections to reflect a new scope that I have created in Search. When the site collections were created at a previous stage, they were using the “All sites” scope as the default scope.

My first thought was that you should be able to do this in PowerShell, and then my second thought, naturally enough, was has someone else already done this? A quick search brought up the following link, which looked like a good contender, so I quickly cobbled together a script based this.

However, when I ran the script, I ran into a problem on the following line of script:
$group = $scopes.GetDisplayGroup($site.Url, ‘Search Dropdown’)

Which led to the following error message:
“Error Calling GetDisplayGroup with 2 arguments, Specified cast is not valid”.

So after another round of searching based on this error, it was soon apparent I was not the only one who had hit on this error message.

Interestingly, whilst no one is able to definitively state why the problem occurs, it appears that if you browse to the actual scope settings page within the site collection administration before running the script, the error does not happen! Hmm….

However, I have over 300 site collections to update, and I certainly did not want to have to browse to each scope settings page for each of those sites beforehand. Luckily for me, there is another approach that works. Instead of getting a reference to the Search context and then loading the scopes based on that, you should actually invoke the Service context for the site collection, which should be the preferred approach anyway as the Searchcontext is an old SP2007 method, and then get the scopes based on the RemoteScopes object, like so:

$ServiceContext = Get-SPServiceContext -Site $SiteUrl
$Scopes = New-Object Microsoft.Office.Server.Search.Administration.RemoteScopes($ServiceContext)

This method works and allows me to run my script to update all my site collections successfully. I have a link to the script for your consumption here.