Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Content Deployment

  Asked By: Charmaine    Date: May 07    Category: Sharepoint    Views: 1804

I'm having some problems with the content deployment feature. I created
Site Collection A with all the content and customization. I then
created Site Collection B using the blank site template. I was able to
setup a path and was able to connect successfully. When I ran the job
it told me it completed successfully but when I go to Site Collection
B, all I see is the blank site that I had created originally.

Has anybody gotten this to work?

I need this capability in order to manage a Development, Staging and
Production environment.

Share: 

 

14 Answers Found

 
Answer #1    Answered By: Chelsey Watts     Answered On: May 07

I've done this several times and the only time I had an issue was when
trying to move a Site collection  on an installation that was upgraded
from B2TR. What options did you select in the Job when you created  it
for what was to be transferred?

 
Answer #2    Answered By: Nagesh Maulik     Answered On: May 07

I am also having issues with content  deployment. I am also trying to
set up the same scenario found below, but I never get past
the "preparing" phase of the content deployment. Someone please
advise...

 
Answer #3    Answered By: Jonathan Scott     Answered On: May 07

How long does a content  deployment take? I've successfully  created a path  and
now running the deploying but the status has been sitting at "Preparing" for
over an hour. My site collection  does not have any content but the structure has
about 6 sites as well as some sub-sites. I just want to make sure that it's
still running and how long I can expect to wait to see a change in status.

 
Answer #4    Answered By: Asia Meyers     Answered On: May 07

It can take a while, although I haven't ever seen it do Preparing for
that long. But have you refreshed the screen? That screen isn't setup
for auto refresh.

 
Answer #5    Answered By: Shelley Reese     Answered On: May 07

I've been refreshing the screen and still the same status. I also have some
third party web parts on the page, do you think this might be causing the
problem?

 
Answer #6    Answered By: Omar Arnold     Answered On: May 07

Anything is possible, but I've done it before with some 3rd party web
parts. It shouldn't be an issue.

 
Answer #7    Answered By: Christen Roberson     Answered On: May 07

I meant to say it shouldn't be an issue, because webparts won't be
deployed along with the content. Any custom webparts will need to be
loaded onto the WFE server in the destination using either STSADM or a
Solution (WSP) file.

 
Answer #8    Answered By: Faith Delgado     Answered On: May 07

Oh, so am I misinterpreting content  Deployment then, it does not deploy the
entire structure as well as content?

I have a DEV - TEST - PROD environments where I need to deploy everything that
I've done on DEV to TEST. Will Content Deployment allow me to roll the DEV
environment over to TEST?

 
Answer #9    Answered By: Amrita Durgude     Answered On: May 07

That is a common misunderstanding.

Content deployment  comes out of the world of content  Management Server
and is designed to deploy Content changes in a Content Driven website
model. It supports a model of AUTHORING - STAGING - PRODUCTION.

But in SharePoint you need to make a distinction between Content and
Architectural Components. Content Deployment will deploy content and
provision sites for that content. But it will not deploy Webparts, Site
Definitions, Features, etc. In general if it's a change to the Web
Application directory or the 12 hive Content Deployment will not move
it. If its in the SharePoint Content Database it will move it. (There
are certain exceptions like site  Columns and Content Types that also
won't be moved.) You need to move things like Features and Webparts
using a Solution deployment package. The model for SharePoint is that
EndUsers build out the structure of the sites so there is no support for
the traditional Dev-Test-Production environment  for SharePoint sites.
You can use that environment for rolling out new webparts etc. using
Solution Deployment.

 
Answer #10    Answered By: Maricela Conway     Answered On: May 07

So do you recommend doing a backup and restore of the site collection  in my
environment in order  to go from DEV - STG - PROD?

 
Answer #11    Answered By: Vinay Thakur     Answered On: May 07

That won't move architectural components like Webparts either since the
12 hive is not backed up by a backup and restore. I recommend using
Solution Deployment files (WSP) to move architectural stuff from Dev to
production, and Content Deployment to move Content. Just be aware that
if your destination is a collaborative site  you don't want to use
Content Deployment to deploy changes, just new Sites.

 
Answer #12    Answered By: Shameka Rich     Answered On: May 07

Even Backup / Restore does not move code in the file system.

Any code will need to be deployed with either features
or solutions.

I prefer solutions.

The rationale is that with collaborative sites, users work on the
production sites.

With publishing sites, historically, users have contributed content  on a
staging site  which is then moved (deployed) to production.

SharePoint offers the capability  of being both collaborative and
publishing on the same site which complicates the issue.

Still Content deployment  only deploys content.

It uses the "PRIME" API in doing so. The same API is used by saving site
as a template  and STSADM export\import.

All require the original site templates to be available on the
destination server for the deployment to be successful.

 
Answer #13    Answered By: Royce Orr     Answered On: May 07

So could somebody please explain to me (as someone with no previous
publishing experience) the pros and cons of the following approaches
for a portal that will mix both publishing and collaborative sites in
the same site  collections:

1. Developing and deploying features as SharePoint solutions in a
classic Development-Staging-Production setup and authoring/approving
content in staging  then publishing it to production.

2. Developing and deploying features as SharePoint solutions in a
classic Development-Staging-Production setup and authoring/approving
AND publishing content  in production only.

 
Answer #14    Answered By: Laura Walker     Answered On: May 07

If the destination site  is a truly collaborative site then you should go
with Option #2. If the site is more of an Internet presence site then
Option #1 provides more control over the approval process of content.

The real Pro and Con to deploying content  from an Authoring -> Staging
-> Production model is that if content is changed both in Authoring and
Production then changes made in Authoring may overwrite changes made in
production. If Production is a collaborative site then this becomes a
real possibility.

There are also some known issues with Content Deployment even to a
stable Production site. For example, if you put a webpart on the page
of an Authoring site and modify it to select a custom view, it will
default back to the original view when pushed to Production through
Content Deployment. Some of these issues have been fixed, but others
remain.

 
Didn't find what you were looking for? Find more on Content Deployment Or get search suggestion and latest updates.




Tagged: