none
Project Workspaces in Seperate Content DB in 2010 RRS feed

  • Question

  • Hi, all finally getting to doing some 2010 deployment dev myself and question about doing a separate content db for the Project Workspaces.  I think this ended up being a best practice in 2007 and the current farm I work with has moved to the model of having their normal SharePoint site collections in the their db's (splitting where it makes sense) and PWA site collection in its own content DB and then finally Project Workspaces in their own content DB as a separate site collection from /PWA on say /PWS.  Is this still the case with 2010 or is it something else, I haven't seen it documented anywhere I believe on TechNet library?

    Next Q, I was going about setting up a blank deployment and ran into an error when doing the separate DB setup. 

    WSS_Content - / (root site collection - blank site template, my site collection - my sites host template)
    WSS_Content_PWA - /PWA (PWA site collection)
    WSS_Content_PWS - /PWS (Project Workspaces site collection - blank site template)

    So when I go and configure Project Site Provisioning Settings, selecting the PWS site collection and saving produced the error, Access denied for the appPool account we use.  So I gave appPool account permission (db_owner) on the WSS_Content_PWS, rerun provisioning and works fine, creates sites etc.  So why is appPool automatically added to all the other content DBs fine, but not the PWS one?  Something to do with the site collection top site template that’s used?  Is it okay to do the permission manually, or is there some other way I should be doing this?

    Just want to get this as correct as possible first swing on deployments of 2010, instead of the jigging and jagging we sometimes did with 2007.

    Thanks.

    Wednesday, September 1, 2010 12:47 AM

Answers

  • Q1: I've wrestled back and forth with this a lot, and I agree with you for
    2007 that separate content db's were the way to go. That's because in 2007,
    PWA was married to its SSP, and it was a major pain to try to restore an
    existing PWA site to another farm with a different SSP. In 2010, my initial
    conclusion is that it's not necessary. In 2010, you can now move a content
    db, PWA site and all to a new farm, and restore it, and PWA works just fine.
     
    Q2: Not sure what the answer is on that one, but I would suspect it's more
    effort than it's worth given the answer to Q1. Don't forget that in 2010,
    the Project Detail Pages reside as content within PWA. Hence if you want
    to restore to another farm, you will have to move PWA as well as the PWS.
     
    I am curious how other folks will respond. I would suspect that the only
    reason you would want to break out PWS across multiple site collections would
    be from a scalability perspective, i.e. you expect your total PWS size to
    grow past the magic 100-150GB recommendation for content databases. If that's
    the case, your second question becomes quite relevant.
     
    - Andrew Lavinsky
     
     
    Wednesday, September 1, 2010 1:31 AM
    Moderator

All replies

  • Q1: I've wrestled back and forth with this a lot, and I agree with you for
    2007 that separate content db's were the way to go. That's because in 2007,
    PWA was married to its SSP, and it was a major pain to try to restore an
    existing PWA site to another farm with a different SSP. In 2010, my initial
    conclusion is that it's not necessary. In 2010, you can now move a content
    db, PWA site and all to a new farm, and restore it, and PWA works just fine.
     
    Q2: Not sure what the answer is on that one, but I would suspect it's more
    effort than it's worth given the answer to Q1. Don't forget that in 2010,
    the Project Detail Pages reside as content within PWA. Hence if you want
    to restore to another farm, you will have to move PWA as well as the PWS.
     
    I am curious how other folks will respond. I would suspect that the only
    reason you would want to break out PWS across multiple site collections would
    be from a scalability perspective, i.e. you expect your total PWS size to
    grow past the magic 100-150GB recommendation for content databases. If that's
    the case, your second question becomes quite relevant.
     
    - Andrew Lavinsky
     
     
    Wednesday, September 1, 2010 1:31 AM
    Moderator
  • Thanks for the response. The more I continue to play around I see no reason not to do the different content DBs even if not hitting the size ceiling, just leaves options open for any future changes.  2 DBs isn't that much trouble, but yes the PWA site has much more "meaning" and content then in 2007, so its not something you can leave behind anymore, or as easy as it was in 2007. 

    I am interested as well to what others are doing for their deployments so everyone please feel free to chime in with what you are doing and why.

    Wednesday, September 8, 2010 2:10 AM
  • Koolin,

    there is a bit of confusion in the question, it seems.

    in 2007 not only did you create multiple DB's, but multiple site collections, hence the disconnect on the permissions.  Yes, there was guidance to that effect in 2007 TechNet, but I found that it was faulty at a number of other levels.  I abandoned the practice after a few installations exhibited undesirable behavior for the user based upon that setup.  there are other technical solutions that are needed if you must move / copy your entire PWA + workspace sites in 2007.

    In 2010 much of the 2007 issue with PWA and PWS are fixed.  I find it much better to simply have a private web application - therefore a private content DB.  create 1 and only 1 site collection (i use team site for the template, my preference) and 1 and only 1 PWA instance.  (ok, you can have more than 1 instance, but now you are muddying the waters)

    I think the MS guidance that still exists in 2010 TechNet is both a carry over from 2007 and a mixup in thinking that PWA will reside in some other web application that is also used for other purposes (has other site collections). 

    If you follow an installation in 2010 TechNet, you would be starting with a new web application, then adding a 2nd database.  I think they want to separate out PWA as a site, and the Project Workspaces sites.  I don't think they have thought it through - all the implications and you don't see any references to it in other docs (like backup / restore)...for example.

    I think Andrew's answer to Q1 iscorrect.

    if you need more than 1 content DB due to size limitations, you simply add a new content db to the existing web application. no need for new site collections and all...don't mix up ideas.  SP will then start using the new db to add project workspace sites.

    remember, SP knows to create sites based upon the Web Application and Site Collection path, so if there is only 1 for Project Server / PWA, you are fine!

    Eric Schyberg

    Pcubed

     

    Thursday, December 16, 2010 8:22 PM
  • Eric got me to do a little research on splitting site collections across multiple content dbs.  Do you mean something like this?  http://social.technet.microsoft.com/forums/en-US/sharepointadmin/thread/5f5cee6a-a2af-4129-9518-a5ecf91fa405/
    Andrew Lavinsky [MVP] Twitter: @alavinsky Blog: http://blogs.catapultsystems.com/epm
    Thursday, December 16, 2010 8:28 PM
    Moderator