http://companyweb/ - Major problems at a business ...

thecomputerguy

Well-Known Member
Reaction score
1,427
So a local business had a ATT "tech" come out to install UVerse. I dont know why the tech went beyond getting the interner working and leaving but basically he removed the old router to put the Uverse in place of the current modem/router.

Of course this royally F'd everything up beacuse the previous router had specific ports open for rdp, used a different local addressing scheme, and ended up bringing the whole network down. The only thing working when he left was the internet, connectivity to the server had been lost. This guy was there for 6 hours and left it like that.

I came in and was able to get everything working by switching the new router over to assigning 192.168.0.XXX instead of 192.168.1.XXX - I popped the old router into place and transferred the port settings to the new router. Got the local, internet, and rdp working.

Problem is they use Server 2008 SBS which has a feature built into it I am not familliar with. You can use " http://companyweb/ " as a means to share data. That is something that is still not working, and I really don't even know where to start with this. I think it may have something to do with exchange ... any help?
 
Problem is they use Server 2008 SBS which has a feature built into it I am not familliar with. You can use " http://companyweb/ " as a means to share data. That is something that is still not working, and I really don't even know where to start with this. I think it may have something to do with exchange ... any help?


You probably just need to set up the server to handle dhcp/dns. Sounds like the router is doing that now.
 
Companyweb is an intranet site hosted by SBS's IIS server. It is part of Sharepoint.

if companyweb was working then it's likely that the server was already doing DNS and probably DHCP too until that guy messed with the router. You'll need to check. If it wasn't then it should be - especially DNS.
 
So a local business had a ATT "tech" come out to install UVerse. I dont know why the tech went beyond getting the interner working and leaving but basically he removed the old router to put the Uverse in place of the current modem/router.

Of course this royally F'd everything up beacuse the previous router had specific ports open for rdp, used a different local addressing scheme, and ended up bringing the whole network down. The only thing working when he left was the internet, connectivity to the server had been lost. This guy was there for 6 hours and left it like that.

I came in and was able to get everything working by switching the new router over to assigning 192.168.0.XXX instead of 192.168.1.XXX - I popped the old router into place and transferred the port settings to the new router. Got the local, internet, and rdp working.

Problem is they use Server 2008 SBS which has a feature built into it I am not familliar with. You can use " http://companyweb/ " as a means to share data. That is something that is still not working, and I really don't even know where to start with this. I think it may have something to do with exchange ... any help?



Why do you blame the tech for any of this? It is NOT his fault. He is NOT responsible for the workings of their network only the ATT router & access to the Internet.

If it was setup right to begin with the SBS 2008 server would be doing DNS and DHCP. He would have set it to the previous IP of the Default Gateway IP address and that would have been it; everything would still be working.

If the other one was running DHCP, it is not his responsibility to set it to give out the same IP addresses or even use the same range.

********

What version of Sharepoint is it? Sounds like an internal IP problem more than anything. If DNS can resolve COMPANYWEB to an A record pointed to Sharepoint, it should be fine.
 
Why do you blame the tech for any of this? It is NOT his fault. He is NOT responsible for the workings of their network only the ATT router & access to the Internet.

If it was setup right to begin with the SBS 2008 server would be doing DNS and DHCP. He would have set it to the previous IP of the Default Gateway IP address and that would have been it; everything would still be working.

If the other one was running DHCP, it is not his responsibility to set it to give out the same IP addresses or even use the same range.

********

What version of Sharepoint is it? Sounds like an internal IP problem more than anything. If DNS can resolve COMPANYWEB to an A record pointed to Sharepoint, it should be fine.

He was working on their server, and probably disabled dhcp and dns on the server. A new line had to be run for the UVerse to work and the old line was still adtive (supposedly) when he left. He should have got the internet working on the UVerse box and told them their tech needed to take it from here.

They aren't supposed to touch anything, because stuff like this happens.

Sad part is, this company is on bad terms with their tech which is why I was called out so I am knee deep in learning right now.
 
Companyweb is an intranet site hosted by SBS's IIS server. It is part of Sharepoint.

if companyweb was working then it's likely that the server was already doing DNS and probably DHCP too until that guy messed with the router. You'll need to check. If it wasn't then it should be - especially DNS.

No, they should run both Microsoft DNS & DHCP, so they can setup internal Dynamic DNS where when DHCP gives out an IP lease it automatically registers that record with DNS, and ALL the computers can find it. <== This is how it is supposed to work on a healthy network.

The type should be Active-Directory-Integrated.
DNS Zone Replication Scope should be setup to all DNS servers running on domain controllers in the domain (without Windows 2000 compatibility) <==Windows 2000 shoudl NOT be running.
Dynamic updates should be: Secure Only
Aging should be setup to do scavenging of stale records!

The name servers tab should have ALL the DNS servers listed.

Start of Authority should be left alone... the first DNS server is fine.

Zone Transfers should be setup to "Allow zone transfers" but "Only to the servers listed on the Name Servers tab." <== For security reasons.

You will WANT to setup the Forwarders to forward to your Internet ISP's DNS servers for any queries this server cannot resolve. (you do this directly on the Server node). Make sure to check the box to "Use root hints if no forwarders are available."

You NEED to turn on the box that says "Enable automatic scavenging of stale records" or the server will not trim it's zones even if they are setup to scavenge.

*******

Under Reverse Lookup zones, you had better have a 1.168.192.in-addr.arpa or 0.168.192.in-addr.arpa

If not created, just go to create a new zone and specify 192.168.1 for the Network ID & it will automatically make the reverse lookup zone name.

To TEST reverse dns, you can execute "ipconfig /registerdns"

Then you can check the DNS console and verify that comptuer was added.

From another computer, you should be able to do nslookup 192.168.1.55 (or whatever) and it should lookup the name (reverse lookup) in addition to forward lookup.



^^^^^^^^^^^^ This will get Active Directory on its feet and probably the sharepoint site, too.
 
He was working on their server, and probably disabled dhcp and dns on the server. A new line had to be run for the UVerse to work and the old line was still adtive (supposedly) when he left. He should have got the internet working on the UVerse box and told them their tech needed to take it from here.

They aren't supposed to touch anything, because stuff like this happens.

Sad part is, this company is on bad terms with their tech which is why I was called out so I am knee deep in learning right now.

If he touched the SBS 2008 server and turned off DNS & DHCP... and then put in the router... then yeah, he blew up the entire network. (without doubt)

***

Thecomptuerguy said:
I came in and was able to get everything working by switching the new router over to assigning 192.168.0.XXX instead of 192.168.1.XXX

This is probably why Sharepoint won't work.


I would logon to the SBS server and look at DHCP and DNS & figure out EXACTLY how it was setup before i.e. names/IPs... <== If they are not installed, install it (the zone files should still be around; thank God!)...

Hopefully, if it was all setup right before he can just set the Default Gateway on the new router to match than on the Old Router & Disable DHCP on the new router.

He can then point the forwarders (for the SBS 2008 DNS server) at the ISP's DNS servers or at his Router (if it does DNS, which would be forwarded to the ISP)...

Either way, if he gets them on the same scheme they were on before everything should work as before without reconfiguration. SharePoint is always a PITA about this kind of stuff too. Often they will bind IIS to not just a port but an IP causing a problem like this. :D
 
If he touched the SBS 2008 server and turned off DNS & DHCP... and then put in the router... then yeah, he blew up the entire network. (without doubt)

***

Thecomptuerguy said:


This is probably why Sharepoint won't work.


I would logon to the SBS server and look at DHCP and DNS & figure out EXACTLY how it was setup before i.e. names/IPs... <== If they are not installed, install it (the zone files should still be around; thank God!)...

Hopefully, if it was all setup right before he can just set the Default Gateway on the new router to match than on the Old Router & Disable DHCP on the new router.

He can then point the forwarders (for the SBS 2008 DNS server) at the ISP's DNS servers or at his Router (if it does DNS, which would be forwarded to the ISP)...

Either way, if he gets them on the same scheme they were on before everything should work as before without reconfiguration. SharePoint is always a PITA about this kind of stuff too. Often they will bind IIS to not just a port but an IP causing a problem like this. :D

This all sounds pretty much like what the problem probably is ... unfortunately netwizz I think you are at a whole nother level than I am when it comes to this type of setup. I may have to back out of this one and just charge for what I have done to get them working with the server and getting rdp up again.

Either way im in for a lot of research.

I've never had someone teach me what is required to solve this problem.
 
This all sounds pretty much like what the problem probably is ... unfortunately netwizz I think you are at a whole nother level than I am when it comes to this type of setup. I may have to back out of this one and just charge for what I have done to get them working with the server and getting rdp up again.

Either way im in for a lot of research.

I've never had someone teach me what is required to solve this problem.

Let me rephrase that ... I have never taken the time to learn.
 
Let me rephrase that ... I have never taken the time to learn.

PM me a time/zone & Tel#. I will be happy to call you at a time of your choosing (outside my working hours) and walk you through all of it. It is funny how once you do it one time, it will be easy... I really WISH you were in my area... I would just show you how my network is configured and go into one of our lab rooms with 20 computers and it's own IDF switch (for custom configurations/ scenarios) & bring a few servers... and setup EVERYTHING together.
 
I don't know what you're saying "no" to?

I am not sure what I was saying no too... Probably just saying DNS will not work alone with the DHCP from the ATT UVerse because the UVerse cannot update the DNS resource records.

Hence, I was saying the proper procedure is to run both DHCP & DNS from Active Directory. It's the only way to manage large numbers of computers dynamically.

****************************

Anyway, we were able to work out the network problems.
 
It's whoever originally set up the networks' fault. Should have known better not to set up the network on the back of a ISP router like that.

They should have at least had a separate router handling the network, and the ISP's device plugged into that.
 
It's whoever originally set up the networks' fault. Should have known better not to set up the network on the back of a ISP router like that.

They should have at least had a separate router handling the network, and the ISP's device plugged into that.

Exactly... and the ATT guy should have known enough NOT to touch the Windows Server he knew nothing about.
 
Back
Top