9/10/2009
Please read first two posts in this series. Planning for SharePoint 2010 Part 1, Planning for SharePoint 2010 Part 2.
In the last two posts I showed you how to move your data tier to your new 64bit Farm. That is you moved all your databases and tested that you now have a 64bit based database server to host all the content databases.
Let’s look at how we can move the application server and the web front end server tiers. In this case you can choose to move both Tiers Tier B and C at the same time or individually. In either case the approach is the same.
In order to move your Application Server(s) and the Web Front End Server(s) you’ll need to first install the SharePoint binaries on the servers on Farm B.
With information you gathered in your audit you’ll need to do a fresh install of SharePoint on the SPAPP1 server. Note that you can add an extra application server to this tier as per Microsoft best practice. In this case your application tier will consist of SPAPP1 and SPAPP2 with one server providing Indexing and the other server providing the Query role.
Before moving the application tiers one of the main testing and deciding factors are components that you have manually installed in the servers which you will have to install yourself. You should check with your third party suppliers and your developers that any add-on SharePoint component works correctly in a 64-bit environment. Some of the components that fall into this category are, installation of antivirus products, backup products, iFilters, alternate access mappings and as well as any Web Parts, Features and Site Definitions that you did not install as SharePoint Solutions.
For the installation of SharePoint on Tier B make sure that you follow guidelines for using domain service accounts. You can obtain the latest service updates and the SharePoint binaries from the following links.
Also please note that you will need to create a slip stream build of SharePoint 2007 with SP 2 when installing on Windows Server 2008 R2.
For SharePoint Server 2007, you can follow Create an installation source that includes software updates (Office SharePoint Server 2007) to create one. Below are the complete steps to create a new slipstream build for SharePoint 2007.
Installation Steps
- Copy the content of SharePoint 2007 setup files from the installation media to a folder on your hard drive.
- Delete everything inside Updates folder.
- Download Windows SharePoint Services 3.0 SP2 and Office SharePoint Server 2007 SP2 to a folder. - Ensure SharePoint 2007 SP 2 is downloaded after July 29th. (which provides the SKU error fix)
- Open a command prompt, change directory to the folder you put the downloaded patches, and run the following two commands:
- wssv3sp2-kb953338-x64-fullfile-en-us.exe /extract:[Path to installation bits]\Updates /quiet
- officeserver2007sp2-kb953334-x64-fullfile-en-us.exe /extract: [Path to installation bits]\Updates /quiet
- Change [Path to installation bits] to where you put the bits. These will extract all the content from the two packages to Updates folder. SharePoint installation program will automatically read this folder to apply the patches.
- Delete wsssetup.dll. This is a very important step so please don’t miss it.
- If you also need the Cumulative Updates to be applied when installing SharePoint you can download the latest WSS 3.0 and SharePoint 2007 Cumulative Update packages and extract them into Updates folder like step 4, 5, 6.
- You now have a slipstream build of SharePoint 2007
- The site version will show 12.0.0.6421 or possibly a higher version if you added additional cumulative update files.
Make sure that your server administrators are aware of the Cumulative Update cycles as published on TechNet and the SharePoint Team Blog.
http://blogs.msdn.com/sharepoint/archive/2009/05/13/april-cumulative-update-packages-ready-for-download.aspx
Moving the Application Tier
- Prepare the WFEs for Farm B, but do not add them to the farm. *
- Use the stsadm and do a full backup of all the SSPs on MOSSAPP1 on Farm A (32bit)
- Delete all the SSPs from Farm A (32bit) via STSADM: stsadm -o deletessp -title [ssptitle] –force
- Completely stop Farm A by stopping the services associated with Office SharePoint 2007 and by stopping IIS
- Prepare the WFEs for Farm B, but do not add them to the farm. *
- Use the stsadm and do a full backup of all the SSPs on MOSSAPP1 on Farm A (32bit)
- Delete all the SSPs from Farm A (32bit) via STSADM: stsadm -o deletessp -title [ssptitle] –force
- Completely stop Farm A by stopping the services associated with Office SharePoint 2007 and by stopping IIS
- Copy farm elements that need to be moved manually from the server share to locations on Farm B (SPWEB1, SPWEB2, and SPAPP1) that correspond to their locations on Farm A (32 bit) – Best Practice is that Solutions should be deployed and features activated if using custom code! (Please see my previous post about deploying custom code for SharePoint)
- Start all required services on SPAPP1
- Configure SPAPP1 on Farm B (64bit) to connect to the restored Databases on SQLSERVER08
- Restore the SSPs on SPAPP1 using stsadm –restore with the [keepindex] option
- Set the new default SSP and then delete the original default temp SSP
- Restart Farm B
- Test and fix issues
At this stage you should have your application server and data tier in 64bit mode with only the web front ends to be added.
Moving Tier C – Web Front Ends
In this step you are now adding the web front end servers by joining the new 64-bit servers to the farm, SharePoint Server will create the Web applications on the new servers for you. However you need to make sure that if there are any manual changes that these are applied and working correctly. Also if you are using network load balancing for the web front end’s these have been tested and configured. For reference please read this White Paper by Steve Smith (MVP) titled “How to Scale out SharePoint Server 2007 from a single server farm to a 3 server farm with Microsoft Network Load Balancing on the Web servers” (PDF)
- Completely stop Farm A (32 bit)
- Connect and add the SPWEB1 and SPWEB2 servers to Farm B (64 bit)
- Test and fix issues
Now you should have your SharePoint deployment moved to a 64 bit server tiers to further test your upgrade compatibility for SharePoint 2010.
Alternative Approach for 32bit to 64bit
There are also other variations to moving to 64bit. One other approach has been outlined by Steve Smith and Penny Coventry in a White Paper. You can download the White Paper titled “How to move a 32bit SharePoint farm to 64bit Windows Server 2008”.
- Install the latest Service Pack (SP2) on MOSSAPP1 and MOSSWEB1 (32 bit)
- Prepare your 64bit servers by installing SharePoint
- Add SPAPP1 and SPWEB1 to the existing server farm which will create the web applications but you will have to move custom solutions/third party code manually
Steve and Penny outlines this approach with steps in the White Paper.
In my next post I will outline how to test your existing SharePoint farm using the preupgrade tool provided with SharePoint Service Pack 2.
25/09/2009
Please read Part 1 of this post series before you continue.
In this post I will highlight how to move your (32 bit) SQL Server tier to 64 bit.
In the case of moving your data tier there are few prerequisites that you should consider. In this case we have the assumption that your new 64bit SQL server deployment has followed best practice guidelines for SQL server. From a SharePoint point of view you should consider the following to enable effective management of your existing content databases or any new databases you are creating. SQL Server 2008 or 2005 (64bit) are both supported when moving to SP2010. Details about preparing your database server can be found here (TechNet).
This may be a good time to also plan what your SQL maintenance regime would look like for your new data tier. Start with Database maintenance guidance for SharePoint Server on TechNet. Most important though is that you should read up about Kimberly L. Tripp’s extended blog post series on these tasks in detail. If you are not an SQL server expert or have a DBA who usually looks after your SharePoint SQL databases make sure that they read the series of posts as well.
Remember we are now moving our data tier. At the end of the process you will have your 32 bit farm (APP and WFEs) pointing to a new 64bit data tier.
Moving your Databases
When moving from your 32bit source SQL server to a new 64bit SQL server there are two paths you have to consider. In my example the topology of the final destination 64bit farm is as follows. SPWEB1 , SPWEB2, SPAPP1 and SQLSERVER08 (all 64 bit). At the end of the database only tier you will have a configuration that will reflect MOSSWEB1, MOSSWEB2, MOSSAPP1 (32bit) and SQLSERVER08 (64bit). The options that you have is to completely build a new farm provided that you have the hardware available or just build as you go along. In the case of you doing the big bang approach you can choose to build an entirely new farm and only move the associated web application content databases or you can move all of your databases.
One of the recommendations when deploying your SharePoint farm is to use a combination of DNS record or a SQL Server alias for SharePoint servers to connect to, rather than the actual name of the SQL Server. This gives you the flexibility to move SharePoint databases to another SQL Server instance in the event of general maintenance.
Example: You can move from SQL\sharepointsql to SQLSERVER08\sharepointsql
By using an alias name to connect to (ex: sharepointsql.yourcompany.com), you can save a lot of effort of doing manual steps and a full re-index post deployment. In the case of this scenario both options are considered. To set this straight what you should do is setup this alias and use the stsadm renameserver command to rename the name of the SQL instance prior to carrying out your database move.
Let’s first look at what databases we need to backup. You can find out about all the databases used in your SharePoint deployment by doing a site audit as described in my previous post. At a high level these are.
- Databases for Shared Services Providers (SSPs)
- Search databases for SSPs
- Content databases
- Search database
- Central Administration content database
- Configuration database
You can get a full view of your backup tree using stsadm –o backup –showtree you can use this to note down the databases which are are part of your deployment.
Note: We are not backing up the databases using STSADM or the SharePoint GUI but rather using SQL server management tools on the source 32bit SQL server to backup the databases. Please note that if you are using Single Sign On (SSO) in your deployment you should read this TechNet article first.
Once you have a list of your databases you can choose to backup and restore the databases or alternatively detach all the databases from the source 32bit SQL Server and copy and move the MDF and LDF files and re-attach them to the 64bit destination SQL server and restart the farm.
Before you do that you need to document and identify and test what the overall steps are for your chosen scenario. (Please make sure you read and understand and plan everything before you do anything that involves your PRD SharePoint deployments)
In the case of moving to a SQL server with the same instance name you can follow these steps. (We are only moving the data tier in this scenario)
- Record which Web applications are associated with the SSPs. To do this you can use the STSADM command stsadm –o enumssp –title [nameofssp] This information can be used to re-associate Web applications with the restored SSPs and do your testing and troubleshooting
- Prepare to backup SSPs
- To back up SSP settings type
stsadm -o backup -directory <UNC path> -backupmethod full -item <SSP name>
- Stop the source 32bit farm, stopping the farm ensures that no data is written to the databases before you can move all the databases then back up databases using SQL server management studio or chose to move them via detaching them as mentioned earlier
- The following services should be stopped prior to making any backups of the databases. The reason for this is that unless you stop the associated SharePoint services the SharePoint Configuration db will be out of sync.
Make sure you go to the services snap in on the application server and stop all of the following services on the 32bit source farm MOSSAPP1 (32bit)
Microsoft Single Sign-On service
Office Document Conversions Launcher service
Office Document Conversions Load Balancer service
Office SharePoint Server Search service
Windows SharePoint Services Administration service
Windows SharePoint Services Search service
Windows SharePoint Services Timer service
Windows SharePoint Services Tracing service
Windows SharePoint Services VSS Writer service
- Once the above services are stopped go to command prompt on the source 32bit application server and type : iisreset /stop and proceed to backup the databases
- Databases to backup : Content databases, Central Administration content database, Configuration database, Windows SharePoint Services Help Search database. The other databases in the farm are backed up and restored at the same time as the SSPs
- Copy or move the database backup files to the destination 64bit database server
- On the destination database server, restore the databases that you backed up or attach (which ever the option you are going for)
- Copy to the destination database server all the SQL Server logins, fixed server roles, fixed database roles, and permissions for these databases. Refer to http://support.microsoft.com/kb/918992/ for information on copying user logins from instances of SQL server
- Shut down the 32bit SQL server instance
- Redirect DNS alias to the farm to reference the new 64bit database server
- Restart the 32bit server that is running Central Administration to apply the changes and ensure that the services, Web sites, and application pools associated with the deployment are started
- Restore the SSPs from the backup created previously
- Start all the services on MOSSAPP1 (32 bit)
- Test and troubleshoot
By the end of this process your deployment should look like this!
In the next post we’ll look at the next two tiers Tier B and Tier C.
18/09/2009
Here is a detailed outline of what I discussed and presented at my TechEd session on Wednesday 16th September in Auckland – New Zealand titled Planning for SharePoint 2010 - Upgrade Planning and Guidance OFC306. Thanks to all of you who came along to the session. This is a first in a series of posts and White Papers that I will publish as part of an ongoing series on planning to upgrade to SharePoint Server 2010. Needless to say that I will only cover planning aspects and will NOT be talking about any new features or functionality of SharePoint 2010. Please visit the SharePoint team blog for details of SharePoint 2010.
System Requirements for SharePoint 2010
This has been common knowledge for a while and the SharePoint product team announced that SharePoint 2010 will only be available in x64 (64bit) versions. Therefore the first step is to plan to move, migrate or upgrade your SharePoint infrastructure to 64bit.
- SharePoint Server 2010 will be 64-bit only
- SharePoint Server 2010 will require 64-bit Windows Server 2008 or 64-bit Windows Server 2008 R2
- SharePoint Server 2010 will require 64-bit SQL Server 2008 or 64-bit SQL Server 2005
For complete system requirements visit : http://tinyurl.com/SP2010SysReqs
In my session and in the series of posts these are the scenarios that I wanted to showcase.
- I have a 32bit SharePoint farm I need to migrate this to a 64bit farm
- I have a plan to move to a 64bit SharePoint farm but I don’t know how
- I am already on 64bit SP 2007 and SQL 2008 64bit so I want to upgrade to SP2010?
- I am a newbie to SharePoint and want to learn..
- We want to start our project with SharePoint 2010
- I am still using SPS2003 what can I do?
Auditing and Planning for your server deployment
One of the first steps that you need to do in ensuring the success of your deployment is to conduct a current system audit and put in place a test environment to test your approach. In any scenario you will need to have a separate environment to be able to test and debug any issues. You can use your existing SharePoint DEV and STG servers or you could use a separate virtualised environment. Considerations that you will need to make when planning is the amount of disk space you will need for backing up and restoring SQL databases.
*Note: Even building your pre test/pre upgrade deployment will be a good test to ensure that you can replicate your server farm.
Evaluate – Existing Server Platform and Audit
Conducting a SharePoint audit should be carried out periodically as part of your administrative regime in your deployment regardless. If you are managing a medium to large SharePoint farm servicing a large number of applications and site collections then this should be a regular audit and document process. There are quite a few tools that you can use to conduct an audit of your existing SharePoint platform. The most common tools that you can use today are as follows.
What option or tool you chose is up to you. You should document the following once you have done your audit.
- Servers
- Accounts
- Web Applications
- Databases
- Installed Updates
- Solution Files
- Custom Code
- Site Collections
The above screenshots show using STSADM to identify content databases associated with a web application. You can also output these as text or xml files to be included as part of a report. For a complete list of available commands in STSADM type “stsadm –help” or for a particular command “stsadm –help commandname”.
After you have done your audit you should be able to now plan out what your strategy is. You may find your self in the following scenarios with regards to your current status of your server farm.
Move - Use the procedures for moving a farm or components when you are changing to different hardware (large disks, more processors)
Migrate – From 32bit to 64bit (or Content from a source farm to a destination farm)
Upgrade – Apply new updates and or Service Packs to SharePoint Server 2007 or upgrade to vNext (SP2010)
In my session I introduced the tiered phased approach. This approach is outlined so that you can plan and move your existing 32bit SharePoint 2007 farm to a 64bit SharePoint 2007 farm.
The idea of the tiered approach is a flexible approach which allows you to move different tiers of your farm depending on your requirements and so forth over time. In some cases you may wish to do the “big bang” approach and move all tiers of the farm in one go. This is also OK provided that you have enough servers etc ready.In my series of blog posts or white paper (If I finish it soon) will guide you through the process.
In my next post I will showcase the planning steps required for carrying out Tier A – Phase 1 which is to move your SQL (32bit) server to a 64bit capable SQL server and move all the associated SharePoint databases.
21/07/2009
I got the following question from a mate of mine recently. I’ve edited the message to only contain the bits that I am blogging about..
“Basically I want to know what the implications are for search if we're on the non-enterprise licence for SharePoint. One of our IT guys has expressed concerns over whether we can have a fully effective search (including people finder type capability) without being on the enterprise licence.”
If you use the word “SharePoint” and “Search” then the above can be interpreted in many ways. In this case what my friend was looking for was mainly what does the Enterprise version of SharePoint Search (MOSS 2007) provide over and above the Standard version of SharePoint Search (MOSS 2007). What is not entirely common knowledge is that Microsoft rebranded the SharePoint Search offering as “Microsoft Search Server 2008”. This was not just merely rebranded but also added some cool features including federated queries. For more information about federated search, see Plan for global enterprise search. You can also download the following guide “Administering Enterprise Search in SharePoint. And the most recent acquisition of FAST will have major benefits for customers who really want to take Search to the next level.
Now before you go “hold on a sec.. what another product for me to buy to have new features?”
Well you don’t need to purchase Microsoft Search Server 2008 if you already have MOSS (Enterprise or Standard). The additional features and some functionality was added as part of Service Pack 1 and the Infrastructure Updates and subsequently improved as part of SharePoint Service Pack 2. You can read about the Service Pack 2 enhancements for “Search Server” by downloading this Excel document.
If you look at a SharePoint Server Search Administration page pre Service Pack 1 + IU updates (below) you will see the difference clearly.
With Service Pack 1 + Infrastructure Updates you get the same user interface that you get with Microsoft Search Server 2008.
So in order for your existing SharePoint deployment to get value this is another very good reason that you should look at updating your SharePoint deployments to the latest Service Pack. (Given business priorities of course). If you are in a situation where a custom developed SharePoint application or a Third party SharePoint add-on is preventing you from going to Service Pack 1 or 2 then.. well it’s another blog post (stay tuned) :-)
Anyways more to the point with regards to the question of Enterprise vs Standard and Search. Refer to MSDN on what you get with each version. (Standard vs Enterprise) as of Currently published on TechNet and MSDN.
So if your Organisation is trying to “get search up and running” you may want to consider these options before you start fiddling with the Search features and functionality.
What is the current SharePoint or Content Management type deployment today? Do you actually want to search any of these systems as part of your Search deployment?
What is the Authentication requirements with regards to Search? Do you have sensitive material that need to be excluded from results?
Is there any database content that needs to be Searched and retrieved?
Are you going to utilise existing server hardware with SharePoint currently installed?
Has you configured and tested Shared Services Provider for Search?
Where is your majority of content stored? Web sites? SharePoint sites? File system? Exchange folders? Lotus Notes? Other areas?
What are the type of content do you have identified for Search? Office Documents? PDFs? Images? Videos? Others? (You may need to have additional iFilters to enable search on types of documents)
Do you want to index and search any back end applications? SAP? Siebel? PeopleSoft? ASP.Net applications? Other databases?
What are the requirements around people search and expertise finding?
Any you using existing search products today? If so what is the perception of your end users?
Any requirements around presentation of results to end users?
These are only some of the few options you have to consider for Search.
Check out my previous series of posts and links about Search in SharePoint.
Other resources that you must have a read through for Search deployments
24/12/2008
So we've come to the end of the year and just when you though that you'd wait for a while before updating SharePoint again we have a new update. Well actually this is quite important since from January if you still have note moved to at least service pack 1 for SharePoint you'll be told by MSFT support to get your deployment upgraded.
So what's in this update. (I haven't had time to test these out in length but here is a round up anyway)
Like I mentioned in my previous posts these updates provide the base framework for future enhancements and are related to stability and performance. Refer to my earlier post about how to apply the updates.
Blog post about December SharePoint Cumulative updates from the SharePoint team blog.
Please note that if you are installing/deploying a brand new SharePoint farm make sure that you include all the updates in your build. This ensures that you have all the required updates from day one.
17/12/2008
One of the important aspects when a SharePoint project has been initiated and completed (successfully or otherwise) is who supports what in terms of the deployment and various SharePoint related components. Previously I posted about what you would need to do in terms of starting a SharePoint project and what you need to know from a project managers point of view.
This post is about what happens or should 'ideally' happen after your core SharePoint deployment has been carried out. Again these are only some example important technical aspects that I am highlighting. Each deployment will be unique so it's up to your project team and business to identify the approach for your post deployment support and maintenance of SharePoint as well as the supporting core infrastructure.
For example if we take some of my points about core infrastructure required for a SharePoint deployment, these essentially should also be part of your overall support process.
- Security and Identity - Active Directory or LDAP source
- SQL server for your SharePoint database(s)
- Network infrastructure
- System management and Monitoring capability
- Backup and Recovery
To establish clear lines of responsibility in some cases is somewhat difficult when your organisation has outsourced different aspects of your core infrastructure management to various vendors. I typically classify the following levels of support for the ongoing maintenance and support of a medium (3-6 servers) - large scale (6 or more servers) SharePoint deployment. This can be taken purely from the view of ongoing support for the core technical infrastructure and monitoring point of view to ensuring that your deployment can be used in the longer term to realise business value.
Core Platform Support
- Installing and Configuration of a multi server SharePoint farm
- Integrated monitoring and management of a SharePoint farm solution
- Database maintenance and optimisation on an ongoing basis for SharePoint content databases
- Troubleshooting issues when they arise and provide pro active support on each component that relates to a SharePoint farm deployment
- Provide infrastructure updates and service pack update schedules as they become available
- Manage the release process of new functionality and ensuring service continuity
- Apply Service packs to each component consisting of the SharePoint farm
Administration Support
- Day to day support of the SharePoint functionality (Sites, Lists, Content Types etc or specific business functionality built using these)
- Training of power users as and when required
- Provision a site management and life cycle option for self service site management
- Establish end user support options using existing SharePoint functionality
- Provide end user support in conjunction with business initiatives using SharePoint functionality
Configuration Support
- Provide configuration for SharePoint specific roles (ex: Search, Index, Query, Excel Services etc)
- Ensuring that all SharePoint configurations are documented
- Any new functionality or features that requires to be deployed goes through a formal SDLC process and have been tested accordingly
Again the who does what is somewhat confusing. If your SharePoint deployment is mission critical it will pay dividends to chose an on premise or in house staff member to manage the whole process of managing support process. They do not necessarily need to have full blown technical skills but the ability to manage the relationships between various vendors and providers who may potentially be involved in your SharePoint implementation is crucial and an overall Enterprise view of what can be delivered using the platform is of most value. Remember that your business value realisation happens "post" deployment. No matter how good your project team was it's the ongoing maintenance and nurturing of the SharePoint platform that will give you the ROI.
Feel free to comment and add your thoughts... most interested to hear from the wider community.
26/11/2008
Thanks to everyone who came to my session at the Christchurch SharePoint User Group and Matt (Btw Matt is doing 1 post a day about SharePoint related development until Xmas!), and Gary for organising the event. This post is aimed at covering off some key points which I wanted to clarify. I introduced a planning framework and wanted to clarify that I use this depending on various factors and the engagement that I am doing.
- Initiation or Pre-deployment should answer questions related to your existing infrastructure and how you manage these. This is the stage where you will spend some time analysing your current processes and also how you may need to establish some ownership and guidelines to what you want to achieve in the longer term with your SharePoint deployment. Governance and Capacity planning can be a lengthy exercise if not scoped correctly. Remember that you are not going to set up the world's best SharePoint deployment but being practical about what you have today and identifying the gaps so that you can potentially address these.
Governance Resources - The best place to start for Governance is the TechNet Governance landing page - [ http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx ]
Architecture Resources - Again TechNet has content to cover all types of deployment scenarios - [ http://technet.microsoft.com/en-us/library/cc261834.aspx ]
- Core Installation and Configuration – This covers installing and testing your architecture and ensuring that your SharePoint farm can service your business initiatives. A document should be outlined on how the install process has been carried out. Load and stress testing - Yes, you have to, this is one key thing that everybody misses after a core installation. This is the point where you can get an benchmark prior to deploying code and other configurations. It’s always the best point to catch performance implications after custom code has been deployed into your farm. Some may argue that you don't have to but I tend to benchmark the server once the installation has been carried out.
Installation Guide for MOSS - [ http://technet.microsoft.com/en-us/library/cc298924.aspx ]
Development server configuration for team development for SharePoint deployments - [ http://msdn.microsoft.com/en-us/library/bb428899.aspx ]
- Configuration and Development – Now that you have a core SharePoint deployment now you can start configuring and adding custom functionality to deliver business related applications. This is where you need to ensure that your development teams follow guidelines on how to create and deploy applications for MOSS. You'll need an established software development process to manage code releases and test these accordingly.
Administration guide – Usually it’s a wiki located in Central Administration site with clear and precise information about what should and should not be done on the server farm. This should also include what type of customisation's you should allow to be deployed. This is for your SharePoint server administrators to know how to manage the environment.
Customisation Guide – This is very essential in terms of establishing what is customised in your SharePoint farm. Example: Custom code/BDC (Business Data Catalog) configurations and any other “foreign” artifacts that you introduce to your farm should be documented. Why? Because when you want to recover or move your SharePoint farm you will need these.
Users Guide and Training – You can build the most extravagant portal but if your users don’t know how and why, why would they use it? Make sure that your business users get the correct amount of training by qualified trainers. Training can and should also be extended to the core Infrastructure team that carry out or are appointed to support your deployment.
- Post Deployment – Establishing your SLA to the business and what is and is not supported is key to on going support. The Governance guide you created should have a section about ongoing maintenance and support scenarios that may be specific to your deployment. The recommendation is to have a regular review of your support process by a team of people (Governance Board) to ensure that service continuity is maintained. One key aspect of post deployment is how you maintain your farm by applying the required service packs and hot fixes when they are made available.
Deployment of Service Packs - [ http://technet.microsoft.com/en-au/office/sharepointserver/bb735839.aspx ]
Data Protection and Recovery - [ http://technet.microsoft.com/en-us/library/cc262129.aspx ]
One of the key aspects that I believe that should be taken into consideration no matter how small or large your deployment is that you need to have an established requirements document that outline your business requirements. Then you can map these to your key cycles of your deployment. In one of my previous posts I highlighted some guidelines for Project Managers on how to approach a SharePoint project. I am keen to hear some feedback about this approach and happy to share some real world experiences in using the above framework. If you are interested email me on chandima 'at' chandima '.' 'net' or via the Contact me link at the top.
26/09/2008
One part of SharePoint deployments that sometimes tend to fall on the way side is planning and providing a viable and practical option for recovering data in the event of a server failure. In most cases when a solution architecture is proposed with SharePoint you need to consider the following options in order to formulate a viable and practical backup and recovery option. Not only should you plan these it should be tested out and the steps required and the times taken to do an actual recovery noted so that your team is familiar with what to expect should the need arise.
Depending on the type of solution being deployed and the impact it may potentially have on the business you may need to add availability as part of your solution architecture. This post however will showcase how you can successfully create and test a mock recovery plan for a small server farm with 2 web front end servers and a dedicated SQL server. As part of the recovery plan you need to typically consider content recovery (Usually via the built in Recycle Bin), site recovery (Accidental site deletions by site administrators) and the focus of this post disaster recovery. Disaster recovery in this context is when you lose one of the content databases or all of the databases related to the SharePoint deployment.
For example assuming that your solution includes regular SQL server backups of your content databases. You can log ship the databases to a secondary server or a network location. Log shipping is one of the practical and less complex options that you should consider to be part of your deployment. TechNet has detailed documentation on how to setup log shipping on your SQL server and what you need to consider. TechNet > Configuring Log Shipping (SQL Server 2005)
This post uses a simple and practical DR plan that can be implemented to provide basic DR capability. The emphasis is purely on the recovery and not on high availability. High availability usually means complexity and higher cost. Depending on your deployment you should provide these options and the pros and cons. My view is that simple DR is better than no DR and there is simply no excuse for not setting up such a setup from day one of your deployment.
What databases can I recover and what's the process?
The most important databases in your farm are the content databases of your SharePoint deployment. In this post I will highlight the steps needed to recover your content database(s). First of all let's establish the overall process of the 'mock' fail over scenario. Remember this is just a simulation to ensure that all the required steps are noted and documented and followed through. In a real world scenario the steps outlined will result in a period of time that your users will not be able to access the data. As I said before this is not about high availability but a solution to recover data. The idea of the 'mock' fail over is to establish how long this process will take and provide a realistic estimate of the downtime. But most importantly this prepares your system administrators to act on a tested plan.
In this scenario I am not going to consider any of the Configuration or SSP and Search databases. Typically when you plan for DR you should have a standby web front end server pre-configured to match as close as possible with your production server. This typically means that you will have installed WSS or MOSS and created your web applications. For fail over you would also have a SQL instance on standby where you can attach your log shipped database(s) to.
Consider the following diagram.
This is a somewhat simplistic view of what your DR plan may potentially look like. In this scenario You have a Live (Production) SharePoint farm in Wellington (Wellington is the capital of New Zealand for those not from New Zealand). Auckland which is situated at the top of North Island in New Zealand is where the DR farm is located. As mentioned previously my focus of the post is to highlight the steps in order for the recovery and not how to setup such a deployment.
Overall process which covers the DR steps
- The primary SQL server (PRD-SQL) and SharePoint WFE (PRD-SPWFE) server is powered down or reaches a non operational stage in Wellington
- An incident is raised via system operational procedures to invoke DR measures and start the DR process
- The fail over SQL server (Log ship destination) and secondary SharePoint WFE server is bought online by a system administrator in Auckland or via remote administration from Wellington
- The log shipped content database is made available via backup/restore for use by system administrator performing the DR operation on the Auckland SQL server
- The WSS content database is added as the current active content database to the new web application on the Auckland DR web application server (*steps below)
- Setup Log shipping in the reverse direction to ensure that now you can recover back into Wellington
- DNS redirect is made to point the DR-SPWFE to serve content
Account pre-requisites for restore and recovery
For the DR plan to be effective you will need to have the following rights setup on the destination (Auckland DR) farm. That is basically the setup accounts used in your Wellington farm and the setup accounts in Auckland should be the same or if they are different they should have the following applied. Previously I have posted about setup accounts and why these are important when deploying SharePoint.
- On the DR farm the Central Administration Application Pool account should be a member of the dbcreator and securityadmin fixed server roles on the SQL server
- All application pool accounts and the search services and default content access accounts should have SQL Server logins in the DR farm, although they are not assigned to SQL Server fixed server or fixed database roles
- Members of the Farm Administrators SharePoint group should also have SQL Server logins and should be members of the same roles as the Central Administration application pool account
Steps to recover content database(s) from the log ship destination and restore the DB DR server in Auckland
Assuming that you are now operating the Auckland servers and have a copy of your database restored to the SQL server in the DR farm, you can now attach the content database to the standby web application server (DR-SPWFE). You can do this via the Central Administration Interface or the STSADM command line. Personally I prefer the STSADM command line.
Delete the existing database (Which is pre-configured without any site collections)
STSADM -o deletecontentdb -url <http:// WebSiteName:port> -databasename <ContentDatabaseName> -databaseserver <OldPrincipalServer>
Add the recovered database from the Wellington server.
STSADM -o addcontentdb -url <http:// BackupServerName:port> -databasename <ContentDatabaseName> -databaseserver <NewPrincipalServer>
Alternatively you can follow the steps via Central Administration
- Go to SharePoint 3.0 Central Administration
- On the Central Administration site, click Application Management
- On the Application Management page, in the SharePoint Web Application Management section, click Content databases
- On the Manage Content Databases page, click the name of the content database that has failed over
- On the Manage Content Database Settings page, in the Remove Content Database section, select the Remove content database check box, and then click OK
- On the Manage Content Databases page, click Add a content database
- Enter the information for the database you just removed, but replace the information in Database Server with the name of the new principal server
Repeat Steps 4-7 for each database that has failed over
The below diagram outlines the reverse scenario.
Things that will take time are typically the time for the databases to be restored fully. The larger your content database sizes the longer it will take. Ideally you would have applied quota templates to your site collections or have setup multiple content databases so that you don't end up with a DB larger than 50GB in size. I'd like to hear from anyone who had actually followed through such a proposed plan in a simulated setup to determine the time it would take to typically get back online. The best that I could do was 24 minutes from time of DR to recovery and back online for a very similar setup with 3 content databases of about 20 GB in size.
Happy DR 'ing :-)
More Resources
Technorati Tags: SharePoint, MOSS, WSS, DR, Backup, Recovery, Log Shipping, SQL, Disaster, Process, Administration, Deployment, Architecture |
|
|
|
|