Depending on the version or product you're using, there are several potential options.
It should be noted however that the agent must be stopped for this to work. As soon as the agent re-starts, those registry keys will be repopulated! So, to do this, you should stop the agent service (leave it set to automatic), remove these registry keys, and immediately follow standard procedures in GSS to capture the image without restarting the system in production OR restarting the service.
Any of the supported versions of DS 6.x will remove the GUID from the NS/SMP agent if capturing using the supported methods. The capture image task takes care of this for you by first removing the GUID from the agent and then running Microsoft's Sysprep tool, and then rebooting and capturing the image while in this state.
DS 7.x takes care of this when you run the Prepare for Image Capture task (which is run prior to capturing the image itself). This is the only supported method of capturing a disk image (as apposed to a backup image). The Prepare for Image Capture task takes care of this for you by first removing the GUID from the agent and then running Microsoft's Sysprep tool Unlike DS 6.9, you then need to run the Capture Image task separately (before a reboot to production), but the net effect is the same.
There are those who insist on running Sysprep manually and only using our engine/tools (Ghost and RDeploy) to capture and deploy the images.
At least one reason for this is that there is a Microsoft Technet article that indicates that the "appropriate" way to modify the default profile is to run Sysprep in Audit mode and then modify the default profile prior to image capture. Our built-in processes do not support this. The default profile can be modified in several other ways that are supported by our processes, but we acknowledge that those methods are not "as complete" as the one indicated by Microsoft. 99% of our customers have been satisfied with the other methods of modifying the default profile and we highly recommend trying our method first. If you are then still not satisfied and insist on doing things this way, you should consider a few things:
NOTE: If you are using DS 7.x and attempting this method, the Agent should be included and the keys removed manually. This is a very awkward and again unsupported way of doing things, but in order to synchronize with post-imaging processes, we recognize the need to have the agent installed. You could actually install the agent post imaging, or follow the KB on including the installer into the Unattend file, both of which would work, but both of which will delay any post-image processes / tasks you may have included in the job. We recognize this as a viable process, but do not recommend it or support it, other than in a best-effort mode.
This is both not supported by us and not supported by Microsoft. Some have found a single article published once-upon-a-time by a Microsoft employee who claims that Sysprep is not needed. This is incorrect! Every customer we have found who has done this has required several DAYS of support from Microsoft to clean up their directory. We will send you to Microsoft when you run into problems and we will not be able to help you with your Active Directory (we can help with duplicate GUIDS, but be warned, it can be messy). For imaging to work in ANY of our environments, Sysprep MUST be run in some method or manner.
The only exception to this is if you are taking a backup image of a single system and restoring ONLY to that system. As soon as an image is deployed to more than one system without Sysprep having been run first, it is in an unsupported state.