locked
SharePoint, fighting the business, getting it right, doing it right. RRS feed

  • Question

  • We have had SharePoint 2007 in for approx 2 years now running on a medium farm, 2 front ends, 1 app, and 1 sql (another front end runs project server).

    Farm is currently running our portal, project sites (basically project document management), and various team sites. Currently 3 web apps split them. 1 SSP.

    I've realised a lot of problem we need to fix and am now in the process of getting them heard. The reason for posting this thread is because I don't just want to shout problems at the business, more so highlight them with suggestive plans/actions/priorities. I seek advice from people who may have faced the same issues or just know about them.

    1. Currently no DR.
    2. Other than the default daily SQL backup, there is no great backup/restore.
    3. There is no archiving mechanism so all data is going into SQL which will grow/grow/grow, there is no archiving of anything to cheaper storage (stubs left in sharepoint) or no permanent archiving for sites/content not required any more.
    4. Decision made on site collections/content databases is becoming worrying. For team sites, and project sites it's one site to one content database.
    5. How to stop the SharePoint can do/should do everything thought.

    My thoughts on the above

    1. We do need DR but what are the true options? I know that having another farm replicating exactly the above in the event of DR will not happen because of the expense involved.
    2. I make this backup/restore point separate to point 1 because a good solution will allow backup/restore at different levels (farm/site/item level). What are you using, I've seen some options out on the market. And if your using nothing, what do you do in the event of documents/sites being required? (this is even more important I guess when content databases are shared)
    3. Similar to point 2 I've seen options on the market, what are you using? And if you aren't using anything how will you manage the SQL growth? Add more expensive SQL storage? Also if using nothing, how do you "archive" sites no longer of use. Just deleting would be worrying unless backup/restore answered this?
    4. A department split alone mean many sites/content databases per web app. I appreciate they're recommendations but 100 databases per web app is the recommendation and this will easily be exceeded if we continue, especially since older sites aren't removed/archived away (point 3?). I find the decision how and when to split truly a difficult one, at least using the 1 to 1 means when a site is broken restoring it to yesterdays SQL backup only affects the one site. At the same time a recommended 100GB per content database isn't overly big, so piling all project sites into one content database wouldn't be ideal since they are document heavy, but once again archiving (stub or permanent) may help.
    5. I know SharePoint is a great collaboration and CMS platform. At the same time I know it's a good application development platform but I want to set the bar/business expectations and wonder what the best method of doing this is. How do we define what SharePoint is BUT ALSO MORE IMPORTANTLY WHAT IT ISN'T? I remember the days when we used to get application requests; "We need an expenses application", "we need a resource booking application" and doing this would result in apps being built but with reasonable timeframes expected. NOW it's sharepoint will do it, sharepoint can do it, why dies it take so long etc.

    I have looked online and seen lot's of information but subjects are spoke about in isolation and don't truly cover the "plans/actions/priorities" in context of a current setup.

    Thanks for any advice.
    • Edited by Tezler Thursday, June 18, 2009 11:19 PM
    Thursday, June 18, 2009 11:10 PM

Answers

  • I've used both export and backup stsadm commands. While export allows you to do web level, backup targets site collection only. I have had better results however with backup but we had many site collections which is where you differ.

    Another tool we used was Chris O'Brian's SharePoint Content Deployment Wizard http://spdeploymentwizard.codeplex.com/ which worked really well. It allows for command line operation too which means you can schedule an export or import.

    Other than these options I can only think some form of SQL mirroring and/or purchased third party tools are available.

    • Proposed as answer by xaphod Monday, January 24, 2011 11:48 AM
    • Marked as answer by Mike Walsh FIN Monday, January 24, 2011 12:05 PM
    Monday, January 24, 2011 9:37 AM

All replies

  • That's a lot of interesting questions that you are raising here. I'll give you my two cents:

    1. As you mentioned, a mirrored environment is one of the best options but its price tag might be too much. If you have a rock-solid backup/restore procedures defined, you may consider yourself covered as per DR, but as always it depends on your operational requirements.
    2. SharePoint native tools give you backup/restore granularity down to a single site collection. There are third-party tools that backup/restore within the site collection, sites and lists. I haven't used them, though.
    3. There are some options nicely summarised by Cory Burns in his blog
    4. You should start by crafting a Governance Plan for your SharePoint. Joel Oleson has a summarised post that outlines most probable lines of action
    5. SharePoint is a good platform for web applications (it's ASP.NET down to the metal) but it's not a silver bullet. The art of SharePoint is to know when to customize and when to develop, without twisting your requirements (too much) to fit SharePoint. There's a lot of subjective matter here, so I recommend you to begin with a Governance Plan that outlines basic guidelines that would decide what goes in SharePoint and what doesn't, and from there include the business / IT feedback and vary the plan accordingly.

    The problems you face are not trivial. I'd also recommend that you read the "Microsoft SharePoint Server 2007 Best Practices" by Ben Curry and Bill English. You will find much first-hand information on planning and governance.
    -- Edin http://edinkapic.blogspot.com
    Tuesday, June 23, 2009 8:22 AM
  • Hi Tezler,

    I seek information about how others have done and found your qestions. My farm setup is almost the same, a bit simpler even since I have only two servers involved: one for the SQL DB and one for the web front end!

    Could you please share what results and desicions you came to?

     

    Kind regards

    Friday, January 21, 2011 2:16 PM
  • What speficially are you seeking? In truth none of the above were ever answered by anyone, I have gained a little knowledge over the time working with SharePoint.

    As for point 5. It's just about managing the expectations, not easy once it's been promised to deliver the world. Users don't like hearing it but they soon become aware when you make the point of it not being available OOB. Now users ask "can it be done OOB". We then talk about possible workaround OOB or the acceptance that they can raise a change (dev request) but the work will have to be resourced in which means being prioritsed. The main issue now is the business silos trying to do their own thing rather than getting together and discussing the big picture!! As a result we have sites of duplication etc. We are slowly raining this in. Whether it will ever be perfect is unknown.

    • Edited by Mike Walsh FIN Sunday, January 23, 2011 7:36 PM 2010 comment removed. This is a pre-2010 forum.
    Sunday, January 23, 2011 7:29 PM
  • Hi,

    Thanks for your reply! I'm mainly interested in No 3: Archive strategy. Now I have 257 sites in two sitecollections. 30-40 are playground/test sites in but the rest is in production.

    The sites are almost only used for document collaboration.

    DR is based on daily backups of content databases.

    Im now going to do a major audit and will archive sites not in use. I have tried to export sites with stsadm but have found the action not reliable, large sites that would not export, etc. Current plan is to export all content with a third party tool and then delete the site to get it out of the content db.

    We don't have any mirrored environment.

    But maybe there is a better/simpler way to do this, so that is why I am interested how others have done?

     

    Kind regards

    Monday, January 24, 2011 8:52 AM
  • I've used both export and backup stsadm commands. While export allows you to do web level, backup targets site collection only. I have had better results however with backup but we had many site collections which is where you differ.

    Another tool we used was Chris O'Brian's SharePoint Content Deployment Wizard http://spdeploymentwizard.codeplex.com/ which worked really well. It allows for command line operation too which means you can schedule an export or import.

    Other than these options I can only think some form of SQL mirroring and/or purchased third party tools are available.

    • Proposed as answer by xaphod Monday, January 24, 2011 11:48 AM
    • Marked as answer by Mike Walsh FIN Monday, January 24, 2011 12:05 PM
    Monday, January 24, 2011 9:37 AM
  • Ok, thanks for the input and the link.I've looked at  it, and It seems nice. I've had problems with the export web feature and therefore I will probably go with our third-party tool, that exports files as 'physical' documents, and archive on cheaper media.

    But always good with a second opinion.

    Thanks!

     

     

    Monday, January 24, 2011 11:47 AM