Why do I still see our old website even though the DNS should have had plenty of time to propagate?
February 3, 2007 10:03 AM Subscribe
DNS and Small Business Server and Caches, oh my: We switched web hosts at work (and waited a few days for things to propagate), but from the office network I still see the site on the old host. Can anyone help me understand DNS caching, Active Directory, and all the other bits and bobs that go along with the mysterious world of Windows networks?
I work for a nonprofit. We don't have an IT guy; just me, a talentedish amateur who's now trying to troubleshoot DNS caching. I am the quote-unquote administrator of the network, which means I know how to add users to Active Directory, restart the server when it's acting flakey, and Google the right search terms when things go awry.
We switched web hosts on Monday night and a rudimentary check tells me that the DNS changes propagated all over creation within a day or three. But when I'm at work, I still see the old site no matter how many times I flush browser caches or DNS caches on our workstations. I've tried multiple browsers and even brought in a laptop that has never been on the network before, just to make sure it wasn't a problem with the workstations caching something.
Having ruled that out, I checked our router, a Sonicwall TZ 170. I'm normally pretty confident with routers (I always seem to be the friend who gets the phone calls in the middle of the night when somebody's net connection has crapped out) although I don't know much about the setup of our VPN, etc. I noticed that the first DNS server was set to point internally to our server (192.168.1.2), which seemed odd to me. The other two DNS servers were 4.2.2.2 and 4.2.2.1, which seemed normal enough.
Some Googling turned up this tangentially-related question, where a commenter noted that "All DC's should have the primary DNS entry pointing to themselves. A lot of the functionality of Active Directory is based on DNS..." so I figured, OK, it's not an error, let me take a look at the server.
At this point my knowledge peters out. We use Small Business Server 2003, and I got as far as looking at the properties of the server in dnsmgmt. "Interfaces" is set to "Only the following IP addresses: 192.168.1.2"; Forwarders is set to "All other DNS domains" and 4.2.2.2 & 192.168.1.1. I don't really understand why it would be set to try an outside nameserver and then try the router second; wouldn't the router just tell it to circle back around to the server? Does this even have anything to do with anything??
Sorry if this is very wordy. I wanted to try and cover all the bases and show y'all what I've tried (as well as expose how rudimentary my actually skills are on the topic!). One last thing; I've got a text file of some tracert results from my laptop that's connected to the office network via the VPN:
As a final add-on to my question: anybody got any advice on good books/resources to learn about the workings of Small Business Server, Active Directory and the merry world of Windows networking that are good for laypeople who need to do more than have their hands held while using a Wizard?
I work for a nonprofit. We don't have an IT guy; just me, a talentedish amateur who's now trying to troubleshoot DNS caching. I am the quote-unquote administrator of the network, which means I know how to add users to Active Directory, restart the server when it's acting flakey, and Google the right search terms when things go awry.
We switched web hosts on Monday night and a rudimentary check tells me that the DNS changes propagated all over creation within a day or three. But when I'm at work, I still see the old site no matter how many times I flush browser caches or DNS caches on our workstations. I've tried multiple browsers and even brought in a laptop that has never been on the network before, just to make sure it wasn't a problem with the workstations caching something.
Having ruled that out, I checked our router, a Sonicwall TZ 170. I'm normally pretty confident with routers (I always seem to be the friend who gets the phone calls in the middle of the night when somebody's net connection has crapped out) although I don't know much about the setup of our VPN, etc. I noticed that the first DNS server was set to point internally to our server (192.168.1.2), which seemed odd to me. The other two DNS servers were 4.2.2.2 and 4.2.2.1, which seemed normal enough.
Some Googling turned up this tangentially-related question, where a commenter noted that "All DC's should have the primary DNS entry pointing to themselves. A lot of the functionality of Active Directory is based on DNS..." so I figured, OK, it's not an error, let me take a look at the server.
At this point my knowledge peters out. We use Small Business Server 2003, and I got as far as looking at the properties of the server in dnsmgmt. "Interfaces" is set to "Only the following IP addresses: 192.168.1.2"; Forwarders is set to "All other DNS domains" and 4.2.2.2 & 192.168.1.1. I don't really understand why it would be set to try an outside nameserver and then try the router second; wouldn't the router just tell it to circle back around to the server? Does this even have anything to do with anything??
Sorry if this is very wordy. I wanted to try and cover all the bases and show y'all what I've tried (as well as expose how rudimentary my actually skills are on the topic!). One last thing; I've got a text file of some tracert results from my laptop that's connected to the office network via the VPN:
1 1 ms 1 ms 1 ms c-24-62-154-34.hsd1.nh.comcast.net [24.62.154.34]Anyway, that's all I've got. Any advice appreciated. I understand that DNS changes take a while to propagate, but five days seems a bit excessive--plus I'll probably be in trouble at work on Monday if the bosses are still seeing our old website!
2 26 ms 21 ms 7 ms c-3-0-ubr01.concord.nh.boston.comcast.net [73.165.206.1]
3 10 ms 9 ms 13 ms ge-2-37-ur01.concord.nh.boston.comcast.net [68.87.148.193]
4 10 ms 10 ms 10 ms 10g-8-1-ur01.deering.nh.boston.comcast.net [68.87.145.69]
5 10 ms 23 ms 10 ms 10g-9-4-ur01.manchester.nh.boston.comcast.net [68.87.145.81]
6 11 ms 11 ms 13 ms 10g-9-1-ur01.nashua.nh.boston.comcast.net [68.87.145.117]
7 10 ms 14 ms 11 ms te-9-2-ur01.lowell.ma.boston.comcast.net [68.87.144.161]
8 10 ms 12 ms 11 ms 10g-9-4-ar01.needham.ma.boston.comcast.net [68.87.144.157]
9 12 ms 12 ms 14 ms 12.116.130.173
10 20 ms 25 ms 22 ms br2-a350s3.cb1ma.ip.att.net [12.127.5.26]
11 23 ms 19 ms 19 ms tbr2-cl16.n54ny.ip.att.net [12.122.10.22]
12 19 ms 17 ms 19 ms ggr1-p320.n54ny.ip.att.net [12.123.0.85]
13 20 ms 18 ms 20 ms p14-0.ir1.nyc-ny.us.xo.net [206.111.13.33]
14 19 ms 20 ms 19 ms p5-0-0.RAR2.NYC-NY.us.xo.net [65.106.3.41]
15 25 ms 23 ms 26 ms p6-0-0.RAR1.Washington-DC.us.xo.net [65.106.0.2]
16 92 ms 93 ms 106 ms p1-0-0.RAR1.SanJose-CA.us.xo.net [65.106.0.38]
17 91 ms 91 ms 93 ms p0-0-0d0.RAR2.SanJose-CA.us.xo.net [65.106.1.62]
18 96 ms 94 ms 94 ms p15-0.DCR1.DC-Fremont-CA.us.xo.net [65.106.2.154]
19 123 ms 99 ms 94 ms 205.158.60.166.ptr.us.xo.net [205.158.60.166]
20 91 ms 91 ms 95 ms dsr1.dc-fremont-ca.us.xo.net [205.158.60.229]
21 leander.cnchost.com [207.155.252.112] reports: Destination net unreachable.
Trace complete.
As a final add-on to my question: anybody got any advice on good books/resources to learn about the workings of Small Business Server, Active Directory and the merry world of Windows networking that are good for laypeople who need to do more than have their hands held while using a Wizard?
Best answer: Have you flushed your DNS cache for the server itself? The server is probably acting as the DNS server for the office as a whole, but it has to look upstream when it receives a request its unaware of.
Sometimes, when you make a sudden change, or due to weird circumstances, the server won't refresh an existing cache entry properly.
Try this:
A. To clear the DNS cache, perform the following steps:
1. Start the Microsoft Management Console (MMC) DNS snap-in (Go to Start, Programs, Administrative Tools, and click DNS).
2. From the View menu, select Advanced.
3. Select and right-click the Cached Lookups tree node from the left-hand pane.
4. Select Clear Cache from the context menu.
You can also use the Dnscmd command in Windows Server 2003 to clear the cache. From the command prompt, type
dnscmd /clearcache
Also, try setting an individual workstation's DNS server (through TCP/IP properties; you'll also need to configure gateway and subnet) to a higher upstream IP address, or one of a completely different machine. Cox, for instance is 68.3.16.25, or my server: 67.19.162.162. If you can get out to the new site through that, then you know it has to do with your server's stale DNS entries. Reset it back to the server (or "obtain automatically") and if the flush command worked properly on the server, you should be alright.
posted by disillusioned at 12:18 PM on February 3, 2007
Sometimes, when you make a sudden change, or due to weird circumstances, the server won't refresh an existing cache entry properly.
Try this:
A. To clear the DNS cache, perform the following steps:
1. Start the Microsoft Management Console (MMC) DNS snap-in (Go to Start, Programs, Administrative Tools, and click DNS).
2. From the View menu, select Advanced.
3. Select and right-click the Cached Lookups tree node from the left-hand pane.
4. Select Clear Cache from the context menu.
You can also use the Dnscmd command in Windows Server 2003 to clear the cache. From the command prompt, type
dnscmd /clearcache
Also, try setting an individual workstation's DNS server (through TCP/IP properties; you'll also need to configure gateway and subnet) to a higher upstream IP address, or one of a completely different machine. Cox, for instance is 68.3.16.25, or my server: 67.19.162.162. If you can get out to the new site through that, then you know it has to do with your server's stale DNS entries. Reset it back to the server (or "obtain automatically") and if the flush command worked properly on the server, you should be alright.
posted by disillusioned at 12:18 PM on February 3, 2007
Response by poster: Disillusioned: that was it! i was a little afraid to fiddle with anything else in the DNS snap-in for fear of mucking things up.
I Googled every combination of "clear" "dns" "cache" and "small business server" I could think of but never found anything resembling your simple steps.
posted by bcwinters at 12:38 PM on February 3, 2007
I Googled every combination of "clear" "dns" "cache" and "small business server" I could think of but never found anything resembling your simple steps.
posted by bcwinters at 12:38 PM on February 3, 2007
Response by poster: And by "that was it" I mean simply clearing the DNS cache on the server correctly (I had tried clearing it with ipconfig the way you might on a desktop, which obviously didn't do anything).
posted by bcwinters at 12:40 PM on February 3, 2007
posted by bcwinters at 12:40 PM on February 3, 2007
Response by poster: I take it back; my VPN connection had disconnected when the site loaded correctly, so it was using my home settings rather than office settings. When I reconnected to the VPN, I started getting the old site again.
Setting the Sonicwall Virtual Adapter's TCP/IP properties to use your DNS server for some bizarre reason makes it impossible for me to load either version of the site. I get "server not found" errors, although other sites seem to load fine. Cox's DNS server won't work at all--errors across the board. I tried OpenDNS's servers, too, and curiously enough I got the OLD site.
Any other ideas? I appreciate the help so far.
posted by bcwinters at 1:35 PM on February 3, 2007
Setting the Sonicwall Virtual Adapter's TCP/IP properties to use your DNS server for some bizarre reason makes it impossible for me to load either version of the site. I get "server not found" errors, although other sites seem to load fine. Cox's DNS server won't work at all--errors across the board. I tried OpenDNS's servers, too, and curiously enough I got the OLD site.
Any other ideas? I appreciate the help so far.
posted by bcwinters at 1:35 PM on February 3, 2007
Oops! I've been writing up a long response, because you said it was fixed... but now it's not fixed! I'll go ahead and post this, but it's written with the idea that the cache flush fixed the problem, which it didn't. It's still useful information if you have to work with DNS, so I'll go ahead and put it up. I'll get back to helping you troubleshoot in the next post.
**************************************
Note that you can possibly avoid this problem in the future by shortening your 'time to live' in DNS.
The TTL field in DNS means 'how long this record is good'. Most networks have caching DNS servers, and they remember old results for as long as they're still valid. This is the problem you just had; your local server was told that the records were good for, say, a week. For that whole week, it would just return the cached result, without ever checking the master server. The only way to fix this locally is by clearing the DNS cache and/or restarting the service. You are probably not the only person with this problem; anyone else who looked up your website before the change took place probably won't be able to see it either. This is bad. You've made a change, but people who have interacted with you recently (the people you really care about) don't know!
If you are planning a major change, it's a good idea to shorten your DNS TTL a great deal. I generally drop it to 1 minute or so. DNS is a very lightweight protocol, and a modern server can take a hellacious load.
The routine TTL value, what you use in regular times when you're not expecting a change, can be looked at as 'how long it is until I can make a major change'. If your timeout is set to six hours, then at any given time, some percentage of the machines on the net won't notice a change for that long. So you have to change your TTL value to something short, and then wait the original timeout period to be sure that every machine on the Net is now synced up with you and using your short timeout. Then you make your change, perhaps several changes if you didn't get it right the first time. At most, any given network will experience an outage for a minute or two, which is usually acceptable. Once you're happy with the results, you lengthen the TTL time back to your usual value.
I use a routine timeout value of 1 hour. If you have a very busy site, you may want to go longer, say to 6 or 12 hours. That number is how long you're guaranteeing the results will be good for... which means you'll have to wait that long to safely make changes. You're balancing your ability to adjust against the load on your server and network.... but since DNS is so trivial, servers are so fast, and bandwidth is so cheap, you can now opt for very short values without strain. The week timeouts were much more useful in the era of 486-class servers on dialup-grade lines.
posted by Malor at 1:44 PM on February 3, 2007
**************************************
Note that you can possibly avoid this problem in the future by shortening your 'time to live' in DNS.
The TTL field in DNS means 'how long this record is good'. Most networks have caching DNS servers, and they remember old results for as long as they're still valid. This is the problem you just had; your local server was told that the records were good for, say, a week. For that whole week, it would just return the cached result, without ever checking the master server. The only way to fix this locally is by clearing the DNS cache and/or restarting the service. You are probably not the only person with this problem; anyone else who looked up your website before the change took place probably won't be able to see it either. This is bad. You've made a change, but people who have interacted with you recently (the people you really care about) don't know!
If you are planning a major change, it's a good idea to shorten your DNS TTL a great deal. I generally drop it to 1 minute or so. DNS is a very lightweight protocol, and a modern server can take a hellacious load.
The routine TTL value, what you use in regular times when you're not expecting a change, can be looked at as 'how long it is until I can make a major change'. If your timeout is set to six hours, then at any given time, some percentage of the machines on the net won't notice a change for that long. So you have to change your TTL value to something short, and then wait the original timeout period to be sure that every machine on the Net is now synced up with you and using your short timeout. Then you make your change, perhaps several changes if you didn't get it right the first time. At most, any given network will experience an outage for a minute or two, which is usually acceptable. Once you're happy with the results, you lengthen the TTL time back to your usual value.
I use a routine timeout value of 1 hour. If you have a very busy site, you may want to go longer, say to 6 or 12 hours. That number is how long you're guaranteeing the results will be good for... which means you'll have to wait that long to safely make changes. You're balancing your ability to adjust against the load on your server and network.... but since DNS is so trivial, servers are so fast, and bandwidth is so cheap, you can now opt for very short values without strain. The week timeouts were much more useful in the era of 486-class servers on dialup-grade lines.
posted by Malor at 1:44 PM on February 3, 2007
Best answer: Ok, so the problem is that you can't see your website from the work network, but you can everywhere else. That probably means that your work DNS server believes it is authoritative for that zone, and it has the old address in its zone file. If you're using the exact same domain name for your internal Active Directory domain and the website, that's absolutely the problem.
If that's the case, you need to configure your work DNS server (which is usually your Active Directory server unless you have a weird setup) with the new website address. Your server believes it's the final word for domain.com, and it doesn't ask anyone else for info. You can change the rest of the world all you like, and it's going to stubbornly keep saying that the website is at the old address. It's in charge of domain.com, darn it, and it's not gonna ask for other opinions. :)
posted by Malor at 1:48 PM on February 3, 2007
If that's the case, you need to configure your work DNS server (which is usually your Active Directory server unless you have a weird setup) with the new website address. Your server believes it's the final word for domain.com, and it doesn't ask anyone else for info. You can change the rest of the world all you like, and it's going to stubbornly keep saying that the website is at the old address. It's in charge of domain.com, darn it, and it's not gonna ask for other opinions. :)
posted by Malor at 1:48 PM on February 3, 2007
Response by poster: Malor: sorry for the confusion there. That's what I get for trying to fix things at work while sitting at home in my PJs.
Our server is supposed to be mail.domain.org, while the website is www.domain.org and just plain domain.org. You were right that internally it thinks it's authoritative for domain.org--in hindsight I've seen all sorts of things like server01.domain.org and laptop01.domain.org.
I just opened up the DNS settings on the server and poked around; sure enough, the old IP address was specified for www in the Forward Lookup Zones. I changed it to the new IP address, and it seems to be working now! I assume this means that http://domain.org won't work from inside our network, which is fine as long as nobody ever wants to go all Daring Fireball on the www prefix.
(The TTL was set to 1 hour, by the way, and I appreciate your explanation of that whole part of things. I like it when technical terms can be be explained in normal human language.)
Thanks muchly to everybody. Hopefully the issue is now settled, assuming I haven't broken anything else in the process.
posted by bcwinters at 2:12 PM on February 3, 2007
Our server is supposed to be mail.domain.org, while the website is www.domain.org and just plain domain.org. You were right that internally it thinks it's authoritative for domain.org--in hindsight I've seen all sorts of things like server01.domain.org and laptop01.domain.org.
I just opened up the DNS settings on the server and poked around; sure enough, the old IP address was specified for www in the Forward Lookup Zones. I changed it to the new IP address, and it seems to be working now! I assume this means that http://domain.org won't work from inside our network, which is fine as long as nobody ever wants to go all Daring Fireball on the www prefix.
(The TTL was set to 1 hour, by the way, and I appreciate your explanation of that whole part of things. I like it when technical terms can be be explained in normal human language.)
Thanks muchly to everybody. Hopefully the issue is now settled, assuming I haven't broken anything else in the process.
posted by bcwinters at 2:12 PM on February 3, 2007
This kind of thing is exactly why all my non-Internet-visible Windows networks are set up in subdomains of a non-IANA-assigned ".local" TLD, for which the appropriate domain controller is the only possible authoritative source of IP addresses.
It seems to me that deliberately assigning different IP addresses to identical DNS names depending on whether you're inside or outside your local NAT gateway is just asking for trouble.
If you're accessing an externally-accessible web server from inside your own LAN, and you're doing that via its externally-visible DNS address, it seems to me you should also be doing that via its externally-exposed IP address just like the rest of the world would.
posted by flabdablet at 3:38 PM on February 3, 2007
It seems to me that deliberately assigning different IP addresses to identical DNS names depending on whether you're inside or outside your local NAT gateway is just asking for trouble.
If you're accessing an externally-accessible web server from inside your own LAN, and you're doing that via its externally-visible DNS address, it seems to me you should also be doing that via its externally-exposed IP address just like the rest of the world would.
posted by flabdablet at 3:38 PM on February 3, 2007
Another way to do that is to make a subdomain of your master domain name; that is, you're example.com, and the machines in the NAT network are all in local.example.com. That can let you comfortably make external addresses automatically available to inside machines without conflicts.
As far as getting 'domain.org' pointed at www... I'm not very familiar with Windows DNS, but in Unix, you can just make lines that say:
IN A example.com. 50.50.50.50
IN A www.example.com. 50.50.50.50.
(the trailing period is important in Unix, but probably isn't in Windows.) This makes INternet Addresses for both example.com and www.example.com, aimed at the external address. I'm not sure whether that will affect the Active Directory server, though. It might possibly think that example.com is supposed to be itself. (I don't have an AD machine handy to check, as I never, ever run DNS on Windows.)
Before you make that change, try looking up example.com to see what you get. If it comes back with nothing, just list it and you should be good. If it returns the AD server itself, you might not want to do that.
If you're running a webserver on that host as well, you could just put in an HTTP redirect to www.example.com. That would be a very low-impact way of pointing internal users at the right place.
posted by Malor at 6:04 PM on February 3, 2007
As far as getting 'domain.org' pointed at www... I'm not very familiar with Windows DNS, but in Unix, you can just make lines that say:
IN A example.com. 50.50.50.50
IN A www.example.com. 50.50.50.50.
(the trailing period is important in Unix, but probably isn't in Windows.) This makes INternet Addresses for both example.com and www.example.com, aimed at the external address. I'm not sure whether that will affect the Active Directory server, though. It might possibly think that example.com is supposed to be itself. (I don't have an AD machine handy to check, as I never, ever run DNS on Windows.)
Before you make that change, try looking up example.com to see what you get. If it comes back with nothing, just list it and you should be good. If it returns the AD server itself, you might not want to do that.
If you're running a webserver on that host as well, you could just put in an HTTP redirect to www.example.com. That would be a very low-impact way of pointing internal users at the right place.
posted by Malor at 6:04 PM on February 3, 2007
Heh, after reading your link... in essence, that would be Daring Fireball in reverse. :)
posted by Malor at 6:08 PM on February 3, 2007
posted by Malor at 6:08 PM on February 3, 2007
Boy, that'll teach me to do these things from memory. I got my syntax confused. Ignore those lines completely. They should be:
The trailing periods after 'com' are absolutely crucial in Unix DNS. It means 'the DNS root', which anchors example.com to the root of all DNS. If you forget the period, you end up with example.com.example.com. Sans period, Unix BIND assumes it's a relative address in the current domain, rather than an absolute listing.
If you have weird troubles like that in Windows, try that trailing period after com. But I suspect you probably don't need it.
posted by Malor at 6:16 PM on February 3, 2007
example.com. IN A 50.50.50.50
www.example.com. IN A 50.50.50.50The trailing periods after 'com' are absolutely crucial in Unix DNS. It means 'the DNS root', which anchors example.com to the root of all DNS. If you forget the period, you end up with example.com.example.com. Sans period, Unix BIND assumes it's a relative address in the current domain, rather than an absolute listing.
If you have weird troubles like that in Windows, try that trailing period after com. But I suspect you probably don't need it.
posted by Malor at 6:16 PM on February 3, 2007
At work I also use Small Business Server 2003, for 3 years now. Before you go changing things please remember that SBS2003 is not the same as stand alone win server 2003 or exchange. It has server 2003, exchange, AD and more connected with a series of tubes, i mean wizards. Now the leet types hearing this will say i don't need no stinking wizards, but for sbs 2003 they are so wrong.
So when you change things be sure to re-run the related wizard, Then tweak things if you need to (write down your changes to prevent wizard erasure next time you run them)
My number one source of correct help info for sbs3003 is the microsoft.public.windows.server.sbs news group, I use Google groups to search and it even has helpfull microsoft people (weekdays only, heh).
Also the technet site for sbs and the private (non ms corp) here (scroll down to the SBS people)
Now i know i did not directly answer your question but that is because there are a number of variables that will totally change what is going on with your install. For example depending on where on the network your router is in relation to the server and users will change what does dns/dhcp(and what interferes with DNS/dhcp). My set up is net>modem>firewall router>ouside nic>server>inside nic> hub(router)>users. Your's may be different, a server with one nic for example (2 is mo better).
DNS query
Getting Started Guide
Short non answer is every sbs problem i have had was solved with that news group (play with your search phrases).
Hope that helps, if i knew more details i could dig a little farther.
Luck to you.
posted by blink_left at 7:42 PM on February 3, 2007
So when you change things be sure to re-run the related wizard, Then tweak things if you need to (write down your changes to prevent wizard erasure next time you run them)
My number one source of correct help info for sbs3003 is the microsoft.public.windows.server.sbs news group, I use Google groups to search and it even has helpfull microsoft people (weekdays only, heh).
Also the technet site for sbs and the private (non ms corp) here (scroll down to the SBS people)
Now i know i did not directly answer your question but that is because there are a number of variables that will totally change what is going on with your install. For example depending on where on the network your router is in relation to the server and users will change what does dns/dhcp(and what interferes with DNS/dhcp). My set up is net>modem>firewall router>ouside nic>server>inside nic> hub(router)>users. Your's may be different, a server with one nic for example (2 is mo better).
DNS query
Getting Started Guide
Short non answer is every sbs problem i have had was solved with that news group (play with your search phrases).
Hope that helps, if i knew more details i could dig a little farther.
Luck to you.
posted by blink_left at 7:42 PM on February 3, 2007
All that said...
Do you get the New site/host if you use the new site ip address ? like 123.123.0.123
And the old site using the old ip? yes/no Clue!
If yes you might have tho old site ip hard set in a zone file as Malor mentioned.
You changed "web site" host but not internet service (dsl, cable,etc) in the office right?
If you have no joy by Monday i will poke my setup and gather more clues.
I do my best to forget work on the weekends.
posted by blink_left at 8:26 PM on February 3, 2007
Do you get the New site/host if you use the new site ip address ? like 123.123.0.123
And the old site using the old ip? yes/no Clue!
If yes you might have tho old site ip hard set in a zone file as Malor mentioned.
You changed "web site" host but not internet service (dsl, cable,etc) in the office right?
If you have no joy by Monday i will poke my setup and gather more clues.
I do my best to forget work on the weekends.
posted by blink_left at 8:26 PM on February 3, 2007
Response by poster: Thanks for the additional tips, folks. I'm definitely planning on mapping out whether our whole setup is the best way to do things and I'll keep all this stuff in mind before I make changes. There are so many variables to keep track of.
blink_left, don't lost any sleep on my behalf--it's working now!
posted by bcwinters at 8:55 AM on February 4, 2007
blink_left, don't lost any sleep on my behalf--it's working now!
posted by bcwinters at 8:55 AM on February 4, 2007
This thread is closed to new comments.
I was using a 'regional' web host (regional meaning they were marketing to local customers), when I switched hosts, it worked fine everywhere but on the network of the largest ISP in the area. I called my former host and told them the problem, and they said they had nothing to do with it. I waited for a couple more days, and then called back and talked to a manager. The manager knew right away that they were guilty and was able to fix it promptly. Previously I didn't know of any affiliation between the host and the ISP, but there must have been some infrastructure sharing or something.
Not sure if this is helpful, but worth a shot.
posted by nazca at 11:19 AM on February 3, 2007