I've just been through two days of pain trying to get content deployment to work from an internal authoring site, authenticated against Active Directory, to a live site that is Internet-facing (hence allows anonymous access), and has a forms authentication user store. It's more of an admin nightmare than a developer task, but as I've found over many months, working with SharePoint as a developer involves a lot of the admin side of things too. This blog post is a guide to a proof-of-concept, and not meant for a live production environment.
So, what can I share with you that might help? Well, let's list a few links that you need to read first:
http://technet.microsoft.com/en-us/library/cc263428.aspx
http://www.harbar.net/archive/2007/06/27/Content-Deployment-Ensure-your-platform-hygiene-before-randomly-abusing-the.aspx
http://blogs.msdn.com/sharepoint/archive/2006/05/02/content-deployment.aspx
So, that out of the way, here's how I got it to work. And bear in mind that this is on a development machine where all sites are hosted on the same box - albeit in different web applications. Different applications, different authentication, same central administration application.
Firstly, you'll need to have two sites, one for authoring, one for live. If you want a forms auth site as your live site, there are many resources - this one is pretty good. When you create your sites, the golden rule applies:
The target site for content deployment MUST be created using the BLANK site template
Even better, if you can get it to work (and I could only get this to work for an AD-based site, not the forms auth site, but I digress), you can try the following once you have created the web application to create your target site collection:
STSADM.EXE -o createsite -url <url-to-site-collection> -ownerlogin domain\user -owneremail <email-address>
So, you have a blank target site. I'm going to assume you have an authoring site set up to use some kind of template - I set mine up as a collaboration portal. Another word of warning - as yet, I've not tried content deployment against a site with custom features, web parts, etc. As far as I know, those have to be installed separately and available on the destination server prior to deployment - I may have to write a follow up to this article when I get that far. Enter some content to make it clear that your site has been deployed - I added some images to the main images library and edited a couple of content editor parts. Now, over to Central Administration console you go.
Head to the Operations tab and there you will find the option to change your content deployment settings and to set up deployment paths and jobs. In my Content Deployment Settings, I have configured my server to accept all incoming deployment jobs, and selected my server from the import and export server drop-downs. Worth a note - the temporary files entry on here specifies a local path for temporary storage of deployment data. I have read that you need to make sure this directory can be written to by your service account, so I added appropriate security settings to that path to make sure there would be no grumbles there.
Now, to set up some paths and jobs. I created a new path and selected my source application as the authoring site. Make sure you select the appropriate site collection - mine all use the root site collection, so this was a simple setting. The URL to your Central Administration application should be simple enough to enter, and you need to make sure you can connect to that application using the appropriate credentials. One of the benefits of a hacky dev environment is a central user account for all application pools. Again, this is a proof-of-concept. Select the destination web application and site collection, then decide on what to export - user names, other security information - the choice is yours depending on your configuration. I've set this up to only deploy role definitions. Click OK, and fingers crossed the first part is done.
If this works ok, you'll have a quick deploy job set up already. Try running that and pray for success (keep clicking on the Status column header to refresh the grid). If you get a fail, you may need to double-check some settings. And if you chose anything other than a blank site when you started out, don't blame me :) Now, bear in mind that this quick deploy doesn't deploy the content! This is a big thing I found - I was expecting it to have deployed everything - not so. If you browse to your site now it will look pretty empty, so you should now create a new job to deploy content from authoring to live.
Create a new content deployment job for that same path and set it to deploy the entire site collection, and deploy all content, including anything previously deployed. You may be able to run this with just deploying new content, but my first instinct was to deploy everything first time. Later on, create a job to deploy changed content and set it to run on a schedule if you like. Run the job, make a coffee, then come back and find that the whole thing has run perfectly... well, that's the theory, and I certainly hope it works for you. If not, there are a lot of resources out there with suggestions for how to make it run a bit more smoothly, and there's a great blog post from Andrew Connell with information on a couple of hotfixes that might help solve some issues.
I'm going to be doing a lot of work on a project that involves this configuration over the next few weeks, so I may write some more on this as and when I can. In the meantime, I'd like to thank Nebulae Voom, friendly SharePoint guru from the .NET group in Second Life, and SharePoint from twitter (The official tweetstream of the SharePoint product group) - while neither solved this for me, you helped my brain think the right way!