On the domain controller holding the PDC Emulator flexible single-master operations (FSMO) role in the forest root domain of your Active Directory forest should have an external-to-the-forest time source specified. On every other DC, time synchronization should be handled by the "Windows Time" service automatically. The DCs in each domain will sync with their domain's PDC Emulator role-holder, and the PDC Emulator role-holders in each domain will synchronize with the forest root PDC Emulator role-holder.
Per this document from Microsoft, be sure that you've disabled time synchronization in Host Integration Services.
Follow the procedure here to locate the DC in your domain that holds the PDC Emulator role. If you have a single-domain environment, then the PDC Emulator role-holder should have an external-to-the-forest time source configured.
Microsoft offers some more detailed guidance here, but the gist of setting an external-to-the-forest time source is using the "NET TIME" command, run on the forest root PDC Emulator role-holder, to specify the NTP server:
NET TIME /setsntp:server-name-here
Be sure that you can resolve the NTP server's name and that your firewall passes NTP (UDP port 123).
Reverse-engineering the script provides some hints about what it does, but ultimately the behavior that it attempts to invoke occurs inside the "black box" of the Active Directory domain controller code itself, so troubleshooting it is going to be difficult (unless you've got source code access to AD... >smile<).
Essentially, the script prepares the domain for an runSamUpgradeTasks call, then executes it. This involves appending a value to the otherWellKnownObjects attribute of the "CN=Server, CN=System. DC=domain..." object in the directory, then making an LDAP call to modify the runSamUpgradeTasks attribute. That's supposed to trigger the W2K8 domain controller to automatically create its default groups and users in the directory and, as such, cause the missing account and group to be created.
I'm a little dubious of the script because the runSamUpgradeTasks reference calls for the balue to be appended to otherWellKnownObjects attribute to end with "...:X", whereas the script doesn't do that. Even so, you indicate that the "IIS_IUSRS" group was created, so that means that, presumably, the W2K8 DC "got the message" and created groups.
This one is fairly perplexing, and I'd opt to go to Microsoft Product Support Services on it. You're not going to spend a lot of money, but given the strangeness of the behaviour you're seeing they're probably the best people on the planet to help you.
Best Answer
PS GetSid from Sysinternals will show if the SIDS match.
https://technet.microsoft.com/en-us/sysinternals/bb897417.aspx
If they match then that's the answer, if they are different then it won't show if it was cloned and sysprep'd, or changed via another method, or not a clone at all.
OTOH, MS provides a 180 day free trial, spin up a new 2012 vm, promote it and then remove AD from the possible clone. If the problems stop then there is at least one known solution.
[EDIT] Above is incorrect, thank you @RyanRies.
GetSID will return the same computer account SID for all DC's in a domain. In a non-cloned environment, 2 DC's in the same site: ADSIEdit will list different ObjectGUID's and the ObjectSID will match the GETSID + "-%4DifferentDigits%".