Allowing anonymous relay on Exchange 2007/2010 on connectors for programs to send via SMTP using your Mail servers and how to secure it for internal use only.

I was recently helping out a colleague at another school as they were having difficulty in a specialised application sending e-mails to external addresses.  After a bit of investigating we found that the send connector configured for internet e-mail wasn’t allowing anonymous connections to it (which is dangerous) but since this particular application didn’t allow us to specify authentication details we were forced to enable anonymous relay for this connector.

I will first show you the PowerShell command that we used to grant the anonymous permissions for the connector that you specify:

Get-ReceiveConnector “Default SBSSERVER” |
Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON”
-ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Now the above is really one command getting piped into another, so first of all we are specifying a particular receive connector, in this case Default SBSSERVER (change this to reflect the connector you want to modify).  We are then simply giving rights to anonymous logons (anyone) telling exchange to accept any recipient.

Now as for securing this connector, I would strongly suggest creating a separate one for this particular application (for example Sales App Connector).  We then add incoming IP restrictions, by editing the properties of the receive connector and adding entries to Receive mail from remote servers that have these IP addresses using either specific IP addresses or IP ranges in CIDR notation (so 10.1.0.0/16).

And there you have it, allowing anonymous connections / relay for internal applications to use.

When viewing Public Folders in Outlook you recieve the following error, Cannot expand the folder. Microsoft Exchange is not available.

So there have been quite a few posts about Exchange 2010 lately, I guess it’s mainly because that has been my focus for the last few months at my current job. So here is another one regarding an error message when you try to access public folders in outlook and how to fix it.

We were receiving calls that users were unable to access their public folders (which contains our global calendar) We were able to replicate the issue on our own accounts and received the following message.

Cannot expand the folder. Microsoft Exchange is not available.
Either there are network problems or the Exchange server is down
for maintenance. (/o=First Organization/ou=Exchange
Administrative Group (DOMAIN)/cn=Configuration/cn=Servers/cn=SERVERNAME

So we quickly remoted into our server which published our Public Folders, started the public folder tool and could see them all there, also running the get-publicfolder PowerShell cmdlet ran and listed all of the available public folders.  I then decided to take a quick look at the services which were running.

Public Folders are pushed to Outlook clients via Microsoft Exhcnage RPC Client Access Service, and if stopped you are unable to browse for public folders and get the above error.  In our case we were able to simply start the Service and the Public Folders were vieable in Outlook again.  I’ve heard of some isntances where the service no longer starts, if that is the case then you may need to check on permissions in the Bin folder inside Exchange.

 

Exchange Management Console not setting Permissions for Receive Connectors, fixing 5.7.1 Client was not authenticated issues with inbound e-mails

I was recently helping out on a migration from Exchange 2003 to Exchange 2010. The organisation was moving from two servers, a front end and back end server to four with two Mailbox servers running in a DAG (Database Availability Group) configuration and two Client Access Servers in an array and along with Hub Transport roles on the two CAS Servers.  They had been running their Exchange 2003 server for a while with routing connectors setup so the 2003 machine was handling all of the external mail and it had finally come time to decommission the old server and tell the firewall to push e-mail to the two new Hub Transport servers.

By default, Exchange 2010 sets up two connectors, one Client SERVERNAME and Default SERVERNAME with the default connector handling your external e-mail. For external servers to connect to the connector we need to enable anonymous authentication for the connector. So we went ahead, opened up the connector and ensured the Anonymous was ticked, clicked apply for good measure and then Ok. After using telnet to remotely connect to the e-mail server (via 3G) we recieved a Client not autenticated message after giving it the mail from command. So it was clear to me that the EMC (Exchange Management Console) wasn’t saving the authentication settings. So we resorted to powershell to configure the connector. I opened up the Exchange Management Shell and issued the following command

Get-ReceiveConnector -identity "Default SERVERNAME" | list

The list contained everything that was ticked bar the Anonymous that we had just enabled. So we decided to run a Set command to update the permissions list for the Default connector. I issued the following command with SERVERNAME being the name of the Exchange Server hosting the connector

Set-ReceiveConnector "Default SERVERNAME" -PermissionGroups:
"ExchangeUsers, ExchangeServers, ExchangeLegacyServers, AnonymousUsers"

We then ran the Get command again and the Anonymous entry was listed. So after a few minutes we used 3G and telnet to connect back into the e-mail server and after getting passed the mail from command we were relieved that the issued was resolved and that the servers could now accept incomming external e-mail. Microsoft have a good article up on Tech Net regarding Exchange 2010 and the Receive connectors (as well as the defaults Exchange setup creates) at the following article Understanding Receive Connectors.

Note that you won’t recieve this issue if your transport server is an Edge transport server as Exchange setup automatically configures the connectors for external connections.

How to reset the Search Index in Exchange 2010 Search

Exchange 2010 has a built in search feature which allows you to quickly search for emails in your mailbox using Outlook (when Online), OWA, Exchange ActiveSync etc. Exchange 2010 search indexes items as soon as they are received by the Mailbox Database. So if you’ve just transitioned from Exchange 2003 to 2010, Exchange may not index items brought over from the Exchange 2003 server to the Exchange 2010 server. You may find that users using Exchange search may have issues searching for items that were in their mailbox before the transition. For example, you will not be able to find a pre-transition item using instant search but will be able to find them using ‘Advanced Find’ in Outlook.

To fix this issue, you will have to reset the search index to force the Exchange Search service to index all items in the Mailbox Database including items that were moved to the database from Exchange 2003.

To reset the search index, open up the Exchange Management Shell navigate to %PROGRAMFILES%\Microsoft\Exchange Server\V14\Scripts and then run the following command:

.\ResetSearchIndex.ps1 -force -all

You should see output that resembles the following:

WARNING: Waiting for service 'Microsoft Exchange Search Indexer (MSExchangeSearch)' to finish stopping...
MSExchangeSearch service stopped
Deleting catalog for Mailbox Database
removing: <location of catalogue>

MSExchangeSearch service Started

To verify that the rebuilding of the index has completed do the following:

  1. Add this counter to Perfmon: MSExchange Search Indices\Full Crawl Mode Status. This counter will be 0 before running ResetSearchIndex, go to 1 during the full crawl and then back to 0 after ResetSearchIndex completes.
  2. You will receive MSExchange Search Indexer Event ID 109 when the full crawl begins.
  3. You will receive MSExchange Search Indexer Event ID 110 when the full crawl ends.

You should now be able to search for pre-transition items using Exchange search.

Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: “The name on the security certificate is invalid or does not match the name of the site”

I recently setup a SBS 2011 server for one of my clients. For several reasons we changed the external name to reach the server so instead of remote.fdqn.com.au it would be exchange.fqdn.com.au this worked perfectly once DNS settings propagated and allowed employees to connect externally via webmail or Outlook Anywhere (one of the best features in exchange/outlook hands down).  One issue which popped up after we installed the certificate for this new domain is that it was assigned to a different domain than what was configured in Exchange 2010, so internally clients would get security pop-ups everytime they would open their outlook.

The fix requires the use of the Exchange PowerShell Console, so fire it up. Once it loads, we first need to know what the name of our client access server is (for sites with multiple CAS servers you need to use this on the server doing your auto-discovery). So run Get-ClientAccessServer which will list all of the available CAS servers, for this instance it is SBSSERVER. So now that we have a list of servers and we know which is doing the auto-discovery we need to re-configure it to the new DNS entry.  Microsoft documentation doesn’t have ” ” quotation marks but it is important to have. So now run Set-ClientAccessServer with the following
Set-ClientAccessServer -Identity "SBSSERVER" -AutoDiscoverServiceInternalUri "https://exchange.fqdn.com.au/autodiscover/autodiscover.xml" with SBSSERVER being your CAS server and fqdn.com.au being the correct domain the certificate is assigned to.

Once the command runs successfully, re-open outlook and you will no longer be presented with a security warning everytime you are on the internal network.

Fixing the Outlook Web Access web application failed to initialize error

During the Christmas break many still wish to check their e-mails whilst enjoying their holidays.  One of my Clients who don’t use OWA are now taking the plunge and going to be checking their e-mail (great feature). With SBS 2008 (so Exchange 2007), OWA is enabled by default, so I thought there would be nothing that I needed to do, I was wrong.

After loading up OWA on the server and my laptop I received the following error:

The Outlook Web Access web application failed to initialize.
..
Exception
Exception type: Microsoft.Exchange.Clients.Owa.Core.OwaThemeManagerInitializationException

The fix I’ve worked out for this is to copy the original files in the theme directory from your installation media (x:\Setup\ServerRoles\ClientAccess\owa\version\) back into the OWA working directory.

The cause, I suspect a corrupt file, not too sure exactly and didn’t have much time to investigate seeing as it’s holiday time, but believe something had changed the theme configuration causing OWA to look elsewhere for theme files, I also have a suspicion that an update might have caused this, but can’t confirm.