IMAP fails Exchange 2010

The Situation/Problem

E2007 migration to E2010.  Client needs IMAP to work for some high-powered clientele – this thing really needs to be SSL also.  E2007 is working as required, so E2010 should slam dunk this requirement, right?  Wrong!

Using a CASArray, so I configured a Thunderbird to go right at a CAS; nope….no good.

Changed the CAS to plaintextlogin (set-imapsettings –logintype plaintextlogin) – still no go.  Restarted services and spattered the sacred IT Chicken Blood on the nearest wall.  We were also seeing weird results in password types – Thunderbird will “probe” the target server for you – which resulted in Kerberos/GSSAPI as the auth choice – no, that is wrong, we want SSL and regular text password.  Double checked the e2007 server and determined that the e2010 IMAP was configured identically to the E2007.

Double checked that I had changed the IMAP SSL certificate on both CAS array members correctly… (Set-ImapSettings -server Server01 -X509CertificateName CertificateName01) - You do know about the x509 and IMAP SSL thing, right?

I just wasted 3 hours of my life over this….

The Fix

Then this was found on the forums…You must be kidding me! So here is what fixed my issue:

Open the file at

C:\program files\Microsoft\Exchange Server\V14\ClientAccess\PopImap\Microsoft.Exchange.Imap4.exe.config

I went to bottom of the <dependentAssembly> as shown here:

And inserted what was indicated.  Note that I have four lines of additions there, so what you see below is wrapped.  However, I have also cleverly given you an example to follow.  How thoughtful of me, eh?

<dependentAssembly>
<assemblyIdentity name="Microsoft.Exchange.Compliance" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<codeBase version="14.0.0.0" href="file:///C:\Program Files\Microsoft\Exchange Server\V14\bin\Microsoft.Exchange.Compliance.dll" />
</dependentAssembly>

After restarting the IMAP service on the CAS, everything worked ok.  Changed IMAP back to “SecureLogin” – still good.

Now, I did not try the POP fix as that was not needed for my client environment…

YMMV

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…

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.

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:

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

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

Empty Server Container in Exchange Configuration

edit 10.21.2011 1414 PST

Discovered that the ExBPA pitches an error if the servers container is missing.  D’oh!  Makes sense, sorta.  So I recreated the servers container in the First Administrative Group, with only the right type of container and name “Servers” – and that got rid of the error AANNDD the Exfolders access to the E2007 PF still works.  Nifty, eh?

Situation

While in the midst of an upgrade to  to 2010, we noticed that PF replication was bombing, ExFolders would not connect to the E2007 MBX – it threw a “recipient cannot be found” error -  and we were getting sporadic weirdness with the AddReplicaToPFRecursive.ps1 script.  We are using E2010 SP1 RU5.

Odd.

The client had previously removed Exchange 2003 in favor of Exchange 2007 some 18 months or so ago.  Exchange 2003 was removed and roles transferred, but the server was never uninstalled.  This left some remnants behind, as you would expect.  The server was removed from AD with ADSIEdit as part of an AD cleanup prior to deploying E2010.

The Fix

A little light reading here and then we followed the obvious indication to remove the empty “servers” container from the “First Administration Group” left over from Exchange 2003.  DO NOT remove the entire “First Administration Group” container, or any others left over from legacy versions.

Wala!  At least this was an easy one.  This was supposedly fixed with E2010 SP1 RU5, but apparently not.

YMMV

WNLB not working on local subnet

I ran into a very odd situation today.  Now, I know that there are those out there in cyberland who will have seen this before, but I have not, and on the odd chance that it might help you, I post this.

Situation

Doing WNLB, using VMWare hosting the WNLB servers.  Therefore, according to VMWare we should be using multicast.  So we did.  And swiftly noticed that other servers on the local VLAN could not find the WNLB address.  In fact, we noticed that the switch itself could not ping the WNLB address.  Devices on OTHER vlans could ping the WNLB.  WTF?!   Double-check the setup and redo the static ARP on the switch with this:

ARP 10.1.8.75 03bf.c0a8.0164 ARPA

Here is what it looked like AFTER we did the proper static ARP configuration on the switch…

Notice that a tracert is showing that even the simplest action is pushing the packets at the local gateway. 

We are using the following switch hardware:

Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500-ENTSERVICESK9-M), Version 12.2(54)SG, RELEASE SOFTWARE (fc3)

System image file is "bootflash:cat4500-entservicesk9-mz.122-54.SG.bin"

cisco WS-C4948-10GE (MPC8540) processor (revision 5) with 262144K bytes of memory.

Processor board ID FOX092101VW

The Fix

After going back and forth, including rebuilding the WNLB configuration, we realized we were dealing with a multicast capable switch.  Having nothing to lose, we did the following on the switch:

no ip multicast-routing

wala!  Now we can resolve the WNLB, ping it, tracert to it, and actually access services on the member servers.  Oddly, I had a colleague with a similar issue at the same time.  Their situation was resolved by using the arp IP MAC arpa command not only on the switch the WNLB connected to, but all distribution switches and the core of the stack also.

YMMV

RIP Steve Jobs

 

Steve Jobs is gone. Somebody who really made an impact in the world.  RIP.