提出问题提出问题
 

已答复Complete Disconnected Deployment

  • 2009年6月23日 10:09mullkv 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    Hi All,

    I have developed a Internet Publishing Site on MOSS2007 in a sandboxed virtual environment and it works great.  All development is done, the pages are created and everything works fine there.

    My next task is deploy the entire Site collection + content to another disconnected server.

    My Site collection consists of:

    - 1 Top level site and three sub sites
    - Sevel custom lists and image libraries
    - Several content types and columns
    - One custom master page
    - Several custom Page Layouts
    - A few custom Web parts

    I'm just looking at the best options for deploying the whole thing to the new server?

    As they are disconnected is my only option to use the Content Migration API?  If it is, will that deploy everything (such as page layouts, lists, content pages as well as the physical content in the respository)?  Or do I need to do more than that. 

    I have Andrew Conells excellent book with samples on using the Content Migration API but want to check that there isn't any 3rd party tools or other non API ways to achieve this before I go down that route?

    In essence - I want to pick up my entire "application" and place it on another server. 

    Many Thanks for any help you can afford,

    Kevin

答案

全部回复

  • 2009年6月23日 11:02Serge Luca [MVP]MVP用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     已答复
    The easiest way is to use the Sharepoint Content deployment wizzard which makes use of the Migration API in disconnected scenarios. Your features must be deployed before (!)

    Hope this helps

    serge
    Serge Luca; blog: http://www.redwood.be
    • 已标记为答案mullkv 2009年6月24日 11:03
    •  
  • 2009年6月23日 11:06mullkv 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    Hi Serge,

    Many thanks for the very quick reply.  I had looked at using this but I am little confused as to how to set up the destination site.  In some documents I read it says to creat a blank site on the destination first.  I have not created any custom features (all my "code behind" is in one DLL which can be moved manually).  Do I create a publsihing site on the destination server first or a blank site?

    Thanks again for your help - it's very much appreciated.

    Kevin
  • 2009年6月23日 11:12Serge Luca [MVP]MVP用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    Hi kevin,

    if I remember well you must create an empty site collection (not a blank site), stsadm has an option for this; but I strongly suggest to organize your project in features.

    serge
    Serge Luca; blog: http://www.redwood.be
  • 2009年6月24日 6:00AndyGett 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     

    Hi Kevin,

    Here is another option using OOTB stsadm.  I have used it for deploying publishing sites.

    1. Back up your source site using stsadm: Stsadm -o backup -url http://SharePointDevSite:12345 -filename c:\backups\SharepointSite.bak
    2. On the destination server, use Central Admin > Applications to create the destination web application
    3. Create the desitnation site collection wiht a blank site template at the root
    4. Restore the backup to the destination: Stsadm -o restore -url http://SharePointSite:80 -filename F:\backups\SharePointSite.bak -overwrite

    The restore operation includes all site content, content types, list, picture and document library items, web parts, page layouts, custom master page, custom pages, etc.  It does not include any custom code that you put into the GAC or bin directory, nor any features that you installed nor any changes in the 12-hive, nor changes to web.config, which means it should work just fine for you.

    Organizing the project into features is good advice if you have the know how and time to do it. 

     


    AndyGett Blog | @AndyGett Twitter
  • 2009年6月24日 10:58RaghavanS 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    Hi Kevin,

    Below is my understanding:
    1) You have developed a complete publishing site
    2) You want to move it to a new server
    3) This is a diconnected environment

    Below are the possibilities for the deployment
    1) Export / Import
          a) You can use MOSS API
          b) You can use STSADM commands
    2) Backup / Restore
          a) You can use MOSS API
          b) You can use the Central Admin --> Operations --> Backup and restore
          c) You can use STSADM commands

    Of the above two options you can choose one based on the frequence by which you are going to deploy the content from the current environment to the new server.

    If it is one time activity i would recommend going with BackUp / Restore

    But for any activity to succeed you need to have the SharePoint version in destination server >= the version in the source server.

    Also go through the articles of Stefan Gober : http://blogs.technet.com/stefan_gossner/

    Hope this helps






    Raghavan
  • 2009年6月24日 11:02mullkv 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    Hi All - thank you very much for your replies.  I tried several methods, and as this is actually a one off deployment (i.e the content won't need to be deployed like this again), the CDW worked for me.

    Thanks again for your answers,

    Kevin
  • 2009年6月24日 11:05mullkv 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     

    Hi Kevin,

    Here is another option using OOTB stsadm.  I have used it for deploying publishing sites.

    1. Back up your source site using stsadm: Stsadm -o backup -url http://SharePointDevSite:12345 -filename c:\backups\SharepointSite.bak
    2. On the destination server, use Central Admin > Applications to create the destination web application
    3. Create the desitnation site collection wiht a blank site template at the root
    4. Restore the backup to the destination: Stsadm -o restore -url http://SharePointSite:80 -filename F:\backups\SharePointSite.bak -overwrite

    The restore operation includes all site content, content types, list, picture and document library items, web parts, page layouts, custom master page, custom pages, etc.  It does not include any custom code that you put into the GAC or bin directory, nor any features that you installed nor any changes in the 12-hive, nor changes to web.config, which means it should work just fine for you.

    Organizing the project into features is good advice if you have the know how and time to do it. 

     


    AndyGett Blog | @AndyGett Twitter

    Thanks very much Andy.  The CDW worked, which I think pretty much automates what you suggested above.  I want to deploy via features but the urgency of the project did not allow me to learn and use those properly.  I will deffinately impliment Features for the next project.

    Thanks again,

    Kevin