Exchange 2010 has the concept of internal and external URL's for various virtual directories for the Client Access Server (CAS role).

You must correctly specify values for URLs because of potential issues with certificates and discoverability of Exchange services for your users.

Here are commandlets in powershell to control all virtual directories URLs in Exchange 2010 (most or all of them are also will work in Exchange 2013):

I had a problem yesterday with my hybrid Exchange 2010 + 2013 installation. One user set up out-of-office message but it does not sending. Nor in internal domain neither external users.

• We have checked if user forwarding emails to some other users. All good forwarding was net set.
• Also we have disabled all Inbox rules (there was one rule that forwarded messages).
• We have tried to move mailbox to other database (in case corrupted data).
• We tried to disable and enable reply messaging.
• We have reviewed mail flow rules on transport servers.

All these actions didnt give answer.

Exchange 2010 and 2013 partially managed with Exchange Control Panel (ECP). It's a web-service running on IIS on Client Access Server. There is a problem: when you publish OWA in the Internet, you automatically publish ECP to the Internet too. And this is a security issue.

If you use IIS ARR as Reverse Proxy for publishing Exchange to the Internet, you can create rule that will block access to URLs like https://owa.domain.com/ecp/.

How to find all mailboxes in Exchange 2010/2013 with mail forwarding enabled?

It's just a string in Powersehll:

As you know, there are many types of Exchange 2013 logs, and a lot of disk space is used - and - space on system disk. Theoretically, you can change paths of all logs in Powershell. But because of number of logs types in Exchange, managing all these folders (and file sizes, directory sizes, max age of files) becomes a true nightmare.

Thus I created for me and you a little memo in Powershell scripts, so I can run them after installing of next new server.

While been extending and modifying my Exchange infrastructure, I was needed to duplicate Receive Connectors from one server to another. I wrote a simple template script for this task.

Starting from version Exchange 2010, developers presented to us very good solution for high availability and fault tolerance of Mailbox Database Servers - Database Availability Group (DAG).

But situation was not so funny with high availability of Client Access Server in Exchange 2010. We had to create CAS-Arrays and NLB-clusters (based on Windows or hardware solutions).

Fortunately, in Exchange 2013 Microsoft gone forward to the brand new solution of providing client access to the service. Actually, now we have "former" Outlook Anywhere, which work for the clients from the Internet, as well as for the clients from the Intranet. Client requests to servers now processed independently of connection, i.e. now it's absolutely not important, which exactly CAS-server respond to the client, because all processings of requests are done at Mailbox servers, and CAS-servers just throw packets hither and thither .

The huge scalability of Microsoft Exchange carries serious disadvantages in addition to all its benefits. One of these cons - difficulties in message tracking from log files. Because of you have multiple transport servers, every message passing through every mailbox server and leave it's trail in logs.

Today I will try to at least partially help you in message tracking in Exchange 2013.

As soon as all messages of Exchange users are stored in database, we can perform search and, if needed, delete operations against messages. It is needed in some cases for example, when employee sent message with confidentional information to the wrong recipient or you just need to find some message and look into it... there can be a lot of options.

What Exchange 2010/2013/2016 can offer to us in such cases? We can search mailboxes (all or any specific) in database and copy search results into some other mailbox. If needed, we also can delete search results from the source mailboxes.