Monday, 14 July 2014

SSRS 2012 R2 Integration with SharePoint 2013

So it came to my attention the other day that the setup for the SQL Server Reporting Services with SharePoint 2013 wasn't the most straight forward I've installation or configuration I've ever done. If you've got a multi-tier farm like we have, you'll have to actually install the Reporting Services on one of the SharePoint 2013 Servers away from the SQL Server box. In our environment, our Search runs on our second application server, so I decided to install SSRS 2010 R2 onto my first application server.


Mount the SQL ISO onto your SharePoint Application server. The reason for this install is to have Reporting Services talk to SharePoint. You'd rather not install SharePoint onto your SQL box, so the best solution is to install Reporting Services onto the SharePoint box. When coming to create the database for ReportServer, your DBA's may have a certain naming convention they like to use, so you'll want to use this when creating a database from SharePoint for SSRS.

Go through the SQL Reporting Services setup as below as we're only installing SSRS in SharePoint Integrated mode.








When you get to the below screen, choose the following options:













After running these steps, restart the server. 

Once restarted, you'll need to enable the services on the server. I used the powershell commands:

1. “Install-SPRSService “ cmdlet from “SharePoint 2013 Management Shell”
2. Run “Install-SPRSServiceProxy” to install the service proxy
3. Run “get-spserviceinstance -all | where {$_.TypeName -like "SQL Server Reporting*"} | Start-SPServiceInstance” to start the service.


It may say, the services have already been started, which is fine. Go into Central admin and make sure that they are started for sure.


The next step would be to create the SQL Reporting Services Service Application.

Click on Application Management > Manage Service Applications from Central Admin, then New and choose the SQL Reporting Services Service Application.


Fill in all the required details including the name of your Report Server which your DBA may want named in a certain way. And press OK.


Once done, you are all set to go.

You can either create a document library to store reports or see the content types now on your sites.

Friday, 11 July 2014

Deploying and Configuring Office Web Apps Server 2013



I'm installing a single server Office Web Apps 2013 'farm' on a Windows 2012 R2 box.
First up, getting hold of the software.. No subscription needed just head over to Microsoft's website grab yourself the .img file, I wont make you go hunting, the link is here! (UPDATE: I'm afraid now this is not the case, Microsoft have decided to only make this available on the VLSC / MSDN download centers.) While we're in the realm of the Microsoft site, you may as well pick up the latest service pack for it: SP1
(note, you are still required to have a licence, at least for editing Office files, but it is likely you are covered under your EULA if you have one)
OK, before we can install this we need a few prerequisites, luckily nothing to download here, there is a nice little PowerShell one liner to get the server up to speed. Open up a PowerShell window as Admin and run:

Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,
Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,
Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,
Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,
Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,
Web-Includes,InkandHandwritingServices,NET-Framework-Features,
NET-Framework-Core



When complete, you will be reliably informed that you need a reboot.



You can do this right from your PowerShell window by going for
Restart-Computer

Have a check in Server Manager - Manage - Add Roles and Features and check you have some role and features added:



OK, lets move onto install Office Web Apps Server 2013, this is much less exciting than it sounds!

Mount the .img file you downloaded earlier and run it, choose a file location to install to. Generally as good practice (this applied to SharePoint also) I install my OS and Program files on different drives, you will see here I am going for E:\Microsoft Office Web Apps


This then installs with no other options and quietly completes. Nothing to see here!

Onto the Service Pack, run this, accept the agreement, hit continue, again nothing special or noteworthy.



There's a couple of installation scenarios, basically the decision is between single or multi server farms and HTTPS or HTTP. Microsoft recommend in a production environment HTTPS is used. Also if you're going to be using this server farm to service Lync 2013, there aint no option but to go for SSL secured. I do plan to use this for Lync and Exchange 2013 and so will need to be going for the HTTPS option. Making this blog fully fledged but we have to get into creating certificates etc.

Right, so we're going to need to activate the WCF Services HTTP Activation feature to allow us to securely communicate. Head to Server Manager - Manage - Add Roles and Features. Open up the .Net framework 4.5 group, WCF Services and tick on 'HTTP Activation'


You then need to confirm and carry on installing this


Let's now sort out the certificate. This is assuming you have a certification authority setup in your domain. 

Start - MMC - Add or Remove Snap-in

Add the Certificates Snap-in


We want to access certificates for the local computer account
Now you should see the certificate store, we're going to carry on a right click on Personal, choose All Tasks - Request New Certificate
Luckily my 'administrator' has configured the enrollment policy, so i'm going to choose that
We want a Web Server certificate, and due to the encryption options i want to have the choice of later, i'm going for Enterprise
You will see it says that more information is required to continue, clicking this link we see the following window.In here, we need to add the Common Name (CN) in the subject name field. The common name is the name of the server, not fully qualified. If you're planning to have the url the name of the server with a port then this is all for this screen. If you're having a DNS entry pointing to this server you can add this in the Alternative Name section, but for me, just the CN is good enough.
On the General tab, choose a friendly name, make this something meaningful. I have copied this into the description as the description is sometimes displayed in places the name is not, so this covers all bases!
Now, following is one of the differences we get from the enterprise web server certificate option, we want a key length of 2048. This is already selected. We also need to select the box 'Make private key exportable'
In the Certification Authority tab, select your authority.
Click OK and this will take you back to the Certificate Enrollment screen where we can now press 'Enroll'
The certificate will appear in the console
Check this has also appeared in IIS. Head to Server Certificates. Do not bind this, the setup powershell command does the magic for us.
Time now to create the Office Web Apps Farm. Open up a PowerShell window and run the following command. Obviously replacing the red text with your own details.
New-OfficeWebAppsFarm -InternalUrl "https://yourserver.fqdn-CertificateName "Office Web Apps Certificate Friendly Name-EditingEnabled

Note that the 'EditingEnabled' switch is only if you have a licence for editing. You will get a nice little warning about this in the window asking you to confirm. Then followed by a whole load of gumf about the farm details.

Now the moment of truth, time to test that your server is working. On your local machine, enter the https url (which is basically the server name) with /hosting/discovery at the end. All being well you should see an XML output resembling the following


Once you've confirmed the OWA server is accessible via a secure URL, time to bind 
SharePoint to it. Head over to your SharePoint App server and open the SharePoint 
PowerShell window (- as Admin of course!)
Run the command 
New-SPWOPIBinding –ServerName “owaserver.fqdn”

This should flash up all the bindings to various applications being created.
That’s it done! Time to test.
Head to a document library on SharePoint 2013, find a Word document and click on 
the three dots next to it for additional details. This should load with a large area for
preview, then show you Office Web Apps is loading as per the following image. 
All being well this will load and show you a preview of the document!

Friday, 27 June 2014

Using the power of SharePoint 2013 Search in your 2010 environment


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.
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.


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.


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


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.


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..


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 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!

There you have it, SharePoint 2010 powered by the much superior SharePoint 2013 Search engine.