Well we started the Easter break at the excellent European SharePoint Best Practices Conference in London. This was a fantastic session and so far we have produced 8 posts which you can get to directly from here as follows:
- Joel Oleson on avoiding failed deployments and newbie mistakes
- Joel Oleson’s Keynote- 3 key messages
- The file server is dead! Long live the SharePoint!
- The Power of Search with Federated Searches
- Building Capacity into your SharePoint setup
- Planning for failure in your SharePoint setup
- Improving your SharePoint performance
- Reasons to create ‘Custom Site Definitions’
What about days 9 and 10 I hear you (rightly) cry! Our day 9 and 10 posts are slated to be Social Computing based on the presentation by Daniel McPherson and Transforming the My Site into an Information Hub by Mark Eichenberger. We will hold of on these for a few weeks as we are working on both areas at school and dont want to just put out others work but genuinely add value by contextulising the presentation with our experience in Twynham School. I hope you have enjoyed the posts so far and a big thanks to Dave Coleman, Chris Mckinley and Darren White for their efforts in producing 2 great posts each.
Guest Post by Darren White SQL/SharePoint Developer
Note from administrator Mike Herrity: Apologies for the unusual font today. This post was published with this font and despite my best efforts will not be corrected! I love Word Press 99.9% of the time! I did not want to remove it and break a link in RSS.
One session that I attended at the SharePoint Best Practices Conference was titled ‘Designing & Deploying Enterprise Branding Solutions using Custom Site Definitions’ The aim of the session was to address the problem of how to keep a standard look and feel across multiple sites and the simplest way to update and maintain them. A site definition in its simplest form is just a set of instructions about how to create a site, what master page to set and what CSS style sheet to use. It also sets what lists and libraries are put on the page. When you create a custom site definition you can include the master page and CSS style sheet within it.
If a site definition is just a set of instructions why not just go and do these things manually? Well the short answer is time. Imagine you are setting up a site and you need to go and set the master page, tell it what CSS style sheet to use, create all the lists and libraries and them add them to the page. If you only have a few lists and libraries this might not take to long but if you have 15/20 lists and libraries it will take over 30 minutes. With a site definition this wouldn’t take any time as it will all be done for you as the site is created.
At present I am a novice in this area and will be looking to develop Custom site definitions when we get the post-conference video. I will then blog further on our experience but if you can’t wait until then the following is a wealth of knowledge out in the Blogosphere on how to create Custom Site Definitions:
- Todd Baginski’s awesome blog post on custom site definitions
- Muhanad Omar with part 1 and part 2 on custom site definitions
- TechNet article
- MSDN article
One of the sessions that I attended at the Best Practices Conference was titled ‘Go Live! Launching your MOSS Publishing Site’. It went a long way to addressing one of the biggest problems with a large SharePoint setup, performance. One of the biggest challenges surrounds keeping the load time of your pages to a minimum so the end users are not kept waiting. To find out how big your improvements will be you can use a tool called Fiddler. Although Fiddler doesn’t show you how long each page takes to load we can see how big each element on the page is and therefore look at ways of reducing load time.
One way to improve performance is to reduce traffic between the server and the client. This can be achieved by putting all your images in one file and using the css properties- ‘clip’, ‘left’ and ‘top’ to only show the portion of the image you need. The ‘clip’ property is used to only show the section of the image, the size of the orginal image. You use the ‘left’ and ‘top’ tag to move the portion of the image you wish to show to (0px, 0px). So if the section of the image you wish to use is 50px across and 20px down the ‘left’ and ‘top’ properties would be ‘-50px’ and ‘-20px’ respectively. There is also a tool called RPO (Runtine Page Optimizer) that does this automatically. By putting all images into one image file the number of request from the browser for images to the server reduces. So if you have 20 images there is now 19 less request per page request. Although this might not sound much if you have 1,000 user in a school this would reduce requests by 19,000.
Another way to improve performance is to use IIS’s built-in compression tool. There are 10 levels of compression you can use, however it is highly recommend you don’t use the top level compression as your server CPU utilization will be hammered constantly. In IIS 7 you can use dynamic compression which can be turned on and off based on CPU utilization. An example of this working is on a major SharePoint file (core.js). On a fresh install this file is 24% of the page but by changing the compression setting you compress this file from 78kb to 56kb which is a 26% speed improvement.
A third way to improve performance is to using CSS-based page layouts. CSS-based page layouts are pages that use ‘div’ tags and css to position them. Why would you want to use CSS-based page layouts over traditional table-based page layouts? By using CSS-based page layouts you can improve performance between 28 – 71%. This is not a practical solution unless you are using custom master pages and/or have time to convert your existing pages.
Filed under: Best Practices Posts, SharePoint, Twynham School
Guest post by Chris Mckinley- Senior SQL/SharePoint Developer
An occasional day in the Systems Office at Twynham School
The System’s phone rings…
“The system has lost all my files!”
“Where we’re your files stored?”
“On the Gateway”
“OK, do you know where on the Gateway?”
“Oh! Don’t get technical I don’t understand all this VLE stuff”
“Where did you last see the files?”
”In the revision resources section on the History gateway”
“OK, one second… I’m just looking now…I can see about 10 files there”
“Yes, it’s the one called ‘important course material 101′”
“I can see the file on my screen here”
“Yes yes, but it’s blank when you open it”
“OK…Click, click, click…Right can you open it again”
“Ah it’s back now”
“I just restored a previous version. It looks like you had overwritten it”
“Humm, yes well, thanks”
This typical scenario can occur in any organisation. Is it a failure? No, but imagine the scenario if the IT guy says, “Nope, sorry you overwrote it. It’s gone.” That’s not such a good end to the story. For this blog post I wanted to focus on planning for failure when it comes, as it undoubtedly will. I’ve split failure into three types and in the table below suggested the likelihood of each event happening over a year.
|Human Failure – Files deleted or overwritten||100%|
|System Failure – Server downtime||100%|
I’ve taken these values from Mike Watson’s #spbpuk session.
What is the impact of these failures in a school environment? Working through the list; lost files will always result in frustrated end users and blame on IT, regardless of who made the error. It’s harsh, but frustrated end users are end users that trust the system less and don’t want to use it. System downtime is unavoidable with power cuts, server maintenance and critical failures leading to networks going down. Natural disasters can’t be predicted, but such events happen, and no matter what you’ll need to get things back online. If you lost your database server how long would it take to supply staff members with group lists and timetables? Would you even know who your 1500 students are? The main focus of the session I attended at the SharePoint Best Practices Conference was preparing for failure and planning how you can manage the process to getting your SharePoint setup back up and running.
There are some simple things you can do to ease the frustration of end users like teaching them about the recycle bin and enabling versioning – that will give you some protection against user failure. You could even purchase third party tools such as AvePoint. Don’t rely on the out of the box SharePoint backups (there are not very good), or even SQL backups, these will only restore databases, not items.
To fully prepare for a SharePoint failure we must begin a process of planning and documentation. If you have a plan that says in a worst case scenario we will be down for 8 weeks and loose 3 years of data and someone signs that off, your covered. But beyond being covered for a time of failure, planning and documentation will help to establish how you will get your SharePoint back up and at what cost.
Work out some statistics showing how long you would be down for and how much you would loose? When you know this you can design your recovery solution. If you want 3nines availability (99.9% up time-that’s only 8hrs downtime per year) then you’ll need fault tolerance on your servers, if you want regular backups that will cost in storage. How much is your data worth? It is hard to put numbers on data in a school when there are no customer databases and multimillion pound contracts but instead John Smith’s Y11 Maths coursework. If he looses that a week before hand-in then that’s not a happy time for anyone.
Planning for failure is all about preparation and balance. What can you afford to implement and what can you afford to sacrifice? Again it is time for the hard miles and documentation. Plan what you need, what you can afford, and put it into action. And of course when things go wrong you can wave that signed off document and say… don’t worry we’re backed up and will be back to normal by the end of the day as we said we would be.
Filed under: Best Practices Posts, SharePoint, Twynham School
Guest post by Chris Mckinley- Senior SQL/SharePoint Developer
Imagine a scenario for an educational SharePoint setup as a development team….
SharePoint is installed, setup and configured seamlessly with the public drives made read only. Staff and students are uploading and collaborating and together with the systems administrators and SharePoint they ride into the sunset and live happily ever after…
Of course this is not how it happens, as Joel Oleson said in his keynote SharePoint is like the killer bunny in Monty Python- if you’re not careful and don’t think things through it will take your head off.
Warning- graphic scenes of violence with a killer bunny!
SharePoint is an excellent solution in a school for removing shared drives and delivering content to a large number of users but it is often entered into tentatively. You can put it on one server, try it out on an old server, virtualise it, use multiple front ends, run a separate SQL server or multiple clustered SQL servers, and create load balanced solutions. There are many approaches to getting SharePoint running within a school but they will all end up the same – broken. Running Moodle or one of the many other platforms? Same problem, broken.
So why does it break? Well the simple answer is: Because it works.
Allow me to explain my madness.
When SharePoint works people will use it, if it really works people will do more and more with it. They’ll add more documents, use rich media content, take advantage of versioning and custom lists. Like a motorway, SharePoint works beautifully until a certain capacity is reached; then it’s long waits and alternative routes. If you fail to plan for expansion you’ll get trapped on that stationary motorway.
The way to make sure this doesn’t happen is to plan. There is no silver bullet, no useful book or blog post to tell you what to do. It’s time for the hard miles – you just need to sit, think and plan; not something that comes naturally to most IT professionals in a school. This doesn’t mean you have to build the largest system you can think of, that’s just a waste. You just need to be ready to expand when you need to, look at your deployment road map (you have one, right?) and be ready for the extra traffic from parents logging in or year 11s revising at times in the evening when the servers could be busy backing up?
If you’re killing public drives you’re going to have a whole lot of files moving into the SharePoint database, that will really hurt your single server setup if you’re not expecting the growth. Have plans in place to add servers and storage in a way that will cause minimal disruption you may need to think about the network backbone too. It’s a tough, long, and tedious task but you’ll be smiling when everything just keeps on ticking as the Head puts that 5MB PDF on the gateway and emails all staff and students asking them to view it.
So you’ve got everything in place and you’re ready to expand quickly and easily to 1500 MySites and 100GB of data, people are happy, end users aren’t complaining, system administrators are kicking back and feeling proud. The sky is blue and the sun is out with the SharePoint bunny happily hopping around.
Then the black clouds of disaster begin to roll in…….How do you prepare?