If you see errors like that, you should never attempt to force replication. There is a reason that replication was stopped, and it is usually bad.
Do not use snapshots on a domain controller.
You don't want to be in a scenario where someone turned up an old copy of a dc and now you are replicating objects that should be gone. If you have not already done so, you should enable strict replication. Enabling this setting on a domain controller prevents lingering objects from being replicated inbound from an offending dc with a lingering object.
Running Domain Controllers in Hyper-V
From the article:
Strict replication consistency should be enabled on all domain controllers
When a domain controller in your Active Directory environment is disconnected from the replication topology for an extended period of time, all objects that are deleted from AD DS on all other domain controllers might remain on the disconnected domain controller. Such objects are called lingering objects. When this domain controller is reconnected to the replication topology, it acts as a source replication partner that has one or more objects that its destination replication partners no longer have. Problems occur when these lingering objects on the source domain controller are updated and these updates are sent by replication to the destination domain controllers. A destination domain controller can respond in one of two ways:
If the destination domain controller has strict replication
consistency enabled, it recognizes that it cannot update the object
(because the object does not exist), and it locally halts inbound
replication of the directory partition from that source domain
If the destination domain controller does not have strict
replication consistency enabled, it requests the full replica of the
updated object, which introduces a lingering object into the
An outdated domain controller can store lingering objects with no noticeable effect as long as an administrator, application, or service does not update the lingering object or attempt to create an object with the same name in the domain or with the same user principal name (UPN) in the forest. However, the existence of lingering objects can cause problems, especially if the object is a security principal. The following symptoms indicate that a domain controller has lingering objects:
A deleted user or group account remains in the global address list
(GAL) on computers running Microsoft Exchange Server. Therefore,
although the account name appears in the GAL, attempts to send e-mail
messages result in errors.
Multiple copies of an object appear in the object picker or GAL for
an object that should be unique in the forest. Duplicate objects
sometimes appear with altered names, causing confusion on directory
searches. For example, if the relative distinguished name (also known
as DN) of two objects cannot be resolved, conflict resolution appends
"*CNF:GUID" to the name, where * represents a reserved character, CNF
is a constant that indicates a conflict resolution, and GUID
represents the objectGUID attribute value.
E-mail messages are not delivered to a user whose Active Directory
account appears to be current. After an outdated domain controller or
global catalog server becomes reconnected, both instances of the user
object appear in the global catalog. Because both objects have the
same e-mail address, e-mail messages cannot be delivered.
A universal group that no longer exists continues to appear in a
user’s access token. Although the group no longer exists, if a user
account still has the group in its security token, the user might
have access to a resource that you intended to be unavailable to that
A new object or Exchange mailbox cannot be created, but you do not
see the object in AD DS. An error message reports that the object
Searches that use attributes of an existing object incorrectly find
multiple copies of an object of the same name. One object has been
deleted from the domain, but it remains in an isolated global catalog