Ofer had an issue where a setting that was manually done in the SMTP settings didn’t get changed by the CEICW wizard…the reason?  It’s not a setting that the SBS wizard ‘touches’ or sets, so when the wiz was wiz’d .. it didn’t make the change.  Conversely, if you have placed in the SMTP smarthost connection information the username/password for outbound smarthost authentication, you rerun that wizard and because the wizard “touches” that part of the SMTP information, it will remove it.


The issue was with email delivery …and that blog post above was what was specially done to the SBS box but is not part of a CEICW wizard…. so now…. without further ado….

Our Oferism of the day:

Very recently I had the opportunity to assist one of my larger clients in migrating their entire Internet related presence from one ISP to another. That is, new ISP, new static IP address, new DNS, new gateway, new web host, new Mail Exchanger, new Name Servers etc.  – in short, The Works.

For purposes of identification, this is a large rack mount SBS 2003 Standard installation I performed exactly three years ago in December 2003 – it is dual NIC with a hardware firewall and currently it is fully patched to the latest and greatest.


After much planning, meetings, consultations and countless emails to all stakeholders in this process – over the course of 4 weeks and following Best Practices – I had scheduled the changeover be implemented over the Christmas Holiday weekend which in 2006 allowed us 3 full days (Sat, Sun & Mon) for all of the above items to propagate – as they say, when changing name servers allow anywhere from 24 to 72 hours – A record, MX records, mail queue, DNS propagation, RWW, wildcard email account, PTR records, reverse DNS, FTP uploads, FTP downloads etc.


After all the planning, earlier in that week prior to the switchover I once more confirmed all of the necessary information with the new ISP and was ready with all of the pertinent zone information for proper entry at the exquisitely right time on Friday afternoon in the Network Solutions panel.


The goal was that by the following Tuesday, all services would be fully propagated and the web site, incoming mail and DNS would work smoothly.


So as scheduled, on Friday afternoon at close of business – early that day at 3:00 pm because of the holiday – I showed up at my client site to start the changeover from the previous ISP router to the new ISP T1 CPE device.


I logged into the hardware firewall, changed to the new public static IP, subnet mask and gateway – changed the DNS settings on the firewall to reflect the new DNS servers from the new ISP. I then connected the hardware firewall to the new ISP’s T1 CPE device and after recycling the firewall was able to connect to the Internet right away from the server – GREAT, I thought – all that planning and I have Internet right away.


Now it is just basically a 2 day waiting game until all Name Servers and services propagate and everything should work.


So I proceeded to run the CEICW and followed the wizard and plugged in the new DNS server information from the new ISP – I went ahead and also proceeded to run major maintenance on the server, updates, memory and disk optimization, reboots, etc.


Since I knew that the web site and email would not really start resolving until Sunday night into Monday (all holidays), and users would not resume work until Tuesday, I did not check back on it until mid day Monday – and at that point I checked the web site in its new home (worked), DNS (worked), RWW (worked), A and MX records (correct) – I sent test mail to the Administrator account (worked).


Great, I thought – all that planning paid off.


Then about 2:00 pm on Tuesday afternoon, I get a call from one of the managers (25 users at the site) stating that they did not think that their emails were going out – they definitely confirmed that their internal emails were working in both directions – they definitely were RECEIVING email from the outside, but they were pretty certain that their emails to the OUTSIDE were not going out.


Are you getting non-delivery reports I asked? – no was the response – ANY message as to the error – no they said.


So I logged onto the server remotely, went on OWA from the Administrator account and sent an email to myself to my business email – I waited 5 minutes and never received it – so I went looking around on the server in Services to make sure everything Automatic was started, poked around in the server AntiVirus software settings to see anything out of the ordinary and then went to System Manager in Exchange – and there they were – over 2,000 messages sitting in the queue – including the email I just had sent myself.


MMMMmmm I thought – perhaps the PTR or reverse DNS is not set at the new ISP yet – maybe they are blocking port 25 because my client had not yet filled out the “I-am-not-a-spammer” application, maybe it was still a holiday and things were slow.


So I logged into the Network Solutions panel, called the new ISP and we started troubleshooting everything possible to get to the root of why the messages were not leaving the Exchange server. After more than an hour of testing and confirming that everything at the new ISP, was in fact, correctly set I came to the realization that this was an internal issue on that server.


I got off the phone with the new ISP and proceeded to log onto other multiple SBS server I had to see if I could “divide-and-conquer” and look for exceptions in other configurations. After much tinkering and lots of trial and error, I found the culprit – but I was not sure at first because the other servers and this server showed one exception – but it had to be the reason, I thought – and it turned out to be correct.


The culprit is the old DNS values get updated EVERYWHERE in the SBS 2003 server if you use the CEICW wizard – everywhere EXCEPT the SMTP virtual server. Additionally, after making the changes described below, you have to put it back the way it was – EMPTY – at least that is the way all of the other SBS servers that I manage are set to.


So you have to do this MANUALLY – CEICW does not, for some reason, do this for you. In Exchange System Manager, or the SBS Server Management Exchange Organization – do the following (*-screenshots at the bottom of this post):

  1. click on the SERVERS hive

  2. click on the name of the SBS server

  3. select PROTOCOLS and expand

  4. select SMTP and expand

  5. right click on the Default SMTP Virtual Server

  6. choose PROPERTIES

  7. click on the DELIVERY tab

  8. click on the ADVANCED command button

  9. click on CONFIGURE next to Configure external DNS servers

  10. you must REMOVE the OLD values for DNS in this window

  11. then ADD the NEW values for DNS for your new ISP

  12. click OK three times and exit the MMC

  13. restart the SMTP service

  14. go back to Exchange System Manager and go the QUEUE section

  15. highlight ALL of the messages in the queue that are outbound

  16. right click and choose FORCE CONNECTION

  17. go get a cup of coffee or otherwise wait 20 to 30 minutes

  18. go back to the DNS settings in Item 10 and REMOVE the NEW settings for DNS

  19. leave that section BLANK

  20. click OK three times

  21. get out of the MMC

  22. restart the SMTP service

  23. You are done

That server has been fine since – so the Gotcha When Changing ISP in SBS 2003 should really be titled SMTP Gotcha When Changing ISP in SBS 2003 and I am now wiser for it.


*-here are the pertinent screenshots for the procedures above.



One Response to Ofer-ism of the day – Gotcha when changing ISPs in SBS 2003

  1. Eric Louie says:

    This was a problem when I moved an SBS server recently, too. I can’t remember how I solved it (precisely) except that having one DNS address in the Network Adapters pointed to the SBS server probably helped the issue somewhat. Thanks for publishing this and putting in the work, Ofer.