Our Application (Oracle) is sending a batch of password resets to the AD via a Gateway machine connected to the AD Domain, and we are getting errors “The remote procedure call failed and did not execute. (Exception from HRESULT: 0x800706BF)” for some password resets. The occurrences of the error are irregular and happens to different random users. When we repeat the password reset operation for the same batch of users, they are processed successfully.
For one batch of 200 to 300 password reset that we submit, there could be about 20 of such RPC error. So far we are sending about 300 batches a day. And out of the 300 batches and almost 80% of the total batch will encounter such error.
We have checked with Oracle on the application side, and Oracle has reverted that this exception is from the AD and not from the Oracle Application and the Gateway software. The Gateway software is relying on the .NET functionality to contact the AD Domain Controller and execute functions there via Remote Procedure Calls, which has failed resulting in the error. Oracle also pointed out that it can be a load problem, and pointed us to a Microsoft Support article, http://support.microsoft.com/kb/960007/en-us . But the Windows Server version in the article is Windows Server 2003, while ours are using Windows Server 2008 (AD and Gateway machines).Is the Support Article still applicable to us? Or is there any settings within AD related to RPC connections that we can explore?
Another related observation is that when we rebooted the AD servers in our testing environment, the Application never encountered the above-mentioned error anymore, even when we pumped in a heavy load of password resets. Based on the observation above, we went ahead and rebooted the Production AD Servers. The Production Application managed to carry out the password resets without any errors for a period of time (approximately 15 hours with the calls spread out unevenly). But the errors came back after we restarted the service of the Gateway software. We tried to replicate this issue in our testing environment with the restarting of the Gateway software service but are unable to do so.
