Thursday 13 November 2014

Load Testing your SharePoint 2013 Servers - Visual Studio 2012 Load Test

So I have been using the Visual Studio load testing for every Infrastructure roll out I have worked on since it was released!

It's a great tool for testing all web servers not just SharePoint.

I am going to run through a very basic test, I found that there is plenty of useful information out there on this subject. But as I always do in my blogs I am trying to pull all the required information together in one easy to follow step by step guide.

I found other sources with steps for creating a web test, but no mention of a load test and similarly load test instructions with no mention of creating the web test first.

So the basic principals I use when planning a load test are:

You can create a web test in your Visual Studio project. This is just a recording of some steps you do in a browser, Visual Studio will then take that recording, remove the junk from the HTTP requests and leave just the calls to the web site you want to repeat over and over in your load test later on.

Once we have a web test, this could be of a single page load, multiple document uploads or anything you like. We then create a load test and configure that load test based on our requirements.

In that load test you can configure the number of concurrent users which is going to create the load on your servers!

Now for the steps.

Create a new Visual Studio project

 
Name your project.




Hit the record button to begin capturing your test in the browser which should open automatically.

Make sure that Internet explorer enhanced security is off (IE ESC) or this won't start and you will get an error. You can do this in server manager.




Browse to a site and begin performing the tasks you want your load test to simulate.




Hit stop recording once you have captured the simulated set of tasks. For my needs I just loaded three pages.

You will see once you stop that the web test is saved in your project, we can now use this is the base for our load test.




Right click the project title in solution explorer.

Add > Load Test




Follow the wizard to create the load test.





There is various configuration options in the wizard that you may wish to change dependent on your scenario and test requirements.

Name your Load test.




Set your number of concurrent users, you may find you need to tweak this and try some different numbers to see how the server reacts to the load.

My virtual server has 16GB RAM and 4 processors so lets see how it gets on with 100 concurrent page views.

Read through the descriptions of the different test mix models, I went for the number of virtual users to simulate 100 users.





Click add to choose our recorded web test.




Select the web test to add it to the load test. You could always have multiple web tests, for example one to simulate uploads and one for page views so that it all runs on the server concurrently.





You can tweak the distribution if you want, this ties in with the mix models if you want to set only a percentage of your users to be running the test at the same time.

You have the option to change network and browser types, not required in my basic example.





You can set computers and counter sets here too.





I'm just going to fire up resource monitor to show you how the server reacts.

Set the duration of the test.



Right click the load test and select 'Run Load Test'




Check the impact on your server!

If it's not enough just tweak the number of concurrent users, I find it useful to have a few load tests with different number of users so you can see how the servers react to 100, 200, 300 users and so on.



Thanks for reading,
Matt

Wednesday 20 August 2014

Colour Coding SharePoint 2013 Central Admin Appearance Using Themes

A quick post I'd like to share as I am sure this can be useful for a lot of SharePoint admins.

As you are all probably aware you can change the theme of any SharePoint site from site settings.

Within Central Administration this option just leads to a blank theme gallery.

A problem I face regularly is having multiple server sessions open which include multiple farm central administration pages.

Sometimes I may have Production, Staging and Development Central Administration sessions open while testing and deploying through the environments.

By colour coding these environments it becomes quickly obvious which farm you are now in, and reduces your risk of making a mistake of which environment you are working in.

In my scenario I could also be working on different regional farms, so UK, USA and Asia all have a Production, Staging and Development.... you can forgive the confusion at busy times.

As I said a short and sweet tip that may be of interest to some administrators.

You can also label your Central Adminstration within the top banner and below is a great blog post covering that in detail.

http://www.wictorwilen.se/sharepoint-2013-central-administration-productivity-tip

Default colour scheme (Notice the 'Production' label at the top).



To access the themes simply take your Central Admin URL - http://server1:2013/default.aspx

and replace the /default.aspx with /_layouts/15/designgallery.aspx

 http://server1:2013/_layouts/15/designgallery.aspx




Choose a theme to suit this environment and save.







So now I have blue for Production and Orange for Staging, nice and easy to differentiate in a hurry.





Thanks for reading,

Matt

Thursday 7 August 2014

Checking your SSL Key file, CSR and Certificate Match

I have been doing a lot of work around security and in particular SSL with SharePoint this year (you might have noticed from my recent posts!).

This obviously leaves me spending a fair amount of time generating and installing certificates for the various farms and sites.

Recently upon receving my certificate from the certificate generation team I could not generate the required PFX file using OpenSSL.

After looking around in my various folders I noticed I had a lot of old CSR files and Key files knocking around and it becomes difficult to know which is the latest version! (I should be better at housekeeping I know!).

So a colleague passed on to me some useful information to check that your CSR/Key/Cert files match before trying to install them or generate PFX files as this will cause issues.

Using OpenSSL use the below commands to check the modulus of your files and ensure consistency between them.

To check the modulus of the certificate file:

x509 -noout -modulus -in certificatename.crt


To check the modulus of the Key file:

rsa -noout -modulus -in privatekeyname.key


To check the modulus of the CSR file:

req -noout -modulus -in csrname.csr


If you run these commands you will get the modulus printed out and be able to check them against each other to ensure they match and were not generated seperately with a different key etc..


I hope this helps out for those who are generating certificates regularly and have had problems with multiple versions of those certificates!

Matt


Monday 7 July 2014

Changing SharePoint Host Named Site Collection Default URL

After changing a site from http to https I was unable to change the default zone URL for the SharePoint site which was hosting host named site collections.

Having the default zone as http was causing multiple issues (Workflows, OWA, Search) as lots of requests were still using http and our load balancer was forcing all traffic to https.

You have some PowerShell available to aid the administration of URLs for host named site collections.

Get-SPSiteURL
Set-SPSiteURL

Firstly I edited by default AAM in Central admin to be https://test.matt.com.

Now using PowerShell I'll show how my site looks currently.

Get-SPSiteURL -Identity http://test.matt.com




Using Set-SPSiteURL you can add new URLs to host named site collection for different zones.

Set-SPSiteUrl (Get-SPSite 'http://test.matt.com') -Url 'https://test.matt.com' -Zone Intranet





Get-SPSiteURL -Identity http://test.matt.com

You will see your additional URL in separate zone.



You can see I have set multiple zone URLs for the host named site collection.

You will not however be able to change the default zone URL with PowerShell SPSite command.

Set-SPSiteUrl (Get-SPSite 'http://test.matt.com') -Url 'https://test.matt.com' -Zone Default



I needed the default zone for the root site to change so that all my host named site collections within the web application would also inherit https by default.

So I removed the Intranet zone URL I added as I do not need this I need to change the default zone URL.

Remove-SPSiteURL -URL http://test.matt.com



Get-SPSiteUrl -Identity http://test.matt.com

Back to just a single URL.



So we have to go back in time and break out stsadm.exe

Open command prompt and run CD C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\BIN


Then run the following command:

stsadm -o renamesite -oldurl http://test.matt.com -newurl https://test.matt.com



And finally lets now check our default URL

Get-SPSiteUrl -Identity https://test.matt.com (Use your new URL here)

Its now changed the default URL!






Something to bare in mind is that this has changed the default URL for the host named site collection. The web application will still have the original default URL in the configuration database and you cannot change this without recreating the web application.

This was a pain for me so hope it can be of help!


Installing SSL Certificate and Configuring a SharePoint Site to Use https - One Stop Shop Guide

I am not a security or SSL expert, but as a SharePoint specialist by trade I do bump into SSL and the requirement for https:// sites regularly especially in the financial sector.

What I am hoping to achieve in this post is a friendly guide for SharePoint admins to install their certificates and set their sites to https.

I found that all of the content required to do this is covered in various blogs but no where could I find a friendly guide covering the end to end process, so here is my attempt.

Firstly you need to install the certificate.

I have tried installing the certificate file straight into the MMC console, but the certificate file never shows up in IIS. I think this is to do with the way the certificate is created and I have the below way of getting it to work.

In this example I will use http://test.matt.com as my fictional pre existing web application.

You can specify to create a Web Application as SSL from the off and you should install the certificates before creating the Web Application if you are starting off with SSL rather than configuring an existing SharePoint site.

With most of the clients I have worked with they have their certificates issued for them by a dedicated team or person. So I am assuming you have the below files for your sites certificate.

1. test.matt.com.csr (Certificate signing request)
2. test.matt.com.key (Key file)
3. test.matt.com.cer (Certificate file)
4. group.cer (Root Certificate file)

On a machine with openssl installed browse to  C:\Program Files (x86)\GnuWin32\bin
Copy the certificate attributes to bin location (.cer/.csr/.key).
Copy the Group.cer into  C:\Program Files (x86)\GnuWin32\bin from this location
Firstly we need to generate a .pem file.

If you do not have a certificate file you can generate a delf signed one:
x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

You can then create the .pem from that cert:
x509  -in plexus/plexus.dev.echonet.crt -out plexus/plexus.dev.echonet.pem


Open the openssl application and run: x509 -inform der -in test.matt.com.cer -out test.matt.com.pem





A .pem file should appear in the bin directory.

Open the openssl application and run: pkcs12 -export -out test.matt.com.pfx -inkey test.matt.com.key -in test.matt.com.pem -certfile Group.cer


Once prompted set the password (keep this safe you will need this to install the certificate).


Open the certificate console by typing MMC in to the search.


Import the .pfx file within the Personal certificates store


Enter your password.

NOTE: Be sure to tick the box




Your certificate should now be visible in the personal certificate store.

Now to the IIS configuration.

Within the IIS settings for the server, click on 'server certificates'.

Your installed certificate should be visible.





Open the bindings for your SharePoint site.



NOTE: If you require to have http and https configured so you could in theory use both then add a new binding. Alternatively if you only require to use https then just edit the current binding and change the settings as detailed below.

Type = https
Host Name = Use the same as the http binding (e.g matt.test.com)
IP address = Use the same as the http binding
Port = 443
Certificate = Select your newly installed certificate

OK your changes.

That is all the required configuration for the IIS site, perform this on every SharePoint server that hosts the SharePoint IIS sites.

You will now need to edit the SharePoint alternate access mapping for the web application.


Click on the default URL and change it from http:// to https://


NOTE: If you require to browse the site by http or https or even just wish to leave both configured as an option then add a new AAM for http by following the next step. If you only want to use https then skip the next step.

Save and then click on 'Add Internal URLs'


Add a new http:// address exactly the same as the original before we changed to https://

The original default address must be changed to https:// you cannot just add a new https:// address as you want the default URL to be using https://





Now do an IIS reset

You should now be able to browse your https site!

If you configured both http and https alternate access mappings you can access your site in both http and https. You may wish to leave this configured for future but you can force all traffic over https if you require.

Open the SSL settings for the site.



Select require SSL and set client certificates to require.

 Apply settings.



Do another IIS reset for this to be applied properly or you will receive errors.

You will now get a 404 forbidden if you try to use http.

Https will work!




Saturday 10 May 2014

Distributed Cache Issues - AppFabric Caching Service Terminated unexpectedly

In this post I am trying to provide a short and sweet overview of the distributed cache service in SharePoint 2013, and point you in the right direction for configuration or troubleshooting advice provided by Microsoft in some useful articles.

The distributed cache service is built on the Windows Server AppFabric, this is installed as a pre-requisite for SharePoint 2013.

There are some key indicators that your distributed cache service may not configured to its optimum.

·         Server performance issues (resource usage)
·         SharePoint 2013 slow page loads
·         AppFabric caching service terminating (event viewer errors)


Without going in to great detail the distributed cache service is either required by or is used to improve performance of the below:

·         Authentication
·         Newsfeeds
·         OneNote client access
·         Security Trimming
·         Page load performance


This means that should it be configured incorrectly it can have huge consequences for the performance and usability of your SharePoint 2013 farm.

So how should you configure the distributed cache?

This really depends on your requirements, especially the number of users who will be visiting your SharePoint sites.

From my experience the most common approach is to use the collocated mode, this means running the distributed cache service on SharePoint servers alongside other services (they will form the distributed cache cluster).

This is generally acceptable for organisations with less than 10000 SharePoint users.

In this instance I would recommend setting the distributed cache size limit to an acceptable amount in relation to the amount of RAM on the servers running the distributed cache service.

PowerShell example:

Update-SPDistributedCacheSize -CacheSizeInMB 8000

The total memory allocated to your cache cluster should be a minimum of 8GB, this can be split across multiple servers hence the cluster.

I would recommend allocating a maximum of 40% of any cache servers available RAM to the distributed cache.

More recently I have been involved with an environment where we are running distributed cache in dedicated mode. This is recommended when the number of users is over 10000.

As the name suggests, in dedicated mode there is a layer of SharePoint servers that are dedicated distributed cache servers with all other SharePoint services stopped. This allows their resources to be managed and monitored solely with distributed cache performance in mind.

For more detail please see the below articles

Distributed cache overview and detailed articles: