Alexander’s Blog

There could be several reasons for the above error. I recently ran into a specific situation on an Exchange 2003 Server where the Exchange administrator had recently configured some security options. Some of the clients on the Internet were using POP3 to access their e-mail. People on the internal network (e.g. techgalxaxy.net) were able to successfully send and receive e-mails from internal clients. However, from external POP3 clients on the Internet, users were unable to send e-mails to other domains (e.g. intel.com). They were getting Error 550.5.7.1 Unable to relay for… error in their Outlook clients.

After running several tests and verifying that the third-party anti-spam software was not the culprit, I focused on the SMTP server. It turned out that the administrator had blocked the relaying for authenticated computers, which is allowed by default. As soon as that option was checked, the external clients were able to send out e-mails.

Here’s the procedure for configuring this option. This procedure assumes you only have the Default SMTP Virtual Server running. You need to configure the following option on the specific SMTP server that’s having the problem.

In Exchange System Manager, go to Servers, server_name, Protocols, SMTP, Default SMTP Virtual Server.
1. Right-click Default SMTP Virtual Server and select Properties.
2. Click the Relay button.
3. Ensure that the box Allow all computers which successfully authenticate to relay, regardless of the list above is checked. If not, check the box and click OK twice.
4. Restart your SMTP Virtual Server.

Checking the above option doesn’t open your SMTP server for relaying. If you have any doubts, use the following URL to verify that your SMTP server is not relaying.

http://www.abuse.net/relay.html

User your SMTP server’s FQDN to test relaying, e.g. ns1.techgalaxy.net. You should see about 17 relay tests with a report of status at the end.

Over the years, I have used several backup applications, including Windows NTBackup utility. Recently, I discovered a program called Backup4All by Softland. This award-winning software runs on Windows 95/98/NT/2000/Me/XP/2003 and you can backup data to a local hard drive, to another computer on the LAN, USB drives, or to other removable media such as CD-R, DVD+R, DVD-R, DVD+RW, DVD-RW, etc.

This software is incredibly simple to use, very intuitive, and has some features that makes it one of the most useful backup utilities in the market.

More info…

ISA Server allows you to configure Virtual Private Networks (VPNs) so you can create a Point-to-Point Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP) over IPSec tunnels to the ISA Server. ISA Server also allows you to create site-to-site VPN tunnels. However, in some cases hosting VPNs on the ISA Server itself is not enough. In situations where you may be using a third-party VPN server, or if you want to host a VPN server on the internal network for your clients, you may be interested in setting up a VPN behind the ISA Server firewall on your private network.

You can configure VPN client access in ISA Server Management Console which allows VPN access to the ISA Server computer, not to another server on the private network. Normally you wouldn’t want your users to be tunneling into the ISA Server. You would want them to tunnel into a server behind the ISA Server firewall.

In this article we will learn how to configure a VPN server on the private network and configure ISA Server with the rules required to publish an internal VPN server. You can either use PPTP or L2TP over IPSec tunnel. Compared to L2TP over IPSec, PPTP is much easier to configure so we will use PPTP in this document.

Here’s what our scenario looks like.

The first thing you need to do is to install and configure your VPN server. The procedure for configuring a VPN server on a Windows Server 2003 is described in the KB article How To Install and Configure a Virtual Private Network Server in Windows Server 2003. Because we will use server publishing feature on the ISA Server, the VPN server should be using the private interface of ISA Server as its default gateway. In our scenario this will be the interface using IP address 10.0.0.1.

Creating a Server Publishing Rule
As mentioned above, we will use PPTP to publish our VPN server. This requires a server publishing rule on the ISA Server computer.

1. Open ISA Server Management console and select Firewall Policy.

2. In the task pane on the right hand side click on the Tasks tab.

3. Click on Create New Server Publishing Rule.

We will use the screen shots to look at the rest of the steps.

10.0.0.2 is the IP address of the internal VPN server that you are publishing through the ISA Server.

Selecting PPTP Server will configure inbound TCP port 1723 for VPN. It will also use the built-in PPTP filter on the ISA Server.

If you have more than one IP addresses on your external interface and you want to publish VPN server on all of them then you need to make sure that ISA Server listens on all of those networks. In our example we are only using one IP address on the external interface so will only configure ISA Server to listen on the External network.

Don’t forget to enable VPN access for clients either through Remote Access policy or through Active Directory in the users’ account properties or else users will not be able to create VPN connections.

For a printer friendly version of this article, click here.

Microsoft offers a free utility called Lookout that you can download from Microsoft. It allows you to search for e-mails, contacts, notes, tasks, calendar, as well as data from Exchange, POP, IMAP, PST files, public folders, and even files on your computer or other computers. The tool runs on Windows 2000/XP/2003 and requires .NET Framework 1.1 and one of the following Outlook versions: Outlook 2000, Outlook 2002, or Outlook 2003.

You won’t find detailed instructions on how to install and use this tool as this is an “unsupported” tool from Microsoft. However, the tool is easy to install and use. The program adds its own toolbar, called Lookout. After you install the software, you may have to restart Outlook. You will see a Welcome screen shown below. Use the Search option on the new Lookout toolbar to locate information. The latest version available at the time of writing was Lookout v1.2.

On May 9, 2005 I wrote about a problem where my students were unable to raise Domain Functional level from Windows 2000 Native to Windows Server 2003 in an Active Directory workshop. The error said that the domain controller was too busy so the functional level could not be raised. I also documented the solution provided by Microsoft TechNet article which required modifying the registry.

This week I ran into a situation where a child domain was unable to demote it’s only domain controller. The Event Viewer pointed to an error 8614 The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime. Here’s what the Event Viewer error looked like.

********************************************************************************
Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 2023
Date: 6/30/2005
Time: 9:19:24 AM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: PERTH
Description:
The local domain controller was unable to replicate changes to the following remote domain controller for the following directory partition.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
********************************************************************************
Please ignore the typo in the above error (”Additonal” Data). Apparently, Microsoft doesn’t run spell-checker on error messages.

My student did a quick search on TechGalaxy’s homepage for the word “tombstone” and found the blog entry from May 2005. The solution provided for Event ID 2042: It has been too long since this machine replicated also worked to resolve the problem with demoting a child domain’s domain controller. Here’s the quick solution for your convenience.

1. Start registry editor (regedit.exe).
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
3. If the registry entry exists, modify it; otherwise create a new DWORD value by right-clicking Parameters.
4. Type Allow Replication With Divergent and Corrupt Partner and press Enter.
5. Double-click the entry and for the Value data type 1, then click OK.
6. Close the registry editor. You do not need to reboot after this change.

NOTE: Make this change on the both the source and destination Domain Controllers that are having replication problems. There is no need to reboot the computers.

Verify that replication is successful between the Domain Controllers and then demote the child domain’s Domain Controller. Go back and set Allow Replication With Divergent and Corrupt Partner back to 0. You won’t see the NTDS node in the registry on the Domain Controller that you’ve just demoted because the computer no longer has the Active Directory. You should make the change on the other Domain Controller that is still running the Active Directory.

In a classroom or test environment these issues are not unusual because of the old images that are used to setup the classroom network. In my class I discovered that the setup folks forgot to update the date and time on classroom computers which was set to November 14, 2004. We updated the date and time but that didn’t cure the tombstone lifetime issue on the Domain Controllers. The TechNet article I mentioned above has a good explanation on the cause of these problems.