About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.

2011/10/21

RUS Issue #2 (ExBPA)

Situation

First off, you would think the ExBPA would be smart enough to recognize this situation and not behave this way, but that is a subject for another post.

The E2010 Exchange Best Practice Analyzer (ExBPA) throws the following error when run against a new E2010 install.  The environment originally came from E2003, then moved to E2007, now moving to E2010.  The E2003 was removed 18 months or so ago…

image

This link from the ExBPA gives some great information provided you are still running E2003.  If you are not, what to do?

There are a variety of resources in google-land that will advise you to just ignore the errors messages.  As an example, here is one with an Exchange MVP advising against doing some drastic like removing whole containers from the configuration.  Sembee gives great advice.  But what if you don’t like seeing those Red X notices?  What if your boss does not like them and judges you accordingly?  Let’s see if we can do something non-invasive to remove this specific error.

The Fix (NOT SUPPORTED!)

Read the first link above, and then attempt to digest this part of it:

The Microsoft Exchange Server Analyzer Tool queries the Active Directory directory service to determine the value of the msExchAddressListServiceLink attribute for each Recipient Update Service object in the directory. The msExchAddressListServiceLink attribute is a link from the address list service to the Exchange Server computer it should be running on. If the Exchange Analyzer finds that there is no msExchAddressListServiceLink attribute for a Recipient Update Service object, or the msExchAddressListServiceLink attribute value for the object is not populated, an error is displayed.

How does this translate into reality?  From an ADSIedit viewpoint, we can see the RUS container is very much still in AD (the reference environment came from E2003). In this view, I am showing the actual attribute on the domain RUS object.

image

So, this is why the ExBPA is pitching the error.  What do we put in there to remove the error.  Well, the name of an Exchange server of course!  But what format and where can I get it? 

Here is the format:

CN=E2010,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com

And here is where you can get this wonderful data string:

image

Plug this into the attribute of the RUS object as shown:

image

Depending on which DC/GC you are talking to with what server, wait 15 minutes or so for replication to occur, then re-run ExBPA.  The RUS error will now be gone.  Please note that this is visual only, E2010 ignores the RUS containers as RUS no longer exists in E2010 (E2007 for that matter).

This is NOT a supported fix.  I suppose if you are still running E2003 and get this error, you could use this to resolve that instance as it illustrates the guidance of the recommended fix.

The Fix #2 (Supported)

After doing a bit more research, and reviewing exactly how to remove E2003, I realized that removing the RUS is part of the process:

  1. Perform the following steps to delete the domain Recipient Update Services:

    1. In Exchange 2003 or Exchange 2000 System Manager, expand Recipients, and then select Recipient Update Services.
    2. Right-click each domain Recipient Update Service, and then select Delete.
    3. Click Yes.
  2. You will not be able to delete the Recipient Update Service (Enterprise Configuration) by using Exchange 2003 or Exchange 2000 System Manager. Perform the following steps to delete the Recipient Update Service (Enterprise Configuration) by using ADSI Edit (AdsiEdit.msc):

    1. Open ADSI Edit, expand Configuration, expand CN=Configuration,CN=<domain>, expand CN=Services, expand CN=Microsoft Exchange, expand CN=<Exchange organization name>, expand CN=Address Lists Container, and then select CN=Recipient Update Services.
    2. In the result pane, right-click Recipient Update Service (Enterprise Configuration), click Delete, and then click Yes to confirm the deletion.

YMMV

No comments:

AudioCodes 400HD firmware v3.04

Those fine folks (and apparently busy beavers) at AudioCodes have popped a new IP Phone firmware release out into the wild. Brings a nice ne...