I sometimes come across customers that would like to relay email through their Exchange Sever from external clients and maybe use a different sending address.  Here is how I configure this. First, we will create a new receive connector via the Exchange Powershell. To do so, open up the Exchange Management Shell (powershell) Once this loads, use the following command New-ReceiveConnector -Name ‘ExternalRelay’ -Usage ‘Client’ -RemoteIPRanges ’0.0.0.0-255.255.255.255′ -Server ‘SERVER’ Here is an example: Now we have created the Receive Connector, and you will see this in the Exchange Management Console. Let’s check our work, even though it was only one line of text Now we can verify the network, authentication, and permission groups settings to see how a Client receive connector has been configured. If you go to the properties, you will see that it’s listening on port 587 , that it has enabled Basic authentication over TLS, and that it is only allowing Exchange Users (Authenticated Users) to connect. You will see all of this by looking at the connector in the Exchange Management Console. NOTE: Make sure that port 587 is open in your firewall or this will not work for external users Further inspection of the AD permissions on the receive connector show that authenticated users have the ms-Exch-SMTP-Accept-Any-Recipient right. This is the correct relay permission and you should never have it be owned by anonymous users. You can view and verify this by running the following powershell command: Get-ADPermission “ExternalRelay” | where {$_.ExtendedRights -match “ms-Exch-SMTP-Accept-Any-Recipient”} | fl You will see the output looking like: If it says under user “NT AUTHORITYANONYMOUS” then you have an open relay. Stop and delete the connector! Next, we need to set some additional parameters to make this work. To allow the authenticated user to be able to send email with a different address, we will use the following powershell command   Get-ReceiveConnector ExternalRelay | add-ADPermission -User “NT AUTHORITYAuthenticated Users”-ExtendedRights “ms-Exch-SMTP-Accept-Any-sender” looking like: If you are running an SBS 2008 or SBS 2011 server, this also applies: If you have successfully run the Internet Address Management Wizard from the SBS Console, then your Exchange certificate for TLS has already been installed and configured. You can verify this by running the Get-ExchangeCertificate commandlet and find the certificate with your external DNS domain name. The certificate will have IPWS listed under Services, which stands for IMAP, POP, Web and SMTP respectively.   At this point, make sure that your Client receive connector is configured with the same FQDN that is listed in the subject of your Exchange certificate. This will be displayed in the banner: Once all of this is done, you are ready to setup Outlook, Outlook Express, Windows Mail, etc. Important points here are: The client machine must trust both the Exchange certificate and the Root CA in which it was created from. A good test is to open IE on the client and browse OWA to see if you get the certificate warning(s). You must configure the mail client to connect on port 587 and to send the proper credentials for authentication. The server requires a TLS connection, you must specify this in the mail client   Some of this information in this blog was obtained from the SBS Blog team at  http://blogs.technet.com/b/sbs/archive/2008/09/18/how-to-configure-trusted-smtp-relay-in-exchange-on-sbs-2008.aspx Lyle Epstein Kortek Solutions Lyle Epstein’s Systems Engineer Blog

Tonight I had a customer informing me that since we installed the latest rollup for Exchange 2010 SP1 their BlackBerry were sending duplicate messages. After doing some research into the issue, I came across this blog http://blogs.technet.com/b/exchange/archive/2011/03/14/exchange-2010-sp1-rollup-3-and-blackberrys-sending-duplicate-messages.aspx For the time being, hold off on installing RU3 until Microsoft get’s this fixed. In fact, they state that they have pulled the Rollup for now. I suggest looking at the EHLO link above to confirm when it is fixed.

I am currently working on planning out a new data center that will be running Exchange 2010. I found a great tool from the Exchange team called Exchange 2010 Mailbox Server Role Requirements Calculator which is quite powerful. An updated version of this tool can also be located at http://blogs.technet.com/b/exchange/archive/2010/01/22/3409223.aspx

Today my wife updated her Sprint Samsung Transform phone with the latest Android OS. I have been waiting for Sprint to push out this update as I found a very strange bug in the base OS that was shipped with the phone in November 2010. For a list of versions and when they were shipped, see http://socialcompare.com/en/comparison/android-versions-comparison The bug I identified was if you setup the phone to Sync with the Exchange server, in this case Exchange 2010 SP1 RU2 and then proceed to select a contact, change the picture of the contact to one that is on the device, and re-sync, you will now see the new picture in your Outlook. That is how it is suppose to work. The bug part comes in when you now edit that contact, say change the phone number or email address. Now sync the device, and you will notice the data doesn’t change in the device. The only way to fix it from my testing was to delete the contact via the phone. Once you do that, re-sync, and it will be gone from the Contacts in Outlook. Now go into your deleted items and you will see the contact. Move it back to your contacts, and re-sync the phone, and the contact is now correct on the phone. But if you make a change to the contact again, you will run into the same issue. This was VERY annoying! I had found an update to the Android OS but it required rooting the phone, something I didn’t want to do. After the update came down today from Sprint, I retried my issue, and the bug has now been fixed. Other things I noticed in the new update is the support for OOF, or Out of Office. That is a nice touch as Active Sync get’s more aligned to the features in Exchange 2010 and EAS. I also noticed that the new update now enforces Active Sync’s security policies, including requiring a device password. Now we wait for Microsoft’s own Windows Phone 7 to start supporting more Exchange EAS policies. If you are interested in knowing more about EAS, here is a chart by Marco Nielsen