I recently came across a client’s backup that was completing successfully daily but not flushing the transaction logs for Exchange as it should.  In the job properties of Backup Exec, the Exchange section declares that it will perform a full backup and flush the comitted logs but it simply never happens.

After some research, Veritas article 280659 had the answer…and it was a simple one.  In the job properties, review the options under Advanced Open File and make sure the option “Process Logical Volumes for backup one at a time” is not checked.   As its explained in the article, if this is unchecked, Backup Exec will use a different open file option (VSS) for the Exchange logs to allow it to flush them afterwards. 

Microsoft Forefront Security for Exchange Server is the cause of this messsage:

The original contents of this file have been replaced with
this message because of its characteristics.
File name: ‘winmail.dat’
Virus name: ‘CorruptedCompressedFile’

====================

Quick fix:

Goto Forefront Server Security Administrator > Settings> General Options > Scanning
Goto checkbox name “Delete Corrupted Compressed File”
Uncheck the box and test

To find the product version in Exchange 2007, execute the following command in PowerShell:

Get-ExchangeServer | fl name,edition,admindisplayversion

Refer to the article below to find out how the build number corresponds to a product version:

http://blog.kazmarek.com/2008/07/04/exchange-server-version-and-build-numbers/

This microsoft article details the various Exchange Server versions, including service packs.

http://support.microsoft.com/kb/158530

Some recent ones:

Microsoft Exchange Server  2003                       6.5.6944                             October 2003
Microsoft Exchange Server  2003 SP1                 6.5.7226                             May 2004
Microsoft Exchange Server  2003 SP2                 6.5.7638                             October 2005

Microsoft Exchange Server  2007                       8.0.685.24 or 8.0.685.25    December 2006
Microsoft Exchange Server  2007 SP1                 8.1.0240.006                      November 2007

I came across a situation where an organization had been setup to use RPC/HTTPs “Outlook Anywhere” for some time and all the Outlook 2003 clients seemed to work fine. One user had Outlook 2007 and was unable to connect using this method. In the LAN and through OWA everything worked fine. I tried tons of different solutions online but in the end, the problem was with the configuration in Exchange. I looked over the suggested configuration here:

http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm

and I discovered that the RPC ports hadn’t been configured as the article suggests. I used the recommended “RPCnofrontend” tool: http://www.petri.co.il/software/rpcnofrontend.zip and everything worked fine after that.

There is no specific SMTP service like you saw with Exchange 2003 and IIS. However, if you’re just trying to stop the listening port 25 for Inbound/Outbound mail, stop the ‘Microsoft Exchange Transport’ service.

In Active Directory when you have an Exchange server a user or group, even a public folder can have multiple smtp email addresses associated with the entity (user/group/public folder etc.), but finding the non-default email address can be tedious. A great way to search for it is:

Go to Active Directory Users and Computers –> right click on the domain and click find –> in the find field, change the criteria to ‘custom search’ –> click the advanced tab where you can type in a LDAP query. If you are trying to find out who has sales@yourdomain.com, type proxyAddresses=smtp:sales@yourdomain.com.

Wildcards can be added to the email address portion, and you can also type a wildcard ie. *.yourdomain.com and then change the view to add the proxyaddress column to see all of the entities with their proxyAddresses (email addresses)

These days many mailservers are requiring reverse DNS (rDNS) and SPF records to validate the sender from this domain.

How does SPF work:

SPF is easy to understand. The “Internet” uses DNS (Domain Name System) to resolve Domain Names (as an example www.msexchange.org) into IP addresses. DNS is also used to direct requests for different services like e-mail and Web Servers. For every Domain around the world an MX (Mail Exchanger) record must exist. An MX record tells the e-mail sender where the target server for receiving mail is located.

SPF is publishing “reverse MX” records in DNS which tells the mail sender which machines send mail from the domain.

The recipient of the e-mail can now check these records to ensure that e-mail is coming from a “trusted” sender from this domain.

These “reverse MX” records can be easily published in DNS. It takes only one line in DNS to fullfil all requirements.

Microsoft has come up with a good and easy wizard (webpage not downloadable tool) that asks a few questions and spits out the correct SPF.

How to add SPF file to Windows Server DNS - link

OpenSPF Website - link or old site

Scenario:

UserA sends a meeting request to UserB and UserA gets a NDR message with the following details:

————————————–

Your message did not reach some or all of the intended recipients.
Subject: test
Sent: 1/24/2008 1:32 PM
The following recipient(s) could not be reached:

—————————————
After digging into Active Directory using ADSIEdit, (which came up empty) I removed all delegates from UserB, added a new delegate that has never been a delegate in UserB’s mailbox, then put the original delgates back for UserB. Basically this resets the delegates and the meeting requests won’t NDR any longer.

Sources: http://www.outlookexchange.com/articles/HenrikWalther/RPC_over_HTTP.asp
http://www.msexchange.org/tutorials/Implementing-RPC-over-HTTPS-single-Exchange-Server-2003-environment.html
http://blogs.techrepublic.com.com/networking/?p=292

In order to make use of all Exchange’s collaborative tools, Outlook must communicate with the Exchange server via the remote procedure call protocol (RPC). It’s not a good idea to open these ports to the Internet due to RPC’s rich history of exploitable vulnerabilities. RPC over HTTPS allows RPC traffic to be tunnelled inside secured HTTP packets. This enables roaming users to enjoy full Outlook/Exchange functionality without having to open any additional firewall ports or dial a VPN connection.

The following steps are necessary to implement RPC over HTTPS in a single Exchange Server environment:

- Configure an Exchange Server 2003 back-end server as an RPC proxy server.
- Configure the RPC virtual directory for Basic authentication and SSL
- Configure the RPC proxy server to use specified ports for RPC over HTTP
- Set the NT Directory Services (NTDS) port on all global catalog servers that act as Exchange Server 2003 back-end servers
- Create a Microsoft Office Outlook 2003 Profile for your users to use with RPC over HTTPS
- Test the connection

Requirements in order to get RPC over HTTP working:

Client(s)
Windows XP with Service Pack 2.
Outlook 2003 installed, previous Outlook versions won’t work.

Server:
The exchange server needs to be running Windows 2003 and Exchange 2003.

It’s not a requirement running Exchange in a Front-End/Back-End topology as many believe, actually you could get by running everything from a single server. But depending on your environment, Microsoft recommends you make use of a Front-End/Back-End scenario, and if possible placed behind an ISA 2000 server.

You will also need to have a Microsoft Certificate Authority (CA) installed , this should be used to issue the respective certificates needed in order to have SSL/443 working properly. You could as well go the easy way and get the certificate from a certificate provider like Verisign or Thawte.

Configuration Steps:

1)  Install the RPC over HTTP Proxy component on Windows Server 2003
- Click Start | Settings | Control Panel
- Double-click Add/Remove Programs
- Click Add/Remove Windows Components
- Double-click Networking Services
- Put a checkmark in RPC over HTTP Proxy
- Click Next | Ok | Finish

2) Configure the RPC virtual directory for Basic authentication and SSL

Installing the RPC proxy will create two new virtual directories under your Default Web Site. We need to modify these slightly in order to allow proper authentication and encryption of RPC over HTTP connections.

- Open up the IIS Manager.
- Navigate to Web Sites | Default Web Site.
- Right click on the RPC directory and select Properties from the drop-down menu.
- Select the Directory Security tab.
- Click on the Edit button within ‘Authentication and access control’.
- Make sure that the option ‘Enable anonymous access’ is deselected.
- Check ‘Integrated Windows authentication’ and ‘Basic authentication’ and click on OK. You may be prompted with a warning dialogue; click on Yes and ignore this as it does not apply while using SSL.
- Click the Select button next to Default Domain and select the domain from the list.
- Click the Select button next to Realm and select the domain from the list.
- Click OK.
- Click on the Edit button within ‘Secure communications’.
- Check ‘Require secure channel (SSL)’ and ‘Require 128-bit encryption’ and click on OK.
- Click on OK to apply the changes.
Repeat these steps for the RPCWithCert directory.

3) Configure the RPC proxy server to use specified ports for RPC over HTTP

Now we need to edit some values in the registry editor, so start it up and navigate to the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy

The ValidPorts key will likely already include an entry for ports 100-5000; we need to add a few more. Below is an example; you will need to change the hostnames and domains to match your own environment. This should be entered as a single line with no spaces after the semicolons.

ISLMAIN:100-5000;ISLMAIN:6001-6002;ISLMAIN.ISLLLC.local:6001-6002;ISLMAIN:6004;ISLMAIN.ISLLLC.local:6004

4) Set the NT Directory Services (NTDS) port on all Global Catalog Servers that act as Exchange Server 2003 back-end Servers

There are two ways to do this:A) Tell the Exchange server to act as a target for the RPC proxy:
Open up Exchange System Manager, browse to your target server, right-click, and select Properties.
Just above the General tab you will find the RPC-HTTP tab. Select this tab and ensure that the option ‘RPC-HTTP back-end server’ is checked.
Click on OK to exit.  You will be prompted to restart the server.

B) Use Regedit to navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

- Then click Edit in the menu > New then click Multi-String Value
- Name it NSPI interface protocol sequences
- Right-click the NSPI interface protocol sequences multi-string value, and then click Modify
- Type ncacn_http:6004 in the value box
- Now restart the Global Catalog Server.

5) Create a Microsoft Office Outlook 2003 Profile for your users to use with RPC over HTTPS

- Open the Control Panel | Double-click Mail
- Click Show Profiles
- Click Add…
- Give the profile a name and click Ok
- Click Next and set bullet in Microsoft Exchange Server
- Now you should type in yourExchange server FQDN (ex.  exchange.domainname.local)
-Set a checkmark in Use Cached Exchange Mode, type in your username, but don’t hit Check Name yet, instead click More Settings…
- Click the Connection tab
- Set a checkmark in Connect to my Exchange mailbox using HTTP
-Now open up the ‘Exchange Proxy Settings’ and use the options below.

Use this URL to connect to my proxy server for Exchange:
https://mail.domainname.com

-Check ‘Connect using SSL only’.
-Check ‘Mutually authenticate the session when connection with SSL’.
‘Principal name for proxy server:’ msstd:mail.domainname.com
-If you want to use RPC over HTTPS even while on the internal network, then check ‘On fast networks, connect using HTTP first, then connect using TCP/IP
-Make sure ‘On slow networks, connect using HTTP first, then connect using TCP/IP’ is checked.
-For the ‘Proxy authentication settings’ we can use either NTLM or Basic authentication. I prefer NTLM as it doesn’t constantly prompt for a username and password to be entered.

Apply the changes and you’re ready to start testing. Don’t forget to forward port 443 to the Exchange Server on your external firewall.

6) Test the connection

After enabling the RPC Proxy settings, your Outlook connection to the Exchange Server should be established successfully. The question is now: How to determine that it is an RPC over HTTPS connection?

The answer is simple. Right click the Outlook icon in the taskbar while you are holding the CTRL Key. The Context menu opens and now you have the option to see the Exchange Server Connection Status. Here you can see if your connected, and if yes what connection type is used.