If you create a content deployment path using the UI the EnableEventReceivers property of the path will be configure to "false".
If you create a content deployment path using powershell (New-SPContentDeploymentPath cmdlet) you can control whether the EnableEventReceivers property is configure to true or false using the -EventReceiversEnabled parameter. The default with Powershell is "true"!
This setting controls whether "after" events will fire during content deployment import or not. So the default when creating a content deployment path using the UI will be false which prevents executing of after events during import.
After events - especially asynchronous after events - can cause content deployment import to fail if these events are modifying content. The reason is that the update operations performed in asynchronouse after events are executed on a different thread than the import operation and this can cause update conflicts which can lead to exceptions during the import operation which might event cause content deployment to fail completely.
So it is highly adviced to keep the EnableEventReceivers setting configured to false.
That means if you are creating a content deployment path using powershell you should create it with the following syntax:
PS> New-SPContentDeploymentPath ... -EventReceiversEnabled:$false
To change the value of the EnableEventReceivers property after the path has been created you can use (e.g.) the following STSADM command:
STSADM -o editcontentdeploymentpath -pathname <pathname> -enableeventreceivers yes | no
Surprising to see an STSADM command being given as a recommended post-creation fix. Isn't STSADM being phased out? What would be the way to do this fix in powershell?
STSADM is still full supported in SP2010. The same command works for MOSS 2007 and 2010 - that's why I posted it. In addition the syntax with STSADM is much simpler than with powershell.