2. Who am I?
• Chandima – aka “Chan” follow @chandimak on twitter
• Solution Architect from Knowledge Cue @knowledgecue on
twitter
• Started with SharePoint 2001... It’s been a great journey
• SharePoint MVP since 2007
• chan@knowledgecue.com
3. Agenda
• Understand the technology deployment operational
management layer
– Understanding the logical SharePoint design
– Ownership of the platform
• Options to consider when planning the deployment
– Operational management challenges
Just because you can it doesn’t mean you should..
Prevention is better than the cure..
4. I am not talking about..
• Managing an Intranet built with SharePoint…
5. SharePoint Logic (for everyone to know)
• Server farm: The top-level element of a logical architecture
design for SharePoint Server.
• Web application: An IIS Web site that is created and used by
SharePoint Server 2010.
• Content database: Provides storage for Web application
content. You can separate content into multiple content
databases at the site collection level.
• Site collection: A set of Web sites that have the same owner
and share administration settings.
• Site: One or more related Web pages and other items (such as
lists, libraries, and documents) that are hosted inside a site
collection.
6. SharePoint deployment planning
• Using on a true enterprise scale.. One
“platform” many uses on managed SLA
– Project sites
– Custom Apps
– Collaboration
– Intranet
8. Solution
Solution
Solution
Solution
Solution
Solution
Solution
Solution
Solution
SharePoint Platform
Production
Development Test
Production
Backup
Disaster Recovery
15. In real world…
• Layer 1 – Governance top level –
– sets the strategy and direction for SharePoint as a platform.
– The key activities of this group are to ensure that the decisions made are aligned to IT
strategy principles.
– They provide direction and delegation to execute key initiatives and will seek advice
from internal experts or third parties where required.
• Layer 2 – Delegated execution –
– this groups main tasks and or activities are to plan out the execution of the overall
strategy set by Layer 1 in relation to SharePoint use in the organisation.
– They also gather information from downstream operations and support team(s) about
the type of requests from the business users and stakeholders.
– This information aids in planning activities and also balancing and prioritisation of
requests based on Layer 1 strategy. In some cases where requests are not in line with
what can be delivered by the existing capability and capacity, the information can be
used to re-plan or set priorities accordingly.
• Layer 3 – Day to day operations - carry out day to day operations that are part
of the overall planning and operational processes. Layer 3, governance is
about negotiating and advising on requests that are coming in from the user
community and their needs. Layer 3 is the buffer zone and also one of the
most important participants since Layer 3 has direct access to requests coming
from users.
16. What should a Team do?
• SharePoint Expert (Solution Architect)
Solution Review
• Key stakeholders/team (multiple)
Solution is • Decision makers who understand the
Fit for Purpose existing solutions/process
Implementation/Support • Regular development cycle
Team • Hand over to operations
17. Operations Planning – solution vs. platform
• Separating “technical exercise”
• Identifying the overall process
– Risk assessment
– Business impact assessment
– Business continuity plan
Business Business Continuity
Risk
Impact Plan
Assessment (Operations Plan)
Analysis
18. Planning Scenarios
• ABC application is a business application used by all users
between the hrs. of 8am and 6pm
• It is hosted on the SharePoint platform
• XXX server has gone down and to mitigate the business
impact to users of ABC application we need XXX to be
operational in N hrs. In order to recover XXX server/system we
will opt for YY process. In order to meet this we need ZZ
hardware/software etc
19. Operational Management Characteristics
• There is work involved to ensure something is working
(running) – ex: TimerJobs - Backups
– Schedule with actions to perform
– Daily/Weekly tasks
• Actions performed by ‘technical’ experts
• Focus is on repeatable and consistent actions
• Investment in equipment/technology or staff
• Value of operational actions must outweigh the costs
21. Why is SharePoint special?
• It’s a business enabler
• Requires ‘business first’ attitude
• There is shortage of people with experience in
business/technical balance
• Must be able to turn around solutions rapidly and consistently
Know what you know well and know what you don’t know..
22. Key decision points
• Learn as you go
• Up skill your existing team
• Seek external expertise
• Outsource everything
• Out source but In source key knowledge
• Do nothing..
23. Easier said than done…
• The mythical all encompassing ‘Governance’ document! –
who wrote that?
• Fairly new people in SharePoint space
• People leave.. (after you’ve trained them!)
• Continuous change..
• More solutions..
• Shrinking windows for overall SLA’s
• High complexity..
24. SharePoint – post deployment stress
• Company XYZ has deployed ‘SharePoint’
• Company XYZ has used SharePoint ‘Expert(s)’ company ABC to
build an Intranet/DM/RM/Widget etc – or something that no
one knows apart from it’s ‘SharePoint’
• You are part of a team or ‘the team’ who looks after IT or the
designated ‘SharePoint thingamabob’
– You get called into a meeting and you are IT! (from tomorrow)
– You are a manager who has been told by your boss that your team is
now responsible for managing ‘SharePoint’!
– You get called/email by a user with “my sharepoint is broken”
25. RTO and RPO
• Recovery Time Objective
– The amount of time that can elapse between the occurrence of a
‘disaster’ and the affected system being returned to an ‘agreed’
operational readiness state
– The time it takes to get up and running again
26. RTO and RPO
• Recovery Point Objective
– The amount of time prior to any ‘disaster’ where data loss may (and
will) occur
– Maximum amount of data loss that is deemed acceptable in the event
of DR
– Near – Zero RPO always incurs $$$ and complexity
27. Less critical
RPO = 12 Hrs. – Data loss of 12 Hrs. or less
RTO = 24 Hrs. – SharePoint is unavailable for 24
Hrs.
Disaster declared at 8am
Last backup
at or after
Fully operational by at 8am next
8pm
day
Time
RPO 12 Hrs.
RTO 24 Hrs.
28. High critical
RPO = 30 Mins. – Data loss of 30 Mins. or less
RTO = 1 Hrs. – SharePoint is unavailable for 1
Hrs.
Disaster declared at 8am
Last backup
at or after
7.30am Fully operational by at 9am
Time
RPO 30 Mins.
RTO 1 Hrs.
29. Typical NZ deployment scenarios
Good
Web Front End
Servers (WFE) • Dual/Quad Core Processors
• 4GB for WFE (Virtualised)
• 8GB for APP (Virtualised)
• 8-12GB for SQL < Dedicated
Application
Servers (WFE)
Suitable for typical medium size
organisation in NZ (200-500 users)
Database
Backend (Shared) • Collaboration sites (light)
• Project Sites
• Intranet
30. Typical NZ deployment scenarios
Web Front End Better
Servers (WFE)
• Dual/Quad Core Processors
• 8GB for WFE (Virtualised)
• 8GB for APP (Virtualised)
Application • 16GB for SQL on a cluster or log
Servers (WFE)
shipping
• Can support more than 1500+ users
Database
Backend (Shared)
31. Large deployment scenarios
NLB
Best (Large high availability)
Web Front End • Quad Core Processors
Servers (WFE)
• 8GB for WFE x 2
• 8>12GB for APP x 2
Application
Servers (WFE)
• 16>32GB for SQL on a cluster with
log shipping/mirror
• 10k users
Database
Backend
(Dedicated)
32. Re-consider
Web /App Result will always be..
Server
Virtualised all in
one box!
• Slow performance
• Expectations not met
• Dissatisfied users/business
Database
Backend
(Shared with lots
of other apps)
Only Good if you are the only person using it!
33. Training… not an afterthought..
• There is no point in telling someone else to run with
SharePoint if you don’t know how to walk with SharePoint
– Invest in a balanced mix of out sourced vs. in sourced
– Ensure you get ROI from vendors/third parties by working with them
directly ‘on-site’
34. SharePoint – post deployment stress
• Company XYZ has deployed ‘SharePoint’
• Company XYZ has used SharePoint ‘Expert(s)’ company ABC to
build an Intranet/DM/RM/Widget etc – or something that no
one knows apart from it’s ‘SharePoint’
• You are part of a team or ‘the team’ who looks after IT or the
designated ‘SharePoint thingamabob’
– You get called into a meeting and you are IT! (from tomorrow)
– You are a manager who has been told by your boss that your team is
now responsible for managing ‘SharePoint’!
– You get called/email by a user with “my sharepoint is broken”
38. Layer 1 - Monthly Tasks
• Security Checks
• Capacity Planning
• Disaster Recovery Test (Maybe each quarter?)
39. Key Takeaways -Operational Management
• The managing of stuff to keep everyone in a ‘happy’ place
– There is NO ‘one size fits all’
– What works for me will not work for you
– Take the ideas and build on them
– Start Small – Think BIG
– Consider Office365 > All of the usual operational headaches are taken
care of!
– White paper with ‘Tasks’ and ‘Checklists’ > http://bit.ly/spopschecklist
- good learning point…
Everyone loves demonstrations if you’re able to show one!If not just delete or hide this slide in your presentation.
This talk is targeted to highlight poor planning in SharePoint projects that leave IT teams with a “SharePoint deployment” that has no clear definitions or ownership.
Key slide to describe how organisations need to think about SharePoint when talking about a SharePoint deployment – the key planning phases and how ownership needs to be dictated.
The true challenge with a ‘deployment’ that is multi-use is the way in which you manage it – for example if you commoditize the offering to a large user base with different needs then your process/rigour around how you look after the ‘core deployment’ is very important.
Highlights the intranet that has been delivered on Day 1 and handed over to BAU
The key point is feedback between each of these layers!
What else would you add to this?ABC application should not incur any data loss?ABC application should must not be offline for more than 30mins a day!
When starting for form a picture of what it is that is meant by operational management its important to understand that you need to relate these to the underlying technology stack of SharePoint as well as what’s possible with SharePoint..
By special I mean difficult… most SharePoint deployments are started with some good intentions and purposes.The second part of the challenge is that with SharePoint you need to have people who are able to work with business users and technical (IT) to realise what was intended with a solution.
The key decision points for any type of organisation when it comes to SharePoint is if whether to ‘learn as you go’ vs options such as hiring new or third parties.
What I want to make sure we focus is on not the ‘before’ – but the ‘after’ – you might find yourselves in these situations or you might already know of people/customers/colleagues who are in this situation so it’s important that we put this all into contextIf you don’t match any of these scenarios and you are hear to know and learn what to avoid – then that’s great! So what I’ll talk about is two companies who had gone through a learning curve and what they did and what they found out what worked best for them and why!Along the way you’ll find something you’ll be able to take away and be able to put into use in within your own context.
Recovery point objectiveRecovery time objective
Server Farm Diagrams and How to scaleConcept of a Farm which contains web front end servers and application servers.Single Farm (All in One)Multiple Server Farm (Roles assigned)Web front ends respond to user requests.
Server Farm Diagrams and How to scaleConcept of a Farm which contains web front end servers and application servers.Single Farm (All in One)Multiple Server Farm (Roles assigned)Web front ends respond to user requests.
Server Farm Diagrams and How to scaleConcept of a Farm which contains web front end servers and application servers.Single Farm (All in One)Multiple Server Farm (Roles assigned)Web front ends respond to user requests.
What I want to make sure we focus is on not the ‘before’ – but the ‘after’ – you might find yourselves in these situations or you might already know of people/customers/colleagues who are in this situation so it’s important that we put this all into contextIf you don’t match any of these scenarios and you are hear to know and learn what to avoid – then that’s great! So what I’ll talk about is two companies who had gone through a learning curve and what they did and what they found out what worked best for them and why!Along the way you’ll find something you’ll be able to take away and be able to put into use in within your own context.
The challenge that we see at the moment is across many organisations is that over time as the use of SharePoint grows up – the demands from business as well as users also goes up! When a single ‘solution’ is deployed to SharePoint then there is only less things to worry about – however as we all know SharePoint as a platform can be used for many things. Whether it is document management or as an intranet that provides a host of ‘services’ that sit on the SharePoint ‘platform’ over time the existing processes must be revisited and revised.