|
Home > Archive > IIS and SMTP > June 2007 > SMTP Service not functioning on IIS 5
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SMTP Service not functioning on IIS 5
|
|
|
| Hello,
We have are running IIS 5 on a Windows 2000 sp4 file server to host our
local intranet as well as local copies of multiple websites used for testing
(copies of live websites). There is only 1 "site" configured and each local
copy is simply a sub-directory off of the main site. This sites' domain in
DNS is the same as our Active Directory domain ("corp.domain.com") so browser
requests for the local domain go to this server.
We are running a Windows 2003 domain (2003 functionality level) with
Exchange 2003 as our mail server for the local domain, "corp.domain.com" and
our main "domain.com".
The default site and FTP site have been running great since we set this up,
but we installed the SMTP service and configured it with the following:
- LDAP routing to a Global Catalog Server using Active Directory as the
schema.
- in Advanced Delivery, "corp.domain.com" as the masquerade domain and the
FQDN is set to the hostname "host.corp.domain.com" by default.
- I added our exchange server as a Smart host, with the SMTP service
attempting direct delivery first
- configured access to be restricted to the local subnet, where DNS, email
and DC servers reside
In IIS, the Default SMTP server shows up as "Default SMTP Virtual Server
(Unknown)" with a question mark in front. When you click on Current
Sessions, the message displays "The service instance is not running".
In Event Viewer, the only messages I see are Event ID 105, which MS states
is due to an unplugged network cable on an adapter. There are no open
adapters on this server. Also note that the server has not been rebooted
since the install this morning, but IIS services and SMTP have been restarted
multiple times.
Anyone have any ideas?
--
Thanks, Jeff
| |
| Sanford Whiteman 2007-06-06, 1:21 pm |
| > We have are running IIS 5 on a Windows 2000 sp4 file server to host
> our local intranet as well as local copies of multiple websites used
> for testing (copies of live websites). There is only 1 "site"
> configured and each local copy is simply a sub-directory off of the
> main site. This sites' domain in DNS is the same as our Active
> Directory domain ("corp.domain.com") so browser requests for the
> local domain go to this server.
Technically speaking, the setup on the server itself is irrelevant to
a remote browser. The browser will use DNS to resolve corp.domain.com
to an IP, and there presumably is an A record for corp.domain.com
pointing to your IIS 5 box. Host headers take over only at that point.
I have to tell you that in an AD environment, your use of the domain
FQDN is quite atypical and risky; the fully-qualified domain name of
the AD domain typically resolves to AD domain controller(s), for very
good reason. However, this is unlikely to be directly pertinent to
your situation with the SMTP service.
> - LDAP routing to a Global Catalog Server using Active Directory as the
> schema.
LDAP routing doesn't do what you think it does; turn it off.
> - in Advanced Delivery, "corp.domain.com" as the masquerade domain
Unless you can justify rewriting envelope information, turn this off,
too. It is not commonly necessary to use this feature, esp. if you are
already using a public DNS TLD like .com when submitting mail. I think
you've overdone the settings a bit... you might reenable some of these
later, but it makes troubleshooting more difficult in your beginning
phase.
> FQDN is set to the hostname "host.corp.domain.com" by default.
OK.
> - I added our exchange server as a Smart host, with the SMTP service
> attempting direct delivery first
Why'd you do that, exactly? That setup is suggesting that you want the
server to use the DNS MX algorithm by default, but to hand off
messages to the Exchange box on failure instead of returning a DSN.
The Exchange box will then be retrying using the same DNS MX
algorithm, so what is the precise use case in which "Direct Delivery
First" will do more than add confusion?
DDF + Smart Host would typically be used if you want to take load off
a busy mail server after the initial attempt to send, so subsequent
retries are done by a secondary server that likely has a much larger
queue, a longer queue retry interval, more horsepower to spare, etc.;
for example, if your primary server were *also* servicing
POP3/OWA/Outlook clients, you would use DDF + SH to ensure the
promptest/cleanest delivery possible when there were no errors
encountered, while on any initial error you would hand off the message
to a dedicated server, accepting the additional log complexity as well
worth it because you've saved your main server's CPU and disk I/O.
Also, you haven't described exactly what you want to do with this SMTP
service. If, as indicated in your "Direct Delivery First" checkbox, it
will be connecting to remote servers, have you made sure it has a
valid Reverse DNS (PTR) record, that in turn has an A record pointing
back to its public IP? Granted, this won't stop the service from
starting, but it is crucial for direct delivery.
--Sandy
| |
|
| I used the FQDN of the domain because it made sense to me for an intranet
site, i.e. the home page for this domain. I've been using AD since 2000 and
I've never had a problem with doing this, but I didn't know there was
anything inherently risky about it - by default, you are right that AD will
resolve the domain name to a domain controller(s), but I've seen no AD issues
whatsoever. Yes there is a record in DNS that resolves this to the IIS box,
I only mentioned the browser for the example of corp.domain.com as an
intranet site, I didn't configure a domain name anywhere in IIS. I wouldn't
put IIS on a DC ever, but why shouldn't a browser request for a domain name
bring up an intranet home page like an external website? Makes perfect sense
to me
I configured the LDAP routing because AD stores the information on
containers for mailboxes and usernames and can resolve recipients. What does
it do that I am thinking it doesn't? Perhaps an explanation would help, but
I will turn it off as suggested and try it out.
The masquerade domain was added to help in troubleshooting. Since it puts
the masquerade domain in the "Mail From" part of the header, I figured it
might help at some point.
With the smart host, this was something I was testing to see if it would
work. My thinking was that if mail was being sent out and not going anywhere
from the SMTP service, if it went to Exchange and was delivered ok, then I'd
have an idea that mail was at least being sent out properly and there might
be some other issue from the IIS box. I'd be able to check the headers and
see what server it came from.
The purpose: This IIS box is for development of websites and an intranet
site for our employees to post company policies and procedures. It is
strictly internal to our company and doesn't have anything to do with
anything on the outside. We develop a lot of websites and our website
manager asked me to setup SMTP from the webserver to test sending out email
from his scripts and forms.
Hope this helps.
--
Thanks, Jeff
"Sanford Whiteman" wrote:
>
> Technically speaking, the setup on the server itself is irrelevant to
> a remote browser. The browser will use DNS to resolve corp.domain.com
> to an IP, and there presumably is an A record for corp.domain.com
> pointing to your IIS 5 box. Host headers take over only at that point.
>
> I have to tell you that in an AD environment, your use of the domain
> FQDN is quite atypical and risky; the fully-qualified domain name of
> the AD domain typically resolves to AD domain controller(s), for very
> good reason. However, this is unlikely to be directly pertinent to
> your situation with the SMTP service.
>
>
> LDAP routing doesn't do what you think it does; turn it off.
>
>
> Unless you can justify rewriting envelope information, turn this off,
> too. It is not commonly necessary to use this feature, esp. if you are
> already using a public DNS TLD like .com when submitting mail. I think
> you've overdone the settings a bit... you might reenable some of these
> later, but it makes troubleshooting more difficult in your beginning
> phase.
>
>
> OK.
>
>
> Why'd you do that, exactly? That setup is suggesting that you want the
> server to use the DNS MX algorithm by default, but to hand off
> messages to the Exchange box on failure instead of returning a DSN.
> The Exchange box will then be retrying using the same DNS MX
> algorithm, so what is the precise use case in which "Direct Delivery
> First" will do more than add confusion?
>
> DDF + Smart Host would typically be used if you want to take load off
> a busy mail server after the initial attempt to send, so subsequent
> retries are done by a secondary server that likely has a much larger
> queue, a longer queue retry interval, more horsepower to spare, etc.;
> for example, if your primary server were *also* servicing
> POP3/OWA/Outlook clients, you would use DDF + SH to ensure the
> promptest/cleanest delivery possible when there were no errors
> encountered, while on any initial error you would hand off the message
> to a dedicated server, accepting the additional log complexity as well
> worth it because you've saved your main server's CPU and disk I/O.
>
> Also, you haven't described exactly what you want to do with this SMTP
> service. If, as indicated in your "Direct Delivery First" checkbox, it
> will be connecting to remote servers, have you made sure it has a
> valid Reverse DNS (PTR) record, that in turn has an A record pointing
> back to its public IP? Granted, this won't stop the service from
> starting, but it is crucial for direct delivery.
>
> --Sandy
>
| |
| Sanford Whiteman 2007-06-10, 1:18 am |
| > I used the FQDN of the domain because it made sense to me for an
> intranet site, i.e. the home page for this domain. I've been using
> AD since 2000 and I've never had a problem with doing this, but I
> didn't know there was anything inherently risky about it
Well, AD DCs will auto-register an A RR for the domain FQDN with their
IP(s) -- unless you overtly block this autoregistration by making
static entries. While the domain A RR entry is the least important of
the locator records (viewable in NETLOGON.DNS), as it is only used if
a client can't or won't use the more robust SRV RR type, it is
nonetheless part of the server location process and not having it will
bite you if you introduce downlevel clients. At any rate, that's
*almost* 100% likely to be unrelated to your SMTP service problem (I
cannot dismiss it entirely, but let's forget it for now).
> why shouldn't a browser request for a domain name bring up an
> intranet home page like an external website?
Because the DNS zones "federated" with your AD domain are crucial to
AD operation. They are not just any old zones. That's kind of like
(though, I admit, not as extreme) saying "How come I can't have a
website called '_ldap._tcp.corp.domain.com' anymore, now that I said
that domain.com is the top of my AD hierarchy?" One main difference,
of course, is that the underscores are illegal in public hostnames, so
you would tend to avoid them even if all the end users are using your
MS DNS servers and are inside your firewall. The A record for plain
'corp.domain.com' _looks_ like a regular, publicly referenceable
hostname, but IME it is best to reserve it for AD's needs, even if at
the point of AD implementation you don't have any clients that need
those A records. I would use intranet.corp.domain.com instead, which
is not reserved at all. But that's just me, and again, I think this is
off the SMTPSVC topic.
> I configured the LDAP routing because AD stores the information on
> containers for mailboxes and usernames and can resolve recipients.
> What does it do that I am thinking it doesn't? Perhaps an
> explanation would help, but I will turn it off as suggested and try
> it out.
LDAP routing is for list explosion on the server. It doesn't, for
counterexample, maintain or reject unknown recipients. It is only
useful in purpose-built mailing list environments.
> The masquerade domain was added to help in troubleshooting. Since
> it puts the masquerade domain in the "Mail From" part of the header,
> I figured it might help at some point.
You'd use the masquerade if, for example, you knew that internal
clients were generating mail with invalid right-hand-side data --
perhaps using an private TLD like username@domain.lan -- and you
needed to massage the data so that your mail would not be rejected for
having an invalid sender.
> With the smart host, this was something I was testing to see if it
> would work. My thinking was that if mail was being sent out and not
> going anywhere from the SMTP service, if it went to Exchange and was
> delivered ok, then I'd have an idea that mail was at least being
> sent out properly and there might be some other issue from the IIS
> box.
I would say that having a known-good secondary server that takes over
for your probably-bad primary is certainly *worse* for troubleshooting
the primary, even if it's better for overall delivery. That someone
received a test message becomes info useless without additional
diagnostics.
> I'd be able to check the headers and see what server it came from.
True. Though I think at this point you should be concentrating on
logs, not headers. Logs are always the better friend, IME.
Aaaaanyway, I would recommend that you uninstall and reinstall the
SMTP service, if you haven't already. If that doesn't work, uninstall
again, get Metabase Explorer and delete all SMTPSVC keys, then
reinstall (back up beforehand, obviously). Also ensure that nothing
else on the box is attempting to listen on TCP 25. The error that
you're seeing suggests a corrupt or unusable base installation for
reasons outside of the SMTP config itself.
--Sandy
|
|
|
|
|