• State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 93 subscribers
  • Views 3239 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DPRProjectionStartInfo_Synchronization running for over 24 Hours

jpatel
over 5 years ago

Hello All,

i have an issue with a Sync Process that has been running over 24 hours now.  Its our nightly sync from AD to OneIM.  we have it scheduled to run at night to bring in changes from one of our domain that is not managed thru oneIM.  i now have jobs from 2 days in Processing status... i am unable to end with any option... is there a way to kill these jobs as its holding other jobs on this particular job server?

One Identity Manager 8.0.1

All your help is greatly appreciated...

  • 0 over 5 years ago

    Hello,

    This is a domain that has never been synced?  Are you seeing that objects are being synced, as per the stdioprocessor log?

    I suggest to not kill this job as it can lead to data problems.

    Are the job server and database server meeting the system requirements?

    Thanks

  • 0 over 5 years ago in reply to Trevor Pike

    Hi Trevor,

    The domain was synced when we went live with the system and then set up a nightly sync a few weeks later.  This is our new domain that we will be moving to in near future.  This domain gets all the changes synced from the legacy domains that are managed thru OneIM.  Since its not a managed domain but we still provision to this domain thru oneIM, we want to make sure both systems are on same page on daily base...

    The Job servers meet the system requirement and able to communicate with out errors...  

  • 0 over 5 years ago

    Hi,

    Do you know what stage the sync is at?  JobQueueInfo > Job Server State > Job Queue > Right mouse click on the server/queue running the sync > Show in browser > Select the executing instance for the queue.

    You should see a line like: EXTERNAL / FullProjection / Executing .......... (Step X of X) ..... (N of N)

    What do you see?

    The reason I ask is that I have known syncs to take a long time to run when processing the group membership part of the sync.  This typically happens when the connector is looking for a particular GC and can't find it through DNS resolution.

    You will be able to see this for yourself if you run the sync again with trace level logging enabled.

    I have been able to resolve this by taking the IP address of the DC that is being used for the sync and entering that IP into the hosts file of the Job Server machine running the sync.

    There may be several lines in the hosts file all pointing at different DNS names e.g.

    1.2.3.4   GC1.domain.com

    1.2.3.4   GC2.domain.com

    etc.

    Maybe that helps.

    Barry.

  • 0 over 5 years ago in reply to Barry Jackson

    Barry, the Sync is at Step 6 of 23.

    EXTERNAL / FullProjection / Executing synchronization step (group) (Step 6 of 23)... (8191 of 9961) 
    EXTERNAL / FullProjection / Executing synchronization step (group) (Step 6 of 23)... (2050 of 9934) 

    I have added the entries to the host files on each of the job servers to be on safe side.

    is there a way for me to stop this current sync that is going on over 24 hours so i can restart it?

    Thanks in advance for your help.

    JP

  • 0 over 5 years ago in reply to jpatel

    Hi,

    <Insert Disclaimer Here>

    You can stop the current sync by stopping the service on the server that is running the sync.  This will in turn stop the StdioProcessor process that is doing the actual sync.

    (Remember to start the service again.)

    You should see the job go to Frozen state. This job should be finished with "End with error" so that the sync run date gets reset.

    But ........ if you have edited the hosts file on that same server and entered the correct IP address / Host name combinations the currently running sync should start to use those values.

    IF this is indeed the thing that is causing the slowness.  But we have not established that to be fact yet.

    Regards, Barry.