ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.
Commander
Commander
2862 views

Discarding transaction because entry was deleted

Hi All,

I have an issue with the Google Apps driver. Here is the entirety of the level 3 trace when I try to migrate an account using iManager and the Google Apps driver.

[09/07/18 09:47:09.218]:IDM4GMAIL ST:Start transaction.
[09/07/18 09:47:09.218]:IDM4GMAIL ST:Discarding transaction because entry was deleted.


The association state on the user object changes to Migrate from Processed.

If I delete the association from the user account, I can migrate the account successfully and a match is found. Any subsequent migrate results in the condition above. This is happening to multiple user objects.

Google driver is version 4.1.1.5.

Any advice appreciated.

Thanks
Adam
Labels (1)
0 Likes
28 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

On 9/14/2018 2:24 AM, keil0008 wrote:
>
> Thanks al_b. I have validated the object I'm using for testing on both
> servers. You are correct, both hold a replica. IDVPRD01 holds a master
> and IDVPRD02 holds a read / write of all partitions.
>
> It's worth noting that this problem appears to affect all user objects
> and not a select few.
>
> I have another driver which has the DirXML-Assocaiations configured in
> the driver filter and an event is triggered on this driver after the
> failed migrate on the AD driver.
>
> As you can see in the trace, the DirXML-Associations attribute of the
> user object is modified when triggering a migrate using a different
> driver.
>
>
> Code:
> --------------------
> <modify cached-time="20180914062036.967Z" class-name="User" event-id="IDVPRD01#20180914062036#3#1:11c5f417-0b5b-47ac-48a6-17f4c5115b0b" qualified-src-dn="O=PEOPLE\CN=a1999973" src-dn="\UOFAIDV\PEOPLE\a1999973" src-entry-id="186632" timestamp="1536906036#2">
> <association state="associated">a1999973</association>
> <modify-attr attr-name="DirXML-Associations">
> <remove-value>
> <value timestamp="1536905528#2" type="structured">
> <component name="nameSpace">4</component>
> <component name="volume">\UOFAIDV\RESOURCES\Driver Set\IDM4 Active Directory Driver</component>
> <component name="path">8ed750ac88633345b7982d89c345d7a9</component>
> </value>
> </remove-value>
> <add-value>
> <value timestamp="1536906036#2" type="structured">
> <component name="nameSpace">3</component>
> <component name="volume">\UOFAIDV\RESOURCES\Driver Set\IDM4 Active Directory Driver</component>
> <component name="path">8ed750ac88633345b7982d89c345d7a9</component>
> </value>
> </add-value>
> </modify-attr>
> </modify>
> --------------------


This is normal. The way a Migrate FROM IDV is triggered is by changing
the state (nameSpace component) of the current association (per driver)
from 1 to 3 or 4.


0 Likes
Commander
Commander

Just an update. I've raised a SR. Currently working through the issue with Support. Will post here with results.
0 Likes
Commander
Commander

So it seems the solution may be a trivial one but the cause is unknown. Support pointed out that we have different versions of IDM on each server. This is despite iManager showing versions being the same. Running dxcmd on the command line shows that the problem server is running IDM 4.5.0.0 whereas the properly functioning server is running 4.5.5.0.

Now I'm sure I'd upgraded both over time. So I went back through the logs and found that idvprd01 was indeed running 4.5.5.0 back in March this year. At which point the logs started showing 4.5.0.0 again. Looking at the .jar files on the server (dirxml.jar) etc they are showing as versions from 2014.

At the same time in March, I had deployed a new loopback driver but that was the only change of any significance. Anyone got any ideas on how I may have inadvertently reverted my IDM engine back to 4.5.0.0? Is this possible with deploying changes from Designer? I wouldn't have thought so. I'm now quite confused.

Regards
Adam
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

On 11/1/2018 7:04 PM, keil0008 wrote:
>
> So it seems the solution may be a trivial one but the cause is unknown.
> Support pointed out that we have different versions of IDM on each
> server. This is despite iManager showing versions being the same.
> Running dxcmd on the command line shows that the problem server is
> running IDM 4.5.0.0 whereas the properly functioning server is running
> 4.5.5.0.
>
> Now I'm sure I'd upgraded both over time. So I went back through the
> logs and found that idvprd01 was indeed running 4.5.5.0 back in March
> this year. At which point the logs started showing 4.5.0.0 again.
> Looking at the .jar files on the server (dirxml.jar) etc they are
> showing as versions from 2014.
>
> At the same time in March, I had deployed a new loopback driver but that
> was the only change of any significance. Anyone got any ideas on how I
> may have inadvertently reverted my IDM engine back to 4.5.0.0? Is this
> possible with deploying changes from Designer? I wouldn't have thought
> so. I'm now quite confused.


Engine is mostly dirxml.jar and the vrdim library.

Almost all the patches update the main JAR files. Designer could not do
this.

0 Likes
Commander
Commander

Hi All,

I just wanted to confirm that patching the IDM Engine to 4.5.5. (the version being reported in iManager but not the version of the .jar files) has resolved the issue. I appreciate everyone's help and comments.

Cheers
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.