During a recent Exchange 2010 migration, we encountered issues with mail-enabled groups. At first we thought it was a SMTP related issue as no 2010 mailbox could send mail to any of the groups. The mail would just disappear. No NDR was delivered, it wasn’t in the queue, it simply vanished.
Because of this issue, we decided to go ahead and convert all the groups to Universal Mail-Enabled groups through the Exchange 2010 EMC. This is when we encountered a really strange error. The groups would not convert stating that the object had invalid characters in its SMTP address. After checking all the SMTP addresses, no invalid characters or malformed addresses could be found. It was actually stating a physical address was set as a SMTP address.
We opened ADSIEdit on the 2003 server and started scanning the attributes of the group object since this object was still a 2003 distribution list, again nothing could be found. We then thought about using the 2010 server for the ADSIedit since it was running on 2008 R2 and would show the new attributes added. Sure enough there was the attribute targetAddress populated with these physical addresses.
The fix was to clear this attribute across every mail-enabled group, then convert the group to an universal mail-enabled group. This also fixed the strange SMTP issue that we were initially experiencing.
NOTE: You can use a tool like ADModify.NET to perform bulk object attribute changes.
Download here: http://www.computerperformance.co.uk/w2k3/utilities/admodify.htm
Recently for a customer with a rather large exchange environment, we implemented multiple CAS Arrays across various sites in the network. The customer decided that all external access to OWA would come into once Internet entry point and that Array would proxy OWA request to the other CAS Arrays to retrieve the user mailbox.
We found out quickly that this does not work straight off. When you create a new CAS array in PowerShell, it repopulates all the local URLs for the web services, autodiscover, and RPC client access point with the new CAS Array name. Normally this is ideal as you want all connections to use the virtual array name and IP for redundancy purposes. However for CAS proxying, the local URL field for OWA on the remote CAS array servers cannot be populated with the array name, and instead must be populated with the internal FQDN for the individual servers. The external URL fields were empty as required.
FYI: For proxying to work, the external URL for OWA must be left blank otherwise Exchange will offer the user another URL to try rather than proxy the request.
I went ahead and changed these fields back to the server FQDNs and proxying started working. The reason the server FQDN is required is because Exchange uses Kerberos to pass authentication from one CAS to another. This field is primarily to let other Exchange servers know how to access this server through the internal network. The server will still answer request for OWA on other names, so the array name does still work from a web browser if an internal users opens a browser and browses to the array name for OWA. Exchange 2010 overcomes this by using the InternalNLBBypass attribute on the Client Access Server.
NOTE: For further instruction on setting up Proxying between CAS servers:
Proxying OWA across CAS Servers in different Active Directory Sites