In todays episode of discovering awesome features in SharePoint 2013 we’re going to take a look at something really interesting, a feature that has been requested for years, a better management of end-user licensing in SharePoint.
Even though this article contains a lot about SharePoint 2013 licensing I must make it very clear that nothing has yet been communicated from Microsoft regarding licensing on SharePoint 2013, and I am no expert on licensing and this is a Preview and this article must be considered as-is, things will and might change over the course of time. Remind me to go back to this article once SharePoint 2013 has gone gold. Microsoft has not made any statements about this and it might be so that you can forget about this article after RTM.
SharePoint has historically existed in two versions, the free called SharePoint Services or SharePoint Foundation and the paid version named SharePoint Server (built on top of SharePoint Foundation). SharePoint Server has had two editions (I’ve no idea how it will be in SharePoint 2013 RTM, but most likely the same as today) – Standard and Enterprise, where Enterprise is the most expensive one requiring specific Enterprise CALs. For some companies it is just a too big expense to go for the Enterprise version, due to the limit that you need(ed) to have Enterprise licenses for all users in the SharePoint farm. But in some cases only a small subset of the users actually require the Enterprise license (which has a lot of the BI and integration stuff). And a lot of companies I’ve met can not justify the extra investment for this. I’ve seen numerous ways to work around this (remember I’m no licensing expert so I’m not saying it’s the legit way to do it). Multiple farms – one standard and one enterprise, is the most obvious one. Downside is that you need to double up on everything (almost)! I’ve seen companies use the multi-tenancy features in SharePoint 2010 to work around it – a really bad decision. And some other ways that we should not discuss here…
Introducing the User Licensing Features in SharePoint 2013 Preview
In SharePoint 2013 Preview there are eight new Windows PowerShell cmdlets, that we are going to cover in this post:
What do these cmdlets do and how do we use them? I’ve been experimenting with the Preview and these cmdlets and set up a sample scenario, which is extremely interesting given the problem statement above about combining Standard and Enterprise licenses.
For another great example on how to use these cmdlets I recommend reading Spence Harbar’s post “Enabling Office Web Apps Preview editing with SharePoint 2013 Preview Licensing” which focuses on how to handle the licensing with the new Office Web Apps server.
Enforcing User Licensing in SharePoint 2013 Preview
Let’s start from the top of that list of cmdlets. If we execute the Get-SPUserLicensing cmdlet in a SharePoint 2013 Preview farm it will return false by default. If we take a look at the help text of that cmdlet we will see something really interesting, The synopsis says “Returns the state of user-license enforcement.”. Looks like we can control/enforce licensing in some way in SharePoint 2013!?
If we move on to the Enable-SPUserLicensing cmdlet and run that cmdlet (Synopsis: “Enables user-license enforcement.”), and then run the Get-SPUserLicensing cmdlet again. It will now return true instead of false – wow, we’ve just enabled User License Enforcement in this farm! We’re on to something really interesting now!
To get back to normal, just run the Disable-SPUserLicensing cmdlet.
Actually, all these cmdlets do is to check or update the Farm property called UserLicensingEnabled. You can check it for yourself:
Note: You should leave the user licensing disabled until you have configured all your license mappings, as I’ll describe in a minute. Not doing so can result in unwanted results.
If we now take a quick look at the Get-SPUserLicense cmdlet and run it. It will return four different licenses; Enterprise, Standard, Project and OfficeWebAppsEdit.
Very cool, huh. I think now you’re starting to get a picture on where we are going with this scenario…
User and license mappings
Let’s take a look at the remaining cmdlets *-UserLicenseMapping. First let’s run Get-SPUserLicenseMapping – it will return nothing. So let’s try to create some.
Before we start that, let’s make sure we have something to do the mapping with. For this I created two Security Groups in Active Directory called “Standard Users” and “Enterprise Users”.
Now, let’s use the New-SPUserLicenseMapping cmdlet and try to create a mapping. The following command creates me a mapping using the “Standard Users” group (the name of the AD group) to the “Standard” license (the name of the license from the Get-SPUserLicense cmdlet):
$map = New-SPUserLicenseMapping -SecurityGroup "Standard Users" -License Standard
If we take a look at the $map variable it looks like this:
There’s plenty of cool stuff in that picture. First of all notice that the –SecurityGroup argument to the cmdlet is converted to a claim, and if you take a look at the New-SPUserLicenseMapping cmdlet you can see that you actually can add a claim directly (for instance create a mapping for all users sitting in a specific building, belonging to a specific department etc…). Also notice that the WebApplication value is empty here – the New-SPUserLicenseMapping cmdlet can also take a Web Application as an argument, which means that you can configure licensing on a per Web Application basis.
This mapping is so far only created “in-memory”, we need to add it to the farm, this is done by just using the Add-SPUserLicenseMapping cmdlet like this:
Add-SPUserLicenseMapping -Mapping $map
We’ll add another mapping, this time using the other group and the “Enterprise” license, and add it to the farm:
$map = New-SPUserLicenseMapping -SecurityGroup "Enterprise Users" -License Enterprise Add-SPUserLicenseMapping -Mapping $map
Now, we can run the Get-SPUserLicenseMapping again and see our result:
We have now created two license mappings – one for Enterprise license users mapped to the Active Directory group “Enterprise Users” and one for Standard license users mapped to the “Standard Users” group.
All that is left is to verify that it all works!
Verify the license assignment
To see if it all works, as we all now hope it should, let’s create a page with, let’s say, the Excel Viewer Web Part. In this case I use a user which is member of the “Enterprise Users” group to create the page and add the Web Part. It looks like this, just as we expect:
Ok, let’s log in as a user who is member of the “Standard Users” group and go to the very same page:
What! Did you see that. It’s worth a close-up:
Woohaa! This must simply be one of the best features ever implemented in SharePoint!
Even if I take a look at that page using a user that is not part of any of the two groups with license mapping (i.e. not having any license) it will show me that I don’t have licenses to use it.
Let’s do another test – edit the page and look at the available Web Parts using the two users. And as you can see the Standard user cannot add the Enterprise Web Parts.
Enterprise user Standard User
Where is this licensing enforced?
I’ve been fiddling around in excitement with this and found that the licensing is enforced in the following places, which seems the logical places to have it enforced:
- Web Parts – just as you’ve seen above
- Web Part Gallery – second example above
- Web Templates – when creating new sites
- In Document Libraries – in combination with Office Web Apps permissions (as Spence Harbar explains here)
What areas does it affect, prohibit usage?`
Although I have not tested all features, some testing and reverse engineering have told me that these are the things you get with the different licenses:
- Standard: My Sites
- Enterprise: Access Services, BCS, BI-stuff, InfoPath, PerformancePoint Services, Visio, My Sites (and some more)
- Project: Project Server
A couple of notes…
To get this to work, you need to have a Claims Web Application – without it, it just don’t work!
This article is all about on-premises installations. There are features in this capability only for SharePoint Online/365 to satisfy those needs (desk less users etc.).
Do not “over design” your license mappings for a manageability reasons. It defeats the whole purpose of this feature – you need to know what users have what licenses. And nothing is worse than having your end-users getting the message that they don’t have permissions to use the features they are entitled to.
Make sure that you have a fallback mapping! As I mentioned if any user does not fit into any of these mappings they will not even have access to the “Standard” features.
There is only Windows PowerShell configuration for this. Nothing fancy in the Central Administration that helps you visualize it. It is all up to you to create the correct scripts. Oh, and to document this configuration!
I think Microsoft finally nailed it! If all this works as above when SharePoint 2013 RTM’s and it actually can make clients combine Standard and Enterprise licenses in a single SharePoint farm, without violating any license agreements, this is going to be huge. Using these features you can actually have control of exactly how many users that have access to a specific license and pay for the correct amount of licenses. I can for sure tell you that Microsoft will get a handful of new clients and especially Enterprise CAL users, just from my set of clients. Also this will clear up a lot of the licensing discussions and most likely prohibit people from doing really stupid design decisions/mistakes. And this fits very nice where Microsoft is going as well, into a more versatile and agile licensing/subscription model and it will likely be easier for clients to move to the cloud/Office 365 if they start thinking about subscriptions internally (as in don’t let the IT department pay all the licenses, let the ones having needs for it pay it instead).
Finally SharePoint has a solid and manageable way to configure licensing within a single farm. Really looking forward to discuss this new feature with my clients.
For some reason I get a lot of questions in my inbox about different SharePoint problems people have. I don’t mind, as long as they are polite. If I have time I do try to help out, but sometimes time is not enough. I’m sorry if I don’t answer all of them. But in order to help more people I have compiled a set of rules for SharePoint Troubleshooting.
First rule of of SharePoint troubleshooting: You should always check the ULS logs
The Trace Logs, often called ULS Logs, is where you find your answer to most of your problems. Always use ULS Viewer - if you do not have that tool in your kit, then you’re out on thin ice, period! Check the correlation id, search for exceptions and warnings. Things I almost always find the answer to here is “file not founds” (404) and “Access Denied”s (401). If you cannot find it immediately in the logs and you can re-create the problem, turn up the logging level to Verbose.
Second rule of SharePoint troubleshooting: You SHOULD ALWAYS check the ULS logs
That’s right! This is the first thing I ask people when they are in trouble and in 99% of the cases the problem is detailed in the logs.
Third rule of SharePoint troubleshooting: If SharePoint yells stop or goes limp, do an IISRESET
Using IISRESET will solve a lot of issues with SharePoint, or any IIS based product for that matter. Note that IISRESET often only temporary solves the problem, so you would most likely want to investigate it further, hence the other rules…
Wish there was a noderunnerreset in 2013…
Fourth rule of SharePoint troubleshooting: At least two guys to a fight
When in doubt – ASK SOMEONE! You don’t have to e-mail Spence Harbar the first thing you do, but please, please ask someone else before you start to mess with your farm, without knowing what you are doing. The first question back you’re going to get is of course – “Have you checked the ULS Logs”, so make sure to do that!
Ask the community, use the Twitter #sphelp hashtag, use the great forums out there such as SharePoint StackExchange, there’s almost always someone there who would like to help you. Oh, and most likely you will find it on your first Bing attempt.
Fifth rule of SharePoint troubleshooting: One problem at a time fellas
This is also a very obvious rule, but I so often see that once a problem occur SharePoint “Professionals” try to fiddle with all the knobs and dials in SharePoint to mitigate the problem, only to get themselves out on deeper water. Step away from the keyboard, take it easy, check the ULS logs and isolate and understand your problem!
Sixth rule of SharePoint troubleshooting: No database fiddling
Touching the SharePoint databases is a big no-no. There are tons of blog posts out there that “solves” problems by manually editing the SharePoint databases. Once you’ve done that you will be unsupported and you will live in shame forever. Just don’t do it!
Seventh rule of SharePoint troubleshooting: Troubleshooting will go on as long as it have to
Prepare for a long fight with SharePoint. Sometimes she is a really vicious one, and you will often see others having the same problem(s) on forums etc., but most often without any decent answers. I’ve spent numerous long nights trying to figure out what the heck is happening. Always remember, that you can open a case with Microsoft – and let them stay up all night instead!
Then eight and final rule of SharePoint troubleshooting: Is this is your first problem, you have to fight!
This is the rule most people have problems with. But if you follow the rest of the rules you will while troubleshooting realize how much you learn about SharePoint and all the surrounding products. And this will make your next troubleshooting much, much easier!
“Without pain, without sacrifice, we would have nothing…”
I thought it was about time to bust one quite common myth in the SharePoint world (and there are lot of them!). This one in particular is interesting because it can cause you some interesting troubles, or at least some embarrassment. This is about that you can determine the current SharePoint  version by checking the HTTP Response Header called MicrosoftSharePointTeamServices. So let’s bust that myth, or at least try!
On a standard installed SharePoint Farm when you request a page you will get a set of response headers back. One of these response headers are named MicrosoftSharePointTeamServices and it has a version number as value, like this:
As you can see in the image the version number is 126.96.36.19914, which corresponds to SharePoint 2010 (14) and December 2011 Cumulative Update (6114).
This header is not added by SharePoint (in the pipeline) but rather by IIS, even though it is SharePoint who adds it to IIS.
If you fire up the IIS manager and go to a SharePoint web site and check the HTTP Response Headers Feature, you can see that it is configured there.
If you check the Central Administration Web Site you’ll it also have the same exact version value.
You can even change the headers in the IIS Manager (what good that now would do). So we basically already busted the myth! But let’s assume that you don’t fiddle with this and continue our research…
Applying a cumulative update
Let’s take this 6114 farm, which was a slipstreamed 6114 install, and apply the April 2012 CU (6120) and see what happens. After applying the April CU we’re seeing this in the returned header on our Central Administration that the response headers shows the correct value – 188.8.131.5220.
Now, take a look at the header on the content web application that we looked at before the B2B upgrade:
6115!!! What!? After checking both Todd and Todd’s version lists we have no idea what version this is?!? It is something in-between December 2011 and February 2012! Ok, let’s apply June 2012 CU, which is build number 6123, on top of this. After running the Configuration Wizard again this is response header we’re receiving.
6122! Close but no cigar! Central Admin on the now patched farm still shows the correct build (6123).
Adding a new Web Application
Now let’s do another experiment – add a new Web Application to this farm. After that we’ll see that it actually contains the correct version header (6123).
Adding a new server to the farm
One final experiment, let’s add a new server to this farm, that was upgraded from December 2011, to April 2012 and then to June 2012 CU, with a slipstreamed June 2012 machine. This is how it looks if we browse to the original web application (that we updated twice).
The newly created one, shows the “correct” build. Also a check in the IIS verifies that both web sites have the “correct” build number in the response headers feature.
This is interesting, this means that in a load balanced scenario you could actually get different build values from the response header!
Let’s do this experiment once again but slightly different. This time instead of running the Configuration Wizard after applying the patch, let’s do it the hard core way by using psconfig.exe:
psconfig.exe -cmd upgrade -inplace b2b -wait
The key here is that I use the –wait flag, which makes sure that the upgrade process is executed as the user running the command, instead of in the owstimer.exe process (which is running as the farm account).
Low and behold, now the response header shows the correct build version (6123) in Central Admin and on the content web application!
Why these strange build numbers?
To make a long story short it all comes down to how the farm is updated, specifically which account you’re doing the upgrade with. We can also say that if you’re running the Configuration Wizard and get the “correct” build number in the response headers, you’re farm is misconfigured :-). When I ran the psconfig.exe command with the –wait switch I used an account that was a member of the local Administrators group, whereas my farm account (running the owstimer.exe process) is not.
Deep down between the zeroes and ones in the SharePoint code there is actually a code snippet that checks if the account running the upgrade is a member of the local Administrators group. If the account is member it will nice and quietly update the IIS metabase with the (file) build number, taken from the current assembly which is Microsoft.SharePoint.dll. But if the user is not a local Administrator (and cannot edit the metabase), the operation is passed on to the WSSAdmin component (running as Local System) which uses another assembly. This assembly is called Microsoft.SharePoint.AdministrationOperation.dll, and the metabase is updated with the (file) build number for that assembly. This table below shows you the version info for the two CU’s we’ve been looking at.
Microsoft.SharePoint.dll Microsoft.SharePoint.AdministrationOperation.dll April 2011 Cumulative update 14.0.6120.5000 14.0.6115.5000 June 2012 Cumulative update 14.0.6123.5002 14.0.6122.5000
Fortunately in these cases the AdministrationOperation dll has had changes between released CU’s, but what will happen the one day when there is no need to patch that assembly. Well, in that case the build number will stay as in the previous version/build/CU.
So there you have it – you cannot trust this MicrosoftSharePointTeamServices response header as a single source of trust when you need to remotely find out your SharePoint build and version. Even if you keep track of all the specific builds of the administration assembly, since it might not be updated, and you cannot be sure that everyone runs psconfig with the –wait switch.
The myth is busted!
SharePoint Designer shows the correct version!?
Let’s take a look at how you can retrieve the correct version number remotely. It hurts me to tell you – but the best source for this is to use SharePoint Designer! Yes, SharePoint Designer shows you the current build in site information panel.
Note: SharePoint Designer uses a call to /_vti_bin/shtml.dll/_vti_rpc to find out the version number
“I read somewhere that the Client Object Model has the correct version number!”
When we take a look at the response from this request we’ll see this:
6108! That is somewhere in-between the June 2011 CU and the August 2011 CU, a year old stuff! It is basically the same reason as previously, this build number is fetched from the Microsoft.SharePoint.Client.ServerRuntime.dll assembly, and that one has not been/needed to be updated since last year (someone give that PM a nice cake!).
How about removing the header?
Someone of you might think that it is a good idea to remove this header, since it can at least tell you (or your enemies) something about your farm. Ok, for a public facing WCM site (or public facing blog sites :-) it might make sense, but if you do it you must know that it will cause troubles when crawling, people will not be able to work with documents etc etc. So just don’t do it without a proper cause and testing.
Note: Disabling Client Integration on the web application will remove the response header.
That was fun, right? We did bust a myth about how you can find out the current SharePoint version just by looking at the HTTP response headers. The MicrosoftSharePointTeamServices response header really doesn’t say anything (except some kind of minimum build level) since you don’t know how they built/slipstreamed the install or upgraded the farm.
In this small post I’m going to show you a really nice new feature to SharePoint 2013. It’s the Access Request and Invitations feature that allows you to easier manage access requests to your sites. Access Requests has been in the product for quite some time but required that your admins checked their e-mails once in a while. Using the new Share feature in SharePoint 2010 this process is so much easier. This has somewhat been blogged by the SharePoint team, but I would like to share my view of it.
Note: this is written for the SharePoint 2013 Preview. Change things will….
For this article, assume that we have a public site enabled with Azure Access Control Services federated authentication so end-users can sign in with Google Id, Live ID (or whatever they call it today…) etc. If we do not have anonymous users enabled all users without access will be prompted with the polite message “Sorry, this site hasn’t been shared with you”.
Nothing more than that. So how do I share it then…
Enabling Access Requests
First of all you need to enable Access Requests, and this is no magic feature or button in Central Admin, it is actually enabled the same way as it has been in previous versions. To enable for users, with no access to the site, to request access to the site you need to enable Outgoing e-mail settings. This is done in Central Administration under System Settings > Configure outgoing e-mail settings. Note that this is a per farm configuration!
Once this is enabled your users will instead see this screen:
Nice huh. Now if you want access to the site you’ll just jot down a reason and click Send Request. The site administrator will be notified by e-mail and your request will be saved in the site. If you get back to the site after a couple of weeks without getting any access you can see your request history and that it is pending.
Access Request administration
The site administrators can at any time click on Site Settings (the cog wheel) > Shared With to see the current Sharing status. If there are pending access requests, they will see a notification and can click on View Requests to deal with them.
The administrations will see all pending access requests in a list where they can see who wants access to which site and by clicking the ellipsis (the … ) they can see status of a specific request.
They can use this dialog to Approve or Decline the request or to initiate a communication with the person doing the request. For instance if we write a message to the requestor it will show up on the access denied page like this:
If the site administrator declines the request this will also be noted on the access denied page:
The end-user can still continue to hassle the site owner (or bribe, whichever works best) until he get’s an approval, which results in an e-mail to the requestor. The site owner can when approving a request specify what Permissions to give to the user either through a group or by setting a Permission Level directly on the user (discouraged!).
Site owners can also go to Site Settings and choose Access requests and invitations.
If you want to disable this feature for your Site Collection you need to go to Site Settings > Site Permissions and then click Access Request Settings in the ribbon (Note: this is only available if it’s enabled at a farm level, that is outgoing e-mail is configured). From there you can turn off the access requests, for instance if you don’t want annoying users requesting access to your über cool site!
Note: in the SharePoint 2013 Preview build, the History feature does not work, unless you use something like Internet Explorer Developer toolbar to unhide the History web part :-). It’s just a small opacity bug…
The site owners can check the sharing history on the sharing admin page, by clicking on the Show History link.
This list will show all approved or accepted requests and who did the actual approval/denial.
Some quick notes about the Access Requests internals. It is all stored in a hidden list (hey, it’s SharePoint) called “Access Requests”. This list has three views/pages:
- Guest user invitations (Access Requests/pendinginv.aspx)
- History (Access Requests/oldreq.aspx)
- Pending Requests (Access Requests/pendingreq.aspx)
Good to know if you want to leverage/improve the functionality of access requests in your applications. This list has unique permissions with only Site Owners with Full Control.
SharePoint 2013 has with this simple feature made it so much easier to create and manage community sites; internal or external. It’s these little things that make a huge difference!
SharePoint 2010 introduced the Service Application concept and that architecture model also includes the possibility to publish and consume service applications between farms. For instance you could have the Managed Metadata service application in one of your farms and use it in another farm. There are several interesting and valid scenarios for this and some of them include having dedicated Shared Services farms, that is a farm that’s only hosting service applications and not any content applications. If you have one of these farms, or farms that publishes or consumes service applications you are facing an interesting upgrade scenario when looking at SharePoint 2013. In this Visual Guide I’ll try to go through all the required steps for a successful upgrade to SharePoint 2013
Note: this is written for SharePoint 2013 Preview. Things might change over the next few months up until RTM. If I remember I’ll go back and revisit the post when RTM is due, if not, remind me.
As you perhaps know by now, there is no inplace upgrade in SharePoint 2013, which means that you have to do the database attach approach in a completely new SharePoint 2013 farm. If you’re still reading I assume that you have farms and service applications that are published and consumed, and you might start to get a slight headache now when you realize that you might have to synchronously create new farms and move all your databases. Well, don’t be sad – I have good news for you.
SharePoint 2013 allows it’s published service applications to be consumed by a SharePoint 2010 farm. This means that we can upgrade the farm that is hosting the service applications first! In a services farm case, it means that the services farm can be upgraded to SharePoint 2013 and then you can later upgrade the consuming farms, one at a time. This will save you lot’s of administration and testing and is just plain awesome! Of course this is not a recommended long-term scenario – you would like to get up on SharePoint 2013 with all your farms, but you can take one farm at a time which allows for better resource management and most likely you make it an easier decision for the ones owning the budget. So let’s get started…
Note: I’m not going to cover content application upgrade or upgrade of all service applications in this article, I’ll save that for later or for someone else…
Prerequisites and setup
In this guide I have a two farm setup; one farm with content applications and one farm with service applications. I will only use one service application – the Managed Metadata Service Application (which is the SA that is the best candidate for SA publishing). Beware of that not all service applications can be published and you cannot take advantage of the new 2013 Translation Service (which can be published) in a 2013 farm. Also you cannot take advantage of all the new features in the new service applications until you have fully upgraded the consuming farms to 2013.
In this guide I’m running SharePoint 2010 Service Pack 1 (December 2011 CU) in both my 2010 farms. I’ve not seen any specific requirements of version or CU level, if someone knows, please chime in. The farms in this case isn’t that spectacular it is single machines with Windows 2008 R2 and SQL 2008 R2 installed, but it sounds better with saying farm. They are all in the same domain, and the DC is located on its dedicated box.
The consuming farm machine is called SP2010A and has one content web application, with a Site Collection that has a Managed Metadata site column. The Managed Metadata is consumed from the other farm (machine name SP2010B).
Step 1: Set up a new Services Farm using SharePoint 2013
In order to start our upgrade path the first thing we need to do (except all the backup you normally do anyways, no?) is to set up a new parallel SharePoint 2013 farm. This farm is set up on a machine, called SP2013A, with SQL Server 2008 R2 and SQL Server 2012 SP1 CTP (going a little bit crazy here…). It’s a vanilla install, no farm configuration wizard or other voodoo. The 2013 farm has all the pre-requisites installed as well as the three KB articles KB2708075, KB2554876 and KB2472264. The installation of the 2013 farm was also done using the same accounts as used in the 2010 service farm.
Before proceeding I need to setup the publishing trust between the 2010 content farm and the 2013 services farm. This is done by exchanging certificates. Let’s start with exporting the certificates from the 2010 consuming farm:
asnp microsoft.sharepoint.powershell $rootCert = (Get-SPCertificateAuthority).RootCertificate $rootCert.Export("Cert") | Set-Content "C:\ConsumingFarmRoot.cer” -Encoding byte $stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate $stsCert.Export("Cert") | Set-Content "C:\ConsumingFarmSTS.cer" -Encoding byte
asnp microsoft.sharepoint.powershell $trustCert = Get-PfxCertificate C:\ConsumingFarmRoot.cer New-SPTrustedRootAuthority "SP2010A" -Certificate $trustCert $stsCert = Get-PfxCertificate c:\ConsumingFarmSTS.cer New-SPTrustedServiceTokenIssuer "SP2010A-STS" -Certificate $stsCert
To verify that it worked fine, open up Central Administration on the 2013 farm and go to Security > Manage Trust, it should look something like this:
Next is to export the root certificate from the 2013 farm:
$rootCert = (Get-SPCertificateAuthority).RootCertificate $rootCert.Export("Cert") | Set-Content "C:\PublishingFarmRoot.cer" -Encoding byte
Copy the file to the 2010 farm and import it like this:
$trustCert = Get-PfxCertificate C:\PublishingFarmRoot.cer New-SPTrustedRootAuthority "SP2013A" -Certificate $trustCert
And verify it on the 2010 consuming farm:
Now we need to make sure that the consuming farm can query the Application Discovery and Load Balancing Service in the 2013 farm. This is done by using the Id of the consuming farm as identity. This is a Guid that you get like this (run the PowerShell on the 2010 farm!):
In the 2013 farm go to Central Administration > Application Management > Service Applications and select the Application Discovery and Load Balancing Service. Then click on the Permissions button in the ribbon. Enter the Guid into the textbox and click Add, then give the remote farm Guid Full Control permissions and click OK, as in the picture below.
Now we are all set and done to proceed to the next step.
Note: as you just saw, the steps are exactly the same as on 2010.
Step 1b: The firewall (optional, but required)
If you have the/a firewall enabled you need to open up the required ports for Service Applications between the farms. This is a script that I find handy for that:
netsh advfirewall firewall add rule name="SharePoint 2010 Service Apps HTTP (TCP 32843)" dir=in action=allow protocol=TCP localport=32843 profile=domain netsh advfirewall firewall add rule name="SharePoint 2010 Service Apps HTTPS (TCP 32844)" dir=in action=allow protocol=TCP localport=32844 profile=domain
Step 2: Set your Service Applications into read-only mode
Once you have your (now) three farms ready you have a couple of options, depending on which service applications your services farm host. For instance if you have the Search Service Application published you are a bit lucky. This is a service application where users do not edit/write data – they just read the index. So you can have your 2013 service farm and 2010 service farm running in parallel and testing the new one. In service applications such as Managed Metadata its another story. In this case end-users might tag information, they might add new terms etc. In order to not loose any data you need to make sure that the end-users can’t edit data in that service application.
In the case of managed metadata I do two things – first of all I remove all permissions for the end-users, so that they do not update/add any data. Secondly I set the database used by the managed metadata service application to read-only – to make sure that no edits are done. And third – I put up a notification about this service update on the Intranet a couple of weeks in advance :).
Note: The MMS service application has some issues with having it’s database in read-only mode and it logs warnings and errors to the trace log. In this case we don’t care about that – we just want to protect the data.
I set the database into read-only mode on the 2010 service farm to Read-Only by editing the properties of the database and under Options select Database Read-Only to true.
Step 3: Backup and restore Service Applications databases
From this time we need to know about timings, since the users cannot add new terms and stuff in the MMS database. For your production farms you should test and time this properly so you can inform your users about how long it’s going to take.
To move the database to the SQL Server on the new 2013 services farm I just do a backup and restore of the MMS database and then since we backed it up in Read-only mode I just flipped the switch back to normal mode.
As you can see in the picture, I restored it to a new name. This is my personal preference and a recommendation. In a few minutes it will be a 2013 database and no longer a 2010 one.
Step 4: Create new Service Application
The next step is to configure the 2013 service farm and to create a new MMS service application and do a database attach upgrade of the database we just copied.
Note: This part can (and probably should) be fully automated using PowerShell, but in this post it kinda contradicts the idea of a Visual Guide…
First of I configure a service account to be used for the service application pools on the new service farm. In this case I use the exact same service accounts that I did in the 2010 service farm, to minimize the likelihood of errors. Once that is done I’m ready to create the new MMS service application.
In Central Administration under Service Applications choose to create a new Managed Metadata Service.
In the dialog that appears fill in the name of your new service application and in Database Name, enter the exact database name of the database you just restored to. That is, we’re pointing the new service application to an existing database. When we click OK, SharePoint 2013 is going to take care of the upgrade of that database.
Next fill in to create a new application pool using the managed account you previously registered.
Once that is done, just click OK, and wait for the service application to be created and the database to be updated. When all is done you Service Application Page in the 2013 services farm should look like this:
Now, go ahead and start the service instance on the servers in your new services farm.
The service should now be up and running and all you have to do is to give permissions to the service application. In this case a good starting point is to configure the same permissions on the new 2013 MMS SA as you had on the 2010 one.
Step 5: Publish and Update the Service Application Connection
Now we are ready to start the publishing process of the new 2013 MMS SA. First of all we need to give the consuming farm permissions to use the service connection. This is done exactly the same as we did for the Application Discovery and Load Balancer Service Application. Use the Farm Id of the remote farm and give it permissions for the new MMS SA:
Time to hit Publish! Publishing of a service application hasn’t changed so the steps are the same as you did for your old 2010 service farm. First select the service application, then click Publish. Copy the hideous long Published URL into notepad (or remember it)
Click OK and wait for it to finalize its configuration.
Now it’s time to go back to the 2010 content farm. Navigate to Service Applications in Central Administration.
This is probably the most critical part of this whole upgrade. We are going to remove the old connection to the 2010 services farm. And once we click Delete, the end-users will be limited in what Managed Metadata features they can use. Don’t be worried though, it will only take a minute to get the new 2013 connection up and running.
So select the old 2010 connection and click Delete.
Now, let’s create a new Connection. Select Connect > Managed Metadata Service Connection
In the dialog paste (or enter) the Published URL that you got from the 2013 farm when published the MMS SA.
Click OK and wait for the 2010 farm to discover the remote 2013 MMS SA. It will take a couple of seconds. When it’s done, you are welcomed with a fantastic intuitive UI. You need to click on the Managed Metadata Service Connection, its background should turn into yellow. Then Click OK.
When prompted for the name of the Service Connection, either enter a vanity name or accept the suggested one. Click OK to finalize the connection.
You should now be able to see your new Service Application Connection as well as the connection to the new remote Application Discovery SA.
Step 6: Test
All that is left now is to test if we got what we wanted.
First; in the new 2013 MMS SA enter a couple of new terms and let’s see if that is reflected on our 2010 farm.
Fire up the MMS management interface on the 2010 farm and see our newly created term. Looks like it is working!
In this view, note that we do not have all the new 2013 features, but you can clearly see the Term Groups from the 2013 MMS SA that is created for the new Search Service.
Then in the content web application, where I had a document library with a MMS column. Let’s edit document properties for a document there…
Yup, the new term is there as well.
Step 7: Kill the old services farm
Next step is to decommission/kill/retire the old services farm and return the metal to the metal gods! Well, you need to make sure that you have upgraded all shared service applications before doing that. The procedure for the rest of the service applications are almost the same, but I’ll let you figure out the differences :)
Step 8: Upgrade the consuming farm(s)
Even though this works fine it’s not a long lasting situation, you would like to draw benefit of all the new 2013 features. So the final step in this upgrade scenario is to upgrade the content farm. Details for that is for another post.
I hope this bedtime story post gave you some insights in how to upgrade a shared services farm from SharePoint 2010 to SharePoint 2013. As you can see it’s a very smooth transition and upgrade. This whole scenario should also show you one of the benefits of having separate service farms, this allows you to make an upgrade easier and faster.