Is a new SID applied when sysprep-ping a Windows image or when deploying?

From : Sysprep Command-Line Syntax

/generalize Prepares the Windows installation to be imaged. If this option is specified, all unique system information is removed from the Windows installation. The security ID (SID) resets, any system restore points are cleared, and event logs are deleted.

The next time the computer starts, the specialize configuration pass runs. A new security ID (SID) is created, and the clock for Windows activation resets, if the clock has not already been reset three times.

This means on the next reboot (after deployment!) your SID will reset. Your machines will get 10 different SID's, yes.

There are multiple kinds of SID's. Users have SID's, Machine's have SID's, there are local SID's, Domain SID's, and there are "special" SID's, but the SID's you are talking about (MachineSID) is the same in sysprep and NewSID (Machine SID)

There are Machine SIDs, Service SIDs, Domain SIDs, and User SIDs. NewSID and sysprep /generalize only reset Machine SIDs. Yes, those are the same Machine SIDs, and yes, sysprep changes the Machine SID after deployment.

However, changing Machine SIDs is not necessary. According to this blog entry on TechNet by Mark Russinovich:

So is having multiple computers with the same machine SID a problem? The only way it would be is if Windows ever references the machine SIDs of other computers. For example, if when you connected to a remote system, the local machine SID was transmitted to the remote one and used in permissions checks, duplicate SIDs would pose a security problem because the remote system wouldn’t be able to distinguish the SID of the inbound remote account from a local account with the same SID (where the SIDs of both accounts have the same machine SID as their base and the same RID). However as we reviewed, Windows doesn’t allow you to authenticate to another computer using an account known only to the local computer. Instead, you have to specify credentials for either an account local to the remote system or to a Domain account for a Domain the remote computer trusts. The remote computer retrieves the SIDs for a local account from its own Security Accounts Database (SAM) and for a Domain account from the Active Directory database on a Domain Controller (DC). The remote computer never references the machine SID of the connecting computer.

In other words, it’s not the SID that ultimately gates access to a computer, but an account’s user name and password: simply knowing the SID of an account on a remote system doesn’t allow you access to the computer or any resources on it. As further evidence that a SID isn’t sufficient, remember that built-in accounts like the Local System account have the same SID on every computer, something that would be a major security hole if it was.

ThatGraemeGuy here on Server Fault agrees with me.

Seriously, you don't need NewSID. Microsoft has retired NewSID on the grounds that it's not necessary. The NewSID download page says, "Note: NewSID has been retired and is no longer available for download. Please see Mark Russinovich’s blog post: NewSID Retirement and the Machine SID Duplication Myth."

Sysprep still gets rid of things like those pesky registry keys that interfere with WSUS, however. Microsoft does not support cloning without sysprep.

I presume from your question that you're hoping to get rid of that NewSID step (yay!) by saying that sysprep /generalize performs the same function. This is true, but hopefully pointing out that NewSID has been unsupported since 2009 will also help you get rid of that unnecessary step in your rollout process.

After deployment. Common sense. If the generalization would generatea new SID, you would have to repeat it on every machine - which would sort of totally go against what the word means.

After generalize the machine is generalized and then reinitializes on next boot. So you shut down, deploy and then - the deployed images boots and generates a new SID pe machine.