Minrole and Services for 2016

This article will just be a jumping off point for a larger discussion of MinRole and how it works in SharePoint 2016.  This is just a quick listing of each Role and what services are automatically defined for each. There are ways around this of course to have server that are not constrained by these roles, but there are a lot of recommendations encapsulated in these roles.

Like I said, details later!

 

Service Application WFE Search Distributed Cache Single Server
Access Database Service 2010
Access Services
App Management Service
Business Data Connectivity Service
Claims to Windows Token Service
Distributed Cache
Document Conversions Launcher Service
Document Conversions Load Balancer Service
Lotus Notes Connector
Machine Translation Service
Managed Metadata Web Service
Microsoft SharePoint Foundation Sandboxed Code Service
Microsoft SharePoint Foundation Subscription Settings Service
Microsoft SharePoint Foundation Workflow Timer Service
Microsoft SharePoint Insights
PerformancePoint Service
PowerPoint Conversion Service
Project Server Application Service
Request Management
Search Query and Site Settings Service
Secure Store Service
User Profile Service
Visio Graphics Service
Word Automation Services
Work Management Service
Advertisements

SharePoint 2010 – 2013 preupgradecheck

For all of you who are considering an upgrade to SharePoint 2013 you may have noticed one feature that is missing from SharePoint 2010, the pre-upgrade check. In SharePoint 2007 (post service pack 2) there was an stsadm.exe -o preupgradecheck option that gave you information about possible issues upgrading your 2007 farm to 2010. In SharePoint 2010 that option is no longer available and instead the recommended upgrade tests are Test-SPContentdatabase , Test-SPSite , and Request-SPUpgradeEvaluationSite . These three PowerShell cmdlets can give you a lot of useful information, and they definitely tell you many of the things you need to know to successfully upgrade your 2010 farm to SharePoint 2013. These commands all come with one big problem, to use the above commands you have to have a SharePoint 2013 farm in which to run those commands. If you are just wondering about the upgrade to SharePoint 2013, but you aren’t yet serious enough to have installed a server you were out of options…until now!

To make some attempt at correcting this terrible injustice I have written a fairly basic PowerShell script that can give you some of the same information the old “preupgradecheck” option gave you. Information like what your farm’s build number is, what templates you have and what web uses which template, database sizes, solutions installed in the farm, etc. If you felt like it you would be able to get most of this information by digging around in Central Administration, SQL Management studio,  the SharePoint settings pages, or SharePoint designer, but this script may save you a little time. The script won’t tell you anything specific about the problems you may have upgrading to 2013, it just gives you all the information in one place to use as a reference. I hope you find it to useful, and you can find it HERE.

 

No Warranty Expressed or Implied. Use with caution (that applies to all PowerShell written by some random person on the internet). Do not drive or operate heavy equipment for at least 4 hours after using PowerShell. Side effects may include bleeding from the eyes (my code is not pretty), heart palpitations and severe migraine headache. Good luck.

Help! SharePoint 2013.

Lots of stuff is going on with SharePoint 2013. Not much has been going on with my blog. I need some topics people. My specialty is Infrastructure, Install, and technical issues around getting SharePoint up and running, but if I get a clear idea of what people want help with I will stretch to other topics. So help a guy out, let me know what information you are really dying to see content about.

2013 Info Wave

 

I have been off the grid for a few days, but I am trying to catch up and here are some of the links I think might be helpful for anyone trying to get up-to-speed on Windows 8, SharePoint and Office 2013! I know it isn’t even close to a definitive list, so leave any other links you find useful in the comments.

Todd Klindt’s first SharePoint 2013 install
Introducing Excel 2013
Office and the Cloud
Rackspace Sharepoint Team Gets Early Look at Microsoft Office 2013
SharePoint 2013 Web Part: Content Search
SharePoint 2013: presentation: IT pro training
What’s new in SharePoint Server 2013 for Developers?
SharePoint 2013 Video Tutorials
SharePoint 2013 – Cross Site Collection Publishing Part 1
SharePoint 2013: 5 Reasons Why the New App Model Will Make Everyone Happy
Building Your First Power View report
Welcome to the World, SharePoint 2013 & Office 2013 !

When /Reports isn’t /Reports

Hold on tight, this one gets a little confusing.

Say you have a SharePoint 2007 farm with SQL Server Reporting Services (SSRS) integrated with it. Your reports site in SharePoint is http://this.that.com/Reports. You create a new 2010 farm and migrate your 2007 content to it. For the 2010 farm you install SQL Reporting Services 2008r2 taking mostly the defaults for a SharePoint integrated report server and then you load up the http://this.that.com/Reports site to test the new SQL reporting install. Instead of seeing the SharePoint web you expect, you see this:

This operation not supported on a report server that is configured to run in SharePoint Integrated mode (rsOperationNotSupportedSharePointMode)

So what happened? To understand the cause of the problem you have to understand one key difference between SSRS 2008r2 and SSRS 2005. The 2005 version of SQL Reporting uses IIS to serve out information over http and https. SSRS 2008r2 (and just SQL 2008 for that matter) has its own web server component.

Typically on a SQL Reporting 2005 setup the /Reports directory for SSRS will end up in the “Default” IIS  web application, the one that exists as soon as you install IIS and has the *:80 host header binding. What this means is, any request on port 80 will go to the Default web application unless there is a specific host name requested that is bound to a different web application.

Let’s look at an example. You have a machine with the name SPWF1 and an additional fully qualified domain name (FQDN) this.that.com assigned to it in DNS. With SSRS 2005 IIS is the only web server on the system. If 2 web applications are located on port 80, one the default with the *:80 host header binding, and the other a SharePoint web application with the  this.that.com:80 host header binding, any http request (on port 80) that comes to IIS will have to pass one test before it gets connected to a web application. Is the request for http://this.that.com (the name bound to the SharePoint web application) or something else , the machine name or the machine ip address for example? On such a machine you could have a SharePoint web at http://this.that.com/Reports and a SQL reporting URL at http://SPWF1/Reports and IIS would automatically sort them out. Http://this.that.com/Reports would go to the SharePoint web application, any other request would go to the default web application.

That same server with SSRS 2008r2 would actually have 2 web servers, SQL Reporting Service’s own web server and IIS. The difference is, the web server built into SSRS doesn’t check the host header bindings in IIS. By default when you set up SSRS it will create http://<servername or FQDN> /Reports and /Reportserver URLs on port 80 with a *:80 binding. These URLs can be renamed ( /SSRS and /SSRSServer for example). SQL Reporting’s web server will completely ignore any requests that it doesn’t have a direct match for, so it shows no sign of itself if you browse to http://SPWF1 or http://this.that.com but if it has a direct match such as http://SPWF1/Reports or http://this.that.com/Reports it will grab the request before IIS gets to it. What this means for you is either you have to do one of two things. Make that SharePoint doesn’t have any URLs that would match the Report Server URLs, either by changing the default name of /Reports and /Reportserver,  or by changing the host header binding in the SQL Server Reporting configuration tool from *:80 to something more specific, like the machine name or a totally different FQDN and make sure that all requests to the report server use that specific name. I told you it was a little confusing 🙂 . Leave any questions in the comments and I will try to answer them to the best of my ability.

 

Virtualizing SharePoint

Virtualization is not the new kid on the block anymore. Almost all businesses with the need for more than a couple of servers are at least developing a virtualization strategy and most have started thinking about about ways to virtualize a couple of their employees. Luckily SharePoint is an almost ideal candidate for virtual hardware as long as you keep just a few things in mind.

Virtual hardware doesn’t mean requirements magically become recommendations.

My wife and I went on vacation last year and rented a car that had one of those gauges that tell you how many miles you get to the gallon. My normally lead-footed bride suddenly became an eco-champion driver. Our 0 to 60 times where being measured in minutes instead of seconds, but at some moments we were getting 75 miles to the gallon and my wife was enjoying every agonizingly slow second of it. The same thing happens to a lot of people when they start boiling their servers down to a pool of VMs. Performance takes back seat to the thrill of shaving off a gigabyte here and a processor core there. Suddenly your company is running on the computational equivalent of a closest full of 5 year old desktop workstations and you are actually happy about it.

Stop the madness. Microsoft has provided hardware and software requirements, not because they guarantee the best SharePoint experience possible, but because if you don’t come close to those specifications you make them and their products look bad. In the end that makes you unhappy and it makes SharePoint look bad in your organization. Microsoft’s requirements aren’t laws, but they are a good starting point. Cutting them in half will only give you a moment of joy when you squeeze SharePoint into a tiny virtual box. That flash of fun will be followed by a lot of waiting and confusion for the rest of your SharePoint journey, because…

SharePoint wants to please you, even if it has to lie to do it.

I have gone through my preachy spiel above dozens of times with customers and about a third of the time they listen patiently then tell me; “We already set up a test SharePoint farm with less than the recommended specs, but when you look at the virtual management console it never even gets close to maxing out the processor or memory we gave it and you are telling me it needs more?” Yes, yes I am, because SharePoint is perhaps the most polite of all Microsoft products when it comes to resources; attempting do its best to live with whatever you give it. When starved for resources some applications will grab all unattended RAM refusing to release it under any circumstances just in case it might need it in the future. SharePoint on other hand will always try and leave some memory open for everyone and when it absolutely can’t get by with the resources available, it just stops doing some things. Things like completing that database upgrade you requested, or like running timer jobs, or in co-operation with IIS, caching pages so that it doesn’t take 45 seconds for each page to load. SharePoint doesn’t complain a lot about missing resources, it just does what it can and forgets the rest. Unless you look closely at the logs you might not even notice some of the things that are being skipped. I have seen SharePoint running on a virtual with 2GB of RAM, only 1.5 where in use. The customer asked if I had any idea why their system was so slow.

The moral of the story is, get close to the requirements. A 60GB c: drive instead of 80? OK. 6GB of RAM in a test server? Fine. However, cutting all the requirements in half doesn’t make sense on real hardware, so don’t expect it to work better in a virtual. While we are talking numbers though, let’s discuss your virtual host.

8+8 does not equal 12.

There is another numbers game that virtualization sometimes creates. You probably already know the term for this game, over-commitment. The details vary depending on what virtualization products you use, but many virtual hosts will allow you to create servers that strictly speaking shouldn’t “fit” on a single host server. If you total up the amount of RAM or CPUs used by all your guest machines they exceed the total amount available on the host, but somehow things magically work. Mostly. Over-commitment is a valid strategy and is one of the things that drives the economic benefits of virtualization in the first place. Like most things, a little can be good, too much can be bad, and the line isn’t always clear. I am not going to be completely naive here and tell you to never over-commit a host that has SharePoint on it. The economics of virtualization sometimes don’t allow that luxury. I am going to remind you of SharePoint’s sometimes over polite nature. If you are seeing unexplainable performance issue, take a look at both the SharePoint logs and server applications logs for signs of distress as well as the host’s monitoring tools. VMware has published a whitepaper of best practices for virtualizing SharePoint 2010 using their products. At 50 pages you may see that developing a successful strategy for virtualizing SharePoint might not be as easy as it seems at first. VMWare’s examples show a number of configurations that work and only by really diving into the numbers can you see how they might work better with some tweaking. SharePoint won’t give you a clear indication that you have pushed it too far.

So enough about polite and co-operative SharePoint, let’s talk about the other key member of your SharePoint farm, Microsoft SQL.

SQL is not SharePoint.

SharePoint might be the shy orphan in a Charles Dicken’s novel asking for another bowl of gruel. Microsoft SQL is more like a rampaging Viking raiding the server for any resources it can find. This is a big clue about how you might want to approach virtualizing your database server. If you want to figure out the best strategy for allocating resources to SQL in a virtual environment just remember how it works. Microsoft SQL is built for two purposes, executing transactions quickly, and executing transactions accurately. Anything that distracts it from those two goals is bad for performance, and database performance is a very large part of SharePoint performance. Anytime you create a situation where SQL has to request or wait on resources you create the opportunity for something to not work correctly. That is why SQL collects all the available RAM in a server even when it’s not loaded with work. By collecting resources prior to needing them Microsoft is ensuring that your database information is ready to move as soon as a request arrives. Treat SQL like an angry Viking. If you tell the Viking you are giving him 16GB of RAM, make sure there are 16GB of RAM in the bag. The same goes with persistent storage on a hard drive or SAN. You do not want the Viking to be looking at you angrily as you feverishly try to clear enough space for him to store his latest acquisition. In the world of busy database servers, microseconds are important and waiting for the virtual host to reallocate resources is not something that SQL is built to expect. Thin provisioned drives (telling the server it has a 250GB drive when it is really a 100GB file that “grows on demand”) and over-commited hosts are not things that mix well with a product that was designed to take complete charge of all the resources available to it. Give Microsoft SQL exactly the resources that you promise to it and you will avoid a lot of troubleshooting and head scratching. If you aren’t prepared to do that, maybe real hardware is your best bet for SQL right now.

This post is a little longer than I thought it would be at first, but I hope it helps to get you thinking about your SharePoint virtualization strategy. Virtual servers are here to stay and that is a good thing if we use them properly. It is just important to get past the hype and excitement of getting more for less and focus on knowing what you really need to get the best out of your technology.

URL rewrite for SSL in SharePoint

(Shamelessly plagarized from myself as originally published here )

It’s a common problem: You have a bright, shiny new SharePoint installation, and you suddenly realize that before you can put it on the Internet, you need to set up SSL and redirect HTTP for all your Web applications. HTTP works fine for an intranet sometimes, but HTTPS and SSL are essential for Internet deployments for security’s sake.

Once an SSL certificate is installed, you need to find a way to capture any HTTP requests for your SharePoint server and redirect it to the SSL-encrypted site. At first you may assume there is a standard way to redirect HTTP to HTTPS in SharePoint, but after a little time combing the search engines, you’ll find out there isn’t.

There are several ways of dealing with an HTTP-to-HTTPS redirect; ASP scripts and the built-in HTTP redirect in IIS are two popular examples. In the SharePoint world though, where there can be so many different URLs to deal with, it can get to be a little tiring to create a redirect for each one. So how can we create one rewrite that will cover our SharePoint Web applications?

Let me introduce the URL Rewrite extension for IIS.  Install the URL Rewrite by using the Web platform installer option, or by downloading the x64 version and launching it on your SharePoint Web front end(s). URL Rewrite is a Swiss Army knife of IIS optimization, and I am not even going to begin covering all the uses it has.

Before I go any further, however, let me caution you: URL Rewrite is powerful, but dangerous. Whenever possible, thoroughly try any rewrite rules in a test system before putting them in your live environment. Rewriting and redirecting SharePoint URLs can cause unpredictable or even damaging results; use extreme caution.

With that warning in mind, let’s set the stage for our example. Our test farm has multiple Web applications on the Contoso domain (team.contoso.com, portal.contoso.com, etc.) Each Web application is set to use a wild card certificate for *.contoso.com over HTTPS, and none of them any longer have a binding on port 80. For example, team.contoso.com:

Site Bindings

Now we need a Web application that will capture all those HTTP requests, no matter which specific URL is the final target, team, portal, MySite, etc. This Web application does not need to be a SharePoint Web application; in fact it is better if it isn’t. It just needs to be bound to any requests on port 80, like this:

http site binding

Once all that is in place, we just need to make a simple rule using URL Rewrite.

In IIS, choose your site that is bound to port 80, and choose the freshly installed URL Rewrite extension in the Features View of IIS:

URL Rewrite

In the far right-hand corner of IIS manager, choose Add Rule(s).

Add Rule(s)

Name the Rule anything you like. As you can see in the screenshot above, mine is called 80redirect.

Fill out the Match URL section with the information below. In this case, the “pattern” is basically any request that comes to port 80:

Match URLs

In the Conditions section, click the Add button and enter the following information, then click OK.

Add Condition

The Conditions Panel will end up looking like this:

Conditions Panel

Skip the Server Variable section and go to the Actions panel and fill it out like you see below:

Once the Action section is complete, click Apply and, believe it or not, you are done:

Finished

At first, people may ask why URL Rewrite is needed or even wanted here, and the answer is simplicity. If you set up this redirect on your Web Front End(s), any request to an HTTP site will automatically be redirected to the correct HTTPS site. http://team.contoso.com redirects to https://team.contoso.com, http://localhost redirects to https://localhost; the redirect doesn’t care what the final destination is, so any new Web applications you create are automatically covered by the process.

Because of that, you probably don’t want to set this up on your app servers or servers that are doing search crawls, unless the crawl is happening on a port other than 80. But since all the changes are happening on an IIS Web application, and not one created in SharePoint, it can exist on some servers in your farm and not others. Is this the only solution? No, but for a simple way to make sure all your Web applications are covered, it works well and doesn’t require adjustment each time you create another Web application. I hope you find it to be useful!

Create a free website or blog at WordPress.com.

Up ↑