We help IT Professionals succeed at work.

Getting Operation Failed: 80004005 trying to update RUS Enterprise Configuration

I am having an issue updating the config of my RUS Enterprise Configuration object in Exchange. I can change the Exchange server but not the Domain Controller. When I click the browse button, it appears to be trying, and then I get a popup message indicating Operation Failed. ID: 80004005. Now I have already read through MS article 821465 and everything appears to be OK as far as permissions and the serverReference attribute. One thing I will say is the DC its pointing to was dcpromo'd down to a member server a few days ago, but when we realized there was a dependency in Exchange, we promoted it back up to a DC so it should be back to where it was. Of course, I have no idea if this problem was there before the DC demotion because I never tried to update this particular RUS until now. Has this happened to anyone else. I am thinking maybe I need to reboot the Exchange server but I have 4. Since this is at the Org level, which one do I reboot. There is nothing in the Event logs and all the searchng I have done points back to the above MS article.
Comment
Watch Question

CERTIFIED EXPERT
Top Expert 2008

Commented:
Is that DC that you DCPromo'd also a GC now?

Author

Commented:
Yes. Its also a GC just like it was before.

Author

Commented:
OK. No response. So let me ask this. Is it possible to simply point the RUS to another DC using ADSIEdit.
I found an attribute on the RUS object called msExchServer1NetworkAddress that points to the current DC in our environment. It looks like all I need to  do is modify this to point to another DC. The object I am talking about can be found in ADSIEdit under Configuration > Services > Microsoft Exchange > Org name> Address List Container > Recipient Update Service > Recipient Update Service (Enterprise Configuration) If you look at the properties of this object, you will see the attribute I am talking about. Just wondered if thats all there is to it.

Author

Commented:
Does anyone know what this particular RUS does and how would I test it just to make sure its doing what its supposed to? I read a technet article about this and it said the Enterprise Configuration is responsible for updating the email address of the System Attendant and MTA but I am not sure what they mean by that.
CERTIFIED EXPERT
Top Expert 2008

Commented:
Sorry, this one slipped through the cracks;

This is an explanation of what the RUS does -> http://www.msexchange.org/articles/Troubleshooting-Exchange-Recipient-Update-Service-RUS.html

The best test is to create a user called "a test" and see if they are assigned an email address automatically (use a name that starts with A, it is alphabetical)

Modifying the RUS attributes with ADSIEdit is *probably* going to be unsupported, but I don't know.  Before you go down that path, I would be calling MS PSS and paying their fee - $400 for a question before doing it is better than x amount of hours of downtime.

Author

Commented:
I saw that article. I tested the modification in a VM environment with no issue, but maybe I should contact MS support. Because the DC in question is a VM, they may not be supportive however.

Author

Commented:
Also, I have several RUS components. One for each Domain and they work just fine populating email addresses they way they are supposed to. It appears the RUS for the Enterprise is also working because I turned up logging and there are no errors in the app log when I force an update, but the RUS for the enterprise I don't think has anything to do with user email addresses.
CERTIFIED EXPERT
Top Expert 2008

Commented:
OK good, if you are in a VM environment then your backup and recovery options are a little better - if you have tested it, and it works, then I would consider doing it, but I am a bit of a cowboy like that...

As for the Enterprise RUS - test that by creating a mail enabled public folder (and see if it gets an address).

http://support.microsoft.com/kb/822794
"The Enterprise RUS only stamps objects in the Configuration naming context, such as public folder stores and site replication services. The Enterprise RUS does not stamp objects such as users, groups, contacts, or public folders."

Author

Commented:
Thanks for this article. Have not seen this one before. A little confused with your last post. You said test by creating a mail enabled Public Folder, but then state the Enterprise RUS does not stamp Public Folders with email addresses.
CERTIFIED EXPERT
Top Expert 2008
Commented:
Lol, I can see how that was confusing - I misread the article :)

There is no real way of testing the Enterprise RUS Policy, unless you have the enterprise version of exchange and want to create a new PF store.

Author

Commented:
Well, I do have the Enterprise version and I have a DR server to play with. I can create another Public Folder Store on this server, but, what do I check for after creating it. There is no email addresses tab on the properties of the Public Folder Store.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.