SharePoint replication
•Download as PPTX, PDF•
0 likes•465 views
Ron Charity will present on increasing user adoption of SharePoint through replication. Replication can copy SharePoint content to other regions to reduce workload and publishing errors while making content closer to users. It also enables active/active disaster recovery environments and offsite backups. The presentation will cover common replication reasons, types of replication, information architecture and technical considerations, and operational best practices for sustaining a replication solution.
More Related Content
What's hot
Similar to SharePoint replication
Similar to SharePoint replication (20)
Recently uploaded
Recently uploaded (20)
SharePoint replication
- 1. SharePointIncrease User Adoption with SharePoint Replication • Ron Charity • roncharity@gmail.com • 416-300-6033
- 2. Read me (Remove when presenting) • This is a draft document – Reviews are required by Penton and Metalogix – Review each page and notes – Edit as you see fit and highlight change in RED • The presenter has 15-20 minutes to present • The presentation contains 15-20 slides to meet time slot
- 3. Abstract (Remove when presenting) Organizations with remote or global field offices are finding that despite massive growth in collaboration and content sharing, speed and accessibility has been decreasing. And that means less productivity for your organization. The solution is replication. Join SharePoint expert, Ron Charity as he walks IT professionals through a cursory overview of what replication is, how to identify replication as a solution, best practices for technical solutions and operational activities required to sustain a replication solution.
- 4. BIO Ron Charity A published Technologist with 20 + years in infrastructure and application consulting. Experience working in the US, Canada, Australia and Europe. Has worked with SharePoint and related technologies since 2000. Currently he is responsible for a large global SharePoint environment consisting of several farms that service a financial institution. Plays guitar in a band, rides a Harley Nightster, owns a Superbird, and enjoys travel, especially to beach destinations.
- 5. Agenda • Common reasons for replication • General type of replication • Information architecture considerations • Technical architecture considerations • Operational considerations • Next steps • Further reading • Contact information
- 8. Reasons for Replication •Content Replication – Copying SharePoint content to other regions to reduce content authoring workload, costs and reduce publishing errors. Also replicate content closer to end users improving user experience. •Disaster Recovery – active / active multi-farm environment to creates a highly resilient service offering. •Data Backup – Copying content databases to off site to comply with offsite backup policy.
- 9. Types of Replication •Storage-level replication - At the storage level (focused on a block of binary data typically offered by Storage venders) •Database-level replication - Provided by your RDBMS (e.g. Microsoft SQL Server) •Application level – Replication at application enables replication in a more granular manner
- 10. Types of Replication •Storage-level replication - At the storage level (focused on a block of binary data typically offered by Storage venders). •Database-level replication - Provided by your RDBMS (e.g. Microsoft SQL Server). •Application level – Replication at application enables replication in a more granular fashion at the site collection, sites, lists and library level.
- 11. Categories for best practices •Information Architecture – content level practices and steps you must take. •Technical architecture – technology design practices and steps you must take. •Operational – operational practices you must take.
- 12. Information architecture considerations •Identify content (site collections, sites, lists and libraries to be replicated). •Document publishing intervals for content to understand how often content is refreshed. •Document source content owners / publishers. •Obtain service levels for decision support regarding solution – metrics, •Know your company policy specific to records management and privacy.
- 13. Technical Best Practices •Run a risk workshop with stakeholders to create a risk plan (technical and operational). •If replicating for a warm standby solution (e.g. SharePoint) make sure inventory all the databases required. •If replicating for off-site backups know your company policy regarding retention •Document and track data (e.g. database) size and growth patterns.
- 14. Technical Best Practices •Document current operational jobs such as indexing, profile imports etc. •Investigate your network bandwidth and latency – will impact replication times. •Make sure the product(s) have capability to error check in case of corruption. •Make sure the product(s) log replication times and duration – tie into helpdesk system for notification and reporting.
- 15. Technical Best Practices •Speak with Network staff to obtain information regarding network bandwidth and latency. •Script and where possible – minimize chance of human error and reduce operational workload. •Test the solution in an environment that closely mimics the production design. •Document product architecture and configuration for production support and reference purposes.
- 16. Technical Best Practices •Create a document a legal hold process jointly with records management / compliance and audit •Document operational procedures for day to day support and verification of correct operation. •If using for warm standby document the recover procedures (e.g. rebuilds, jobs to be run, URL pointers to be changed, testing for correct operation etc.)
- 17. Technical Best Practices Con’t •Utilize encryption to protect data – follow company policy and or vender recommendations as required. •Utilize compression – utilize as required based on network and job window available - follow vender recommendations and plan as required.
- 18. Operational Best Practices Con’t •Track and report on data (e.g. database) growth and replication times. •Log events related to data replication (e.g. start, end, duration and errors). •Use help desk software to log and send messages to staff regarding status and success/errors. •Test the replication solution on a regular basis (e.g. yearly or after major technical and or operational changes).
- 19. Operational Best Practices Con’t •Test legal hold process on a regular basis and involve record management / compliance office and audit. •Document the operational procedures for day to day operations/administration and troubleshooting. •If operations are outsourced make sure the contract includes the responsibilities and skill set required.
- 20. Operational Best Practices Con’t •Make commercial arrangements for support and software license maintenance. •If you’re in a very large organization consider utilizing a product manager to look after product lifecycle. •Keep diligent eye on operational jobs and possible overlap that could impact performance and proper completion of jobs (e.g. backup, replication, virus scans etc.).
- 21. Next steps •Assemble a business case for replication •Work with stakeholders and or sponsors •Scope a proof of concept •Deploy proof of concept •Deploy pilot •Deploy to production •Documentation for each step with rigorous communication
- 22. Further Reading •Metalogix Replicator •SQL Server Replication •Fundamentals of SQL Server 2012 Replication •Pro SharePoint Disaster Recovery and High Availability (Expert's Voice in Sharepoint)
- 23. Contact Information • Questions? Ideas or suggestions you want to share? • Text chat or contact me at – roncharity@gmail.com – ca.linkedin.com/in/ronjcharity/
Editor's Notes
- Final Version 2.0 Date 10/6/2014
- Left blank intentionally
- Left blank intentionally
- Mental note >> What's the point? Why should they care? There are many ways to approach this topic Being allotted 20 minutes, I must briefly touch on important areas I’m a consultant / architect – take a holistic approach – multiple view points Your level of success depends what you’re managing to as success criteria I will be prescriptive throughout the webinar and will be available through email
- Left blank intentionally
- Mental note >> What's the point? Why should they care? You require a strategy and plan to be truly successful. Success often depends on specific points of view. Especially in large organizations without governance or those using outsourced resources. An executive sponsor is key to your success. Leverage the team, company policy, stakeholders. Maneuver carefully around fiefdoms and other politics.
- Mental note >> What's the point? Why should they care? Successful people usually Have a strategy Have a solid network Have some help Think of the it this way… Coyote as your sponsor and Gorn as all the politics
- Mental note >> What's the point? Why should they care? The following are the common reasons for replication: Content Replication Copying SharePoint content to other regions to reduce content authoring workload, costs and reduce publishing errors. Also replicate content closer to end users improving user experience - reduce distance/latency between content and user. Disaster Recovery Active / active multi-farm environment creating a highly resilient service offering. Copy SharePoint content to another farm located in another geographic region that is acting as a warm standby. Data Backup – Copying content databases to another site to comply with company offsite backup policy.
- Mental note >> What's the point? Why should they care? The following are the common types of replication: Storage-level replication - At the storage level (focused on a block of binary data typically offered by Storage venders) – fast but does allow for granular control of application content replication. Also storage level replication is generally not within the control of the SharePoint team. Database-level replication - Provided by your RDBMS (e.g. Microsoft SQL Server) . Still fast but does and does provide more granular control of replication (at database level). RDMS level replication is generally not within the control of the SharePoint team. Application level – Replication at application enables replication in a more granular fashion at the site collection, sites, lists and library level. Application level replication is generally within the control of the SharePoint team.
- Mental note >> What's the point? Why should they care? The following are the common types of replication: Storage-level replication - At the storage level (focused on a block of binary data typically offered by Storage venders) – fast but does allow for granular control of application content replication. Also storage level replication is generally not within the control of the SharePoint team. Database-level replication - Provided by your RDBMS (e.g. Microsoft SQL Server) . Still fast but does and does provide more granular control of replication (at database level). RDMS level replication is generally not within the control of the SharePoint team. Application level – Replication at application enables replication in a more granular fashion at the site collection, sites, lists and library level. Application level replication is generally within the control of the SharePoint team.
- Mental note >> What's the point? Why should they care? The best practices and steps are broken down as follows: Information Architecture – content level practices and steps you must take. Technical architecture – technology design practices and steps you must take. Operational – operational practices you must take.
- Mental note >> What's the point? Why should they care? Information architecture considerations: Identify content (site collections, sites, lists and libraries to be replicated). Document publishing intervals for content to understand how often content is refreshed. Document source content owners / publishers. Obtain service levels for decision support regarding solution – metrics that will communicated to stakeholders (expectations regarding replication of content). Know your company policy specific to records management and privacy – especially when replicating content between countries. general disposition schedules for content
- Mental note >> What's the point? Why should they care? Technical considerations: Run a risk workshop with stakeholders to create a risk plan (technical and operational). If replicating for a warm standby solution (e.g. SharePoint) make sure inventory all the databases required. Also know which databases not to replicate (e.g. profile database) and related rebuild/job times required to re-populate (e.g . profile and search) . If replicating for off-site backups know your company policy regarding retention and follow it. Document and track data (e.g. database) size and growth patterns. Document current operational jobs such as indexing, profile imports, virus scans and backup jobs for later use when planning replication jobs. Investigate your network bandwidth and latency – will impact replication times. Make sure the product(s) have capability to error check in case of corruption. Make sure the product(s) log replication times and duration – tie into helpdesk system for notification and reporting. Speak with Network staff to obtain information regarding network bandwidth and latency. Script and where possible – minimize chance of human error and reduce operational workload. Test the solution in an environment that closely mimics the production design. Document product architecture and configuration for production support and reference purposes. Create a document a legal hold process jointly with records management / compliance and audit Document operational procedures for day to day support and verification of correct operation. If using for warm standby document the recover procedures (e.g. rebuilds, jobs to be run, URL pointers to be changed, testing for correct operation etc.) Utilize encryption to protect data – follow company policy and or vender recommendations as required. Utilize compression – utilize as required based on network and job window available - follow vender recommendations and plan as required.
- Mental note >> What's the point? Why should they care? Technical considerations: Run a risk workshop with stakeholders to create a risk plan (technical and operational). If replicating for a warm standby solution (e.g. SharePoint) make sure inventory all the databases required. Also know which databases not to replicate (e.g. profile database) and related rebuild/job times required to re-populate (e.g . profile and search) . If replicating for off-site backups know your company policy regarding retention and follow it. Document and track data (e.g. database) size and growth patterns. Document current operational jobs such as indexing, profile imports, virus scans and backup jobs for later use when planning replication jobs. Investigate your network bandwidth and latency – will impact replication times. Make sure the product(s) have capability to error check in case of corruption. Make sure the product(s) log replication times and duration – tie into helpdesk system for notification and reporting. Speak with Network staff to obtain information regarding network bandwidth and latency. Script and where possible – minimize chance of human error and reduce operational workload. Test the solution in an environment that closely mimics the production design. Document product architecture and configuration for production support and reference purposes. Create a document a legal hold process jointly with records management / compliance and audit Document operational procedures for day to day support and verification of correct operation. If using for warm standby document the recover procedures (e.g. rebuilds, jobs to be run, URL pointers to be changed, testing for correct operation etc.) Utilize encryption to protect data – follow company policy and or vender recommendations as required. Utilize compression – utilize as required based on network and job window available - follow vender recommendations and plan as required.
- Mental note >> What's the point? Why should they care? Technical considerations: Run a risk workshop with stakeholders to create a risk plan (technical and operational). If replicating for a warm standby solution (e.g. SharePoint) make sure inventory all the databases required. Also know which databases not to replicate (e.g. profile database) and related rebuild/job times required to re-populate (e.g . profile and search) . If replicating for off-site backups know your company policy regarding retention and follow it. Document and track data (e.g. database) size and growth patterns. Document current operational jobs such as indexing, profile imports, virus scans and backup jobs for later use when planning replication jobs. Investigate your network bandwidth and latency – will impact replication times. Make sure the product(s) have capability to error check in case of corruption. Make sure the product(s) log replication times and duration – tie into helpdesk system for notification and reporting. Speak with Network staff to obtain information regarding network bandwidth and latency. Script and where possible – minimize chance of human error and reduce operational workload. Test the solution in an environment that closely mimics the production design. Document product architecture and configuration for production support and reference purposes. Create a document a legal hold process jointly with records management / compliance and audit Document operational procedures for day to day support and verification of correct operation. If using for warm standby document the recover procedures (e.g. rebuilds, jobs to be run, URL pointers to be changed, testing for correct operation etc.) Utilize encryption to protect data – follow company policy and or vender recommendations as required. Utilize compression – utilize as required based on network and job window available - follow vender recommendations and plan as required.
- Mental note >> What's the point? Why should they care? Technical considerations: Run a risk workshop with stakeholders to create a risk plan (technical and operational). If replicating for a warm standby solution (e.g. SharePoint) make sure inventory all the databases required. Also know which databases not to replicate (e.g. profile database) and related rebuild/job times required to re-populate (e.g . profile and search) . If replicating for off-site backups know your company policy regarding retention and follow it. Document and track data (e.g. database) size and growth patterns. Document current operational jobs such as indexing, profile imports, virus scans and backup jobs for later use when planning replication jobs. Investigate your network bandwidth and latency – will impact replication times. Make sure the product(s) have capability to error check in case of corruption. Make sure the product(s) log replication times and duration – tie into helpdesk system for notification and reporting. Speak with Network staff to obtain information regarding network bandwidth and latency. Script and where possible – minimize chance of human error and reduce operational workload. Test the solution in an environment that closely mimics the production design. Document product architecture and configuration for production support and reference purposes. Create a document a legal hold process jointly with records management / compliance and audit Document operational procedures for day to day support and verification of correct operation. If using for warm standby document the recover procedures (e.g. rebuilds, jobs to be run, URL pointers to be changed, testing for correct operation etc.) Utilize encryption to protect data – follow company policy and or vender recommendations as required. Utilize compression – utilize as required based on network and job window available - follow vender recommendations and plan as required.
- Mental note >> What's the point? Why should they care? Obtain service levels for decision support regarding solution – metrics that will communicated to stakeholders. Run a risk workshop with stakeholders to create a risk plan (technical and operational). If replicating for a warm standby solution (e.g. SharePoint) make sure inventory all the databases required. Also know which databases not to replicate (e.g. profile database) and related rebuild/job times required to re-populate (e.g . profile and search) . If replicating for off-site backups know your company policy regarding retention and follow it. Also document and track data (e.g. database) size and growth patterns. Investigate your network bandwidth and latency – will impact replication times. Make sure the product(s) have capability to error check incase of corruption. Make sure the product(s) log replication times and duration – tie into helpdesk system for notification and reporting. Speak with Network staff to obtain information regarding network bandwidth and latency. Script and where possible – minimize chance of human error and reduce operational workload. Test the solution in an environment that closely mimics the production design. Document product architecture and configuration for production support and reference purposes. Document operational procedures for day to day support and verification of correct operation. If using for warm standby document the recover procedures (e.g. rebuilds, jobs to be run, URL pointers to be changed, testing for correct operation etc.) Utilize encryption to protect data – follow company policy and or vender recommendations as required. Utilize compression – utilize as required based on network and job window available - follow vender recommendations and plan as required.
- Mental note >> What's the point? Why should they care? Operational best practices: Track and report on data (e.g. database) growth and replication times. Log events related to data replication (e.g. start, end, duration and errors). Use help desk software to log and send messages to staff regarding status and success/errors. Test the replication solution on a regular basis (e.g. yearly or after major technical and or operational changes) by accessing replicated data (e.g. database) or testing the failover of the warm standby system. Test legal hold process on a regular basis and involve record management / compliance office and audit. Document the operational procedures for day to day operations/administration and troubleshooting. If operations are outsourced make sure the contract includes the responsibilities and skill set required. Make commercial arrangements for support and software license maintenance. If you’re in a very large organization consider utilizing a product manager to look after product lifecycle. Keep diligent eye on operational jobs and possible overlap that could impact performance and proper completion of jobs (e.g. backup, replication, virus scans etc.).
- Mental note >> What's the point? Why should they care? Operational best practices: Track and report on data (e.g. database) growth and replication times. Log events related to data replication (e.g. start, end, duration and errors). Use help desk software to log and send messages to staff regarding status and success/errors. Test the replication solution on a regular basis (e.g. yearly or after major technical and or operational changes) by accessing replicated data (e.g. database) or testing the failover of the warm standby system. Test legal hold process on a regular basis and involve record management / compliance office and audit. Document the operational procedures for day to day operations/administration and troubleshooting. If operations are outsourced make sure the contract includes the responsibilities and skill set required. Make commercial arrangements for support and software license maintenance. If you’re in a very large organization consider utilizing a product manager to look after product lifecycle. Keep diligent eye on operational jobs and possible overlap that could impact performance and proper completion of jobs (e.g. backup, replication, virus scans etc.).
- Mental note >> What's the point? Why should they care? Operational best practices: Track and report on data (e.g. database) growth and replication times. Log events related to data replication (e.g. start, end, duration and errors). Use help desk software to log and send messages to staff regarding status and success/errors. Test the replication solution on a regular basis (e.g. yearly or after major technical and or operational changes) by accessing replicated data (e.g. database) or testing the failover of the warm standby system. Test legal hold process on a regular basis and involve record management / compliance office and audit. Document the operational procedures for day to day operations/administration and troubleshooting. If operations are outsourced make sure the contract includes the responsibilities and skill set required. Make commercial arrangements for support and software license maintenance. If you’re in a very large organization consider utilizing a product manager to look after product lifecycle. Keep diligent eye on operational jobs and possible overlap that could impact performance and proper completion of jobs (e.g. backup, replication, virus scans etc.).
- Mental note >> What's the point? Why should they care? Assemble a business case for replication Align with business need / key selling points financially and technically Identify gaps and friction points Work with stakeholders and or sponsors Get to know the commercial aspects Know what they want from replication / more leverage the better Scope a proof of concept Keep it small and inexpensive Focus on demonstrating concept / value Deploy proof of concept Limited run for 30/60 days Review against success criteria Deploy pilot Deploy to production
- Mental note >> What's the point? Why should they care? Metalogix Replicator http://www.metalogix.com/Products/Replicator/Replicator-for-SharePoint.aspx SQL Server Replication http://msdn.microsoft.com/en-us/library/ms151198.aspx Fundamentals of SQL Server 2012 Replication http://www.amazon.com/Fundamentals-SQL-Server-2012-Replication/dp/1906434999/ref=sr_1_1?s=books&ie=UTF8&qid=1410903907&sr=1-1&keywords=sql+server+replication Pro SharePoint Disaster Recovery and High Availability (Expert's Voice in Sharepoint) http://www.amazon.com/SharePoint-Disaster-Recovery-Availability-Sharepoint/dp/1430263288
- Left blank intentionally