Advertisements

Archive

Archive for September, 2008

Controlling local SMTP mail relaying with Exchange 2003

September 17, 2008 Leave a comment

The organization needed to enable a specific database server to send out e-mail confirmations to remote users after specific events have occurred. Simple, I thought, as I had previously configured just these options back when we first installed our Exchange 2003 Standard server over a year ago. I was wrong though, as the confirmations were not being sent, seeming to just disappear out into the void.

  1. First step was to run some simple tests using Bmail (which is a free command-line SMTP mailer, available here. Initial tests were run from my local workstation, and lucky for me, led me to the solution right off the bat.
  2. The Bmail tests from my workstation immediately produced SMTP 550 5.7.1 “Unable to relay” error messages. What? My workstation should be authorized to use SMTP…
  3. I then ran the exact same test from the server in question with the problem. Same result as my local workstation, SMTP 550 5.7.1 errors.
  4. Time for a Google search on the issue. This lead me to the Default SMTP Virtual Server Properties dialog box (Exchange System Manager -> Organization -> Administrative Groups -> First Administrative Group -> Servers -> Server01 -> Protocols -> SMTP -> Default SMTP Virtual Server). From the dialog box, I went to Access, then the Relay restrictions Relay button.
  5. As I previously indicated, I had not changed these options since I first set up our Exchange 2003 server. The list of server IP addresses under “Only the list below” was incorrect, and it contained IPs that were no longer in use, and was missing the address of the server with the mail relaying problem. It was simple to correct the list.

Additional Notes:
You have all kinds of options with the Relay Restrictions window. I strongly suggest sticking with the principle of least access, and only granting open relay access to those systems which really need it. Adding a domain name or a group of IPs to the list seems a very bad idea to me, since as indicated, this is not an area that is visited often. Also, assuming you are using Outlook clients with your Exchange 2003 server, make sure you leave the “Allow all computers which successfully authenticate to relay, regardless of the list above” option checked, or your Outlook clients will not be able to send outbound SMTP (Internet) mail. My local workstation system was unable to relay with Bmail because its IP address was not on the list, and I was attempting to send mail directly from the command line, outside of an authenticated Outlook session.

Advertisements
Categories: Exchange 2003, mail relay, SMTP

Mac OS X not able to connect to Windows Server 2003 R2 running Terminal Services

September 3, 2008 Leave a comment
  • System Notes: Mac Pro, OS X 10.5, Microsoft RDP Client for Mac 1.0.3 and 2.0

Error Message: You were disconnected from the windows-based computer because there were problems during the licensing protocol. Try reconnecting to the Windows-based computer or ask your administrator if the license is properly configured.

Recently, we retired our old, outdated Windows 2000 Terminal Server, and replaced it with a Windows Server 2003 R2 server running Terminal Services. Terminal services are used for remote access only, not for application virtualization or anything extensive like that. We have three Mac clients in the office which also use terminal services for access to a Windows-only database application. This is where the problem came in. With the new terminal server, we reset the licensing database on our existing Licensing Server, which was running on one of our domain controllers. All three of the Mac clients started getting the above listed error message, even though there were plenty of licenses on the licensing server (15 total, to be exact).

After searching around the web, and finding lots of references to this being a “temporary license” not being issued, I eventually stumbled across this link, which led me to checking the directory permissions on Users/Shared/Microsoft/RDC Crucial Server Information/RDC GLOBAL DATA for the logged in Mac user, who was an Administrator on the Mac. We did originally have version 1.0.3 of the RDP client on this Mac, and we had upgraded it to the release version 2.0. The security permissions on this folder were not set to full for the user, and once they were corrected, the problem with the login went away. I still do not understand why the Administrator privileges were not correctly applied on this folder in the first place.