So consider the scenario, you have a SharePoint 2010 environment running your corporate intranet, mySites, team sites etc. You want to make the move to 2013. Migration from team sites is going to take some planning and also some time, heartache, sweat and tears. As for the intranet that is simply going to be an absolute pain to move.
So although migration is on the cards, you want to make the most of the some of the new features 2013 provides. For example the new search, continuous crawl, deep refinement and greater relevancy. Basically the kind of stuff people want from a search engine. Well you can, and on top of that you can do this so your users don't notice a change, except of course for better results!
What we can do is create a trust between your 2010 and 2013 farms, publish your 2013 Search Service Application and consume it in 2010 using the original 2010 Search Center, and here's how...
Within your 2013 Farm Search Administration, first check the default access
account.
Back in 2010, this account needs adding into the User Policy
to the web application(s) to be crawled with the ‘Full Read’ permission. (It’s
worth pointing out here, both farms are on the same domain. Otherwise domain trust
needs to be setup and you have to set searchadforests people picker property
etc etc, this is a different blog for a different day)
Now add a new Content Source in 2013, here I have called
mine ‘SharePoint 2010 Sites’ (you could of course add these URL’s to the existing
Local SharePoint Sites content source, but you may want to scope these out
later so I recommend separating them.
You can add schedules for full and incremental crawls or
enable continuous crawling at this stage, but again you can come back to this
later. When your happy with the settings, kick off a full crawl.
Check
in crawl log that you’re getting successes on the newly added content source.
Also check some results are coming back from the new content
source when running a search in an SP2013 Search Center.
OK, time to add some trust between the farms. First up we
need to dip into Powershell to get some certificates. Now, the way this works
is certificates need transferring from the publishing farm to the consuming
farm and vice versa, creating a two way trust. There are two certificates in
question, the Root Certificate and the Security Token Service (STS) Certificate.
Just to make things a little complicated, both farms need each other’s Root Certificate, however only the publishing farm needs the STS Certificate of the consuming farm. SharePoint does try to explain this in the ‘Manage Trust’ dialogue located in Central Admin – Security.
Just to make things a little complicated, both farms need each other’s Root Certificate, however only the publishing farm needs the STS Certificate of the consuming farm. SharePoint does try to explain this in the ‘Manage Trust’ dialogue located in Central Admin – Security.
On an SP2010 server, fire up a SharePoint Powershell window
and run the following to grab the Root Certificate (the folder these are copied
to needs to be created otherwise the command will error).
$rootCertificate = (Get-SPCertificateAuthority).RootCertificate
$rootCertificate.Export("Cert")
| Set-Content C:\Cert\SP2010Root.cer -Encoding byte
And now for the STS Certificate
$stsCertificate = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
$stsCertificate.Export("Cert")
| Set-Content C:\Cert\SP2010STS.cer -Encoding byte
Copy these off to somewhere safe on your local machine, or
the machine you’re launching your Central Admin sessions from.
Before closing the Powershell window on the 2010 box, we may
as well grab the farm GUID while we’re here, all will become clearer later on!
Run the following and copy the resulting GUID it provides.
$farmID= Get-SPFarm
$farmID.ID
Head over to an SP2013 box, again fire up Powershell and run
the script to get the root certificate, again copy this to your machine. Notice
I’ve named these appropriately so we choose the right ones later!
$rootCertificate = (Get-SPCertificateAuthority).RootCertificate
$rootCertificate.Export("Cert")
| Set-Content C:\Cert\SP2013Root.cer -Encoding byte
Right, now to apply these certificates in the respective farm’s
Central Administration. Let’s get 2010 out the way first. Head to Security – General
Security - Manage Trust, we’re going to add a new trust relationship, so yep,
you guessed it, hit the new button. We want to give this trust a name, this is
only really for you as an admin so pick something meaningful, I’m going for ‘SP2013
Farm Trust’.
Next, in the Root Certificate for the trust relationship section, click browse and locate the 2013 Root Certificate you copied earlier. Finally, leave the STS Certificate section blank.
Next, in the Root Certificate for the trust relationship section, click browse and locate the 2013 Root Certificate you copied earlier. Finally, leave the STS Certificate section blank.
Hit OK, and we’re done. Now for SP2013 CA. Again, same as
before Security – Manage Trust – New.
This time I’m going for SP2010 Farm Trust as the name and applying the root certificate we extracted from the 2010 farm. This time though, we need to tick the box ‘Provide Trust Relationship’, provide if you want a Token Issuer Description, and add the 2010 STS Certificate in the final section of the Establish Trust Relationship dialog.
This time I’m going for SP2010 Farm Trust as the name and applying the root certificate we extracted from the 2010 farm. This time though, we need to tick the box ‘Provide Trust Relationship’, provide if you want a Token Issuer Description, and add the 2010 STS Certificate in the final section of the Establish Trust Relationship dialog.
Hit OK, and that’s trust configured. Now we need some
permissions. Still in SP2013 Central Admin head to Application Management –
Manage Service Applications.
Find the ‘Application Discovery and Load Balancer Service Application’ highlight it, and choose ‘Permissions’ from the ribbon
Find the ‘Application Discovery and Load Balancer Service Application’ highlight it, and choose ‘Permissions’ from the ribbon
Remember the GUID of the SP2010 farm we collected earlier?
Now’s the time to make use of it.
Paste it into the picker in the Connection Permissions dialog.
Paste it into the picker in the Connection Permissions dialog.
And choose ‘Add’, this should resolve and give a bit more detail
in the name, tick the full control checkbox and hit OK.
Repeat this for your Search Service Application also.
When done, leave the Search Service Application highlighted
and we’re now going to publish this, so in the ribbon you’ll see a Publish
button.
Hit this. In the resulting dialog choose your connection
type (my farms are both internal and so not SSL secured I’ll be going for http),
tick the ‘Publish this Service Application to other farms checkbox’, we’ve already
added trust so no need to click the ‘add a trust relationship’ link. You will
see a published URL, get a copy of this from urn through to svc. In the
description text, put something useful in here.
Now let’s see the fruits of our labour and connect to the
published Search Service Application from our 2010 farm! Head to 2010 CA, Application
Management – Manage Service Applications. Choose ‘Connect’ form the ribbon and
select the ‘Search Service Proxy’ option.
Paste in the published URL copied from the SP2013 publish
operation.
Choose Ok and this will tick over for a moment or two and
then hopefully tell you that there is a Search Service Application at the
address you specified. Click on it to highlight it and the OK button will
become active.
Just a quick note on the Add this service application’s proxy to the farms default proxy list. I’m not going to go into the whys and wherefores of Service Application proxy’s, but in some instances it may not be best to add this to the default at this stage. For example, in my circumstances, I have an up and running 2010 Search Service Application service our users, I plan to do a scheduled switch over to the 2013 search engine at some stage, but not right now. For this reason, I will be deselecting this box and at a later date editing the default proxy to remove the existing search and add this one. So just something to consider..
Just a quick note on the Add this service application’s proxy to the farms default proxy list. I’m not going to go into the whys and wherefores of Service Application proxy’s, but in some instances it may not be best to add this to the default at this stage. For example, in my circumstances, I have an up and running 2010 Search Service Application service our users, I plan to do a scheduled switch over to the 2013 search engine at some stage, but not right now. For this reason, I will be deselecting this box and at a later date editing the default proxy to remove the existing search and add this one. So just something to consider..
Anyway, after hitting OK, you get the chance to give this
connection a name, again choose something meaningful.
Following this, and all being well, you should get a lovely
successful message!
Finally we need to associate this with your web
application(s) that you are running your searches from. There are a few
scenarios here depending on your setup.
I mentioned before I didn't add my connection to the default
proxy group as I have an existing SSA. If this is your case, then you can
create a new proxy group in SP2010 (or use custom) and associate your new 2013
Search Connection leaving off your old one, and then in turn associate the
desired web application(s) with the new proxy to use the new search.
In the case you added this to the default proxy group, one
of the following will apply:
- You do not have an existing SP2010 Search, in which case you’re good to go.
- You have an existing 2010 Search. This will still be the default search provider. To make your web applications switch to the new 2013 one, head to 2010 Central Admin – Service Applications – Configure service application associations, click on the ‘default’ Application Proxy Group and you will see both your Search Service Applications ticked, notice the original one has the word [default] next to it, to set the other one active, click the [set as default] link
- You do not have an existing SP2010 Search, in which case you’re good to go.
- You have an existing 2010 Search. This will still be the default search provider. To make your web applications switch to the new 2013 one, head to 2010 Central Admin – Service Applications – Configure service application associations, click on the ‘default’ Application Proxy Group and you will see both your Search Service Applications ticked, notice the original one has the word [default] next to it, to set the other one active, click the [set as default] link
You could of course un-tick one of the Search providers here
as well, which would do the same thing.
The settings made in the Configure Service Application Associations dialog are applied immediately and you can make searches from the respective providers and see the results!
The settings made in the Configure Service Application Associations dialog are applied immediately and you can make searches from the respective providers and see the results!
There you have it, SharePoint 2010 powered by the much superior SharePoint 2013 Search engine.
