Search, SharePoint, Technical

On-Premise SharePoint 2013 Edition Comparison–Search

Pulling the table below from TechNet, the difference between Standard and Enterprise search in SharePoint 2013 is really only:

  • Content Search Web Part
  • Custom Entity Extraction
  • Extensible Content Processing
  • Advanced actions on Query Rules
  • Video Search

The differences from Foundation to Standard are too many to list separately so I’ll let the table do the talking.

Search features SharePoint Foundation SharePoint Server 2013—Standard Edition SharePoint Server 2013—Enterprise Edition
Advanced Content Processing Yes Yes Yes
Content Search Web Part No No Yes
Continuous crawl Yes Yes Yes
Custom entity extraction No No Yes
Deep links No Yes Yes
Event-based relevancy No Yes Yes
Expertise Search Yes Yes Yes
Extensible content processing No No Yes
Graphical refiners No Yes Yes
Hybrid search Yes Yes Yes
Managed navigation No Yes Yes
On-premises search index N/A N/A N/A
Phonetic name matching Yes Yes Yes
Query rules—Add promoted results No Yes Yes
Query rules—advanced actions No No Yes
Query spelling correction Yes Yes Yes
Query suggestions No Yes Yes
Query throttling No Yes Yes
Quick preview Yes Yes Yes
Recommendations No Yes Yes
Refiners Yes Yes Yes
RESTful Query API/Query OM Yes Yes Yes
Result sources Yes Yes Yes
Search connector framework No No No
Search results sorting Yes Yes Yes
Search vertical: “Conversations” No Yes Yes
Search vertical: “People” No Yes Yes
Search vertical: “Video” No No Yes
Tunable Relevancy No No No
PowerShell, SharePoint, SQL Server, Technical

SSRS, SharePoint 2013, and SQL 2012 Standard Edition

When building out a new farm using SQL 2012 Standard and SharePoint 2010, a multi-server farm deployment with a dedicated SSRS server was possible. In SharePoint 2013 with SQL 2012 SP1, not so much possible, but with additional “gotchas”. To be clear, here’s the architecture:

image

SP-WFE1 and SP-WFE2 are just front ends, so really the three boxes we care about are SP-APP1 (running central admin), SP-SSRS (where we want SSRS to run), and our SQL box.

Following these guidelines from TechNet and this blog article pointing out some gotchas, we can extract the gist of what the steps are:

  1. Install SQL Server 2012 SP1 on SQL box
  2. Install “Reporting Services – SharePoint” and “Reporting Services Add-in for SharePoint Products” on SP-APP1 and SP-SSRS
  3. Install “Reporting Services Add-in for SharePoint Products” on SP-APP1 (don’t install the “Reporting Services – SharePoint” component)
  4. Install “Reporting Services – SharePoint” and “Reporting Services Add-in for SharePoint Products” on  SP-SSRS
  5. Run  Install-SPRSService and Install-SPRSServiceProxy on SP-APP1 and SP-SSRS
  6. Start the “SQL Server Reporting Services” service on SP-SSRS
  7. Create a new SQL Server Reporting Services service application

The result is a new service app, but it will throw an error when you try to access it’s settings through Central Administration. Viewing the ULS error, it will tell you that it received a 503 error when calling the reporting web service on the app server. Well, that makes sense because we didn’t start the service on the app server, we want it to run on our SSRS server. If you look in IIS on the app server, the reporting site doesn’t exist. If you look in IIS on your SSRS box, it will exist. The URL will be something like http://sp-ssrs:32843/{GUID}/ReportingWebService.svc, with the GUID getting generated when you start the SQL Server Reporting Service.

So now we’re in quite a quandary. If you try to start the service on your app server to create the reporting web service, you’ll get an error stating that the version of SQL doesn’t support a scale-out farm. It seems like SharePoint is looking at servers in the farm with Reporting Services installed on it, regardless of whether the service is running on that server, when checking licensing. Well, we can’t uninstall Reporting Services from our app server since we would then lose the ability to create a service app, so we’re screwed.

Taking a look at the feature comparison, Standard definitely does not support a scale-out deployment. However, unless I’m misinterpreting the definition of farm scale-out, that’s not what this architecture is. Since we are trying to run Reporting Services on a single instance in the farm, this should be covered by Standard license.

Bummer. So, for now, we can’t do the above architecture using Standard. Maybe I’m wrong and I’m missing a configuration step somewhere. If so, please chime in.

—————————————————————————-

By the way, there are two versions of SQL Server 2012 with SP1 installs out there. One says it’s SP1, but doesn’t really install SP1. At some point, this was resolved so the latest package does install SP1 as it should. After you install SQL, you should see a version of 11.1.3000.0 or higher. If you don’t, you still need to install SP1 over your install. This goes for SQL Server as well as the SQL components you install on your SharePoint servers. The latest installs can be found here, with either a slipstreamed ISO or a SP1 executable.

If you miss this and get a new SSRS Service App created, it will throw an error. ULS logs will show a 500 error, and when navigating to the reporting service URL you will see that it can’t read the configuration file. Diving into the 15 hive, you will notice that there is no “Reporting” folder under “15WebServices”, which is where the IIS site is looking for it’s configuration settings. There will be one in the 14 hive. After installing SP1 on the SharePoint servers you will see this folder and know you’re good to go.

<UPDATE>I was able to get the above architecture configured correctly by making the changes noted in the post. Turns out the trick was to not install the Reporting Services – SharePoint component on the APP box. Thanks go to my co-worker Mark for helping me with that one.

SharePoint, Technical

SharePoint Saturday Utah 2013

The second incarnation of #SPSUtah is in the books and it was another success for the local community. Joel, Christian and Josef did a great job bringing everything together and working to increase attendance over last year and bring in some awesome speakers. Well done, guys!

For the session I presented, I was able to get back to some of my roots and focus on the developers perspective, specifically developing search solutions for SharePoint 2013. We covered the architecture of 2013 enterprise search and then dove into the out of the box components that can now solve many of the problems that previously needed a developer to solve. From there, we could elevate the discussion and look at how to develop solutions using those base components, specifically the Content Search Web Part and Display Templates and how to deploy them properly using a solution file. The session wasn’t a deep developer session, but my plan is to have it be the first in a series that gets deeper and deeper into more complex development tasks. I really do see search as a powerful tool in the developers toolbox and I hope to have the opportunity to continue the series.

Thank you to everyone who attended the session and for the conversations during and afterwards. Attached to this post is the slide deck and the sample Visual Studio project I presented. The solution includes a simple page with a display template being deployed and then used by a CSWP that is added to the page. Nothing fancy, but it shows the concepts we covered.

PowerShell, SharePoint, Technical, Workflow

Install & Configure Workflow in SharePoint 2013 Multi-Server Farm

Recently going through a farm install and configuration of Workflow in a 2013 multi-server farm, I learned a couple things along the way that weren’t covered by the still-catching-up documentation.

First of all, prior to RTM, the messaging was that Workflow needed to be installed on a dedicated server and could not be on an existing server in your farm. This changed when RTM became available and it is now supported, although perhaps not recommended for environments needing scalability, redundancy, and availability to support a high throughput of processes. In my case, I chose to install and run Workflow on an app server that was running Central Administration.

Once that decision is made, we need to make sure we have the accounts and groups in AD we need:

  • Install account – A domain user with admin rights on the server being configured, as well as SysAdmin rights in SQL Server
  • RunAs account – A domain user with login rights to SQL Server (additional rights will be granted during the configuration)
  • Admin group – A domain security group with the RunAs account as a member, optionally the Install account as a member as well (see note later regarding starting the service)

A couple other requirements noted in the documentation that need to be checked:

  • SQL Server 2008 R2 SP1, SQL Server Express 2008 R2 SP1, or SQL Server 2012
  • TCP/IP connections or named pipes configured in SQL Server
  • Windows Firewall enabled
  • Ports 12290 and 12291 must be available (the configurator will open these ports in the firewall and use them for workflow traffic)

Now we can start the install and configuration of Workflow Manager (download link). The TechNet documentation (and here) is pretty bare, but it was sufficient to get me going. The installer will install any prerequisites that are missing and then install Workflow Manager. For configuring, you can either use the Configuration Wizard or PowerShell. I went with the wizard since the PowerShell documentation on Workflow was a skeleton and didn’t have much. I went with the Custom Settings option in the wizard so I had more control over things like database names. I also let the wizard generate a certificate for me with my provided key. If you don’t have your own, we’ll need to use this later. Everything else should be self-explanatory.

Depending on your scenario, the next steps may vary. The TechNet covers the options well so I won’t repeat them, but the decision is based on whether Workflow Manager is on a server in the farm and whether communication is over HTTP or HTTPS (in production, you should be using HTTPS.) I have Workflow Manager on a server in my farm using HTTPS so I needed to:

  • Install my certificates on my WFEs by exporting the cert and then importing it into the Trusted Root Certification Authorities store in each WFE, and then running New-SPTrustedRootAuthority cmdlet (all of which is covered well on TechNet)
  • Install the Workflow Manager Client on each WFE (download link above)
  • Run the Register-SPWorkflowService cmdlet:
    Register-SPWorkflowService –SPSite “https://myserver/mysitecollection” –WorkflowHostUri “https://workflow.example.com:12290”

That last step has a couple things worth noting.

  1. To get the WorkflowHostUri, go into IIS where you installed Workflow Manager and find the workflow service web application. Check it’s properties to get the Uri, with port (which is the same port you entered during the configuration, by the way)
  2. The command needs to be run using an account that is a member of the admin group you created earlier. If you added your install account, you can use that. If you didn’t, you need to run the command as your RunAs account

Following the TechNet docs, your next step would be to validate the install using SharePoint Designer. It’s been my experience that SPD will only be able to create 2013 workflows after two more steps, that aren’t documented:

  1. You need to have an App Management Service Application created. You don’t need to completely configure apps in your environment, but you need to at least create the service app or you’ll get an error when you publish a workflow from SPD.
  2. I wasn’t getting the 2013 workflow option to appear in SPD at first. I didn’t find the culprit, but a reboot of the Workflow Manager server did the trick for me.

If you need help creating an App Management Service Application, here are some scripts:

Register-SPWorkflowService –SPSite "https://myserver/mysitecollection" –WorkflowHostUri "https://workflow.example.com:12290"
$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $applicationPool -Name "App Management Service Application" -DatabaseName "AppManagement_DB"
New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

You should be able to create 2013 workflows after all that. If you run into any hiccups, post a comment and I’ll do what I can to help out.