Standard 5.7.17 Error when sending email from SMTP server

Some months ago we were struggling to get an Exchange Server working. We could send but not receive. In the end we walked away from it.
Today we have been recovering a server from a broadband change, a router reset and re-configuration but without changing anything on the server itself which had previously been running Exchange OK. We could not get mail through.
We did a Google search for 5.7.17 and found some posts which were not very useful but then we happened upon this thread
http://www.google.com/support/forum/p/Google%20Apps/thread?tid=14a3d1192c489e16&hl=en
from M1ke on Google Support Forum
I have followed this thread and can now successfully receive email
I think that I now understand it better than M1ke has described so I will offer some clues.

First, 5.7.17 is NOT an Exchange Server error so if you get it you have not got to the Exchange Server.
Second, the ability to send from servers such as hotmail and gmail are crucial to understanding what is going on.
Third, this content from M1ke is vital

My server and accounts are controlled by Plesk. All domain settings are in 123-Reg but Plesk has its own list of domain settings for each address. I assume it follows the 123-Reg settings because the MX and DNS lookups give those values, and Gmail/Hotmail/Yahoo addresses do not encounter the 5.7.17 error. If there are known Plesk issues please can you detail them so that I can investigate?

the important pieces here are 'My server ..... by Plesk' and by the way I do not think this is a Plesk issue.

Fourth, M1ke gives us the solution in his third post --- remove the mail boxes from Plesk and turn off the mail service for the domain in question. Playing with the MX records is a red herring.

Having done this our email gets correctly transported to Exchange without issue.

Now to the better understanding of the issue.
We were trying to send emails to an exchange server that is related to a domain which is hosted on our Plesk server. The public DNS records at the registrar correctly direct traffic to our server for http, ftp, etc and mail to the Exchange server - each server being found on different IP addresses. Thus hotmail and gmail find the public DNS record and the mail gets transported to the Exchange server.
Like M1ke, we were trying to test sending email from OUR server (running Plesk) to the Exchange server but our domain and the recipient domain are both virtual hosts on our Plesk server, hence Plesk tries to resolve the mail addresses itself, and will do one of two things. It will either drop the mail in a mail box which it knows about or give you a 5.7.17 error if it cannot find that mail box. Because Plesk can resolve the mail to a mail server which it knows about and mail never goes outside the local server and is never seen on the Public network and therefore cannot be received by Exchange.
Once you disable the mail server for that domain in Plesk the mail HAS to go to the public network and can be correctly transported to the correct host.
I hope this post will short cut a few problems for other people.
My thanks to M1ke and if anyone knows how to contact him please do so on our behalf.

HTTP error 403 in SharePoint

The solution is blindingly obvious once you understand it, but then isn’t it ever thus. Certificate errors, folder permissions, port numbers, SharePoint access levels, intricate IIS problems, public domain dns errors and all those issues you find when you Google “SharePoint Error 403 Windows Server” are largely red herrings. That is NOT to say that you can ignore these but when you know these are OK and you are still getting the error you need to find a different solution.

Starting from Basics

Platform: Windows server 2003 standard (that is NOT SBS); SharePoint V3

Problem: after configuration I could access default site on the server but not from outside – constant 403 errors.

The answer came to me via a visit to a link to Microsoft Technet on about page 4 or 5 of the Google output (it is sometimes worth going in that far!).

Fed up with getting these errors using the FQDN in the address bar [for those unfamiliar with FQDN I was typing hostname.domainname.com (please substitute your own hostname and domainname)] I typed in the IP address and got a connection. That proved that there was a route through to the site and that certificates and folder permission were NOT the issue.

The technet link [ http://technet.microsoft.com/en-us/library/cc288173(office.12).aspx ] gives you the basics but it is still a bit cranky. I am not going to repeat the contents of that link so keep it handy.

The Alternate Access Mapping link defaults to 'show all'. When you use the drop down you have to choose the ‘Change Alternate Access Mapping Collection’ link. You will be offered the sites in your collection – in my case ‘Central Administration’ and ‘SharePoint – 80’.

Select the site you want to change (in my case 'SharePoint -80'). You are presented with the URLs that point to this site – initially it will be something like ‘http://yourservername’.

Now this is the bit to get your head around. There needs to be a complete separation in your mind about where you are accessing the site from.

If you are accessing the site from within your network (ie intranet mode) you will need an internal URL such as ‘http://yourservername’ and then for clients working within your own domain they will need to enter this internal URL in the address bar of their browser (I can use both IE and Firefox – after all it is only a website).

If you want to access the site from outside your domain (eg from home, extranet mode) then you need to have a public URL such as ‘http://hostname.domainname.com’ and then clients need to put this URL into their browser when accessing the site from outside the domain.

So now you have 2 URLs to the same site.

Your users will have to get used to the idea of using the internal URL when they are at work and the public URL when they are at home.

I was so pleased that I had cracked this last night once I had changed the Public URL that it came as shock this morning when I could not access the site from the server on which it resides which was resolved once I re-entered the internal URL.

As an administrator you also need to be very sure that you are setting the URL details when the ‘Alternate Access Mapping Collection’ is lodged on to the correct site. Otherwise you could be changing the URLs for a different site.

We are happy to take requests for further information on this. Please visit www.hillierconsultants.com or email stephen@hillierconsultants.com for further help.

Poor programming undoes Microsoft access control mechanisms

Why do developers of Windows programs write their programs in such a way that they force users to be local administrator?
Last week we were setting up a new domain server and all went well until we went to run some software. We had what looked like permissions problems and spent a long time checking that the users we were setting up did in fact have access to the data files we had copied to the new server.
Only after half an hour did it transpire that users had to be made local machine administrators in order to make the software run. Some files held locally cannot be accessed otherwise.
The main problem with Windows is that it derives from an OS that gave any user full control over the machines and the system itself.
Microsoft have been trying to do their bit to redress that with making domain members restricted users and with the new UAC controls. We all know why Microsoft has to address this issue. So why do developers then undo all this by writing code that requires ordinary users to have local admin rights. This leaves machines open to attack from malware which is just plain stupid.
Developers cannot absolve themselves by saying it's Microsoft's problem. If we pull together then we might get to a position where Windows no longer needs to have performance dragging anti malware in place.