Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 1

re: Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 1

Stu Fox — Wed, 07 Jul 2004 21:40:00 GMT

Here's a question. Why does the RUS fail in an environment where it can't find a particular address extension, even though the policies it's trying to apply don't even refer to that address extension? I've seen this in a mixed mode org where one of the 5.5 sites has the Rightfax proxy generator, and the RUS won't run until you copy the dll to the machine running the RUS. In this case I didn't actually have access to the machine so I had to get a remote administrator to email me the file. Hassle.

re: Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 1

Nino Bilic — Wed, 07 Jul 2004 22:20:00 GMT

Well,

The trick here really is - how do you tell the RUS that it is not supposed to ever apply a specific policy?

In current design, you can not really tell a specific RUS that it should apply a specific policy but never some other policy... if the address generator is installed on the 5.5 server, it will be added to 5.5 Site Addressing - and therefore will replicate into a policy on the Exchange 200x side. Seeing that the RUS can not know that it will not have to (at some point) apply a specific policy that is available, that is why there are problems if all address generators are not available. Hope that helps understand it?

re: Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 1

Stu Fox — Sun, 11 Jul 2004 22:40:00 GMT

Fair enough, but why have it fail totally? Why not apply addresses it can do something about and log an event saying "I couldn't apply this address type because...". That would certainly make it more useful and at least allow it to continue working to a certain extent.

re: Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 1

Bill Long — Mon, 12 Jul 2004 17:44:00 GMT

Having the RUS continue and just not stamp the addresses corresponding to the missing DLL is an idea that's been brought up, but since the problem is well documented, easy to identify, and easy to fix (unless you can't get access to the machine with the DLL on it), it's hard to justify making a hotfix to change the behavior, since changing the RUS to work this way runs the risk of destabilizing working code. They're keeping this in mind for the future, though.

re: Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 1

Raveendran Chinnasamy — Thu, 15 Jul 2004 18:36:00 GMT

We always have problems with RUS. Often resolved with just reboot of DC/Exchange servers( native /Singel forest/single domain /20000 user objects ). We contacted PSS and they are not able to help with event ids 8011.To resolve the issue nowadays we are just stick with reboot.
Raveendran@gmail.com

Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 2

You Had Me At EHLO... — Thu, 15 Jul 2004 21:48:00 GMT

re: Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 1

Bill Long — Thu, 15 Jul 2004 21:11:00 GMT

If a reboot is fixing the problem, the most likely scenario is that an intermittent network problem is causing the RUS to hang in an LDAP query. You can determine if this is the case by closely watching the logging and looking for the 8011 and the corresponding 8012's (see Part 2, which was posted today).

The way I typically troubleshoot this is I start a netmon capture with the filter set to Exchange <-> DC, and then cycle the System Attendant. Then I just let the netmon run. Periodically, we'll create a test user and see if he gets stamped. As soon as we notice the RUS is no longer stamping, we stop the netmon capture. Then, I use the app log to see when it last queried against the domain (looking for the 8011 and 8012s), and zero in on that time in the netmon. In the netmon you can follow the TCP conversation and see why it hung.

In one recent case I worked on, this was due to the switch that the DC and the Exchange server were plugged into. We would see a bizarre series of frames where Exchange was acknowledging a particular packet and the DC kept retransmitting an older packet, causing the TCP conversation to fall apart. We changed the switch from autodetect to 100 full duplex, our TCP problems were gone, and the RUS was happy.

It should not be necessary to reboot regularly to keep your RUS working. I'm not familiar with your particular case, but it sounds like your issue can certainly be resolved. I would encourage you to reopen the case with PSS and ask for further analysis of the problem. Point them to this blog or tell 'em to shoot me an email. :-)

Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 4 (last part)

You Had Me At EHLO... — Tue, 27 Jul 2004 20:30:00 GMT

Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 2

You Had Me At EHLO... — Wed, 24 Nov 2004 03:34:00 GMT

Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 4 (last part)

You Had Me At EHLO... — Thu, 20 Jan 2005 03:34:00 GMT

Troubleshooting the Recipient Update Service (RUS) using Event Logs - Part 3

You Had Me At EHLO... — Thu, 20 Jan 2005 03:35:00 GMT

Recipient Update Service en Exchange 2000 y Exchange 2003 - Part II

Latin America Support Team Blog — Sat, 15 Apr 2006 00:36:41 GMT

&nbsp;

Recipient Update Service en Exchange 2000 y Exchange 2003
Parte II – Seguimiento de problemas...