Synchronization Conflicts: Examples
This section provides examples of the types of conflict that can occur during each phase of synchronization and describes how you might resolve.
Role conflicts
A role conflict occurs when a role with the same name exist in both the local and remote systems.
During synchronization, all roles on the local system are created on the remote system and all roles on the remote system are created on the local system.
During a re-synchronization process, it is normal for many role conflicts to occur. This is because the first time the sync was run, all roles that were on the local system were created in the remote system and vice versa. This means that you can simply choose the Ignore action for most role conflicts during a re-sync.
Available actions for roles conflicts:
-
Ignore: Choose this option if you know both systems have the same roles
-
Rename Remote: If the two roles are not the same but both have the same name, you will have to rename the role on the remote system. Choosing this action will allow you to specify a new name for the role. Be sure to assign a unique role name.
Before sync | ||
---|---|---|
Local System | Remote System | Action |
BatchRole | Role with name "BatchRole" does not exist | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
Role with name "UserRole" does not exist | UserRole | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
EmployeeRole | EmployeeRole |
Rename Remote New name for EmployeeRole on the remote system: RemoteEmpRole |
AdminRole | AdminRole |
Ignore These roles are the same. |
After sync | |
---|---|
Local System | Remote System |
BatchRole | BatchRole |
UserRole | UserRole |
EmployeeRole |
RemoteEmpRole Note: The remote system shows the renamed role.
|
AdminRole | AdminRole |
Actor conflicts
An actor conflict occurs when an actor with the same ID exists on both the local system and remote systems but one of the following attributes is not the same:
-
lastname
-
firstname
-
email
-
roles assigned
The roles that are assigned to actors are merged regardless of which action was chosen.
During the synchronization, all actors on the local system are created on the remote system and all actors on the remote system are created on the local system.
During a re-synchronization process, you normally will not get any additional conflicts unless you change the user’s lastname, firstname or email in either LSF or LMRK.
When choosing which action to take be aware of that:
-
In LSF, aside from the actor ID the FirstName and LastName are required fields. In LMRK only the actor ID is required.
-
LSF does not check for correct email formatting but LMRK does. The roles that are assigned to actors are merged regardless of which action was chosen.
-
Update Local: Choose this action if the remote system has the correct data and you want to update the local system with this data.
-
Update Remote: Choose this action if the local system has the correct data and you want to update the remote system with this data.
Before sync | ||
---|---|---|
Local System | Remote System | Action |
ID: adoe Lastname: Doe Firstname: Anna Email: |
User with ID "adoe" does not exist | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
User with ID "bdoe" does not exist |
ID: bdoe Lastname: Doe Firstname: Bert Email: bdoe@yahoo.com |
No action required. This will not show up in the conflict resolution page since this is not a conflict. |
ID: cdoe Lastname: Doe Firstname: Cathy Email: code@yahoo.com |
ID: cdoe Lastname: Doe Firstname: Catherine Email: cathyoe@yahoo.com |
Update Remote |
ID: ddoe Lastname: Doe Firstname: Dan Email: |
ID: ddoe Lastname: Doe Firstname: Dan Email: ddoe@yahoo.com |
Update Local |
ID: edoe Lastname: Doe Firstname: Emily Email: |
ID: edoe Lastname: Firstname: Email: |
Update Remote Lastname and Firstname are required fields in LSF. Choosing Update Local will result in an error. |
ID: fdoe Lastname: Doe Firstname: Franz Email: fdoe |
ID: doe Lastname: Doe Firstname: Franz Email: |
Update Local Landmark checks for correct email format. Choosing Update Remote will result in an error because "fdoe" is not a valid email format. |
After sync | |
---|---|
Local System | Remote System |
ID: adoe Lastname: Doe Firstname: Anna Email: |
ID: adoe Lastname: Doe Firstname: Anna Email: |
ID: bdoe Lastname: Doe Firstname: Bert Email: bdoe@yahoo.com |
ID: bdoe Lastname: Doe Firstname: Bert Email: bdoe@yahoo.com |
ID: cdoe Lastname: Doe Firstname: Cathy Email: code@yahoo.com |
ID: cdoe Lastname: Doe Firstname: Cathy Email: code@yahoo.com |
ID: ddoe Lastname: Doe Firstname: Dan Email: ddoe@yahoo.com |
ID: ddoe Lastname: Doe Firstname: Dan Email: ddoe@yahoo.com |
ID: edoe Lastname: Doe Firstname: Emily Email: |
ID: edoe Lastname: Doe Firstname: Emily Email: |
ID: fdoe Lastname: Doe Firstname: Franz Email: |
ID: fdoe Lastname: Doe Firstname: Franz Email: |
Service conflicts
A service conflict occurs when a service with the same name exists in both the local and remote systems.
During the sync, all services on the local system are created in the remote system and all services on the remote system are created on the local system.
During a re-synchronization process, it is normal for many service conflicts to occur. This is because the first time the sync was run, all the services that were on the local system were created in the remote system and vice versa. This means that you can simply choose Ignore action for most service conflicts during a re-sync. If you are unsure, use the compare button to view the conflict.
Available actions for actors conflicts:
-
Ignore: Choose Ignore if you know that both services are the same.
-
Rename Remote: If the two services are not the same but both have the same name, you will have to rename the service on the remote system. Choosing this action will allow you to specify a new name for the service.
Before sync | ||
---|---|---|
Local System | Remote System | Action |
SSOP | Service with name "SSOP" does not exist | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
Service with name "SSOPV2" does not exist | SSOPV2 | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
TestService | TestService |
Rename Remote New name for TestService on the remote system: QAService |
ProdService | ProdService |
Ignore These services are the same. |
After sync | |
---|---|
Local System | Remote System |
SSOP | SSOP |
SSOPV2 | SSOPV2 |
TestService | TestService |
QAService |
QAService Note: The remote system shows the renamed service.
|
ProdService | ProdService |
Domain conflicts
A domain conflict occurs when a domain with the same name exists in both the local and remote systems.
During the sync, all domains on the local system are created in the remote system and all services on the remote system are created on the local system.
During a re-synchronization process, it is normal for many conflicts to occur. This is because the first time the sync was run, all domains that were on the local system were created in the remote system and vice versa. This means that you can simply choose Ignore action for most domain conflicts during a re-sync.
Available actions for domain conflicts:
-
Ignore: Choose Ignore if you know that both domains are the same.
-
Rename Remote: If the two domains are not the same but both have the same name, you will have to rename the domain on the remote system. Choosing this action will allow you to specify a new name for the domain.
Before sync | ||
---|---|---|
Local System | Remote System | Action |
LSFDomain | Domain with name "LSFDomain" does not exist | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
Domain with name "LMRKDomain" does not exist | LMRKDomain | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
TestDomain | TestDomain |
Rename Remote New name for TestDomain on the remote system: ExternalDomain |
InternalDomain | InternalDomain |
Ignore These domains are the same. |
After sync | |
---|---|
Local System | Remote System |
LSFDomain | LSFDomain |
LMRKDomain | LMRKDomain |
TestDomain | TestDomain |
ExternalDomain |
ExternalDomain Note: The remote system shows the renamed domain.
|
InternalDomain | InternalDomain |
Endpoint conflicts
An endpoint conflict occurs if an endpoint with the same FQDN, http port, and https port but with different domains exist on both the local and remote systems.
During the sync, all endpoints in the local system will be created on the remote system and all endpoints on the remote system will be created on the local system.
During a re-synchronization process, it is normal to receive many endpoint conflicts. This is because the first time the sync was run, all endpoints that were on the local system were created in the remote system and vice versa. This means that you can simply choose Ignore action for most domain conflicts during a re-sync.
Available actions for endpoint conflicts:
-
Ignore: Choose Ignore if you know that the endpoints are the same.
-
Update Local: Choose this action if the remote system has the correct data and you want to update the local system with this data.
-
Update Remote: You choose this action if the local system has the correct data and you want to update the local system with this data.
Before sync | ||
---|---|---|
Local System | Remote System | Action |
FQDN: lsf.lawson.com HttpPort: 1111 HttpsPort: 2222 Domain: LSFDomain |
Endpoint does not exist | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
Endpoint does not exist on this system |
FQDN: lmrk.lawson.com HttpPort: 1111 HttpsPort: 2222 Domain: LMRKDomain |
No action required. This will not show up in the conflict resolution page since this is not a conflict. Although an endpoint in the local system has the same http and https ports, the FQDN is different for both so they are treated as unique endpoints. |
FQDN: lsf.lawson.com HttpPort: 3333 HttpsPort: 4444 Domain: LSFDomain |
FQDN: lsf.lawson.com HttpPort: 3333 HttpsPort: 4444 Domain: LSFDomain |
No action required. This will not show up in the conflict resolution page since this is not a conflict. This domain is already in sync. |
FQDN: lsf.lawson.com HttpPort: 9898 HttpsPort: 9999 Domain: LMRKDomain |
FQDN: lsf.lawson.com HttpPort: 9898 HttpsPort: 9999 Domain: LSFDomain |
Update Local |
FQDN: lmrk.lawson.com HttpPort: 7878 HttpsPort: 8888 Domain: LMRKDomain |
FQDN: lmrk.lawson.com HttpPort: 7878 HttpsPort: 8888 Domain: LSFDomain |
Update Remote |
After sync | |
---|---|
Local System | Remote System |
FQDN: lsf.lawson.com HttpPort: 1111 HttpsPort: 2222 Domain: LSFDomain |
FQDN: lsf.lawson.com HttpPort: 1111 HttpsPort: 2222 Domain: LSFDomain |
FQDN: lmrk.lawson.com HttpPort: 1111 HttpsPort: 2222 Domain: LMRKDomain |
FQDN: lmrk.lawson.com HttpPort: 1111 HttpsPort: 2222 Domain: LMRKDomain |
FQDN: lsf.lawson.com HttpPort: 3333 HttpsPort: 4444 Domain: LSFDomain |
FQDN: lsf.lawson.com HttpPort: 3333 HttpsPort: 4444 Domain: LSFDomain |
FQDN: lsf.lawson.com HttpPort: 9898 HttpsPort: 9999 Domain: LSFDomain |
FQDN: lsf.lawson.com HttpPort: 9898 HttpsPort: 9999 Domain: LSFDomain |
FQDN: lmrk.lawson.com HttpPort: 7878 HttpsPort: 8888 Domain: LMRKDomain |
FQDN: lmrk.lawson.com HttpPort: 7878 HttpsPort: 8888 Domain: LMRKDomain |
Endpoint Group conflicts
An endpoint group conflict occurs if an endpoint group with the same name exists on both the local and remote systems.
During the synchronization, all endpoint groups on the local system will be created on the remote system and all endpoint groups on the remote system will be created on the local system.
During a re-synchronization process, it is normal to receive many endpoint group conflicts. This is because the first time the sync was run, all endpoint groups that were on the local system were created in the remote system and vice versa. This means that you can simply choose Ignore action for most domain conflicts during a re-sync.
Available actions for endpoint group conflicts:
-
Ignore: Choose Ignore if you know that the endpoint groups are the same.
-
Rename Remote: If both endpoint groups are not the same but ave the same name, you will have to rename the endpoint group on the remote system. Choosing this action will allow you to specify a new name for the endpoint group.
Before sync | ||
---|---|---|
Local System | Remote System | Action |
LSFHepGrp | HEP group with name "LSFHepGrp" does not exist. | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
HEP group with name "LMRKHepGrp" does not exist. | LMRKHepGrp | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
InternalHepGrp | InternalHepGrp |
Rename Remote New name for hte InternalHepGrp on th remote system: LMRKIntenralHepGrp |
ExternalHepGrp | ExternalHepGrp |
Ignore These HEP groups are the same. |
After sync | |
---|---|
Local System | Remote System |
LSFHepGrp | LSFHEPGrp |
LMRKHepGrp | LMRKHepGrp |
InternalHepGrp | InternalHepGrp |
LMRKInternalHepGrp |
LMRKInternalHepGrp Note: The renamed HEP group.
|
ExternalHepGrp | ExternalHepGrp |
Identity conflicts
The full sync does not have the ability to remove roles from users.
During the synchronization, all identities on the local system are created on the remote system and all identities on the remote system are created on the local system.
During a Resync process, you normally will not get any additional conflicts unless you change the identity or identity assignment in either LSF or LMRK.
Available actions for identities conflicts:
-
Update Local: Choose this action if the remote system has the correct data and you want to update the local system with this data.
-
Update Remote: Choose this action if the local system has the correct data and you want to update the remote system with this data.
Before sync | ||
---|---|---|
Local System | Remote System | Action |
Service: SSOP Identity User: anna Actor: adoe |
Identity does not exist | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
Identity does not exist |
Service: SSOPV2 Identity User: bert Actor: bdoe |
No action required. This will not show up in the conflict resolution page since this is not a conflict. |
Service: OSService Identity User: lawson Actor: adoe |
Service: OSService Identity User: lawson Actor: adoe |
No action required. This will not show up in the conflict resolution page since this is not a conflict. Although the identity is assigned to multiple actors, this will NOT be flagged as a conflict because this identity is for an OS service. |
Service: TestService Identity User: qaUser Actor: ddoe |
Service: TestService Identity User: qaUser Actor: fdoe |
Update Local The identity qaUser is assigned to multiple actors. This will be flagged as a conflict because this is an identity for non-OS service. |
Service: TestService Identity User: cathy Actor: cdoe |
Service: TestService Identity User: catherine Actor: cdoe |
Update Remote Only one identity can be assigned to an actor. The administrator will need to choose whether the actor will use the identity "cathy" or "catherine". |
After sync | |
---|---|
Local System | Remote System |
Service: SSOP Identity User: anna Actor: adoe |
Service: SSOP Identity User: anna Actor: adoe |
Service: SSOPV2 Identity User: bert Actor: bdoe |
Service: SSOPV2 Identity User: bert Actor: bdoe |
Service: TestService Identity User: cathy Actor: cdoe |
Service: TestService Identity User: cathy Actor: cdoe |
Service: OSService Identity User: lawson Actor: adoe |
Service: OSService Identity User: lawson Actor: adoe |
Service: TestService Identity User: qaUser Actor: fdoe |
Service: TestService Identity User: qaUser Actor: fdoe Note: Choosing "Update Local" means the identity qaUser is assigned to "fdoe".
|
Service: TestService Identity User: cathy Actor: cdoe |
Service: TestService Identity User: catherine Actor: cdoe Note: Choosing "Update Remote" means the actor "cdoe" will be assigned the identity "cathy".
|
Conflicts that can occur when setting primary service identities
When the primary authentication service is set (SetPAS), a synchronization is run on identities. This sync analyzes identities between the current primary service (source) and the new primary service (target) and then moves all identities from the target to the source.
An identity conflict during synchronization occurs when an actor contains an identity on both the source and target services.
Available actions for primary service change identities conflicts:
-
Override: Choose this action if you want to "Override the Identity in the New PAS" (Primary Authentication Service). This means you want to continue to use the identity for the "Current PAS".
-
Retain: Choose this action if you want to retain the identity in the New PAS. This means you want to use the identity in the "New PAS".
When you run an additional SetPAS procedure (after you have already performed SetPAS at least one time), you normally will not get any conflicts unless you change the identity or identity assignment on either local or remote system.
Example:
Current Primary Service: SSOPV2
New Primary Service: SSOP
All identities under SSOPV2 will be moved to SSOP. Moving of identities will be done in both Local and Remote Systems. Conflicts will be identified if an actor contains an identity in both SSOPV2 and SSOP service.
Before sync | ||
---|---|---|
Local System | Remote System | Action |
Actor "adoe" does not have an identity for SSOPV2 |
Service: SSOP Identity User: anna Actor: adoe |
No action required. This will not show up in the conflict resolution page since this is not a conflict. |
Service: SSOPV2 Identity User: bert Actor: bdoe |
Actor "bdoe" does not have an identity for SSOP | No action required. This will not show up in the conflict resolution page since this is not a conflict. |
Service: SSOPV2 Identity User: cathy Actor: cdoe |
Service: SSOP Identity User: catherine Actor: cdoe |
Override identity in new primary service. The actor "cdoe" has different identities in both SSOPV2 and SSOP. Choosing this action means you want the actor "cdoe" to override the identity in the new primary service (SSOP) and use the identity in the current primary service (SSOPV2) which is "cathy". |
Service: SSOPV2 Identity User: dan Actor: ddoe |
Service: SSOP Identity User: dan Actor: ddoe |
Retain identity in new primary service. The actor "ddoe" has different identities in both SSOPV2 and SSOP. Choosing this action means you want the actor "ddoe" to use the identity in the new primary service (SSOP) which is "danny". |
On both the local and remote systems, only the selected primary service will contain identities and these are the identities that the user will use when logging into the systems.
After sync | |
---|---|
Current primary service (SSOPV2) | New primary service (SSOP) |
Service: SSOP Identity User: anna Actor: adoe |
|
Service: SSOP Identity User: bert Actor: bdoe |
|
Service: SSOP Identity User: cathy Actor: cdoe The actor "cdoe" will use the identity "cathy" when logging in. |
|
Service: SSOP Identity User: danny Actor: ddoe The actor "ddoe" will use the identity "danny" when logging in. |