Am able to reproduce this quite easily. Working on a fix.
Public description of bug: When re-provisioning with an activation key that has config deploy enabled, deployment will not happen because the re-activation key will have it disabled. Meaning that if you use two keys and one has deploy disabled, deployment will not happen for any of the keys. The auto generated keys that are used for re-provisioning, etc... do not have config deploy enabled, so this would make deployment not work even if only one activation key was specified by the user explicitly.
Fixed in spacewalk master in commit: fa77ce8f3e7badc2c5a445819c4a36aa281f8741 Basically now we just check to see if at least one of the activation keys has deploy enabled and schedule a deploy based off that.
# VERIFIED Applied a check against Satellites installed on RHEL4 and RHEL5 servers. The packages of brew build fixed the issue: spacewalk-java-0.5.44-65.el[4,5]sat spacewalk-backend-0.5.28-39.el[4,5]sat The test cases were based on registering systems (rhel4 & 5) through activation keys where one of the had disabled the config. deployment, and the other(s) had files to be deployed there. Registration did deployed all that files correctly.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0105.html